Prinzipien und Werte der agilen Softwareentwicklung, von Jeff Sutherland

Agile Entwicklung ist ein Begriff, der vom Agile-Manifest abgeleitet wurde. Dieses wurde im Jahr 2001 von einer Gruppe verfasst, zu der die Schöpfer von Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) und Crystal, ein Vertreter der funktionsorientierten Entwicklung sowie weitere Vordenker der Softwareindustrie zählten. Mit dem Agile-Manifest wurden allgemeine übergreifender Werte und Grundsätze für die damals vorhandenen einzelnen agilen Methodiken festgelegt. Die Manifestdetails vier Kernwerte für das leistungsstarker Teams.

• Einzelpersonen und deren Interaktion

• Bereitstellen funktionsfähiger Software

• Zusammenarbeit mit dem Kunden

• Reagieren auf Änderungen

Diese Kernwerte werden von den zwölf Prinzipien unterstützt, die auf der folgenden Website beschrieben sind: Manifesto for Agile Software Development.

Diese Werte stellen nicht nur Lippenbekenntnisse der Unterzeichner des Agile-Manifests dar, die bald vergessen werden. Es sind Werte für die Praxis. Jede einzelne agile Methodik nähert sich diesen Werten auf eine etwas andere Weise. Alle diese Methodiken weisen bestimmte Prozesse und Verfahren auf, denen einer oder mehrere dieser Werte zugrunde liegt.

Einzelpersonen und Interaktionen

Einzelpersonen und Interaktionen sind unverzichtbar für leistungsstarke Teams. In Studien der "Kommunikationssättigung" im Verlauf eines Projekts wurde nachgewiesen, dass Teams ohne Kommunikationsprobleme eine 50-mal bessere Leistung als der Branchendurchschnitt erzielen können. Zur Förderung beruhen, agile Methodiken auf regelmäßigen Überprüfungs- Zyklen. Beispiele für solche Zyklen sind paarweise Programmierung (alle paar Minuten), fortlaufende Integration (alle paar Stunden), Standup-Besprechungen (täglich) sowie eine Prüfung und eine Retrospektive nach jeder Iteration.

Häufigere Feedbacks und Kommunikation sind jedoch nicht ausreichend, um Kommunikationsprobleme auszuräumen. Diese Überprüfungs- und Anpassungszyklen sind nur dann effizient, wenn sich die Teammitglieder durch einige unverzichtbare Verhaltensweisen auszeichnen:

• Achtung vor dem Wert jeder einzelnen Person

• Richtigkeit in jeder Mitteilung

• Transparenz aller Daten, Aktionen und Entscheidungen

• Vertrauen darauf, dass jede Person das Team unterstützt

• Engagement für das Team und dessen Ziele

Um diese Verhaltensweisen zu fördern, muss das Agile-Management eine begünstigende Umgebung bereitstellen, Teamtrainer müssen ihre Annahme erleichtern, und Teammitglieder müssen sie an den Tag legen. Nur dann können Teams ihr vollständiges Potenzial ausschöpfen.

Damit Teams diese Verhaltensweisen ist schwieriger erzielen, als es werden kann. In den meisten Teams werden Aufrichtigkeit, Transparenz und Vertrauenswürdigkeit eher vermieden wegen kultureller Normen oder aufgrund negativer Erfahrungen mit Konflikten, die aus ehrlicher Kommunikation entstanden. Um diese Tendenzen entgegenzuarbeiten, müssen Teamleitung und Teammitglieder die positive Austragung von Konflikten fördern. Wenn Teams in die positive Austragung austauschen, profitieren sie nicht nur produktiveres Verhalten, aber funktionieren auch, um einige weitere Vorteile erzielen:

• Die Prozessverbesserung hängt davon ab, dass die Teammitglieder eine Liste der Hindernisse und Probleme in der Organisation aufstellt, um sie offen in Angriff zu nehmen und entsprechend ihrer Relevanz systematisch auszuräumen.

• Innovation entsteht nur mit dem freien Austausch von in Konflikt stehenden Ideen, einem Phänomen, das von Hirotaka Takeuchi und Ikujiro Nonaka studiert und dokumentiert wurde, die widersprechender von Scrum auf.

