Ich persönlich empfinde die Möglichkeit eine Aufgabe von einem Kollegen weiterentwickeln zu lassen, als sehr angenehm. Nicht selten sind die Arbeiten zeitkritisch und müssen innerhalb weniger Tage abgeschlossen werden. Im Alltag ist mir jedoch immer wieder aufgefallen, dass man dazu neigt sich nicht nur auf eine Teilaufgaben zu konzentrieren. Oft kommt Eines zum Anderen und man hat plötzlich einige offene Baustellen in der Software, die man versucht bis zum Fertigstellungstermin zu schließen. In vielen Fällen klappt es auch, wenn nichts dazwischen kommt. Und genau darum geht es mir. Meiner Erfahrung nach, kommt immer wieder mal etwas dazwischen. Die Arbeit kann dann nicht planmäßig beendet werden. Die Gründe dafür können so vielfältig sein, dass keine Liste der Welt vollständig wäre.
Damit der Kollege die Arbeit jedoch möglichst nahtlos weiterführen kann, muss er den aktuellen Stand der Entwicklung kennen. Welche Teilaufgaben sind bereits erledigt, wo muss weitergearbeitet werden? Sind zu viele Baustellen vorhanden oder die funktionalen Anpassungen an der Software nicht gut nachzuvollziehen, fällt es schwer den aktuellen Stand schnell zu erfassen. Die Arbeiten stehen dann zunächst still, bis der Kollege auf den gleichen Wissensstand ist wie ich war, als ich die Arbeit liegen gelassen habe.
Wenn man die Kollegen direkt neben sich sitzen hat, dann kommt es hin und wieder zu einem Austausch. Sei es, weil man Fragen zu Implementierungsdetails hat oder man regelmäßige Code Reviews durchführt oder man gar Pair-Programming macht. Dadurch haben die Kollegen wenigstens eine Vorstellung von dem aktuellen Stand. Wenn man jedoch in einem verteilten Team arbeitet, verschärft sich die Situation deutlich. Aufgrund der Distanz arbeitet man eher selten so eng zusammen, dass die Kollegen über den aktuellen Stand informiert sind. Sie haben meistens erst dann Berührung mit der Materie, wenn ihnen die Aufgabe zugewiesen wird.
Für mich habe ich daher immer folgende Punkte als minimalen Leitfaden im Hinterkopf:
- Organisatorisch
- Schneide die einzelnen Aufgaben in möglichst kleine Teilaufgaben.
- Dokumentiere Erkenntnisse im Ticketsystem, Wiki, VCS usw..
- UML Diagramme zu eigenen Zwecken.
- Fachlich interessante SQL Statements.
- Fotos vom Whiteboard oder Flipchart.
- Software
- Führe spätestens nach jeder Teilaufgabe einen Commit im VCS aus.
- Baue die Software vor dem Commit mit allen Tests erfolgreich durch.
- Verlasse den Arbeitsplatz nicht mit Quelltext, der nicht in das VCS eingespielt ist.
Wenn ich mich mit anderen Software Entwicklern über diese Punkte unterhalte, dann bilden sich häufig zwei Fraktionen. Die Einen machen es immer so und empfinden diese Punkte als selbstverständlich oder sogar unzureichend, die Anderen machen es auf gar keinen Fall so und empfinden es als zu aufwendig. Den Ersteren muss ich sagen, dass die guten Vorsätze im Entwickleralltag gerne mal vergessen werden. Und die Letzteren machen sich, meiner Meinung nach, das Leben unnötig schwer. Und mir damit auch!
Keine Kommentare:
Kommentar veröffentlichen