0.0.8.5 Vergleich zwischen dem TenStep Prozess und Agile Software Development

Achtung, öffnet in einem neuen Fenster. PDFDruckenE-Mail

In den letzten Jahren sind viele Ideen veröffentlicht worden, wie der Prozess der Software-Entwicklung einfacher werden könnte, leichter zu implementieren und sensibler für die Bedürfnisse der Kunden. Darunter etwa eXtreme Programming, Scrum und die Crystal-Methodenfamilie. Am 11., 12. und 13. Februar 2001 haben sich siebzehn Leute, die an vorderster Front an diesem Denkprozess beteiligt waren, in Utah getroffen, um gemeinsame Ideen zur Software-Entwicklung zu erarbeiten. Das Ergebnis davon war ein Manifest für eine Reihe von Entwicklungsprinzipien und -philosophien, die weiter unten aufgeführt werden.

Die Philosophie befaßt sich zwar größtenteils mit dem Prozess der eigentlichen Software-Entwicklung, doch ein paar Punkte berühren auch das Gebiet des Projektmanagements. In den meisten Bereichen ist der TenStep Projektmanagement-Prozess eine gute Ergänzung zu diesem Entwicklungsprozess. In anderen Bereichen gehen die Meinungen auseinander. Unten können Sie das Agile Manifest lesen, und daneben die Kommentare des Autors, inwieweit es zum TenStep Prozess passt.

Das Manifest der agilen Software-Entwicklung
Siebzehn Anarchisten sind sich einig:

Wir enthüllen bessere Methoden der Software-Entwicklung, indem wir sie selbst durchführen und auch anderen dabei helfen. Infolge dieser Tätigkeit setzen wir heute folgende Prioritäten:

TenStep Projektmanagement-Prozess

Individuen und Interaktionen statt Prozessen und Tools.

lauffähige Software statt umfassender Dokumentation.

Zusammenarbeit mit dem Kunden statt Vertragsverhandlungen.

Eingehen auf Veränderungen statt striktem Befolgen eines Plans.

Wenn in einer Organisation mehrere Projekte durchgeführt werden, ist nach Erfahrung des Autors die Erfolgschance viel größer, wenn es einen flexiblen und skalierbaren Satz konsequenter Prozesse gibt. Wenn diese Prozesse schon einmal mit Erfolg eingesetzt worden sind, ist die Wahrscheinlichkeit größer, dass auch Sie damit erfolgreich sein werden.

Das heißt, die rechts aufgeführten Punkte sind uns zwar wichtig, doch diejenigen auf der linken Seite sind uns noch wichtiger.

Wir richten uns nach folgenden Prinzipien:

Unsere höchste Priorität ist die Zufriedenstellung des Kunden durch frühzeitige und beständige Lieferung wertvoller Software.

Die Agile Philosophie steht für iterative Entwicklung, d.h., auf frühe Anforderungen folgt ein lauffähiger Code, dann weitere Anforderungen und weiterer Code. Das ist schön und gut, doch iterative Entwicklung ist nicht bei allen Software-Projekten der beste Ansatz. Dennoch sollte man es dort, wo man sie implementieren kann, auch damit versuchen.

Wir begrüßen Änderungsanträge, selbst in fortgeschrittenem Entwicklungsstadium. Agile Prozesse machen Änderungen zum Wettbewerbsvorteil des Kunden nutzbar.

Bei iterativer Entwicklung müssen die Anforderungen nicht frühzeitig festgelegt werden. Doch irgendwann muss dies selbst bei traditioneller iterativer Entwicklung geschehen, damit Ergebnisse abgeliefert werden können. An diesem Punkt kommt Scope-Änderungsmanagement ins Spiel. Bei agiler Entwicklung können Anforderungen sich jederzeit ändern. Vom Standpunkt der Entwicklung aus betrachtet, ist das auch völlig in Ordnung, doch Scope-Änderungsmanagement wird auch für den Kunden betrieben. Ihr Kundensponsor hat sich unter der Bedingung zur Finanzierung des Projekts bereit erklärt, dass er für einen bestimmten Kostenaufwand zu einem bestimmten Zeitpunkt eine bestimmte Lösung erhält. Wenn das Projektteam weiterhin jederzeit selbständig Scope-Änderungen vornimmt, wird das Projekt letztendlich viel mehr Zeit und Kosten in Anspruch nehmen, als der Sponsor bewilligt hat. Entscheidend ist, dass das Projektteam bereit sein muss, auf betriebliche Änderungen einzugehen, wenn sie eintreten. Änderungen an den Anforderungen jedoch ziehen Konsequenzen hinsichtlich des Budgets und des Liefertermins nach sich, und diese müssen vom Sponsor genehmigt werden. Wenn das Team sich daran hält, praktiziert es Scope-Änderungsmanagement.

Liefern Sie häufig lauffähige Software ab, alle paar Wochen bis alle paar Monate, vorzugsweise im kürzeren der beiden Zeitrahmen.

Der TenStep Prozess empfiehlt, große Projekte in eine Reihe kleinerer Projekte aufzuspalten. Jedes einzelne kann dann schneller abgewickelt werden und lässt sich eher wiederholen. Nicht alle Projekte sind dazu flexibel genug, doch bevorzugt werden nach Möglichkeit kleinere Projekte. Agile Prozesse können die Kürze des Lieferzyklus ins Extreme steigern. Einige eXtreme Programming Projekte werden in sehr kurzen Zyklen abgewickelt, manchmal sogar wöchentlich. Dies kann zwar schwierig zu managen sein, doch an für sich ist es völlig in Ordnung.

