Verantwortung übernehmen – Das Team und weitere nützliche Rollen

Neben der generellen Übernahme von Verantwortung für den Gesamtprozess, die Selbstorganisation und die Sprint-Ergebnisse habe ich sehr gute Erfahrungen mit der Definition weiterer Rollen im Team gemacht.

So sollte möglichst jedes Teammitglied bei größeren Projekten eine ganz spezielle Rolle einnehmen und sich zusätzlich zu seinen normalen Verantwortungen um dieses eine Thema kümmern.

Sinnbildlich gesprochen bekommt jedes Teammitglied einen Hut aufgesetzt. Ich habe dies gerne zu Projektbeginn am Projekt-Board visualisiert. So gab es für jede vorhandene Rolle eine farbige Karte. Die Teammitglieder durften sich selber ihre Rollen aussuchen und eine Karte mit ihrem Foto oder ihrem Namen an die entsprechende Rolle heften.

Die Rollen sollten individuell auf die eigene Organisation und die benötigten Arbeitsprozesse zugeschnitten werden. Ebenfalls wird nicht jede Rolle in jedem Projekt benötigt. Hier sollte die Auswahl gemeinsam und pragmatisch auf das Projekt zugeschnitten getroffen werden.

Dabei bedeutet die Übernahme einer Rolle nicht, alle damit verbundenen Schritte selbst auszuführen. Es geht lediglich darum die Verantwortung für den Prozess zu übernehmen und das Team auf Probleme und notwendige Schritte hinzuweisen. In größeren oder langfristigen Projekten ist es sinnvoll die Hüte nach einer gewissen Zeit zu tauschen.

Einige häufig genutzte Rollen erkläre ich im Folgenden.

Testing

Maßgeblich für ein Release ist die Reduzierung von Fehlern und das Testen auch unüblicher Benutzer-Interaktionen. Testing kann dabei einen Großteil der gesamten Entwicklungszeit in Anspruch nehmen.

Wer sich für die Rolle Testing im Projekt verantwortlich fühlt stellt sicher, dass der Testprozess reibungslos funktioniert, der Testserver erreichbar ist und mit den richtigen Testdaten gefüttert wurde, dass im [glossary id=’1620′ slug=’testdriven-development’ /] die Tests wirklich frühzeitig geschrieben werden und diese alle wichtigen Funktionalitäten und Möglichkeiten abdecken.

Der Testing-Verantwortliche kümmert sich darum, dass die nötigen Test-Geräte mit entsprechenden Softwareversionen zur Verfügung stehen und der Deployment-Prozess ([glossary id=’1676′ slug=’deployment’ /]) auf das Gerät reibungslos funktioniert.

Wird mit einem Kanban-Board gearbeitet und die Prozesskette sieht die Schritte „interne Abnahme“ und „Done“ vor, so gibt ausschließlich der Inhaber dieser Rolle die Task-Karten frei und zieht diese auf das nächste Feld auf dem Board.

Die explizite Definition und Zuweisung dieser Rolle macht oft ein separates Testing-Team unnötig und reduziert deutlich die Fehlerquote. Eine reduzierte Fehlerquote wiederum erhöht deutlich die Planungssicherheit, kommen doch die meisten Projektverschiebungen durch nachträgliche Bugfixing-Phasen zu Stande.

Code Qualität

Eine hohe Qualität der entwickelten Software bedeutet nicht nur eine geringe Fehlerquote, sondern vor allem auch eine sauber programmierte Code-Basis die auch nachträgliche Wartungen und Erweiterungen zulässt.

Viele Agenturen leben von After-Sales und Projekterweiterungen. Oft wird die erste Projekt-Version als Investitions-Projekt genommen, um den Kunden zu gewinnen und mit Folgeaufträgen den eigentlich Gewinn zu machen.

Möglich ist dies aber nur, wenn Weiterentwicklungen und nachträgliche Änderungen auch noch Jahre später möglich sind und auch von anderen Entwicklern vorgenommen werden können. Nicht selten hört man in länger laufenden Projekten Aussagen wie „Das ist alles nur Kraut und Rüben!“ oder „Da stehen wir fast besser es neu zu programmieren!“. Sicher gibt es in kaum einem anderen Bereich so rasante Entwicklungen wie im Internet. Täglich erblicken neue Frameworks, Programmiersprachen und Tools das Tageslicht und es gibt immer neue, schönere Wege Probleme zu lösen als noch Monate zuvor. Dennoch hat man in der Entwicklung versagt, wenn nach einem Jahr bei einer Weiterentwicklung der Software die Kosten für eine Neu-Entwicklung fast geringer sind als für die Anpassung auf der bestehenden Basis.

