Softwarekostenschätzung im agilen Projektmanagement

Einführung

Eines der schwierigsten Dinge in der Softwareentwicklung ist die Bestimmung, wie lange und wie viel es dauern wird, ein neues Softwareprodukt bereitzustellen. Sollte es so schwer sein? Die Antwort ist nicht einfach.

Die Schätzung der Softwarekosten ist von Natur aus schwierig, und Menschen sind schrecklich schlecht darin, absolute Ergebnisse vorherzusagen. Keine zwei Projekte sind gleich; jedes ist einzigartig in dem, was es erreichen will, und einzigartig in der Myriade von Parametern, die seine Existenz ausmachen. Was oberflächlich wie ein einfaches Problem aussieht, ist in der Realität oft viel schwieriger oder technisch anspruchsvoller umzusetzen. Und zweifellos wird es bei dem Projekt „Unbekannte“ geben, die nur identifiziert werden können, wenn sie auftreten.

Darüber hinaus sind keine zwei Menschen gleich, egal ob Sie ein Kunde, ein Entwickler oder ein Benutzer sind. Wir sind mit unseren eigenen Kenntnissen, Erfahrungen, Werten, Erwartungen, Risikoeinstellungen und Anpassungsfähigkeiten vorbelastet.

Das Schreiben hochwertiger Software ist Brot und Butter für erfahrene Ingenieure; Das Erstellen großartiger Softwareprodukte kann für alle Beteiligten ein viel schwierigeres Unterfangen sein.

Aber wenn es um Software geht, ist das Verständnis von Dauer und Kosten der Schlüssel zum Treffen strategischer Geschäftsentscheidungen, und das gilt unabhängig davon, ob Sie ein Startup gründen, eine neue Geschäftsmöglichkeit realisieren oder Ihrem Unternehmen ermöglichen, bessere Leistungen zu erbringen. Das Timing, die Kapitalrendite und der erzielte Nutzen können Ihr Geschäft zum Erfolg führen, erschüttern oder zerstören. Sie werden sich fragen: Was bekommen wir für unser Geld? Können wir unsere Kosten vorhersagen? Was kostet es, das gewünschte Produkt herzustellen? Wann können wir starten? Bekommen wir für unsere Investition ein Qualitätsprodukt? Wird es mit unserem Geschäft wachsen? Wird es einen Geschäftswert liefern?

Wie schätzt man also den Umfang, die Dauer und die Kosten eines Projekts ein? Lassen Sie uns die Schätzung von Agile-Projekten und die Kosten für die Softwareentwicklung untersuchen und wie wir es bei Toptal tun.

Herkömmliche Vertragspreise und Schätzungen

Traditionell haben Softwareprojekte mit nicht agilen Praktiken versucht, die Funktionalität oder den Umfang festzulegen und Zeit und Kosten als Variable zuzulassen. Das verursacht Probleme:

1. Woher wissen Sie, dass die Funktionalität, die Sie zu Beginn eines Projekts festlegen, wirklich die Funktionalität ist, die Ihrem Unternehmen oder Ihren Kunden am besten dient? In den meisten Fällen ändern sich die Funktionalität oder der Umfang, weshalb wir vom „Scope Creep“ hören, dem Ergebnis gewünschter Bedürfnisse, die während des Lebenszyklus eines Projekts identifiziert und als notwendig oder obligatorisch bestimmt werden

2. Wenn die Kosten zu einer Variablen werden, verlieren wir die Kontrolle über den Return on Investment (ROI), den wir erreichen wollen. Erhöhte Kosten sind oft ein Produkt von nicht identifizierten Risiken oder sich ändernden Anforderungen, was bedeutet, dass wir Teammitglieder hinzufügen müssen, um mehr Arbeit im gleichen Zeitrahmen zu erledigen, oder Teammitglieder länger halten müssen. Beides ist nicht wünschenswert

3. Wenn Zeit eine Variable ist, verlieren wir die Kontrolle über die Position in unserem Markt. Vielleicht verpassen wir einen wichtigen Branchentermin oder unsere Konkurrenten bringen ihr Produkt vor uns auf den Markt und verlieren so jeden Wettbewerbsvorteil, den unser Projekt möglicherweise hatte.

Es gibt viele andere Ergebnisse von variablem Zeit- und Kostenaufwand, die oft negativ und unerwünscht sind.

Natürlich versuchen viele Kunden und Organisationen, alle drei Komponenten dieses „magischen Dreiecks“ zu reparieren. Leider ist es fast unmöglich, es realistisch zu erreichen. Es gibt zu viele Elemente, die dieses Ideal in Frage stellen, was letztendlich zu Produkten führt, die einen Bedarf nicht decken, zu lange brauchen, um den Kunden zu nutzen, oder zu viel kosten, um den Geschäftswert zu realisieren.

Agile Verträge für Softwareprojekte

