Auch bei noch so gründlicher Vorarbeit sind in der Regel zu Beginn eines (Software-) Projektes nicht alle Anforderungen bekannt (siehe Bild bzw. Beitrag: agil ist besser?! ). Dass sich die bekannten Anforderungen dann auch noch verändern gehört zum Alltag. Nicht umsonst gibt es den Begriff des “moving target” – das Ziel bewegt sich, das Treffen wird erschwert. Agiles Vorgehen ist eine Antwort auf das “moving target”. Solange sich das Ziel nur bewegt besteht wenig Grund zur Sorge. Mit gründlicher Beobachtung und etwas Überlegung lässt sich erahnen wohin der Hase läuft. Fatal wird es jedoch wenn der Hase einen Superkräfte-Möhrensaft-Cocktail trinkt und mit Riesenkräften einen Sprung in die andere Richtung macht und plötzlich verschwunden ist. In dieser Situation befinde ich mich gerade. Eine SW-Entwicklung kurz vor dem Abschluss, dann kommt ein Anruf, dass eine grundlegende Konzeptänderung notwendig ist. Wie das neue Konzept aussehen wird ist aber noch nicht klar. Klar ist nur, dass das alte nicht passt. Innerhalb von Minuten sitzt man vor einem scheinbaren Scherbenhaufen:

• möglicherweise ist ein großer Teil des Codes für den Mülleimer
• Projektpläne und Berichte haben nur noch Altpapierwert
• das Gefühl “gleich haben wir es geschafft” ist weg
• ein (Schuld)-Gefühl “warum ist das nicht aufgefallen” kommt hoch
• Budget(planungen) sind im Eimer

Tief durchatmen – keine Panik. Was ist zu tun?

• Ordentliches Release fertig bauen,
  vielleicht wird der Umbau doch nicht so schlimm wie befürchtet.
• Erste spontane Ideen für den Konzeptumbau sichern.
• Mit anderen Aufgaben, zu denen keine Abhängigkeiten bestehen, weiter arbeiten.
• Pläne werden erst angepasst wenn der Hase wieder sichtbar ist.

Dann nochmal durchatmen und in Ruhe eine Tasse Heißgetränk (in meinem Falle Kräutertee) konsumieren. Was ich aus dieser unerwarteten Wendung lerne, weiß ich noch nicht, sie hat mir aber deutlich gezeigt, wie wichtig eine gewisse Ordnung, Dokumentation und Werkzeugeinsatz sind. Der Zielwechsel wird auf Basis einer geänderten Spezifikation, den bisher im Bugtracker dokumentierten Fällen und den lauffähigen Releases im Versionsmanagementsystem halbwegs stressfrei möglich sein. Nicht auszudenken, wenn der Code unversioniert und nicht lauffähig wäre. Wie dem auch sei, auf jeden Fall ist mein Anekdotenschatz wieder um eine Geschichte reicher.

Dieser Satz ist einer Schlagzeile meiner Tageszeitung entnommen. Eine Regierung, die gemeinsam voller Teamgeist arbeitet – das ist eine schöne Vorstellung. Die aktuellen Berliner Regierungsgeschäfte scheinen davon jedoch weit entfernt zu sein. Teamgeist lässt sich aber nicht einfordern. Teamgeist muss wachsen. Der Samen für den Teamgeist ist eine gemeinsame Vision. Möglicherweise fehlt es genau daran. Ich sehe mich, wenn ich mich in die Lage der Regierung versetze, nicht in der Lage eine kurz formulierte Vision für die Regierungsarbeit der nächsten Jahre zu formulieren. Ich befürchte manchem Regierungsangehörigen geht es ähnlich.

Keine Teamarbeit ohne Vision! Und was hat das mit Projekten zu tun?

Dass unklare Ziele einen gewichtigen Misserfolgsfaktor darstellen, ist unbestritten. Über den konkreten Zielen oder Anforderungen steht aber noch die Vision. Auch Projekte brauchen Visionen. Eine kurze Kontrollfrage lautet: “Warum machen wir das Projekt?” Die Antwort auf diese Frage sollte von allen Mitarbeitern ohne zu zögern kurz und prägnant beantwortet werden können. Es bleibt noch anzumerken, dass sich die Antworten ähneln sollten. Wenn bei der Frage nach dem “Warum” schon Differenzen bestehen, werden sich bei der Ermittlung der konkreten Anforderungen zwingend Widersprüche ergeben. Damit schließt sich der Kreis zur Politik Widersprüchliche Maßnahmen haben derzeit Hochkonjunktur.

Ein Tipp zum Schluss: Es lohnt sich die Frage nach dem “Warum” explizit zu stellen und ggf. einen Konsens herzustellen. Damit lassen sich viele Missverständnisse vermeiden.

Ein berühmter Test stammt von Joel Spolsky. Er hat zwölf Punkte formuliert, die den Weg zu besserem Code weisen. The Joel Test: 12 Steps to Better Code.

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. …

