Agiler Lebenszyklus — die Projektseite des Lebens

Obwohl die iterative Softwareentwicklung weit in die 1950er Jahre zurückreicht, erkannte die Agile Software Development Group in den frühen 90er Jahren, dass ein Wasserfallansatz bei der Softwareentwicklung nicht ausreichend war, um eine schnelle und flexible Entwicklung zu ermöglichen. Das Agile Manifest wurde 2001 veröffentlicht und erklärt, wie iterativ entwickelt werden kann und welche Vorteile diese Methoden haben. Kurz gesagt, die Stärke der iterativen Entwicklung liegt in kurzen Entwicklungsphasen und einer klaren Fokussierung auf die Liste der zu erledigenden Aufgaben. Es ist wichtig zu verstehen, dass Sie die Zukunft nicht vorhersagen können und daher nicht viel Zeit damit verbringen dürfen, diese Zukunft zu dokumentieren. Fangen Sie einfach an, das aufzubauen, was Sie wissen, und stellen Sie sicher, dass Sie agil genug sind, um sich an die Veränderungen anzupassen. Durch tonnenweise Wasserfallentwicklung und agile Entwicklung ist mir aufgefallen, dass der agile Ansatz eine bewährte Methode ist, die schnelle Änderungen und kontinuierliche Anpassungen ermöglicht.

Aber du liest diesen Blogpost nicht, weil du alles über agile Entwicklung wissen willst (das kannst du lesen) hier).
Sie fragen sich wahrscheinlich, wie Ihnen der agile Ansatz im Rest des Produktlebenszyklus helfen kann. Die Erwartungen der Kunden steigen und das erfordert dringend eine agile Art, Projekte durchzuführen. Hier müssen die ersten Hürden genommen werden.

AGILE PROJEKTE

Es gibt einige Methoden zur Verwaltung von IKT-basierten Projekten, aber eine der am häufigsten verwendeten ist PRINCE (PROJECTS IN Controlled Environments). Meine Projektmitglieder und ich haben festgestellt, dass wir mit einem PRINCE-Ansatz bei Projekten nicht so flexibel waren, wie wir es uns vorgestellt hatten. Große Dokumente im Voraus zu schreiben, war für uns keine geeignete Lösung, da sich der Umfang des Projekts schon vor Beginn geändert hat. Also dachten wir: „Was wäre, wenn wir den agilen Entwicklungsansatz in unseren Projekten berücksichtigen würden?“
Wir hatten eine Liste von Artikeln, die entwickelt werden mussten, wir hatten eine Person auf Kundenseite, die als Product Owner fungieren konnte, und wir hatten ein Projektteam, das die Liste der Artikel erstellen musste. Es scheint, als ob alle Zutaten für ein agiles Projekt da waren. Wir mussten uns nur auf die Anzahl der Release-Zyklen (Sprints) einigen und sicherstellen, dass wir über die Elemente, die zu diesen Sprints hinzugefügt werden, kommuniziert haben. Ist es wirklich so einfach wie es klingt?

Leider ist es das nicht. Projekte bestehen aus drei Hauptaspekten. Zeit, Geld und zu liefernde Gegenstände. Bei 80-90% meiner Projekte möchte der Kunde, dass alle drei Aspekte behoben werden. Ein Kunde sagt Ihnen, was er will und wissen möchte, wann er es haben kann und wie viel es kostet. Dies ist ein Startpunkt für eine Katastrophe, da eine Änderung an einem der Aspekte sofort zu einer Änderung des Projektumfangs führt. Um ein agiles Projekt durchführen zu können, muss einer der drei Aspekte korrigiert werden, die anderen beiden müssen variabel sein und werden im Falle einer Änderung des Umfangs durch den festen Aspekt beeinflusst.

FESTE ZEIT

Wenn ein Kunde neue Funktionen benötigt, ist es möglich, ein festes Veröffentlichungsdatum zu haben. Niemand kann garantieren, dass die angeforderte Funktionalität an diesem Veröffentlichungsdatum verfügbar ist, aber es ist möglich, die Funktionalität mit dem höchsten geschäftlichen Nutzen bereitzustellen. In den meisten Fällen werden Sie feststellen, dass die Hauptfunktionen zwar bereitgestellt werden, dass aber „nette Dinge“ übersprungen oder auf spätere Versionen übertragen werden. Eine feste Zeit ermöglicht es einem Unternehmen, sich wirklich auf das Nötigste zu konzentrieren (minimal rentables Produkt), bevor es sich um die erweiterten Funktionen kümmert. In diesem Fall können Sie das Veröffentlichungsdatum eines Projekts garantieren. Die Macht von das minimal lebensfähige Produkt ist klar erklärt in 'Das Lean Startup'Buch von Eric Ries.

FESTE FUNKTIONALITÄT

In Besprechungen mit Kunden werden Sie in den meisten Fällen Kommentare hören wie „Wir müssen all diese Funktionen in der kommenden Version haben, nichts kann übersprungen werden“. Das ist kein Problem, solange Sie sich darüber im Klaren sind, dass das Veröffentlichungsdatum variabel ist. Aufgrund der Funktionalität könnte man etwas über die Anzahl der benötigten Sprints sagen, aber das ist auch eine Schätzung. Die Anzahl der Tage, die für die Veröffentlichung benötigt werden, kann niemals im Voraus mitgeteilt werden, aber Sie können die Funktionen garantieren, die Teil der Veröffentlichung sind.

FESTES BUDGET

Die letzte Option ist ein festes Budget. Dies kann dann in eine Reihe von Sprints übersetzt werden, die mit auszuliefernden Artikeln gefüllt werden können. Da Agil jedoch bedeutet, dass sich die Dinge während des Projekts ändern können (und höchstwahrscheinlich werden), ist es möglich, dass das Team irgendwann erweitert werden muss. Bei einem festen Budget führt dies automatisch zu einer abnehmenden Anzahl von Sprints und kann daher zu einer Verringerung der Anzahl der gelieferten Artikel führen.

OKAY, DAS IST KLAR, ABER WIE KANN ICH MEINEN KUNDEN ÜBERZEUGEN?

Dies an Ihren Kunden zu verkaufen, könnte eine Herausforderung sein. Sie befinden sich immer noch im Modus „Alle drei Aspekte müssen behoben werden“. Der CFO möchte ein festes Budget haben, der Projektmanager möchte einen festen Zeitplan haben und der Benutzer der Software möchte feste Funktionen haben. Und alle drei sind an Ihrem Projekt beteiligt. Vielleicht können Sie sie mit einem dieser Argumente überzeugen.

• Wie ich bereits erwähnt habe, kann in einem Projekt nur einer der Aspekte behoben werden und ist daher der wichtigste Aspekt während dieses Projekts. Die anderen beiden Aspekte sind zwar variabel, das heißt aber nicht, dass sie nicht wichtig sind. Tatsächlich könnten sie für Ihren Kunden genauso wichtig sein. Wenn Entscheidungen getroffen werden müssen, die den Projektumfang beeinflussen, sollten Sie alle drei Aspekte berücksichtigen, aber treffen Sie eine Entscheidung, die auf dem festen Aspekt basiert. Vollständige Transparenz bei Projektentscheidungen ist erforderlich, um Ihren Kunden über die getroffene Entscheidung und deren Auswirkungen auf die verschiedenen Aspekte zu informieren. Überzeugen Sie Ihren Kunden, dass, obwohl einer der Aspekte der „Entscheidungsaspekt“ ist, alle drei Aspekte bei der Entscheidungsfindung berücksichtigt werden.
• Die Teams bestehen aus Kundenmitarbeitern und externen Projektmitgliedern und sind multidisziplinär. Dies führt zu kurzen Kommunikationswegen, voller Transparenz (wie im vorherigen Punkt erwähnt) und Teamverantwortung. Jeder kennt den Stand des Projekts, die getroffenen Entscheidungen, die Probleme, auf die das Team gestoßen ist, und die Meilensteine bis zur Veröffentlichung des Projekts.
• Durch die Verwendung eines agilen Ansatzes und die Veröffentlichung in kurzen Iterationen hat der Kunde sofort die Möglichkeit, Änderungen in einem der drei Projektaspekte zu steuern. Auch hier wird volle Transparenz zu einem besseren Einblick in die Auswirkungen der Entscheidung auf das Projekt führen.
• Einzelheiten der Funktionen werden bei Bedarf analysiert, anstatt im Voraus. Der Kunde kann die Anforderungen kurz vor Beginn der Entwicklung angeben. Neue Erkenntnisse über die Funktionalität können vermittelt (und sogar hinzugefügt) werden, ohne den Projektumfang zu ändern. Auf diese Weise kann das Projektteam statt der analysierten Funktionen die benötigte Funktionalität bereitstellen, was zu einer besseren Nutzung der Software führt.
• Sie sind in der Lage, kleine Teile der angeforderten Funktionen vor einer eingehenden Analyse zu erstellen. Menschen neigen dazu, Funktionen besser zu erklären, wenn sie als Prototyp oder als minimal brauchbares Produkt gezeigt werden.
• Da der Kunde eng in das Projekt eingebunden ist, weiß er genau, was er erwarten kann. Sie treffen alle Entscheidungen innerhalb des Projekts oder sind sich darüber auf dem Laufenden und sind sich der Vor- und Nachteile der Entscheidungen und der Auswirkungen, die sie auf das Projekt haben, voll bewusst.
• Die Arbeit wird vorzugsweise am Standort des Kunden durchgeführt und führt daher zu einer engeren Kommunikation und ermöglicht es externen Teammitgliedern, Teil der Kundenumgebung zu sein.
• Vollständige Transparenz über alle drei Projektaspekte durch Standup-Meetings, Projekt-Backlogs, Sprint-Backlogs, Burndown-Charts, Retrospektiven und Sprint-Meetings (mehr Informationen zu diesen Keywords) hier).
• Software wird für, aber noch wichtiger, mit Benutzern entwickelt.
• Am Ende werden die Qualität, Zuverlässigkeit und Stabilität der Software besser sein, der Kunde wird wissen, was er bekommt und kann das Ergebnis kontinuierlich steuern, der effektive Zeitaufwand wird sinken und die Gesamtkosten werden sinken.

Aufgrund unserer eigenen Erfahrung mit vielen Wasserfall- und agilen Projekten habe ich festgestellt, dass Kunden mit den Ergebnissen zufriedener sind, wenn ein agiler Ansatz gewählt wird. Das bedeutet nicht automatisch, dass wir mehr Funktionen bereitstellen, aber die Kommunikation, Transparenz und der Wert des Releases sind höher als bei einem Wasserfall-Ansatz. Die Kunden wissen, was sie bekommen, wann sie es bekommen, und sie haben die volle Kontrolle darüber, ob sie bei Bedarf „an den Knöpfen drehen“ können.

In meinem kommenden Blog“Agiler Lebenszyklus — Die unterstützende Seite des Lebens“ Ich erkläre, welche Auswirkungen der agile Ansatz bei der Unterstützung Ihrer Kunden haben kann.