Die Kosten sind ein Produkt aus Zeit und Personen (Teammitglieder). Fügen Sie mehr Zeit hinzu, und Sie erhöhen die Kosten für die längere Beschäftigung von Mitarbeitern. Wenn Sie mehr Teammitglieder hinzufügen, erhöhen Sie die Kosten, um den gleichen Geschäftswert zu erzielen. Die Dinge, die wir wirklich vermeiden wollen. Aus diesem Grund glauben agile Prinzipien daran, Zeit und Teammitglieder festzulegen und den Umfang als variable Komponente zuzulassen.

Was klingt besser und erhöht das Vertrauen der Stakeholder, Fixkosten oder variable Kosten?

Natürlich ist es wichtig, dass ein Produkt hält, was es verspricht und die Bedürfnisse seiner Kunden erfüllt. Es nützt nichts, eine genaue Zeit und einen genauen Geldbetrag aufzuwenden, wenn man am Ende ein Produkt hat, das niemand effektiv nutzen will oder kann.

Agile Verträge konzentrieren sich also auf Folgendes:

• Festpreis-Arbeitspakete – Das gesamte Projekt wird in logische „Mini“-Releases unterteilt, die zum vollständigen Produktergebnis beitragen. Jedes Release ist ein Arbeitspaket, das entsprechend bepreist ist. Wenn ein Arbeitspaket abgeschlossen ist, werden zukünftige Arbeitspakete neu geschätzt, basierend auf dem, was wir aus dem vorherigen gelernt haben. Dies vermeidet unnötige Kontingenzen und ermöglicht eine Neupriorisierung und die Definition neuer/überarbeiteter Funktionen durch den Kunden.

• Vorzeitige Beendigung – Dadurch kann der Kunde versuchen, das Projekt vorzeitig zu beenden, wenn genügend Produkt geliefert wurde und kein weiterer ROI zu erzielen ist, indem ein Projektteam beibehalten wird, das weiterhin nur geringfügige Gewinne erzielt. Diese Klausel ist in der Regel jederzeit zulässig und gilt, solange das Projektteam und der Kunde eine starke, vertrauensvolle und enge Zusammenarbeit unterhalten haben. Der Vorteil für den Kunden besteht darin, dass das Projekt vorzeitig abgeschlossen wird, nachdem alle wertvollen Funktionen geliefert wurden, die erforderlich sind, um das Produkt rentabel zu machen. Im Gegenzug erhält der Lieferant 20 Prozent des verbleibenden Auftragswertes und gleicht das Risiko der Mitarbeiterbindung aus.

• Flexible Änderungen – Änderung ist ein Thema, das stark durch die Adern der agilen Softwarebereitstellung zieht. Wir erwarten, dass wir nicht von Anfang an alles wissen, was wir brauchen, um ein Produkt erfolgreich zu machen. Daher fördern wir Veränderungen auf der Grundlage relevanter Daten und Rückmeldungen, um sicherzustellen, dass das richtige Produkt geliefert wird. Am Ende einer Iteration können Änderungen gegen alte Funktionen ausgetauscht werden, die nicht mehr als notwendig oder prioritär erachtet werden. Solange das Wechselgeld gleichwertig ist, fallen keine weiteren Kosten an. Wenn die Änderung von geringerem Wert ist, kann zusätzliche Arbeit identifiziert oder aus dem verbleibenden Rückstand vorgezogen werden. Diese Klausel ist gültig, solange das Projektteam und der Kunde während des gesamten Projekts eine starke, vertrauensvolle und enge Zusammenarbeit gepflegt haben.

• Zusätzliche Arbeit – Während der Laufzeit eines Projekts können weitere Funktionen identifiziert werden, die im Rahmen des bestehenden Festpreisvertrags nicht erreichbar wären. Für dieses Szenario können entweder zusätzliche neu bepreiste Arbeitspakete am Ende des Projekts hinzugefügt werden oder auf Zeit und Material zurückfallen.

• Gestaffelte Schätzungen – Es gibt zwei Möglichkeiten, wie Schätzungen in einem Agile-Projektvertrag gestaffelt werden können: eine Reihe von Dauer oder eine Reihe von Funktionen. Eine Spanne der Dauer ermöglicht eine Schätzung, dass das Projekt oder Arbeitspaket für einen bestimmten Umfang 12 bis 16 Wochen dauern wird. Das Hinzufügen von Dauer erhöht jedoch die Kosten, da Sie Projektteammitglieder länger behalten, oder es bedeutet, dass sie nicht für die Arbeit an anderen Entwicklungsprojekten freigegeben werden können. Bei Toptal ziehen wir es vor, Funktionen über eine Reihe von Story Points zu verteilen, wobei wir den Umfang als Variable beibehalten, aber versprechen, dem Kunden innerhalb des festgelegten Zeitrahmens des Arbeitspakets oder Gesamtprojekts einen Mindestwert zu liefern.

