Auf den Tag ein Jahr ist es heute her, dass ich erstmals über Extreme Programming geschrieben habe. Seither habe ich mich ausgiebig auch mit anderen agilen Methoden beschäftigt – allen voran mit Scrum, aber auch mit weniger bekannten beziehungsweise verbreiteten Methoden wie Kanban oder Feature Driven Development (FDD).
Interessant ist, dass all diese Methoden eine gemeinsame Forderung implizieren, ohne diese explizit zu formulieren. Diese implizite Forderung besagt, dass die Entwicklung von Software featurebezogen durchgeführt wird. Am ehesten findet man diese Forderung – dem Namen entsprechend wenig verwunderlich – noch in FDD.
Was besagt die Forderung nach featurebezogener Entwicklung? Ich persönlich würde sie wie folgt formulieren:
Der Kundennutzen weniger, aber voll funktionsfähiger Features wiegt höher als der vieler, aber kaum funktionsfähiger Features.
Anders formuliert: Wird ein laufendes Entwicklungsprojekt vorzeitig abgebrochen, kann der Kunde eine Software, bei der 25% der ursprünglich geplanten Features jeweils zu 100% implementiert wurden, zumindest partiell nutzen – eine Software, bei der 100% der ursprünglich geplanten Features jeweils zu 25% implementiert wurden, jedoch gar nicht.
Daraus folgt, dass es in der Regel sinnvoller ist, die Entwicklung an Hand logischer statt physischer Features auszurichten. Zudem bedeutet dies aber auch, dass ein Entwickler zu einem Zeitpunkt nach Möglichkeit nur an einem einzigen Feature arbeiten sollte – und nicht an verschiedenen gleichzeitig.
Auf diese Art kann ein Entwickler effizient dazu beitragen, dem Kunden beständig neue Features zur Verfügung zu stellen zu können, die für jenen einen eigenen Geschäftswert darstellen und den Wert der in der Entwicklung befindlichen Software stetig steigern.
Die Gefahr, dass der Kunde das Projekt auf Grund von fehlenden Resultaten vorzeitig abbricht, sinkt gleichzeitig – es wird also nicht nur der Gewinn für den Kunden erhöht, sondern zugleich auch das eigene Risiko vermindert.
Die verschiedenen agilen Methoden implizieren dieses Vorgehen, zumindest teilweise, formulieren es jedoch nicht explizit:
- Scrum: Scrum fordert, dass das Team am Ende eines jeden Sprints die zuvor für diesen Sprint ausgewählten Backlog Items erledigt hat, wobei jedes dieser Backlog Items als User Story formuliert ist und einen Kundennutzen darstellt – abgesehen von der fehlenden Forderung, dass ein Entwickler zu jedem Zeitpunkt ausschließlich an einer Aufgabe arbeiten sollte, unterstützt Scrum featurebezogene Entwicklung vollständig.
- XP: Extreme Programming fordert, dass die entwickelte Software häufig veröffentlicht wird, jeglicher Code durch Unittests abgedeckt wird, für jeden gefundenen Fehler neue Unittests geschrieben werden und Code sämtliche Unittests bestehen muss, bevor er veröffentlich werden darf. In Kombination folgt daraus, dass kein fehlerbehafteter Code ausgeliefert wird – da zudem gefordert wird, dass jede Iteration den Kundennutzen verbessert, fehlt in XP letztlich nur die gleiche Forderung wie in Scrum.
- Kanban: Kanban ist das Missing Piece zu Scrum und XP – Kanban sagt zwar nichts darüber aus, wie die einzelnen Tasks aufgeteilt werden, beschränkt aber explizit die Last des einzelnen Entwicklers. Dabei wird in Kanban zwar nicht gefordert, dass zu einem Zeitpunkt nur ein Task bearbeitet werden darf, der Ansatz hierfür ist jedoch enthalten. Nicht zuletzt deshalb werden Scrum und Kanban in der Praxis häufig zu Scrumban kombiniert.
- FDD: Feature-Driven Development schließlich fordert die Ausrichtung auf logische Features explizit, wobei der für die Implementierung eines einzelnen Features benötigte Zeitraum nicht länger als zwei Wochen betragen darf. Auch hier gelten also die gleichen Einschränkungen wie bei Scrum und XP.
Fasst man nun die genannten Aspekte in eine Regel zusammen, würde ich diese als Featurebezogene Entwicklung (Feature Related Development) bezeichnen und wie folgt formulieren:
Der Kundennutzen weniger, aber voll funktionsfähiger Features wiegt höher als der vieler, aber kaum funktionsfähiger Features. Daher arbeitet jeder Entwickler stets an nur einem einzigen Feature zur gleichen Zeit, wobei dieses Feature in sich logisch abgeschlossen ist und einen eigenen Kundennutzen darstellt.
Zu guter letzt verbleibt die Frage, wann ein Feature als abgeschlossen gilt – hier zahlt sich eine gute Definition of Done (DoD) aus, die den Prozess der Entscheidung, ob ein Feature abgeschlossen ist oder nicht, transparent und für alle Beteiligten jederzeit nachvollziehbar gestaltet.
In ihrer vollständigen Fassung besagt die Regel Featurebezogene Entwicklung (Feature Related Development) also:
Der Kundennutzen weniger, aber voll funktionsfähiger Features wiegt höher als der vieler, aber kaum funktionsfähiger Features. Daher arbeitet jeder Entwickler stets an nur einem einzigen Feature zur gleichen Zeit, wobei dieses Feature in sich logisch abgeschlossen ist und einen eigenen Kundennutzen darstellt. Ein Feature gilt dann als fertiggestellt, wenn es die Definition of Done erfüllt.
Wird diese Regel beachtet, wird der Nutzen für den Kunden maximiert und das eigene Risiko minimiert – zudem gelten natürlich alle Vorteile agiler Entwicklung wie zeitnahes Feedback weiterhin.