Agile Analyse im Vorfeld

Einer der sichtbarsten Aspekte der Agilität ist, dass Entscheidungen dann getroffen werden, wenn sie erforderlich sind, und nicht alle im Voraus, bevor die Entwicklungsarbeit überhaupt begonnen hat. Einige Entscheidungen sind jedoch erforderlich, bevor der Rest des Projekts durchgeführt wird.Ein agiler Ansatz bei der Softwareentwicklung hat in den meisten Unternehmen viele Vorteile. Da der Wandel inhärent ist, in den geschäftlichen Anforderungen, in der Technologie, im Wissen, in den Menschen, ist es sehr sinnvoll, einen Prozess zu verwenden, der den Wandel als gegeben hinnimmt und ihn umarmt, anstatt zu versuchen, sich dagegen zu wehren. Einer der Grundsätze agiler Ansätze ist es, Dinge so spät wie möglich zu entscheiden. Gleichzeitig wollen wir Software entwickeln, die von den Anwendern genutzt und gemocht wird und die einen echten Wert für sie hat. Und manchmal stehen diese beiden Ziele im Widerspruch zueinander. Der traditionelle Weg, dies zu erreichen, ist die Durchführung einer umfassenden Anforderungsanalyse vor Beginn eines Projekts. Alle, die an dem zu entwickelnden System beteiligt sind (die Stakeholder), sollten im Voraus sagen, was sie von dem System erwarten. Nach sorgfältiger Abwägung aller Bedürfnisse wird eine Liste von Anforderungen erstellt, die an die Softwaredesign- und -entwicklungsteams geschickt wird. Bei einem agilen Ansatz sind viele der Techniken zur Anforderungserfassung, die im traditionellen Anforderungsmanagement verwendet werden, immer noch sinnvoll. Der Ansatz der Vorabanalyse ist nicht sinnvoll, da er nicht berücksichtigt, dass sich Anforderungen ändern. Menschen ändern ihre Meinung oder gewinnen ein besseres Verständnis für ihre Bedürfnisse, Gesetze ändern sich, Budgets ändern sich, die politische Landschaft ändert sich. Der übliche agile Ansatz besteht darin, die Anforderungen und ihre relativen Prioritäten für eine Iteration kurz vor deren Beginn festzulegen. Eine Verfeinerung ist sogar innerhalb der Iteration möglich. Die Anforderungen sollten so detailliert wie nötig sein; nicht mehr und nicht weniger. Das bedeutet, dass ein Anforderungsingenieur nicht nur mit den Interessenvertretern des Unternehmens spricht, sondern auch mit seinen Hauptkunden: den Entwicklern, die diese Anforderungen verwenden werden.Viele agile (und nicht-agile) Projekte beginnen jedoch zu schnell und vergessen dabei, an die Probleme zu denken, die vor der ersten Iteration gelöst werden müssen. Das Risiko, eine falsche Software zu produzieren, ist zu groß, wenn diese Fragen ignoriert werden. Zu diesen Fragen gehören der Geschäftszweck des Projekts, die Liste der beteiligten Personen und Systeme (die Stakeholder), der Umfang der Arbeit und die kritischsten Einschränkungen. Je nach Unternehmen kann dies auf ein oder zwei Blättern Papier niedergeschrieben werden oder eine gründlichere Analyse und einen Bericht erfordern. Wenn Sie dies nicht tun, laufen Sie Gefahr:

• etwas herzustellen, das keinen Geschäftszweck erfüllt, so dass es als Geldverschwendung angesehen wird, selbst wenn etwas geliefert wird [Geschäftszweck]
• Stakeholder und ihre Anforderungen werden nicht berücksichtigt, was im besten Fall zu Unzufriedenheit führt und im schlimmsten Fall das Ergebnis unbrauchbar macht, weil wichtige Funktionen oder Schnittstellen fehlen [Stakeholder].
• Einbeziehung kostspieliger Funktionen, die außerhalb des Umfangs liegen und in einem anderen Projekt oder System wirtschaftlicher hätten implementiert werden können (oder Weglassen wichtiger Funktionen, die das System lohnender hätten machen können - aufgrund einer falschen Annahme über den Umfang) [Umfang]
• die falschen Leute an Bord zu holen, wie z.B. Oracle-Entwickler, um ein Java-System zu erweitern, oder nicht in der Lage zu sein, auf der bestehenden Infrastruktur zu laufen, oder nicht auf einen wichtigen Termin hinzuarbeiten [Einschränkungen]

Nehmen Sie sich also bei jedem Projekt, auch bei einem agilen Projekt, die Zeit für einen Projektstart, bei dem diese wichtigen Themen angesprochen werden, sonst ist der Erfolg Ihres Projekts ein reines Glücksspiel, egal wie gut das Team ist. Nach dem Startschuss ist das Anforderungsmanagement Teil des agilen Prozesses und wird vom Product Owner verwaltet, der ein echter Teil des agilen Entwicklungsteams ist.