Denken Sie daran, dass Sie später immer mehr Bereich hinzufügen können. Vielleicht haben Sie begonnen, Einnahmen zu erzielen, Sie haben mehr Benutzer oder niedrigere Kosten. In jedem Fall ist es viel einfacher, mehr Geld und Zeit zu verlangen, wenn Sie bereits eine Rendite oder Verbesserung nachgewiesen haben und einen geschäftlichen Mehrwert liefern.

Unser Ansatz zu Softwarekosten und Preisen

Bei Toptal arbeiten wir eng mit unseren Kunden und Ingenieuren zusammen, um Techniken einzusetzen, die das Vertrauen der Interessengruppen in die Projektdauer und -kosten fördern. Wir arbeiten an der kontinuierlichen Ausarbeitung und Anpassung der Planung von einer anfänglichen hohen Ebene bis hin zu detaillierteren Details, wenn es angemessen und notwendig ist, um Verschwendung zu vermeiden und verwaltete Änderungen zu ermöglichen.

Bei der Ausarbeitung eines Kostenvoranschlags und eines Festpreisprojekts werden die folgenden Schritte durchgeführt:

1. Anfangsumfang auf hoher Ebene

Zu Beginn eines Projekts wissen wir am wenigsten über sein Endergebnis. Es ist töricht, sich vorzustellen, dass es möglich ist, von Anfang an genau zu wissen, welche Funktionen unsere Kunden und Benutzer benötigen.

Wir beginnen also mit einer Projektcharta und einer Reihe von „epischen“ Funktionen auf hohem Niveau, die die Richtung des Projekts auf der Grundlage einer soliden Vision und Ziele leiten

A. Vision und Zielsetzung Was müssen wir bauen? Was müssen Sie erreichen und was sind Ihre Unternehmensziele? Das Verständnis dieser Fragen ermöglicht es uns, den Umfang des Projekts festzulegen. Benötigen Sie einen Prototypen, um eine erste Idee, ein Konzept oder eine Technologie zu testen? Haben Sie ein klares Angebot identifiziert, das in Ihrem Markt getestet wurde, und sind Sie bereit, Ihr erstes Minimal Viable Product (MVP) zu entwickeln? Oder skalieren Sie Ihr bestehendes Geschäft oder Produkt, um es auf die nächste Stufe zu bringen?

B. „Epische“ Funktionen auf hohem Niveau Ohne zu sehr ins Detail zu gehen, sollten Sie die Funktionen definieren, die Ihr Produkt haben muss, um die Bedürfnisse Ihrer Kunden zu erfüllen. Dies ist eine strukturierte „Einkaufsliste“, die das Grundgerüst Ihres Produkts beschreibt; oft werden diese als „User Stories“ oder Epics bezeichnet

C. Moskau-Analyse Die Moskau-Analyse ist eine Technik, die, vereinfacht gesagt, dabei hilft, zu erkennen, was wirklich notwendig ist, um das Produkt rentabel zu machen, und was „nice to have“ ist. Diejenigen, die als „Muss“ gekennzeichnet sind, erfüllen das, was die Benutzer dazu ermutigt, sich mit Ihrem Produkt zu beschäftigen und es anzunehmen. Die als „Sollte“ identifizierten Funktionen werden Ihre Kunden überraschen und begeistern, könnten aber später eingebaut werden. Die „Könnte“-Elemente haben oft keinen signifikanten Geschäftswert, erhöhen möglicherweise nicht die Rendite und haben die niedrigste Ihrer Prioritäten. Die "Won't"-Funktionen könnten eines Tages durchaus wichtig sein, sind aber für diese Projektiteration nicht im Rahmen. Diese jetzt zu identifizieren, kann jedoch dabei helfen, den potenziellen Umfang und die Größe des Produkts für die Zukunft im Auge zu behalten.

2. Vorschlag

Um eine Entscheidung darüber zu treffen, ob mit einem Projekt fortgefahren werden soll, ist es notwendig, diese Entscheidung auf gut informierte Daten zu stützen: Kosten und Dauer. Dies sind die Mindestanforderungen, die Sie sich stellen müssen: Was ist erforderlich, um das gewünschte Produkt zu erstellen? Wann können wir starten? Stimmt dies mit unserer Geschäftsstrategie und unseren Finanzen überein?

Mit den obigen Angaben sind wir in der Lage, Ihnen ein Angebot zu unterbreiten. Unsere Ingenieure werden für die spezifischen Projektanforderungen ausgewählt und arbeiten mit einem Projektmanager zusammen, um mindestens eine technische Lösung, eine geschätzte Dauer, die den bekannten Umfang liefert, und geschätzte Kosten für die Fertigstellung des Projekts abzuleiten.

Wie wir bereits erwähnt haben, wissen wir zu Beginn eines Projekts am wenigsten, was geliefert wird. Wir halten die Funktionen und den Umfang bewusst vage, da sonst alles darauf hindeutet, dass wir genau wissen, was erforderlich ist. Eine Schätzung in diesem Stadium wäre am wenigsten genau, gibt aber Aufschluss darüber, ob es sich lohnt, mit dem Projekt fortzufahren.

