- die Kosten (im Prinzip das verfügbare Personal für das Entwicklungsteam)
- die im Projekt vorgegebene Qualität
- der Termin zu der das Produkt oder Release fertig gestellt werden soll
- die Features, die im Produkt/Release umgesetzt werden sollen
Im agilen Ansatz gibt es im Prinzip nur noch eine Variable in den Einflussfaktoren. In einem geschützten Team (Personal stabil) werden bei gleich bleibender Qualität (durch Test Driven Development und festgelegten Definition of Dones) bis zu einem bestimmten Termin (festgelegt durch den Sprintzyklus) eine variable Menge an Features entwickelt. Fehlen zum Go live notwendige Features, müssen entsprechend weitere Sprints durchgeführt werden. Ist der Termin jedoch fix, ist nur die umgesetzte Anzahl an Anforderungen/Features variabel.
Ein sehr guter Artikel Frank, spricht mir aus meiner (Entwickler-) Seele. Dachte zwar, dass jeder Softwareentwickler, der sein Handwerk gelernt hat, auch vor der agilen Entwicklung erst neue Funktionen angeht wenn die vorherigen erfolgreich abgeschlossen sind, aber die Wirklichkeit ist wohl anders.
AntwortenLöschenDass dieses Konzept aber in der agilen Welt wohl neu/wieder aufgegriffen wird finde ich gut, denn wenn nur noch eine "Ecke" variabel ist, und die sonstigen Einflussfaktoren fix sind, würde dies bedeuten, dass wir am Schluss die Funktionen ausliefern die fertig und fehlerfrei sind, und damit eine höhere Qualität zum Kunden bringen.