Tech Talk: “Das effiziente DevTeam” mit Hannes Gerstlbauer

Tech Talk: “Das effiziente DevTeam” mit Hannes Gerstlbauer

Finde heraus, was bei der Leitung eines Entwicklungsteams besonders wichtig ist und wie du die Arbeit noch effizienter gestalten kannst.

Um vernünftige Software zu liefern, muss das Team organisiert sein. Jedes Team ist anders und jeder Leiter wird das Team individuell leiten. Aus Erfahrung erkennt man, dass einige Dinge wichtiger sind als andere.

Hier sind ein paar Ratschläge, die ich geben kann...

Konkretisiere, was zu tun ist

Die Leute kommen ganz normal zur Arbeit. Sie setzen – oder heutzutage „stellen“ – sich zum Computer, arbeiten ab, was verlangt ist. Dann gehen sie heim. Wenn aber die Aufgabenstellung nicht richtig formuliert ist, läuft das nicht so rund. Anstatt an einem Task zu arbeiten, geht viel Zeit daran verloren, überhaupt eine Aufgabe zu finden. Wenn nun also die Ziele nicht klar definiert sind, dann fragen die Developer herum – sofern die Softskills und die zeitliche Verfügbarkeit passen.

Dieses Konkretisieren ist auch in den etablierten Produkt- oder Projektmanagement Methoden ein wesentlicher Punkt: Beim Wasserfall Modell ist es die strukturierte Dokumentation. Bei Scrum sind es die strukturierten User Stories.

Teile auf, was teilbar ist

Jeder mag es, etwas als „done“ zu markieren. Kleine Erfolge sind wichtig, es fühlt sich viel besser an 10 kleine Aufgaben zu schaffen, als wie in der selben Zeit irgendwie vielleicht die Hälfte des einen großen Tasks zu erledigen.

Nicht nur die kleinen gefühlten Erfolge sind wichtig, auch schon nur bei der Aufteilung der Aufgaben treten zusätzlich Ideen, Fragestellungen, Anregungen, usw. auf. Die Problemstellung wird klarer definiert und die Arbeit wird organisierter.

Diese zwei Punkte sind schon einmal ein sehr guter Start. Obwohl sie nicht innerhalb einer Woche eingeführt werden können, werden sie sich auf jeden Fall bezahlt machen! Und wenn man noch weiter in die Tiefe gehen möchte…

Teste, was aus der Entwicklung kommt

Kleine, wohl definierte Tasks sind super. Trotzdem ist es auch wichtig, dass genügend getestet wird. Das Testen sollte in einer Umgebung durchgeführt werden, so wie es normalerweise von einem Nicht-Developer in der Anwendung dann auch gemacht wird.

In verschiedenen Fällen werden natürlich unterschiedlich viele Fehler gefunden, meistens werden aber immer Verbesserungen gefunden. Wird die Funktionalität von Code direkt nach erledigter Arbeit getestet, so hat dies den Vorteil, dass sich der verantwortliche Developer noch immer gut in dem geschriebenen Code zurechtfindet und sich nicht erst wieder langsam einarbeiten muss.

Messe, was alles dauert

Jeder Entwickler soll eine Vorstellung davon haben, wie viel seine Arbeit wert ist. Wenn man beginnt sich den Zeitaufwand für die Arbeit vor Augen zu führen, wird man schnell feststellen, dass womöglich nur ein paar Zeilen Code schon 2, 3, 4 Stunden dauern können. Man wird erkennen, dass Pull Requests, neue Columns in einem Table, neue Permissions anlegen, usw. alles keine „Dauer: Null“ Aktivitäten sind.

Ein Bewusstsein über die Dauer und Kosten von Arbeit lässt das Developer-Team auch genauere Zeiteinschätzungen über die Projekte und Tasks geben. Das ist nicht nur gut für’s Business, sondern auch positiv für das Team. Es ist ziemlich schlecht für die Moral im Team, wenn eine Aufgabe fälschlicherweise mit 1 Stunde eingeschätzt wird und dann tatsächlich 6 Stunden dauert.

Richtiges Einschätzen der Zeit ist hohe Schule, man kann aber noch weiter gehen…

Rückverfolgbarkeit

Bugfixes. Es ist auch wichtig zu sehen, wie viel einerseits für die erste Funktionalität aufgewendet wird, und wie viel andererseits für die Bugfixes.

So etwas wird oft durch Tools wie Jira, Azure DevOps und dergleichen gewährleistet. Nicht nur ungefähre Einschätzungen, konkrete Zahlen. Wer? Wann? Wie lange? Solche Zahlen sind wichtig, man soll sie genau dem Team präsentieren können, oft wird im Nachhinein falsch eingeschätzt, wie lange die Dinge dauern.

„In diesem Sprint haben wir 40 Stunden mit Bugfixes vom vorigen Release verwendet.

„Niemals, wir haben schon ein paar Bugs gefixt, aber doch weitaus nicht 40 Stunden!“

„Hier ist der Beweis.“

Vorschläge

Das Team arbeitet, jeder weiß genau was zu tun ist, jeder kann ungefähr die jeweiligen Arbeitsaufwände einschätzen. Läuft! Jetzt ist man auf einem Level, in dem sich das Team selbst verbessern kann.

Die in Scrum gängige Sprint Retrospektive ist hier der passende Ansatz. Es soll einen gemeinsamen Ort geben, wo Verbesserungsvorschläge eingebracht werden können. E-Mails mit einem bestimmten Betreff, ein Channel auf Slack, usw. Alle Vorschläge sollten gesammelt und gemeinsam in einem Meeting besprochen werden.

Das Team ist um Verbesserung bemüht, weiß was zu tun ist und wie es getan wird. Was nun?

Abläufe

Je mehr sich solche Vorschläge in der Scrum Retro ansammeln, um so mehr häufen sich die Dinge, die es zu berücksichtigen gibt.

Oft ist es der Fall, dass individuelle Verbesserungsvorschläge im Team zwar brav besprochen werden, aber in der Umsetzung wird es dann schwierig. Jemand ist nicht einverstanden mit einer Methode, jemand vergisst etwas Vereinbartes, oder hält sich unabsichtlich nicht an gewisse Abläufe. All dies kann ja passieren, wenn es keine großen Einschnitte in der Performance gibt, sollte man auch nicht zu viel Zeit damit verbringen die schwarzen Schafe in den Meetings zu bereden. Wenn etwas nicht gleich beim ersten Mal funktioniert, macht nichts, einfach noch einmal probieren.

Gegebenenfalls kann man so auch klare Abläufe formulieren, an die sich das Team versuchen soll zu halten.

Was als Nächstes? Versucht euch nicht zu langweilen

Die Entwickler sind zufrieden mit ihrer erledigten Arbeit. Jeder kennt sich aus was und wie es zu machen ist. An dieser Stelle sollte das Team ziemlich gut laufen. Und nun, experimentieren!

Jetzt ist es Zeit, etwas Neues auszuprobieren, sich nicht zu langweilen. Probiert eine neue Technologie oder ein neues Arbeitsschema aus. Wenn im Team kein Pair-Programming gemacht wird, probiert es aus. Wenn ihr die ganze Zeit gemeinsam arbeitet, versucht, alleine zu arbeiten. Probiert was Neues.