Der Vorschlag ist das erste Instrument zur Ausarbeitung der Dauer und Kosten eines Projekts. Sobald ein Angebot akzeptiert wird, können wir fortfahren, um ein Festpreisangebot zu erstellen.

3. Release-Planung

Die nächste Stufe der Schätzungsausarbeitung besteht darin, einen Veröffentlichungsplan zu erstellen, der eine Reihe von Funktionen in einem bestimmten Zeitrahmen bereitstellt. Wir leiten dies aus einer Liste von Funktionen, der Größe des Projekts, der Geschwindigkeit ab, mit der unser Team Qualitätssoftware entwickeln kann, die die Erwartungen eines Kunden erfüllt, und Techniken zum Umgang mit Unsicherheitsrisiken.

A. Product Backlog Das Product Backlog ist einfach eine geordnete Liste von „Epics“ oder „User Stories“, die die für ein Produkt erforderlichen Funktionen darstellen. Diese Liste beginnt wie die zuvor besprochenen Epics, aber zwischen dem zugewiesenen Projektteam, dem Projektmanager und dem Kunden unterteilen wir sie jetzt in aussagekräftigere Elemente. Jeder der Artikel stellt einen Teil des Geschäftswerts für den Kunden dar. Wir gehen an dieser Stelle nicht weiter ins Detail, wir müssen die Akzeptanzkriterien nicht kennen, wir müssen nicht wissen, ob ein Knopf blau oder grün ist, wir müssen nur wissen, dass es einen Knopf gibt, der eine Aufgabe zulässt durchgeführt werden.

B. Schätzung Nun, da wir unsere Liste von Funktionen haben, die als User Stories beschrieben sind, schätzt das Team diese diskreten Elemente von Funktionen mit einer Technik namens „Planning Poker“. Dies ist eine nützliche Technik, die schnelle, zuverlässige Ergebnisse basierend auf Expertenmeinung und analoger Größenbestimmung gewährleistet. Planning Poker weist jedem Gegenstand eine vereinbarte Nummer zu, die seine Größe und Komplexität darstellt. Dies wird als Story Point bezeichnet. Andere Agile-Schätztechniken und -Größen, wie z. B. „ideale Tage“, sind verfügbar.

Am Ende dieses Prozesses werden die Größe des Projekts und die Abhängigkeiten zwischen Features bestimmt. Die Größe wird ermittelt, indem alle Story Points aus den Items im Product Backlog addiert werden. Wenn diese Zahl 120 entspricht, beträgt die Größe unseres Projekts 120 Story Points.

C. Priorisierung Da wir nun einen Rückstand und eine Größe für das Projekt haben, sind wir in der Lage, es mit dem Kunden zu priorisieren. Hier geht es wirklich darum, herauszufinden, was für den Kunden am wertvollsten ist, um die gewünschten Ergebnisse zu erzielen. Das Element ganz oben auf der Liste wird als das wichtigste betrachtet, das zweite Element ist weniger wichtig als das erste und so weiter durch die Liste. Keine zwei Gegenstände können so wichtig wie die anderen sein, die Priorität jedes Gegenstands ist von relativer Wichtigkeit oder Wert zu jedem der anderen Gegenstände.

Dieser Ansatz zur Priorisierung ist ein wichtiger Meilenstein bei der Planung eines Softwareprojekts. Wir wissen jetzt, was für den Kunden wichtig ist und in welcher Reihenfolge die Arbeiten erledigt werden müssen, um Abhängigkeiten zu berücksichtigen, um ein Produkt zu liefern, das den Erwartungen entspricht.

D. Release-Planung Bisher haben wir festgelegt, was das Produkt unserer Meinung nach sein wird und wie groß es ist.

Jetzt bestimmen wir, wie lange es dauern wird, bis ein freigabefähiges Produkt geliefert wird. Der Kunde und das Team, darunter Designer, Ingenieure, Tester, Scrum Master und Projektmanager, arbeiten zusammen, um zu ermitteln, was erreicht werden kann und wie schnell die Arbeit zur Erstellung eines Release-Plans erledigt werden kann.

Der Release-Plan gibt auch Aufschluss darüber, wie das Projekt mit den strategischen Plänen eines Kunden in Einklang gebracht wird.

Und schließlich stellt dieser Plan sicher, dass das Projektteam ein Leitbild hat, das den Weg weist und einen logischen Endpunkt für die Entwicklung definiert.

Bevor wir beginnen, stellen wir sicher, dass wir die vereinbarte Definition von „erledigt“ verstehen. Dies ist ein vorgegebener Satz von Kriterien, die ein Kunde als vollständig akzeptiert und der auch alle technischen Anforderungen erfüllt, um als freigabefähig zu gelten.

