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.

Anforderungs-, Change- und Scopemanagement sind genau genommen Versuche das Wasserfallmodell zu verbessern. Im Laufe der Zeit verbreiteten sich iterative Ansätze und mündeten in den 90er Jahren des letzten Jahrhunderts in agile Vorgehensweise. Das tragische Element an dieser Geschichte ist, dass die Grundaussage der Veröffentlichung eine andere ist als jene die in das Bewusstsein der Branche drang.

Winston Royce schreibt in der Zusammenfassung:

In my experience, however the simpler method has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process listed.

Die erwähnte “simpler method” ist der klassische oben skizzierte Wasserfall. Die Mehrkosten durch den aufwändigeren Prozess (Iterationen) sind geringer als jene, die durch Nachbesserungen (Terminüberschreitungen) am einfachen Modell entstehen. Er schreibt also sinngemäß: “Das hat noch nie funktioniert“. Dementsprechend sind in der Veröffentlichung einige andere Grafiken enthalten, mit denen er bereits 1970 eine iterative Vorgehensweise bis hin zu wiederholtem Coding vorschlägt – das würde man heute Refactoring nennen.

Ein wenig erinnert mich das an die Legende vom Eisengehalt des Spinats

… den bis heute noch gelegentlich behaupteten, außergewöhnlich hohen Eisenanteil besitzt Spinat jedoch nicht – der Schweizer Physiologe Gustav von Bunge hatte 1890 den Wert zwar richtig berechnet, doch bezogen sich seine Angaben auf getrockneten Spinat, wurden aber später irrtümlich frischem Spinat zugeschrieben, der zu ca. 90 % aus Wasser besteht. (Wikipedia)

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.

Dass die Projekte bei denen das Team in einem Raum sitzt erfolgreicher sind hängt wahrscheinlich auch mit der geringeren Größe und ggf. Komplexität zusammen. Dass Teams, die über verschiedene Länder hinweg verteilt sind, einen Kommunikations-Nachteil haben, scheint auch plausibel. Am interessantesten in der Grafik erscheint mir der sanfte Anstieg im “Mittelfeld”. Richtige verteilte Teams – d.h. Teams mit klarer Trennung der Arbeitsplätze – scheinen ein wenig erfolgreicher zu sein als jene die auf dem gleichen Flur sitzen. Möglicherweise führt die klarere räumliche Trennung zu einer bewussteren Kommunikation, die im Falle der benachbarten Zimmer in der irrigen Annahme, dass sie automatisch erfolge, vernachlässigt wird.

Hier zum Vergleich nochmals die Erfolgsquoten der Projekte, die agile Methoden einsetzen:

In dieser Deutlichkeit überraschen mich – selbst als Verfechter agiler Methoden – diese Ergebnisse doch sehr. In der Untersuchung, die zur Zeit vorbereitet wird, werden wir dieses Thema weiter untersuchen … stay tuned.

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.