Ich möchte den Joel Test hier nicht in ganzer Länge zitieren. Er stellt jedoch eine wichtige Grundlage für meinen eigenen 15 Punkte Test dar. Dieser ist an einigen Stellen allgemeiner an anderen Stellen etwas detaillierter formuliert. Es sind jeweils 5 Fragen zu den Bereichen Spezifikation, Vorgehensweise und Rahmenbedingungen bzw. Management. 15 Fragen, für jede 20 Sekunden Zeit um sie mit “Ja” oder “Nein” zu beantworten:

• Haben Sie eine fachliche Spezifikation?
• Haben Sie eine technische Spezifikation?
• Haben Sie dokumentierte Testfälle?
• Haben Sie Tester?
• Haben Sie Tester außerhalb des Entwicklungs- oder Projektteams?

• Verwenden Sie eine Versionsverwaltung?
• Ist Ihr Build-Prozess automatisiert?
• Machen Sie einen täglichen Build?
• Verwenden Sie ein Bugtracking-System?
• Beheben Sie Fehler bevor Sie neuen Code schreiben?

• Kann sich das Entwicklungsteam den Arbeitsplatz selbst gestalten?
• Können die EntwicklerInnen ungestört arbeiten?
• Stehen die besten (Wunsch)-Werkzeuge zur Verfügung?
• Gibt es einen aktuellen und validen Zeitplan?
• Werden Zeit-Schätzungen grundsätzlich von mehr als einer Person gemacht?

15 mal JA: Es gibt kaum noch etwas zu verbessern. Es bleibt höchstens die Frage ob die Fragen wahrheitsgemäß und nicht nur dem Wortlaut nach beantwortet wurden. Es wäre dann z.B. nachzufragen ob die vorhandenen Tester wirklich testen oder nur auf dem Papier vorhanden sind.

weniger als 3 mal JA: Dann haben Sie möglicherweise ein Problem und viel Verbesserungspotential.

Ziel des Tests ist es nicht auf Gedeih und Verderb die volle Punktzahl zu erreichen. Er soll in kürzest möglicher Zeit einen kritischen Blick auf ein konkretes Software-Entwicklungs-Projekt werfen. Die Fragen decken hierbei wichtige Grundsätze der Softwareentwicklung und des Projektmanagements ab, die in der Mindmap nochmals im Zusammenhang dargestellt sind:

Die Mindmap gibt es auch als PDF zum Download: 15 Punkte für gute Software – (Projekte). Und hier die Fragen als ausfüllbare Checkliste: Checkliste 15 Punkte für gute Software.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Entgegen landläufigen Vorurteilen handelt es sich nicht um Aussagen, die etwas negieren. Es wird nicht gesagt, es müsse keinen Plan oder keine Dokumentation geben. Es sind Werte und Prioritäten. Es wird mehr Wert auf die Lauffähigkeit der Software – oder allgemeiner die Funktionstüchtigkeits des Projekt-Ziel-Artefakts – gelegt, als auf eine ausführliche Dokumentation. Es wird in Bezug auf den Kunden mehr Wert auf Zusammenarbeit als Vertragsverhandlung gelegt. Auch im ersten und im letzten Punkt sind Prioritäten formuliert. Diese lohnen aber eine genauere Betrachtung, da hier große Differenzen zum klassischen Projektmanagement sichtbar werden. Trotz der Differenzen steckt in den Punkten “Individuals und Interactions” bzw “Responding to change” auch der Schlüssel zur Kombination agiler und klassischer Vorgehensweisen.

Responding to change over following a plan

In agilen Projekten wird nicht geplant – so lautet eines der Vorurteile. In agilen Projekten gibt es sehr wohl einen Plan, er hat lediglich eine geringere Reichweite und wird sehr häufig überarbeitet und schrittweise verfeinert. Im Falle von Scrum wird täglich geplant und täglich geprüft ob der Plan eingehalten wurde. Jede(r) formuliert täglich die nächsten Aufgaben, die er oder sie in Angriff nimmt. Beim nächsten Meeting wird über die Erledigung oder Nicht-Erledigung gesprochen. Die Aufgaben wurden zuvor bei der Planung des jeweiligen Sprints gemeinsam ermittelt. Die Aufgaben selbst leiten sich aus den Anforderungen, die in diesem Sprint umgesetzt werden sollen, ab. Die Anforderungen wiederum entstammen dem priorisierten Produkt-Backlog. Es handelt sich also um eine verschachtelte Struktur von Plänen, die iterativ verfeinert werden. In einem “Wasserfall”-Projekt wird zu Beginn ein Gesamtplan erstellt, der so gut wie möglich eingehalten wird. Die Grafik zeigt den Unterschied:

Die real zu erledigenden Aufgaben (graue Balken) werden klassisch so früh und so vollständig wie möglich ermittelt und geplant. Im agilen Projekt werden zu Beginn die Eckpfeiler des Projektes (Vision und Endtermin) und der Plan für den ersten Sprint festgelegt. Die weitere Spezifikations- und Planungsarbeit wird über das Projekt verteilt. Die Planungsarbeit liegt klassisch überwiegend beim Projektleiter. In agilen Projekten beteiligt sich das Team wesentlich stärker an der Planung. Der Unterschied der Planung liegt also überwiegend darin “Wann und von wem der Plan gemacht wird”. Eine mögliche Synthese von klassischer und agiler Vorgehensweise ist in der nächsten Grafik angedeutet:

Ein grob ausgeführter Wasserfall liefert den Input für den Start der agilen Implementierung, die agile Implementierung liefert das Produkt zurück. Der klassische Grobplan ist der Rahmen in dem die agile Detail-Planung ablaufen kann. Am Thema Planung wird einerseits die Differenz der Ansätze aber auch ein möglicher Synthese-Punkt sichtbar.

Und hier geht es zum zweiten wichtigen Unterschied zwischem agilen und klassischer Vorgehensweise.

Anforderungsmanagement ganz pragmatisch

- Auf ungefragt geäußerte Information achten!
- Auf persönliche Steckenpferde achten!
- Gibt es mehrere Anforderer?
- Gibt es widersprüchliche Anforderungen?
- Das “Was” und das “Wie” nicht vermischen?
- Was braucht der Kunde wirklich?

Der Prozess genaue und klare Anforderungen zu ermitteln ist lange und mühselig. Manchmal ist es wie das Fischen in einer trüben Suppe. Manches ist schwierig zu erwischne, ss gibt aber auch „Brocken in der Suppe“, die immer wieder von alleine auftauchen. Anforderungen, die freiwillig und ohne Nachfragen genannt werden. Das erleichtert im ersten Moment die Arbeit, dennoch sollten solche Anforderungen besonders genau unter die Lupe genommen werden. Hinter diesen Anforderungen stecken meist starke Interessen des jeweiligen Anforderers. Diese Interessen müssen nicht zwingend im Sinne des Projektes sein. Deshalb gilt es diese Anforderungen kritisch zu prüfen. Im Sinne dieser Prüfung sollte man sich auch fragen ob sich dahinter eventuell persönliche Steckenpferde verstecken. Ich möchte „persönliche Steckenpferde“ nicht schlecht machen, oft ist es eine große Hilfe für die Anforderungsdefinition wenn Spezialwissen gepaart mit Begeisterung für ein Thema zusammen kommen. Die Aufnahme aller persönlichen Steckenpferde kann die Anforderungsliste aber auch überfrachten – womit wir wieder bei der Zielvermehrung angekommen wären. Bei der Bewertung der Anforderungen lohnt sich immer auch ein Blick darauf ob es eine einzelne Person oder mehrere Personen sind, die hinter einer formulierten Anforderung stehen. Nicht immer zählt die Masse aber es hilft bei der Steckenpferdanalyse.

Jetzt wird es spannend. Sehr gut beschriebene Anforderungen können wertlos werden, wenn sie nicht genau auf Widersprüche geprüft worden sind. Wenn Zeit und Budget im Übermaß vorhanden sind, lassen sich manche Widersprüche durch ein salomonisches „sowohl als auch“ lösen. In realen Projekten sind Zeit und Geld aber knapp. Entscheidungen, welche der widersprüchlichen Anforderungen umgesetzt wird, müssen so früh wie möglich gefällt werden um den Anforderer zum Ende des Projektes hin nicht unnötig zu verärgern. Fällt der Widerspruch erst am Ende auf, wenn eine der Anforderungen schon umgesetzt wurde und dann doch die Entscheidung für die andere fällt wurde für den Papierkorb gearbeitet. Das ist dann der „worst case“ im Projektgeschäft.

Die nächste Frage erscheint trivial und ist dennoch von großer Bedeutung. An einem Beispiel wird es deutlich. Die Anforderung lautet: „6 Personen aus Stuttgart müssen morgen um 10:00 Uhr in Mannheim pünktlich zu einem Termin erscheinen“. Das ist das „Was“ – eine Formulierung der Anforderung. Das „Wie“ ist die Frage nach dem Transportmittel, als da wären: Auto, ICE, Flugzeug. Eine vermischte Formulierung wäre „6 Personen müssen mit dem Zug nach Mannheim fahren und pünktlich zu einem Termin erscheinen“. Selbst wenn die Lösung der Anforderung wirklich die Zugfahrt ist, muss die Anforderung selbst lösungswegneutral formuliert werden. Wird dieser Grundsatz vernachlässigt werden manche Entscheidungen vorweggenommen bzw. Entscheidungsspielraum im Projekt eingeschränkt. Dieser Effekt tritt oft in IT-Projekten auf, wenn Anforderungen mit Implementierungshalbwissen vermischt werden. Wer kennt nicht den Satz “Wir brauchen eine Datenbank?” … die Frage “Was soll die Datenbank tun?” bleibt oft lange unbeantwortet.

Die letzte Frage schließt den Kreis zur ersten Frage auf dem vorherigen Kärtchen, diese lautete „Wer ist der Auftraggeber“. Egal ob man diesen Auftraggeber, Stakeholder oder Kunde nennt. Man sollte immer versuchen sich in den Kunden hinein zu versetzen und versuchen zu verstehen was er wirklich braucht. Nicht immer ist das was formuliert wird auch wirklich das was benötigt wird. Echte Zufriedenheit beim Kunden/Auftraggeber wird sich nur einstellen, wenn er wirklich das bekommt was er braucht.