Um ein einfaches Szenario zu nehmen, nehmen wir die Gesamtzahl der Story Points, die wir durch die Dimensionierung unseres Rückstands erhalten haben, und dividieren diese durch die von unseren Teams erwartete Geschwindigkeit. (Hinweis: Die Geschwindigkeit wird normalerweise als Bereich ausgedrückt, aber der Einfachheit halber verwenden wir hier eine einzelne Zahl.) Wir arbeiten in zweiwöchigen Iterationen, sodass unsere Geschwindigkeit sich darin widerspiegelt, wie viel wir in einem zweiwöchigen Zyklus mit den verfügbaren abschließen können Kapazität des Teams. Wenn unsere Story-Punkte insgesamt 120 betragen und wir davon ausgehen, 20 Punkte pro Iteration abzuschließen, würde die Gesamtentwicklungsdauer 12 Wochen oder 6 Iterationen betragen. Dazu fügen wir einen Sprint 0 von 2 Wochen und einen Release-Vorbereitungs-Sprint von zwei Wochen hinzu. Insgesamt beträgt unsere Projektdauer 16 Wochen. Es gibt Techniken, die wir verwenden können, um einen angemessenen Risikopuffer in unsere Planung einzubauen, auf den wir später eingehen werden. Aber kurz gesagt, wir nutzen den Puffer, um das Risiko der Ungewissheit zu managen und eine Mindestvereinbarung über die zu liefernden Story Points zu treffen. Das Ergebnis könnte ein Bereich von 90 bis 150 gelieferten Story Points sein, wobei 90 das Minimum wäre, das akzeptabel wäre, um ein brauchbares Produkt zu schaffen.

Wenn das Projekt alternativ bis zu einem bestimmten Datum abgeschlossen werden muss, beispielsweise in 10 Wochen, würde das Team bestimmen, wie viel des Rückstands in dieser Zeit abgeschlossen werden kann. Wenn wir 20 Story Points pro Sprint erwarten, plus Sprint 0 und einen Release-Sprint, würden wir bis zum Ende des Projekts 60 abgeschlossene Points anstreben. Auch hier würden wir versuchen, das Risiko zu steuern, indem wir einen angemessenen Puffer hinzufügen, was zu einem Ziel von 45 bis 75 abgeschlossenen und zur Veröffentlichung bereiten Story Points führen könnte. Die 45 Story Points würden dem akzeptablen Minimum entsprechen, um ein brauchbares und wertvolles Produkt zu liefern. Dies ist ein Szenario, in dem Sie gegebenenfalls ein Teammitglied hinzufügen müssen, um die Geschwindigkeit zu erhöhen.

All dies wird natürlich durch eine qualitativ hochwertige Kommunikation und Zusammenarbeit zwischen allen Parteien unterstützt, um einen Release-Plan abzuleiten, der erreichbar, realistisch und für den Kunden akzeptabel ist.

4. Festpreisvertrag

Sobald ein Release-Plan vereinbart ist, können wir ein Angebot für einen Festpreis-Projektvertrag erstellen. Wie bereits erwähnt, ist es ratsam, die Projektdauer und das Team fest und den Umfang variabel zu halten.

Das Angebot für einen Festpreisvertrag wird zusammen mit einer Leistungsbeschreibung und einem vereinbarten Zahlungsplan geliefert.

Solange Vertrauen, Kommunikation, Zusammenarbeit und die Bereitschaft vorhanden sind, sich auf den Geist eines agilen Softwareprojekts einzulassen, ermöglichen uns alle oben genannten Schritte, ein Angebot mit einem realistischen Maß an Vertrauen zu unterbreiten, dass ein Projekt pünktlich und pünktlich geliefert wird im Budget. Natürlich wird es Fälle geben, in denen ein Projekt zu früh oder zu spät geliefert wird, und wir gehen mit diesen Abweichungen mit größter Transparenz um.

Schätztechniken

Agile Planung und Schätzung werden durch eine Reihe von Techniken unterstützt, die ein Entwicklungsteam verwenden kann, um Vertrauen in ihre Größe, ihren Aufwand, ihre Dauer und ihre Kosten zu gewinnen. Hier sind einige von denen, die unsere Teams verwenden, um den Umfang und die Kosten eines Softwareprojekts abzuschätzen.

Größe schätzen

Die Größe des Projekts ist wirklich eine Einschätzung seines Umfangs, seiner Komplexität, seiner Dimensionen, seines Risikos und seiner Größe. Um eine Analogie zu verwenden, es geht darum zu verstehen, ob wir den Eiffelturm oder die Chinesische Mauer bauen. Der Eiffelturm ist ein hohes, schweres, komplexes Bauwerk, das in einem engen städtischen Umfeld errichtet wurde. Die Chinesische Mauer ist eine relativ einfache, aber lange und robuste Struktur, die sich über viele Kilometer hügeliges Gelände erstreckt.

Obwohl es sich bei beiden um große Projekte handeln würde, sind ihr Umfang, ihre Komplexität, ihre Dimensionen, ihr Umfang und damit ihre Größe unterschiedlich.