Um dies zu vermeiden wird die Rolle „Code-Qualität“ definiert. Der Verantwortlich überprüft regelmäßig den gesamten Code der Software stichproben-artig auf einen einheitlichen Programmierstil und mögliche oder sogar notwendige Refactorings.

Dieser Punkt sollte sogar in der [glossary id=’1614′ slug=’definition-of-done’ /] fest verankert werden. So ist ein Task erst wirklich abgeschlossen wenn alle Akzeptanzkriterien befriedigt werden, alle Tests einwandfrei durchlaufen und der Code refactored und bereinigt wurde.

Einige Entwickler und Agenturen haben sich auf die Fahne geschrieben, den reinen Code als ausreichende Dokumentation einzusetzen (Self documenting code), und völlig auf Kommentare zu verzichten. Dies ist durchaus möglich, erfordert aber umso mehr einen einheitlichen Programmierstil.

Dokumentation

An das Thema „Code-Qualität“ knüpft auch direkt die Dokumentation aller Projekt-Informationen an. Hierzu gehören sowohl die Ordnung aller Dokumente und Prozess-Artefakte sowie Releases in einem zentralen Projektordner, als auch die Dokumentation des Quellcodes, also verständliche Schnittstellen- und Klassen-Dokumentationen.

Natürlich gilt auch hier, dass der Inhaber dieser Rolle nicht jede Dokumentation selber vornimmt. Aber er prüft regelmäßig, ob der Projektordner aufgeräumt ist und ob am Ende des Projektes alle Dokumente und Informationen zentral abgelegt wurden. Er erinnert alle Projektmitglieder daran, ihre lokalen Festplatten nach Projektdaten zu durchsuchen und diese im zentralen Projektordner abzulegen.

Prozesse

Dieser Hut hat eine ganz besondere Stellung innerhalb der Rollen. Zum einen hilft er den Projektleiter zu entlasten, zum anderen macht er den Prozess und auch die tägliche Arbeit im Projektmanagement etwas transparenter.

Der Rollen-Inhaber wird für dieses eine Projekt als Assistenz des Projektleiters eingesetzt und überwacht den kompletten Prozess. Er kümmert sich um die Einhaltung von Standards und erinnert auch den Projektleiter an wichtige Meilensteine oder Vereinbarungen.

Es liegt in der Natur des Menschen gerne eine kontrollierende Instanz einzunehmen und mit dem erhobenen Finger auf Probleme und Versäumnisse hinzuweisen. Daher wird diese Rolle meist sehr ehrgeizig ausgelebt. So wird penibel darauf geachtet, beim Daily Standup auch wirklich zu stehen und die 15 Minuten-Grenze nicht zu überschreiten, oder beim Einsatz von Kanban das WIP ([glossary id=’1632′ slug=’work-in-progress’ /]) Limit nicht zu überschreiten.

Gerade für diese Rolle macht es Sinn den Verantwortlichen regelmäßig zu wechseln. So wird nicht einer als „Fräulein Rottenmeier“ des Teams wahrgenommen und jeder bekommt einen Einblick in das Tagesgeschäft des Projektmanagers.

Design Abnahme

In Multimedia-Projekten sind selbstverständlich die Fehlerquote und die Code-Qualität nicht die einzigen wichtigen Maßstäbe, um das Endergebnis zu beurteilen. Hier steht oft das visuelle Ergebnis sogar im Vordergrund.

Nachdem das Layout vom Kunden freigegeben und dieses für die Entwicklung aufbereitet wurde ist der Designer oft raus aus dem Projekt oder liefert nur noch nachträglich angeforderte Grafiken und Änderungen.

Nicht selten jedoch entspricht das programmierte Ergebnis nicht exakt dem gelieferten Layout oder kleinere nachträgliche Änderungen werden direkt in der Entwicklung vorgenommen, ohne zuerst eine formale Designabnahme zu erwirken.

Hier ist es sinnvoll alle Ergebnisse von einem Verantwortlichen auf Design-Treue und visuelle Fehler untersuchen und abnehmen zu lassen. Die fertigen Features oder Seiten werden gegen das ursprüngliche Design, den Styleguide des Kunden und auf generelle Usability und eventuell Barrierefreiheit getestet.

Hier drängt sich natürlich ein Mitarbeiter aus den Fachbereichen Design oder Konzept nahezu auf. Jedoch sollte auch überlegt werden Entwickler nach und nach an diese Rolle zu gewöhnen. Dies schult ihr Auge und erhöht die visuelle Umsetzungs-Qualität während der Entwicklung.

Welche weiteren Rollen fallen euch ein? Wir freuen uns über Kommentare!

Leave A Reply

Navigate