• Auflösung von in Konflikt stehenden Tagesordnungen tritt auf, wenn Teams um gemeinsame Ziele entsprechen und ihre Aspekte und Konflikte auftauchen.

• Ein gemeinsames Engagement für die Arbeit ist nur möglich, wenn sich Personen auf gemeinsame Ziele verständigen und sich dann persönlich und im Team für deren optimale Umsetzung einsetzen.

Dieser letzte Gedanke zum Engagement, ist besonders wichtig. Einzelpersonen und Teams müssen sich uneingeschränkt in Sachen Wertschöpfung engagieren – dies ist die unerlässliche Grundlage von Softwareentwicklungsteams. Agile-Methodiken fördern das Engagement und SELFOrganisation durch aufmunternde Teammitglieder, um Elemente aus einer priorisierten Arbeitsliste zu ziehen, ihre eigene Arbeit zu und den Fokus auf die Verbesserung ihrer Arbeitsprozesse zu legen. Diese Vorgehensweisen bilden die Grundlage der SELFOrganisation, die die treibende Kraft beim Erreichen von Zielen in einem agilen Team ist.

Um leistungsstarke Teams aufzubauen, werden bei agilen Methodiken Einzelpersonen und Interaktionen höher bewertet als Prozesse und Tools. Praktisch heißt dies, dass alle agilen Methodiken Kommunikation und Zusammenarbeit durch regelmäßige Überprüfungs- und Anpassungszyklen verbessern. Diese Zyklen funktionieren jedoch nur dann, wenn agile Führungskräfte die positive Austragung von Konflikten ermöglichen. Diese ist nötig, um eine gesunde Atmosphäre der Aufrichtigkeit, Transparenz, Vertrauenswürdigkeit, Respekt und Engagement in ihren agilen Teams herzustellen.

Funktionsfähige Software anstatt einer umfassenden Dokumentation

Funktionsfähige Software ist einer der großen Vorteile, den die agile Entwicklung in sich birgt. In allen agilen Methodiken, die im Agile-Manifest vertreten werden, wird betont, dass dem Kunden in regelmäßigen Abständen kleine Abschnitte von funktionsfähiger Software geliefert werden.

Alle agilen Teams müssen eindeutig vermitteln, was mit "funktionsfähiger Software" gemeint ist, die häufig als fertig gestellte Software angesehen wird. Allgemein gesagt, ist ein Funktionsbereich nur dann abgeschlossen, wenn alle enthalten Funktionen sämtliche Tests bestanden haben und vom Endbenutzer verwendet werden können. Teams müssen mindestens über die Komponententests hinausgehen und auf der Systemebene testen. Die besten Teams schließen in ihre Definition eines abgeschlossenen Funktionsbereichs auch Integrationstests, Leistungstests und Kundenakzeptanztests ein.

Ein CMMI Level 5-Unternehmen 5, das hat bereits eine der niedrigsten Defektkinetik in der Welt angezeigt, hat mit umfassenden Daten auf vielen Projekten die Vorteile von agilen Verfahren. Insbesondere waren die geeigneter systematisch doppelte Geschwindigkeit der Produktion und Defekte um 40 Prozent verringern, indem sie die folgenden Aktionen ausgeführt:. Dieses von einem Unternehmen.

• Definieren von Akzeptanztests, wenn Sie die Funktion definieren.

• Implementieren Sie Funktionen seriell und in Angriff.

• Führen Sie Akzeptanztests für jede Funktion, sobald sie implementiert werden.

• Korrigieren von Fehlern, die identifiziert werden, wie am höchsten so schnell wie möglich.

Das Agile-Manifest empfiehlt, dass Teams funktionsfähige Software in festgelegten Intervallen bereitstellen. Durch das zustimmt, im Team, auf der Erfolg bedeutet, ist eine der praktischen Methoden, die agile Teams die hohe Leistungsfähigkeit und hoher Qualität herbeiführen, die erforderlich ist, um dieses Ziel zu erreichen.

Zusammenarbeit mit dem Kunden vor Vertragsverhandlungen