Es ist wichtig, Erwartungen mit Schätzungen zu verwalten. Sie sind niemals Vorhersagen, Zusagen oder Garantien. Bei der Erörterung von Gesamtgröße, Gesamtdauer und Gesamtkosten arbeiten wir immer innerhalb von Bandbreiten, um Risiken, Unsicherheiten und Unbekannte zu mindern.

Geschichten, die Merkmale Ihres Produkts darstellen, werden individuell dimensioniert und anhand von Story Points oder idealen Tagen geschätzt. Die Gesamtzahl dieser Einheiten definiert die Gesamtgröße des Projekts.

Story-Punkte

Story Points sind eine Maßeinheit, die die Gesamtgröße einer User Story ausdrückt. Die geschätzte Größe einer Story umfasst alle Aspekte von Design, Engineering, Tests, Codeüberprüfung, Integration usw.

Jede Größe einer Geschichte ist relativ zu einer anderen Geschichte. So kann beispielsweise Geschoss A als ein Punkt, Geschoss B als zwei Punkte und Geschoss C als drei Punkte bemessen werden. Dabei ist Stockwerk C mindestens dreimal so groß wie Stockwerk A und nochmals mindestens halb so groß wie Stockwerk B.

Wenn die folgenden Stories in unserem Product Backlog die zugehörigen Größen haben:

Die Gesamtgröße des Projekts beträgt 12 Story Points.

Ideale Tage

Dies ist ein Maß für die Größe, ausgedrückt in Tagen. Es beseitigt das Konzept von Gemeinkosten wie Unterbrechungen, agile Planungsaktivitäten, das Lesen von E-Mails und andere nicht projektbezogene Aktivitäten. Es konzentriert sich nur darauf, wie lange es dauern würde, wenn Sie ohne Unterbrechung kontinuierlich an etwas arbeiten würden, und nicht auf die Zeit, die von Anfang bis Ende vergangen ist.

Wenn wir auf hohem Niveau schätzen, wenn wir am wenigsten über ein Projekt wissen, würden wir in der Regel an idealen Tagen schätzen, da dies ein einfacheres Konzept ist, um mit der Vergangenheit und Erfahrung in Beziehung zu treten, als eine abstrakte Zahl wie ein Story Point. Vor allem, wenn Geschichten auf hohem Niveau mehr Epen mit wenig Details sind und möglicherweise zusätzliche Elemente enthalten, wenn sie zu einem späteren Zeitpunkt aufgeschlüsselt werden.

Bei der Schätzung auf einer detaillierteren Ebene, beispielsweise einer Geschichte in einem etablierten Produkt-Backlog, kann jeder Ansatz verwendet werden und würde vom Engineering-Team entschieden. Beide Ansätze haben Vorteile und jedes Team wird seine Vorlieben haben.

Techniken zum Schätzen

Gemeinsame Schätzungen Schätzungen werden nicht isoliert vorgenommen. Sie werden vom gesamten Engineering-Team gemeinsam durchgeführt und umfassen Design, Datenbank, Server, Front-End-UI, QA und andere funktionsübergreifende Experten. Dies vermeidet Probleme, nicht alle Aspekte der Arbeit zu berücksichtigen, die erforderlich sind, um ein Merkmal fertigzustellen, und stellt sicher, dass niemand die Last oder das Unglück hat, die Größe eines Merkmals zu über- oder zu unterschätzen. Das kombinierte Team wird alle eine Ansicht haben, die diskutiert und vereinbart werden kann.

Analoge Schätzungen Hier betrachten wir zwei diskrete Merkmale und entscheiden, dass eines relativ kleiner oder größer als das andere ist. Wir können uns eine bestimmte Geschichte ansehen und zustimmen, dass sie klein ist, und wenn wir Story Points verwenden, könnten wir ihr eine Größe von zwei geben. Die nächste Geschichte könnte im Vergleich zur ersten als groß angesehen werden, und wir würden ihr eine Größe von fünf geben. Dies deutet darauf hin, dass ein großes Merkmal mindestens doppelt so groß ist wie ein kleines Merkmal.

Wir würden diese Übung mit allen Geschichten fortsetzen. Sobald wir fertig sind, können wir dann alle kleinen, mittleren, großen und extra großen Stockwerke nebeneinander legen und unsere Größe überprüfen, um sicherzustellen, dass unsere Schätzung ein gewisses Maß an Einheitlichkeit aufweist.

Planning Poker Viel ist über Planning Poker geschrieben worden; Ich habe es auch in meinem vorherigen Blog erwähnt. Eine der besten Ressourcen, um es zu verstehen, ist hier.

Im Wesentlichen kombiniert es Expertenmeinung, Analogie und Teamzusammenarbeit in einem einfachen, schnellen und zuverlässigen Prozess.

Es bringt mehrere Experten zusammen, die am besten geeignet sind, um eine Schätzung auf der Grundlage technischer und fachlicher Erfahrung, eines lebhaften Dialogs und einer fundierten Begründung zu erstellen.

Geschwindigkeit

Die Geschwindigkeit ist ein Maß für die Fähigkeit eines Teams, die Arbeit in einer bestimmten Iteration (oder einem Sprint) zu erledigen.

