Freitag, 18. April 2014

Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Der Sinn dieser Reihe ist es Prozessschritte aufzufinden, die für die Softwareentwicklung unabdingbar sind. Auf der anderen Seite gibt es vielleicht Prozesse, die keinen Sinn machen und verschwendete Zeit sind. Einen wesentlichen Einfluss auf diese Prozesse haben Vorgehensmodelle. Über die Jahre hat sich eine Vielzahl von Modellen angesammelt. Bekannt sind das gute alte V-Modell, der Rational Unified Process und in letzter Zeit natürlich immer mehr die agilen Prozesse. In den letzten Jahren habe ich einige Erfahrung mit Scrum gesammelt. Wir entschieden uns für Scrum, weil wir iterativ und inkrementell vorgehen wollten, aber auch, weil wir gehört hatten, dass bei dieser Vorgehensweise Teamarbeit im Zentrum steht. Wir wollten die verschiedenen Begabungen in einem festen Team zusammenführen und gemeinsam verantwortlich vorgehen.

"Bei iterativ-inkrementellen Vorgehen wird die gesamte Softwareentwicklung in zeitliche Abschnitte unterteilt (Iterationen) und das System in Teilen (Inkrementen) realisiert, die einen Zuwachs an Funktionalität bilden." [S. 48, RUPP07] In zurückliegenden Projekten haben wir am Ende eines Projektes ein Lessons Learned durchgeführt. Wir versuchten das Projekt aus verschiedenen Perspektiven zu bewerten, falsche Wege aufzufinden und so für ein nächsten Mal besser gerüstet zu sein. Leider beinhaltet dieses Vorgehen eine fatale Fehlkonstruktion. Es ist eher ein Meckern am Ende des Projekts. Zu oft beginnt das neue Projekt auch mit ganz anderen Leuten, die diese Erfahrungen nicht gemacht haben. Die mögliche Verbesserung bleibt so auf der Strecke.

In Scrum bot sich uns eine ganz neue Möglichkeit. Scrum läuft in sogenannten Sprints ab. Dadurch ist eine iterative Vorgehensweise gewährleistet. Die Dauer der Sprints kann willkürlich festgelegt werden und sollte pragmatischen entschieden werden. Wir hatten uns erst für eine Woche entschieden, verlängerten die Dauer dann jedoch auf zwei Wochen. Der organisatorische Overhead in nur einer Woche war uns zu groß und die erbrachten Ergebnisse zu klein. Die begrenzte Dauer eines Sprints bot für die Verbesserung unseres Prozesses jedoch ungeahnte Möglichkeiten.

In Scrum gibt es drei wesentliche Rollen, den Product Owner, den Scrum Master und das Team. Der Product Owner ist eine Art Multigenie, der sowohl im Requirements Engineering, in der Projektplanung und in der Softwarearchitektur zu Hause ist. Wir hatten erhebliche Probleme mit dieser Rolle und haben sie deshalb durch ein zweites Team ersetzt. In diesem Team waren die verschiedenen Rollen zusammengefasst. Am Ende gab es User Stories, die dem Team übergeben werden konnten. Am Anfang eines Sprints steht das Planning. Dort wurden die User Stories vom Team diskutiert, geschätzt und am Ende übernahm das Team die Verantwortung, je nach Velocity, eine Reihe von User Stories im Sprint umzusetzen.

Während der Arbeitsphase des Sprints fand natürlich jeden Tag der Daily Scrum statt. Die eigentlichen Fragen, was hast du gemacht, was machst du und hast du Probleme, wurden oft über das Ziel hinaus beantwortet. Hier hatten wir noch eine längere Lernphase vor uns. Trotzdem taten die persönlichen Gespräche oft gut. Nach zwei Wochen waren eine Reihe von Aufgaben abgearbeitet und sie wurden im Sprint-Review vorgestellt. In diesem Sprint-Review sollten wirklich nur 100% fertige Aufgaben vorgestellt werden. Alles andere ist nicht fertig.