Im Verlauf der vergangenen zwei Jahrzehnte haben sich die Projekterfolgsraten weltweit mehr als verdoppelt. Diese Verbesserungen traten infolge einer kleineren Projekten und der häufigeren Lieferungen aufgeführt, die die zulässigen Kunden, um das Feedback auf backs funktionsfähiger Software in regelmäßigen Abständen bereitzustellen. Die Autoren des Manifests haben eindeutig einen wichtige Erkenntnis formuliert, als sie betonten, dass die Einbindung des Kunden in den Softwareentwicklungsprozess entscheidend für den Erfolg ist.

Dies wird durch agile Methodiken gefördert, indem ein Vertreter des Kunden eng mit dem Entwicklungsteam zusammenarbeitet. Das erste Scrum-Team hatte z. B. Tausende von Kunden. Da es nicht praktikabel war, sie alle in die Produktentwicklung einzubinden, wurde sie einen Kundenbevollmächtigten aus, einen Produktbesitzer aufgerufen. Der Produktbesitzer kann nicht nur die Kunden im Feld, sondern auch Management, Verkäufen, Unterstützung, Clientdienstleistungen und anderen Projektbeteiligten. Der Produktbesitzer hatte die Liste der Anforderungen alle vier Wochen zu aktualisieren, wenn das Team funktionsfähige Software freigab, sodass die aktuellen Gegebenheiten und das reale Feedback von Kunden und Projektbeteiligten berücksichtigt werden konnten. Geholfene Form der Kunden aktiv die Software, die erstellt wurde.

Das erste XP-Team begann mit einem internen IT-Projekt. Das XP-Team war in der Lage, einen Die täglich zusammenarbeiten mit diesen zu haben täglich. Ungefähr 10 Prozent der Zeit, der Berater und interne Teams einen Endbenutzer gewinnen, der täglich mit dem Team arbeiten kann. Die übrigen 90 Prozent der Zeit müssen sie mit einem Bevollmächtigten zusammenarbeiten. Dieser Kundenbevollmächtigte, der von XP-Teams als Kunde bezeichnet wird, arbeitet mit den Endbenutzern zusammen, um eine eindeutige, nach Prioritäten sortierte Liste von Funktionen zu erhalten, die von den Entwicklern implementiert werden sollen.

Es ist durch tägliche Zusammenarbeit des Kunden (oder Kundenproxys), die Industriedaten anzeigen, dass agile Projekte mehr als doppelt wie die Branchendaten beweisen Projekten im Durchschnitt weltweit haben. Da agile Methodiken den Wert der Kundenverpflichtung erkennen, haben sie in den Entwicklungsteams eine Stelle erstellt, der speziell für den Kundenvertreter eingerichtet.

Reagieren auf Änderungen anstelle von strikter Planverfolgung

Damit Teams erstellen Produkte, die Kunden " und Geschäftswert bieten, Teams müssen auf Änderungen reagieren. Branchendaten verweisen darauf, dass sich während der Entwicklung einer Software mehr als 60 Prozent der Produkt- bzw. Projektanforderungen ändern. Selbst wenn herkömmliche Projekte pünktlich, im Rahmen des veranschlagten Budgets und mit allen geplanten Funktionen fertig gestellt werden, sind Kunden häufig unzufrieden, da das erhaltene Produkt nicht ihren Erwartungen entspricht. " "Humphrey's Law" besagt, dass Kunden nie wissen, was sie möchten, bevor sie die funktionsfähige Software in Händen halten. Wenn Kunden bis zum Abschluss eines Projekts keine funktionsfähige Software sehen, ist es zu spät, um ihr Feedback zu integrieren. Agile-Methodiken sehen Kundenfeedback während des Projekts, damit Teams Feedback und neue Informationen enthalten können, während das Produkt entwickelt.