Es wird als Bereich ausgedrückt, beispielsweise 23 bis 32 Story Points pro Sprint, insbesondere zu Beginn eines Projektlebens. Dies liegt im Allgemeinen daran, dass es schwierig ist, die Geschwindigkeit des Teams genau darzustellen, es sei denn, dasselbe Team hat zuvor an demselben Problem gearbeitet. Beachten Sie, wir beziehen uns auf die Velocity eines Teams und nicht auf die einer Einzelperson!

Wir nutzen Geschwindigkeit, um unsere Releases zu planen und unsere Pläne und Arbeitspakete im Verlauf eines Projekts anzupassen, sodass wir unsere Prognose für die Fertigstellung regelmäßig und genau bis zur Ausführung anpassen können.

Zu Beginn sind wir gezwungen, mit sehr wenigen Daten einen Geschwindigkeitsbereich zu definieren. Wir können historische Werte verwenden, wenn das Team und der Problemraum identisch sind, was oft am wenigsten wahrscheinlich ist. Wir können eine Iteration durchführen, um eine Vorstellung von der Geschwindigkeit eines Teams zu bekommen, das tatsächlich an dem Projekt arbeitet, aber das ist kostspielig und funktioniert nicht, wenn noch Entscheidungen über die Zustimmung zum Start eines Projekts getroffen werden müssen. Oder wir können eine Prognose erstellen.

Das Prognostizieren einer Velocity beinhaltet, die Storys eines Sprints zu nehmen und sie in Aufgaben aufzuteilen, die ausgeführt werden, um die Story zu vervollständigen. Wir schätzten die Anzahl der Stunden, die jede Aufgabe in Anspruch nehmen wird, einschließlich Design, Entwicklung, Tests usw., und bewerteten, wie viel Kapazität das Team in einem bestimmten Sprint haben würde. Eine Kapazität von 70 Prozent für ein unbelastetes Team ist eine gute Basis. Wenn also in einer einfachen Situation die Gesamtstundenzahl, die dem Team zur Verfügung steht, beträgt:

• 4 Teammitglieder * zwei Wochen * 40 Stunden pro Woche = 320 Stunden
• Multipliziert mit unserer 70-prozentigen Kapazität = 224 Stunden
• Addieren Sie alle Feature-Aufgaben und hören Sie bei 224 auf zu zählen
• Nehmen Sie alle abgeschlossenen Features, addieren Sie ihre Story Points und Sie erhalten Ihre Geschwindigkeit, sagen wir 36
• Wenden Sie 20 Prozent auf beiden Seiten an, um einen Bereich zwischen dem niedrigsten und höchsten zu erhalten, um eine geschätzte Geschwindigkeit von 29 bis 43 Story Points zu erreichen.

Die Geschwindigkeit variiert normalerweise in den ersten zwei bis vier Iterationen und stabilisiert sich dann innerhalb eines kleinen Bereichs von Punkten. Während also unsere anfängliche Spanne vor Sprint eins 29 bis 43 betrug, könnte sie bei Sprint vier ein Plateau von 34 bis 38 erreichen. Dies gibt uns dann größeres Vertrauen in die Prognose unseres endgültigen Fertigstellungstermins.

Pufferpläne für Risiken und Unsicherheiten

Alle Softwareprojekte sind mit einem gewissen Maß an Unsicherheit behaftet. Diese Ungewissheit wird weniger, je weiter wir durch das Projekt voranschreiten und je mehr wir über unsere Technologie, Umgebung, Leistung und die Bedürfnisse des Kunden und der Benutzer wissen.

Wir mindern diese Ungewissheit oder dieses Risiko mit einem Puffer im Zeitplan, der eine Fehlermarge in unserer Schätzung und die Unbekannten berücksichtigt, die wir vor Beginn der Entwicklung nicht bestimmen können.

Typischerweise gibt es zwei Puffertypen: Funktion und Zeitplan. Da wir oft einen Festpreis für einen festen Liefertermin definieren, ist es besser, den Feature-Puffer zu verwenden.

Dieser Ansatz gibt uns eine glaubwürdige Risikominderungsstrategie und gibt dem Kunden Vertrauen in das Ergebnis, das er nach Abschluss des Projekts erwarten kann.

Funktionspuffer

Mit einem Funktionspuffer prognostizieren wir, dass wir einen bestimmten Satz von Funktionen liefern, aber idealerweise einen weiteren Satz von Funktionen vervollständigen werden. Dies sollte zumindest den Mindestfunktionssatz widerspiegeln, den der Kunde für notwendig hält, um ein brauchbares Produkt auf den Markt zu bringen, aber es können innerhalb des Zeitrahmens mehr geliefert werden, wenn alle verschiedenen internen und externen Einflüsse dies zulassen.