Kommen wir nun zum Anfangsgedanken zurück, der Möglichkeit einer Prozessverbesserung. Im Anschluss an das Sprint-Review und vor dem Beginn des Sprint-Planning des nächsten Sprints findet die Sprint-Retrospektive statt. Diese Retrospektive sollte einen Verbesserungsregelkreis beinhalten. Es geht weder darum Leute anzuschwärzen, noch um freudvolles Herummeckern. Hier sollen Daten gesammelt werden über vermeintlich ineffiziente Vorgänge. Dabei ist es gut, Dinge messbar zu machen. Die gesammelte Daten müssen einem argumentativen Diskussionsprozess zugeführt werden, der Verbesserungsvorschläge erbringt.

Solche Verbesserungen können im begründeten Weglassen, Verändern oder Hinzufügen von Arbeitsschritten liegen. Die Hypothese, das bestimmte Zusatzschritte einen Mehrwert bringen, sollten durch zu erhebende Messwerte nachprüfbar gemacht werden. Wie in der Lean-Startup-Methode sollten diese Kennwerte aktionsorientiert, allgemein zugänglich und allgemein nachprüfbar sein. Auf diese Weise können vielfältige praktische Erfahrungen gesammelt werden. Oft sind sogenannte Erfahrungen verschleierter Unglaube an die Möglichkeiten. In diesen Fällen existiert hier eine Methode in kleinen Dosen den Nachweis zu erbringen oder sich das Gegenteil beweisen zu lassen. Die Wirklichkeit wird oft von der eigenen Vorstellung übertroffen.



Scrum bietet einige Methoden an, den Arbeitsfortschritt während eines Sprints im Auge zu behalten. Da gibt es den Sprint-Burnout-Bericht. "Der Sprint-Burnout-Bericht zeigt den Fortschritt im Sprint auf. Er betrachtet, wie sich die Aufwände im Sprint Backlog zusammen von Tag zu Tag entwickeln." [S.117, PICH08] "Der Release-Burndown-Bericht beschreibt den aktuellen Projektfortschritt. Er führt die Summe der Aufwände im Product Backlog am Ende jedes Sprint auf und zeigt, wie sich die Aufwände über Sprint-Grenzen hinweg verändern." [S.70, PICH08] Der Sprint Backlog ist praktisch die Ablage aller umzusetzenden User Stories. Mit diesen beiden Diagrammen steht eine allgemeine, nachprüfbare Methode zur Verfügung, die Leistung des Teams im Auge zu behalten.

Aus Prozesssicht erscheint mir eine weitere Unterteilung wichtig zu sein. Diese hat weniger mit Scrum zu tun, als mit wirklicher Teamarbeit, die diesen Namen wert ist. Die Abarbeitung bestimmter Aufgaben im Team ist ein Wechsel zwischen Einzelarbeit und gemeinsamer Arbeit. Im Artikel Arbeitsumgebung kann Kreativität töten habe ich die Notwendigkeit eines Umfeldes beschrieben, in dem genau dieser Wechsel möglich ist. Großen Gewinn haben wir aus der Vermittlung der Systemarchitektur, gemeinsamen Programmier- und Reviewsitzungen und der Diskussion wichtiger Probleme gezogen. Eine Zusammenarbeit führt in den allermeisten Fällen zu einem sehr zügigen Voranschreiten. Viele Augen sehen mehr Fehler und ganz andere Möglichkeiten. Sie ergänzen sich im öffentlich geführten Denkprozess. Genau hier entscheidet sich, ob einzelne Teammitglieder teamfähig sind oder nicht.



In diesem Post habe ich meine Erfahrungen mit Scrum aus Prozesssicht beschrieben. Ich würde mich sehr freuen, wenn es Leser geben würde, die in ähnlichen Gastartikel meine Sicht der Dinge durch andere Vorgehensmodelle ergänzen würden. Jedes Vorgehensmodell hat sicherlich seine Vor- und Nachteile. Vielleicht kann man am Ende dem Eklektizismus frönen und die Dinge neu zusammensetzen.

  • [PICH08] Roman Pichler: "Scrum - Agiles Projektmanagement erfolgreich einsetzen", 1. Auflage, dpunkt.verlag GmbH, Heidelberg, 2008
  • [RUPP07] Chris Rupp & SOPHISTen: "Requirements Engineering und – Management", 4. aktualisierte und erweiterte Auflage, Carl Hanser Verlag, München, Wien, 2007


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen