In unserem ersten Blogbeitrag der Serie „Dokumentieren in agilen Methoden“ haben wir Ihnen die Rollen und Artefakte in Scrum erläutert. Sie sind an dem Artikel interessiert? Hier geht’s zum ersten Artikel.
Im zweiten Teil unserer Blogserie möchten wir Ihnen Adaptive Software Development (ASD) vorstellen. Dies geschieht wie bei Scrum auch anhand der definierten Rollen und Artefakte in diesem Framework. Die Inhalte in diesem Blog stammen aus einem Paper zum Thema Extreme Programming und ASD [1] und aus einem Vergleich von fünf agilen Methoden [2].
ASD ist eine Methodik, die ein Vorgehen für die Entwicklung komplexer Systeme beschreibt. In ASD wird der Entwicklungsprozess, wie in der agilen Softwareentwicklung üblich, in kleine gut überschaubare Abschnitte unterteilt. Diese vier bis zehn Wochen dauernden Iterationen sind wiederum in drei separate Phasen untergliedert. Abbildung 1 liefert einen Überblick zur Prozesseinteilung in ASD.
Während der Speculate phase erfolgt nach der Project Initiation die Planung der aktuellen Iteration im Adaptive Cycle Planning. Dabei werden die grundsätzlichen Ziele für den Entwicklungsabschnitt festgelegt. Die nächste Phase wird als Collaborate phase bezeichnet. Unter dem Begriff Concurrent Component Engineering ist die Entwicklung des Produkts zu verstehen. In dieser Phase kommen Techniken zum Requirements Engineering, zum Design von Systemen und dem Testen der Funktionalität zur Anwendung. Den Abschluss einer jeden Iteration bildet die Learn phase. Dort wird die Arbeitsweise des Teams in einem Quality Review reflektiert und es werden Verbesserungen in den Entwicklungsprozess eingebracht (learning loop). Im Final Q/A and release erfolgt die Qualitätsprüfung und das Release des entwickelten Produktes.
Abbildung 1 – Die Phasen des Entwicklungsprozesses in ASD
Adaptive Software Development betrachtet den Entwicklungsprozess aus der Sicht des Managements und empfiehlt Techniken aus deren Perspektive. Das heißt nicht, dass dem Development Team konkrete Vorgaben zur Umsetzung von bestimmten Problemen gemacht werden. Das Team sollte sich durch die Anwendung von ASD viel mehr selbst zu einer optimalen Arbeitsweise weiterentwickeln und vom Management dabei unterstützt werden. Im Vergleich zu Crystal und Lean Software Development sind weniger Rollen von dem Framework vorgegeben.
Rollen
Es existiert ein Executive Sponsor, der für die Planung und Verwaltung der Ressourcen im Projekt verantwortlich ist. Er entscheidet, welche Features und Funktionen von besonderem Wert für das Produkt sind. Der Project Manager schafft ein optimales Projektumfeld und definiert die Mission des Projektes. Seine Aufgabe liegt darin, das Core Team bei Problemen zu unterstützen. Er ist nicht für die Aufgabenzuteilung an einzelne Mitglieder zuständig.
Das Core Team ist für die Bearbeitung der Projektaufgaben zuständig. Wie auch bei anderen agilen Methoden wie Scrum entscheidet das Team selbstständig, welche Aufgaben während einer Iteration realisiert werden können. Das Core Team sollte aus unterschiedlich spezialisierten Entwicklern bestehen, da das Produkt featurebasiert entwickelt wird. Das bedeutet, dass immer eine Funktion bzw. eine Sammlung von Funktionen über alle Aspekte der Software hinweg implementiert werden.
Client Team Members stellen die Kundenrepräsentanten innerhalb des Teams dar. Sie liefern die Anforderungen an das zu entwickelnde Produkt. Durch das Feedback der Kunden können die Entwickler Fehler frühzeitig erkennen und beheben. Ein sehr enger Kontakt zum Kunden wird von ASD vorausgesetzt.
Zur Überwindung dieser Barriere zwischen Kunden und Entwicklern ist in ASD der Collaboration Facilitator zuständig. Er regelt die Kommunikation zwischen allen Projektbeteiligten und stellt eine zentrale Rolle dar. Zu seinen Aufgaben gehört die Organisation von Meetings, zu denen Kunden, Entwickler und das Management ihre Standpunkte, Wünsche und Probleme darlegen können. Der Collaboration Facilitator sichert damit den Informationsfluss im Projekt. Für einen schnellen Überblick sind die definierten Rollen in ASD in Tabelle 1 zusammengefasst.
Tabelle 1 – Die Rollen in ASD im Überblick
Artefakte
ASD empfiehlt eine minimale Dokumentation. Nur eine geringe Anzahl an Dokumenten, die Verständnis innerhalb des Projektes schaffen soll, wird vom Project Manager bzw. dem Executive Sponsor in Zusammenarbeit mit dem Core Team verfasst. Sie sind in der Project Mission zusammengefasst.
In der Project Vision wird auf zwei bis zehn Seiten auf die Geschäftsziele des Produktes eingegangen. Neben einer allgemeinen Produktspezifikation wird ein Überblick über die aktuelle Marktsituation gegeben. Außerdem werden darin vor Projektinitiierung bekannt Probleme und Risiken vermerkt. Für die Erstellung dieses Artefakts ist der Executive Sponsor verantwortlich.
Das Project Data Sheet liefert eine Zusammenfassung aller wichtigen Produktspezifikationen und zum Projektmanagement. Es beschreibt den allgemeinen Zeitplan für die Produktentwicklung und zeigt verfügbare Ressourcen auf. Der Umfang dieses Dokuments ist sehr kurz zu halten, da es hauptsächlich für einen schnellen Überblick für alle Projektmitglieder dienen soll.
Progress Data bezeichnet eine Sammlung aller wichtigen Zahlen, die den Fortschritt des Entwicklungsprozesses belegen. Beispielsweise enthält es tatsächliche Lieferdaten, eine Auflistung an Mängeln im Produkt und den bisherigen Verbrauch von Ressourcen im Projekt. Hauptsächlich dient dieses Artefakt zur Kontrolle und zur Planung der weiteren Iterationen.
Die Product Specification Outline enthält Features und Funktionen, die im Produkt umgesetzt sein müssen. Zu jedem Feature schätzt das Team den Aufwand für die Umsetzung beispielsweise in Function Points. Diese Schätzung dient als Grundlage für die Planung der folgenden Iterationen. Außerdem kann dieses Artefakt eine Architekturbeschreibung für das Produkt beinhalten. Anforderungen können sich während der Produktentwicklung ändern und schneller als bei sequenziellen Vorgehensmodellen in die Entwicklung einbezogen.
Unterstützt wird die Product Specification Outline von dem Product Mission Profile. Darin erfolgt eine Priorisierung der einzelnen Features durch den Executive Sponsor. Grundlage dafür ist eine Abschätzung des zu erwartenden Markterfolges der jeweiligen Funktion. Es existieren die Level excel, improve und accept. Neben den Features werden im Product Mission Profile auch Zeitpläne, Mängeln und Ressourcen bewertet und bei der Priorisierung der Features beachtet. An dieser Stelle wird das Core Team mit in die Entscheidung einbezogen. Tabelle 2 fasst die letzten Abschnitte in einer kurzen Form zusammen.
Tabelle 2 – Die Artefakte in ASD im Überblick
All diese Artefakte dienen hauptsächlich der Organisation des Entwicklungsprozesses aus der Sicht des Managements. Unter der Bezeichnung Other Products können weitere Dokumente während der Produktentwicklung entstehen. Diese sind allerdings mit dem Kunden und dem Executive Sponsor zu vereinbaren. Dazu zählen sämtliche Mittel zur Dokumentation der Arbeit sowie zur technischen Realisierung spezifischer Probleme.
Fazit
Im Vergleich zu Scrum werden in ASD mehr Rollen definiert. Die Zuständigkeit dieser Rollen ist zum Großteil in den Managementdisziplinen wie Planung und Organisation der Entwicklungsprozesse angesiedelt (siehe Tabelle 1). Auch der Umfang der zu erzeugenden Artefakte ist in ASD größer als in Scrum. Diese Artefakte sind zum Großteil zur Unterstützung des Managements definiert (siehe Tabelle 2).
ASD zielt auf die Verbesserung des Softwareentwicklungsprozesses aus der Perspektive des Managements. Dabei soll der Prozess nicht durch unnötige Arbeiten belastet werden, sondern wird möglichst schlank gehalten. Das Core Team soll sich während der Projektdurchführung so weiterentwickeln, dass es Probleme durch die gesammelten Erfahrungen lösen kann. Das Projektmanagement soll die Teammitglieder dabei bestmöglich unterstützen, ohne direkte Vorgaben zu machen.
Bisher haben wir in unserer Blogserie „Dokumentieren in agilen Methoden“ die Frameworks Scrum und ASD genauer unter die Lupe genommen und darin definierte Rollen und Artefakte vorgestellt. In Teil 3 der Serie stellen wir Lean Software Development als agiles Framework vor, welches aus Best Practices aus großen Produktionsbetrieben entstanden ist.
Falls Sie Fragen haben, können Sie sich damit gerne per E-Mail (heureka@sophist.de) oder per Telefon (0911 40 900 0) an uns wenden. Kommentare, Anmerkungen oder praktische Erfahrungen mit ASD können Sie direkt hier im Blog hinterlassen.
Literaturverzeichnis
[1] D. Riehle, A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn from Each Other
[2] Diane Elizabeth Strode, The Agile Methods: An Analytical Comparison of Five Agile Methods and an Investigation of Their Target Environment. Appendix K, Application of the analytical framework, 2007.