Geschäftsleute und Entwickler arbeiten während des gesamten Projekts täglich zusammen.

Dies ist der beste Weg, die Bedürfnisse des Kunden im Auge zu behalten.

Schaffen Sie Projekte um motivierte Menschen herum. Bieten Sie ihnen das nötige Umfeld und die nötige Unterstützung, und vertrauen Sie darauf, dass sie ihre Aufgabe erfüllen.

Manchmal haben sehr motivierte Leute Schwierigkeiten, ein Projekt termingerecht abzuliefern. Sie konzentrieren sich manchmal zu sehr auf die Entwicklungsdetails und zu wenig auf das Managen des Budgets und des Liefertermins. Wenn motivierte Menschen ihre Projekte immer rechtzeitig zum Abschluss bringen würden, wäre der Prozentsatz der erfolgreichen Projekte höher. Manchmal sind motivierte Mitarbeiter erst erfolgreich, wenn man sie in ein strenger strukturiertes Umfeld setzt. Nach Ansicht des Autors ist der beste Ansatz der, Projekte um motivierte Menschen herum zu schaffen, und dann dafür zu sorgen, dass sie über die richtigen Tools, Prozesse und Kompetenzen verfügen, um ihre Aufgabe zu erfüllen.

Die effizienteste und wirksamste Methode, Informationen an ein und innerhalb eines Entwicklungs-Teams weiterzuvermitteln, ist das direkte Gespräch.

In vielen Situationen ist persönliche Kommunikation das Beste, keine Frage. Manchmal jedoch sind andere Kommunikationsmedien geeignet, wie z.B. dann, wenn man aktuelle Statusberichte an 20 Mitarbeiter senden will. Relevante Dokumentation muss ebenfalls schriftlich festgehalten werden – nicht unbedingt für den Tag, an dem das Projekt beendet ist, sondern für die Zeit danach, wenn all diejenigen, die die Lösung ursprünglich entwickelt haben, weg sind. Diese Dokumentation sollte ausschließlich wichtige Informationen enthalten. Support-Teams halten nur selten die Dokumentation auf dem aktuellen Stand, daher kann sie im Laufe der Zeit an Wert verlieren.

Lauffähige Software ist der primäre Maßstab des Fortschritts.

In der iterativen Entwicklung ist es ein guter Maßstab für Fortschritt, wenn man am Ende jeder Iteration eine lauffähige Software vor sich hat. Es können jedoch nicht alle Projekte mittels iterativer Entwicklung durchgeführt werden, wie z.B. die Implementierung von Paketen. In den meisten Projekten müssen Sie daher weiterhin den Plan mit Hilfe von wichtigen Meilensteinen überwachen, um sicherzugehen, dass Sie sich noch im Rahmen des Terminplans bewegen.

Agile Prozesse fördern nachhaltige Entwicklung. Die Sponsoren, Entwickler und Anwender sollten in der Lage sein, ein beständiges Tempo unbegrenzt durchzuhalten.

In der agilen Entwicklung wird eine 40-Stundenwoche und ein Tempo, das sich unbegrenzt halten lässt, großgeschrieben. Wenn Planung und Management stimmen, ist das natürlich auch der beste Ansatz.

Ständiges Achten auf technische Exzellenz und gutes Design steigert die Agilität.

Technische Exzellenz und gutes Design sind von entscheidender Bedeutung. Wenn jedoch die Designarbeit zu kurz kommt, weil in aller Eile lauffähige Software aus dem Ärmel geschüttelt wird, kann dies problematisch sein.

Einfachheit – die Kunst, die Menge der nicht erledigten Arbeit zu maximieren – ist von entscheidender Bedeutung.

Einverstanden. Software-Entwickler und Kunden sollten sich darauf konzentrieren, zuallererst die Kernanforderungen zu befriedigen. Dadurch "maximieren sie die Menge der nicht erledigten Arbeit", und außerdem kann Software dadurch schneller abgeliefert werden.

Die besten Architekturen, Anforderungen und Designs werden von selbständig handelnden Teams geschaffen.

Wenn jedes Team leistungsstark und technisch überlegen wäre, könnte man diesem Punkt leicht zustimmen. Doch die meisten Teams sind noch nicht fortgeschritten und nicht kompetent genug, um die besten Designs und Architekturen zu entwickeln. Insbesondere die Architekturen müssen auf Organisations- oder Unternehmensebene entwickelt werden. Wenn dies einzelnen Teams überlassen bliebe, würde das zu sich gegenseitig überlappenden Technologien und zu Chaos auf Unternehmensebene führen.

Das Team macht sich regelmäßig Gedanken darüber, wie es effizienter werden könnte, und paßt sein Verhalten dann dementsprechend an.

Einverstanden. Teams sollten sich ständig darum bemühen, ihre Stärken und Schwächen zu erkennen, und zu erfassen, wie die Projektmanagement-Prozesse verbessert werden können. Ferner sollten diese vorgeschlagenen Änderungen nach Ansicht des TenStep Prozesses auch in der Organisation eingeführt werden, damit alle Mitarbeiter die Verbesserungsvorschläge wirksam einsetzen können.

—Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
www.agileAlliance.org