Alle Agile-Methodiken weisen integrierte Prozesse auf, mit denen die Pläne in regelmäßigen Abständen entsprechend den Feedbacks vom Kunden oder Kundenbevollmächtigten geändert werden können. Die Pläne werden so konzipiert, dass der höchste Geschäftswert immer an erster Stelle steht. Da 80 Prozent des Werts durch 20 Prozent der Funktionen geliefert wird, werden optimal ausgeführte agile Projekte häufig vorzeitig abgeschlossen, während die meisten traditionellen Projekte später als geplant beendet werden. Dies führt zu zufriedeneren Kunden, und auch die Entwickler haben mehr Spaß an ihrer Arbeit. Agile-Methodiken basieren auf der Erkenntnis, dass für den Erfolg Änderungen eingeplant werden müssen. Daher wurden Prozesse implementiert (z. B. Prüfungen und Retrospektiven), anhand derer Prioritäten regelmäßig entsprechend den Kundenfeedbacks und dem Geschäftswert verschoben werden.

Agile ist ein Überbegriff - Methodiken sind Implementierungen

Agile Entwicklung stellt keine Methodik an sich dar. Es handelt sich vielmehr um einen übergreifenden Begriff, mit dem verschiedene agile Methodiken beschrieben werden. Bei der Unterzeichnung des Agile-Manifests im Jahr 2001 zählten hierzu Scrum, XP, Crystal, FDD und DSDM. Seitdem wurden Lean-Prozesse als weitere wertvolle Agile-Methodik eingeführt, die daher in der Abbildung später in diesem Thema ebenfalls aufgeführt sind.

Jede agile Methodik weist einen etwas anderen Ansatz zum Implementieren der Kernwerte des Agile-Manifests auf, ebenso wie viele Computersprachen die Kernfunktionen der objektorientierten Programmierung auf verschiedene Weise abbilden. Eine aktuelle Umfrage zeigt, dass etwa die Hälfte der Agile-Praktiker darauf verweisen, dass sich ihr Team mit Scrum befasst. Weitere 20 Prozent sagen, dass sie sich für Scrum mit XP-Komponenten entschieden haben. Weitere 12 Prozent verlassen sich ausschließlich auf XP. Da mehr als 80 Prozent der agilen Implementierungen weltweit Scrum oder XP darstellen, liegt der Schwerpunkt von MSF for Agile Software Development v5.0 auf den Kernprozessen und Verfahren von Scrum und XP.

Scrum ist ein Framework für agile Entwicklungsprozesse. Es umfasst keine bestimmten Entwicklungsverfahren. Bei XP hingegen liegt der Schwerpunkt auf Entwicklungsverfahren, es ist jedoch kein übergreifendes Framework der Entwicklungsprozesse vorhanden. Das bedeutet nicht, dass von Scrum keine bestimmten Entwicklungsverfahren empfohlen werden oder dass XP über keinen Prozess verfügt. Im ersten Scrum-Projekt wurden z. B. alle Entwicklungsverfahren implementiert, die nun unter dem Namen XP bekannt sind. Das Scrum-Framework für Softwareentwicklung ist jedoch so konzipiert, dass es einem Entwicklungsteam den Einstieg in zwei oder drei Tagen ermöglicht, wohingegen die Implementierung von Entwicklungsverfahren häufig viele Monate dauert. Daher wurde die Frage, wann (und ob) bestimmte Verfahren implementiert werden sollen, dem jeweiligen Team überlassen. Die Scrum-Mitgestalter Jeff Sutherland und Ken Schwaber empfehlen Scrum-Teams einen sofortigen Start und das Erstellen einer Liste von Hindernissen und eines Prozessverbesserungsplans. Wenn Entwicklungsverfahren als Hindernisse identifiziert werden, sollten Teams als Verbesserungsmöglichkeit über XP-Verfahren nachdenken. Die besten Teams führen ein durch XP-Verfahren ergänztes Scrum aus. Scrum ermöglicht XP die Skalierung, und XP ermöglicht Scrum eine effiziente Funktionsfähigkeit.

In der folgenden Tabelle wird die Austauschmöglichkeit von Schlüsselbegriffen in Scrum und XP veranschaulicht.

Siehe auch

Konzepte

Nachverfolgen der Arbeit mit Visual Studio ALM und TFS

Weitere Ressourcen

MSF für Agile Software Development für Visual Studio ALM