So kann ein Kunde entscheiden, dass die Funktionen mit der höchsten Priorität aus dem Produkt-Backlog, die sich auf 100 Story Points summieren, am wichtigsten sind. Sie können dann zusätzliche Funktionen in Betracht ziehen, die weitere 30 Story Points ergeben. Das Team wird daher auf der Grundlage von 130 Story Points planen, wobei mindestens 100 bis zum Ende des geplanten Fertigstellungsdatums für den jeweiligen Festpreisvertrag abgeschlossen sein müssen.

Einige abschließende Gedanken

Agilität kann ein sehr schwieriges Konzept sein, das vollständig zu verstehen und zu übernehmen ist. Dies gilt nicht weniger, wenn es um das Management sensibler Themen wie Preis, Umfang und Dauer geht. Leider weiß ich aus erster Hand, dass anspruchsvolle Kunden alles im Voraus repariert haben wollen und gerne dem Lieferanten die Schuld geben, wenn sich alles auflöst. Ebenso kenne ich Anbieter, die sich ins Zeug legen, nicht mehr reagieren und nicht auf Kundenbedürfnisse eingehen. Einen agilen Weg einzuschlagen, basiert im Wesentlichen auf Vertrauen, guten Beziehungen und hervorragender Kommunikation. Dies müssen Werte sein, die von beiden Parteien getragen werden, um ein gesundes Projekt zum gleichen Nutzen, zur Zufriedenheit und zum Erfolg für alle Beteiligten aufrechtzuerhalten. Offenheit und eine konstruktive Haltung gegenüber Zusammenarbeit und Verhandlungen zu wahren, ist der beste Weg, um zu vermeiden, dass Beziehungen schief gehen.

Ich habe mit Kunden gearbeitet, denen es schwergefallen ist, die anpassungsfähige Natur von Agile anzunehmen und eine Befehls-und-Kontrolle-Haltung aufzugeben. Es ist schwer, loszulassen und all sein Vertrauen in ein Team zu setzen, das man nicht kennt. Häufig möchten Kunden möglicherweise alle Anforderungen im Voraus als Spezifikation für das, was geliefert wird, erstellen. Dies gibt ihnen das Gefühl, dass der Umfang eines Projekts genau definiert ist. Als erfolgreicher Ansatz erweist sich dies aber letztlich nicht. Wenn wir in einem Vertrag auf Umfang und unrealistische Forderungen festgelegt sind, treten sehr schnell Probleme auf.

Wir wissen, dass sich bei diesem Ansatz mit traditionellen Methoden der Umfang ändert, Unbekanntes aufgedeckt wird oder das, was wir dachten, der Kunde wollte, nicht mehr stimmt oder weit daneben liegt. Durch einen adaptiven Ansatz in Bezug auf Preisgestaltung, Planung und Umfang können Kunden wirklich erkennen, dass ihr Produkt genau den Anforderungen ihres Marktes entspricht. Es ermöglicht einem Anbieter, reaktionsschnell, einfallsreich und effizient zu sein. Die Zusammenarbeit zwischen Kunde und Anbieter bei Vertragsverhandlungen zu nutzen, ist von entscheidender Bedeutung.

Anbieter müssen ehrlich sein und Kunden müssen von Anfang an realistisch sein, was erreicht werden kann. Ein Anbieter, der unrealistische Ziele verspricht und dann die Kosten erhöht, kann den ersten Vertrag gewinnen, wird aber bald die Gunst eines verärgerten Kunden verlieren. Allzu oft zerbrechen Beziehungen aufgrund eines Mangels an Vertrauen oder Zuversicht zwischen den Parteien. Vertrauen muss von Anfang an aufgebaut und im Laufe eines Projekts aufrechterhalten werden. Ein Anbieter muss flexibel sein und mit sich ändernden Anforderungen kooperieren. Kunden wollen immer mehr; es ist eine natürliche Folge der Geschäftstätigkeit. Es muss einen gleichwertigen und vorteilhaften Werteaustausch zwischen beiden Seiten geben. Für Kunden möchten sie einen Mehrwert für ihr Unternehmen schaffen. Anbieter sollten Wert schaffen, indem sie langfristige Beziehungen zu Kunden aufbauen. Die Einhaltung der Werte und Leitprinzipien des Agilen Manifests ist eine solide Grundlage für den Aufbau starker, ausgewogener und langfristiger Beziehungen.

Zusammenfassung

Ich hoffe, dies hat Ihnen einen Einblick in die Planung, Schätzung und Festlegung eines Preises für ein agiles Softwareprojekt gegeben. Alle oben genannten Ansätze und Techniken sind darauf ausgelegt, Vertrauen in ein Team aufzubauen und Vertrauen in den Köpfen der Kunden darüber aufzubauen, wie lange und wie viel es dauern wird, ein Softwareprodukt zu entwickeln. Und letztendlich, um Vertrauen aufzubauen, um eine Entscheidung zum Fortfahren zu treffen.

Befolgen Sie diese Richtlinien und Sie werden sicher einen zufriedenstellenden Weg finden, um Ihr Softwareprodukt zum Leben zu erwecken.