Jeder möchte wissen, wie lange das Projekt dauern wird. In diesem Artikel erklären wir, wie Sie dem Manager mithilfe von Zykluszeiten und Zählgeschichten gleichzeitig eine genaue und unsichere Prognose liefern und Ratschläge geben, wann Schätzungen insgesamt zu vermeiden sind.

Celeste spürte den Druck. Ihr Manager Barry wollte eine vierteljährliche Prognose ihres Teams erstellen. Die Aufgabe wurde durch die Tatsache erschwert, dass Celestes Gruppe an mehr als einem Produkt arbeitete: Barry wollte eine Prognose für drei auf einmal erhalten. Jeder von ihnen war Teil eines anderen Projekts.

Die Programmierer der Celeste-Gruppe hatten nicht genügend Informationen, um zumindest einige Prognosen abzugeben, insbesondere für das gesamte Quartal.

Celeste beschloss, Barry zu gestehen und zu sehen, wozu sie kommen. Sie verabredete sich am nächsten Tag und sammelte Daten.

Das Mädchen kam genau um 10 Uhr morgens in Barrys Büro an. Als sie an die Tür klopfte, telefonierte Barry immer noch. Er bedeutete ihr einzutreten und hob einen Finger, um es klar zu machen: Er wird in einer Minute fertig sein.

Sie saß auf einem Besucherstuhl gegenüber seinem Schreibtisch.

Barry legte auf und drehte sich um: "Nun, lassen Sie uns den Zeitpunkt der Projekte besprechen, oder?"

Celeste nickte und sagte: „Ja. Das scheint das zu sein, was in einer solchen Situation getan werden kann. “

Barry runzelte die Stirn. "Es scheint?" Ich brauche spezielle Verpflichtungen. Kein "scheint"! "

Celeste saß bequem da: "Barry, werden Sie unter Druck gesetzt, diese drei Produkte herauszubringen?"

"Wie hast du es herausgefunden?" - Barry schüttelte den Kopf. - Wenn Sie den Leuten aus Vertrieb und Marketing zuhören, wird eine Katastrophe eintreten, wenn wir sie jetzt nicht veröffentlichen. Ich weiß nicht, was ich antworten soll, außer dass alles so sein wird. "

"Aber letzten Monat haben Sie ein Portfolio von Projekten besprochen", erinnert sich Celeste. "Ich dachte, Produkt A hat oberste Priorität."

"Es ist", sagte er. "Und die Produkte B und C haben ebenfalls höchste Priorität."

Celeste verdrehte die Augen: "Aber Sie wissen, dass es nur eine Hauptpriorität geben kann, oder?"

"Ich weiß das, und Sie wissen", sagte er. "Aber meine Kollegen wissen es nicht." Ich brauche eine Prognose darüber, was Sie tun können - also Verpflichtungen - und dann können Sie ein wenig ruhig atmen. “

"An welchem ​​Produkt sollten wir überhaupt arbeiten?", Fragte Celeste.

"Produkt A natürlich", sagte er. "Er ist der am meisten zurückgezahlte."

"Nun, das werden wir tun", sagte Celeste. "Wir sind angespannt und werden A innerhalb eines Monats veröffentlichen." Ihre Aufgabe ist es, diese netten Leute dazu zu bringen, jede Woche an unseren Präsentationen teilzunehmen. Sie sollten sehen, was wir in einer Woche tun. Wenn sie nicht zur Demo kommen, lehne ich es ab, ihnen Informationen zu geben. "

Barry lehnte sich zurück: „Warte. Ich habe die Demo verstanden. Und was ist mit den anderen zwei Monaten? Und warum gibst du ihnen keine Informationen? "

Celeste sagte: „Wenn wir nur an einem Produkt arbeiten würden, könnte ich die Bewertung basierend auf unserem Entwicklungszyklus berechnen. Für Produkt A veröffentlichen wir drei bis vier Storys [Code für benutzerdefinierte Aufgaben] pro Woche. Den tatsächlichen Entwicklungszyklus für die Produkte B und C kennen wir jedoch nicht. "

Barry nickte: "Warum nicht?"

"Die Produkte B und C sind in zwei und drei Monaten geplant", sagte Celeste. - Für Marketing ist es ziemlich weit. Das Problem ist, dass je weiter die Arbeit entfernt ist, desto weniger „Zeit“ die Marketingabteilung mit dem Product Owner zusammenarbeitet, um die Geschichten zu klären. Wir haben keine Ahnung, welche Funktionen in zwei und drei Monaten implementiert werden müssen. Wir müssten wissenschaftlich fundierte Annahmen von Grund auf neu treffen (wissenschaftliche Wild-Ass-Vermutung, SWAG). Das ist normal, ich mache das gerne mit meinen Jungs, aber wir brauchen mehr Details. Welches ist nicht. "

"Warum erzählst du ihnen nichts, wenn sie nicht zur Demonstration kommen?" Fragte Barry.

"Wenn es für sie nicht wichtig ist, unsere Fortschritte zu beobachten und Feedback zu geben, ist ihnen das Timing egal", sagte Celeste. "Sie wollen, dass wir uns verpflichten, ohne unsere Verpflichtungen zurückzugeben." Warum sollte ich Zeit damit verbringen, zu bewerten, ob sie keinen Beitrag leisten möchten? "

Barry erklärte sich bereit, die monatliche "Timebox" an Manager zu "verkaufen", die Druck auf ihn ausüben , um Fristen festzulegen. Celeste wird sicherstellen, dass sich das Team nur auf Produkt A konzentriert. Außerdem hat sie wöchentliche Besprechungen für Demonstrationen geplant, damit das Team seine Arbeit zeigt und Feedback erhält.

Würdest du versucht sein, die Dinge anders zu machen?

Schätzung von Begriffen - nicht triviale Arbeit

Das Schätzen von Fristen funktioniert ebenfalls. Viele Teams nehmen eine solche Routine in ihren regulären Arbeitsplan auf. Eine genaue vierteljährliche Schätzung erfordert jedoch häufig mehr als ein oder zwei Stunden Arbeit.

Es gibt mindestens zwei Probleme bei der Bewertung der vierteljährlichen Leistung. Zu oft sind die Anforderungen nicht vollständig definiert, und wie beim Celeste-Team löst die Bewertung das Team von der dringenden Arbeit am Projekt.

Das Problem ist, dass die Planung der Softwareentwicklung nicht mit der Planung eines Road Trips vergleichbar ist. Wenn Ihre Stadt mehr als eine Ampel hat, sind Sie mit Verkehrsschwankungen vertraut. Ich lebe in einem Vorort von Boston, von wo aus eine Fahrt zum Flughafen sowohl 20 als auch 90 Minuten dauern kann. Meistens 30 bis 45 Minuten. Dies ist eine signifikante Variation für eine 13 km lange Reise.

Und auf einer solchen Reise gibt es keine Innovation. Ich war viele Male am Flughafen und kenne verschiedene Wege, um dorthin zu gelangen. Ich habe mobile Apps, mit denen ich auch unterwegs die schnellste Route finden kann. Obwohl einige Optionen etwas vorhersehbarer sind, kann keine von ihnen garantieren, dass diese bestimmte Reise in 20 Minuten endet.

Die Fahrt zum Flughafen erfolgt auf einer vorgegebenen Strecke und mit gut verstandenen Hindernissen. Die Produktentwicklung ist jedoch eine andere Sache. Das ist Innovation. Mit anderen Worten, wir haben so etwas noch nie gemacht. Wenn es anders wäre, müssten wir keine neue Anwendung schreiben oder ein veraltetes System aktualisieren - wir würden die alte verwenden.

Für eine vernünftige Einschätzung haben wir mehrere Möglichkeiten. Eigentlich drei:

• Sie können die Größenordnung schätzen. Ich denke, das ist nützlich für das gesamte Projekt. „Wir erwarten fünf bis neun Monate Arbeit. Wir werden es besser wissen, wenn wir diese Fragen beantworten und diesen Teil der komplexen Arbeit beenden. “ Die SWAG ist für solche Bewertungen gut geeignet.
• Sie können genügend Informationen über die Anforderungen sammeln und einen angemessenen Kostenvoranschlag erstellen. Das Team muss möglicherweise mit User Stories arbeiten, um eine Prognose mit einer relativ geringen Zeitspanne zu erstellen.
• Es besteht die Möglichkeit, die Arbeit für einen kurzen Zeitraum zu bewerten, beispielsweise für ein oder zwei Wochen. Es kann sich herausstellen, dass die endgültige Prognose nicht ganz korrekt ist. Aber normalerweise ist es nah genug am Ergebnis, um die Leute, die darum gebeten haben, nicht zu enttäuschen.

Welche Prognose benötigen Sie für einen Manager?

Mir ist aufgefallen, dass Manager häufig eine Schätzung der Größenordnung benötigen . In diesem Fall kann das Team eine Prognose erstellen und diese wie folgt melden:

„Wir glauben, dass dieses Projekt fünf Monate dauern wird, wobei 50% Vertrauen in die Genauigkeit dieser Prognose bestehen. Wir sind zu 80% von der Einschätzung von acht Monaten überzeugt. Zehn Monate sind 90% Vertrauen. “

Dies hilft Managern zu verstehen, dass es eine Reihe von Vertrauen gibt. Wenn sie 100% ige Sicherheit wünschen, kann dies mehr als 14 Monate dauern.

Sie können die Spiralmethode anwenden: „Wir konzentrieren uns auf das erste Quartal des nächsten Jahres. Wir wissen nicht genau wann im ersten Quartal, aber wir glauben, dass wir damit umgehen können. " Im Verlauf des Projekts geben Sie Folgendes an: „Wir aktualisieren die Schätzung für einen Zeitraum zwischen Mitte Januar und Mitte März.“ Nachdem Sie noch mehr gelernt haben, sagen Sie: "Irgendwo im Februar, wenn kein Schneesturm passiert." Dann kann man im Januar sagen: "Die dritte Februarwoche."

Ich würde auch eine Reihe von drei Daten empfehlen: „Das optimistische Datum ist Januar. Am realistischsten ist Ende Februar. Am pessimistischsten ist Ende April. “

Geben Sie auf keinen Fall eine eindeutige Bewertung ab. Es verführt St. Murphy (aus Murphys Gesetz) dazu, Ihr Projekt aufzugreifen und böse Dinge zu tun.

In einigen Fällen und in einigen Befehlen kann der Kunde zusätzliche Informationen benötigen. Hier können Sie mit ihm die spezifischen Funktionen besprechen, die implementiert werden, um die Unsicherheiten zu verstehen.

Verwenden Sie die Zykluszeit anstelle der Auswertung

Ich mag keine Prognosen zur Laufzeit der Implementierung von Softwareprojekten oder anderen IT-Projekten, insbesondere von Agile. Stattdessen ziehe ich es vor, dass das Team sehr kleine Geschichten veröffentlicht oder die Arbeit nach Zykluszeit bewertet.

Wenn Sie mit der Terminologie nicht vertraut sind:

• User Stories beschreiben, wie ein Kunde oder Benutzer ein Produkt für einen funktionalen Zweck verwendet („Ich möchte einen Platz reservieren“ oder „Ich muss Smart City-Daten veröffentlichen, um die Transparenzanforderungen zu erfüllen“). Geschichten unterscheiden sich von denen eines Entwicklers, der ein Produkt in Bezug auf Datenbanken und APIs betrachtet.
• Die Zykluszeit bezieht sich auf die Gesamtzeit, die ein Team benötigt, um die Arbeit an einer Story freizugeben. Dies umfasst sowohl aktive Entwicklungszeit als auch Ausfallzeiten, wenn die Arbeit etwas erwartet.

Die Idee ist, die durchschnittliche Zeit zu verstehen, die benötigt wird, um etwas Nützliches zu produzieren (Geschichte).

In Celestes Fall wusste sie, dass ein Team drei bis vier Geschichten pro Woche für Produkt A produzieren kann. Für viele Teams funktioniert das Zählen von Geschichten genau wie andere Bewertungsmethoden.

Wenn das Team noch nie an einem ähnlichen Produkt gearbeitet hat, gilt die vorherige Zykluszeit nicht für dieses neue Produkt. Das Team weiß möglicherweise nicht, wie man Geschichten verfeinert und aufteilt, um mehrere pro Woche zu produzieren. Darüber hinaus ist ihr möglicherweise der Status des Codes und die Verfügbarkeit einer ausreichenden Anzahl von Tests nicht bekannt. Wenn Ihr Team seit mehr als drei Tagen an Geschichten arbeitet, müssen Sie keine Vorhersagen treffen. Zählen Sie die Geschichten und versuchen Sie nicht, mehr als gewöhnlich zu tun.

Wenn ein Team innerhalb von ein oder zwei Tagen anfing, sich mit Geschichten zu befassen, müssen Sie auch keine Bewertung vornehmen. Oft ist eine einfache Berechnung einfacher und genauer.

Warum nicht Geschwindigkeit nutzen?

Sie haben festgestellt, dass ich für die Schätzung der Projektzeit eher die Zykluszeit und das Zählen von Storys als die Geschwindigkeit empfehle. Weil Geschwindigkeit ein Ersatz ist.

Zum Beispiel gehe ich jeden Tag, um fit zu bleiben. Ich folge jeden Tag der gleichen Route und verfolge meine relative Geschwindigkeit. An einem schönen sonnigen Tag gehe ich ungefähr 5,6 km pro Stunde. An einem regnerischen oder heißen und feuchten Tag sinkt die Geschwindigkeit auf 4 km / h. Bei Schnee oder Eis kann ich überhaupt nicht nach draußen gehen, in diesem Fall ist meine Geschwindigkeit 0.

Ich gehe den gleichen Weg. (Ja, es ist langweilig, aber es ist mein Problem). Obwohl ich die gleiche Strecke zurücklege, dauert die Fahrt je nach den Bedingungen unterschiedlich lange. Hier ähneln die Bedingungen der Codebasis und den Tests Ihres Teams.

Wenn die Geschichten klein genug sind, entspricht die Geschwindigkeit der Zykluszeit. Aber zu oft versuchen Manager, Projekte mit sehr großen Geschichten zu bewerten. Das Zählen wird einfacher: „Wir können ein oder zwei Geschichten in einem Zyklus fertigstellen. Welche ein oder zwei Geschichten möchtest du wählen? “

Die Verweigerung der Bewertung ist kein Scherz

Als Barry mit Kollegen über Probleme sprach, sagte einer von ihnen: "Sich zu weigern, die Fristen zu bewerten, ist ein Betrug!"

Barry antwortete: „Nicht wahr. Sie möchten, dass wir ein Produkt veröffentlichen, oder? “

Die Antwort war „Natürlich. Sowohl B als auch C. "

"Das Problem ist, dass sie der Reihe nach erledigt werden müssen", antwortete Barry. - Wenn Sie Produkt A wirklich benötigen, wozu sollten Sie dann eine Prognose für den Rest erstellen? Wir können uns an die Arbeit machen und unsere Fortschritte zeigen. Wenn wir genug getan haben, werden wir das Verfahren für B und C wiederholen. Außerdem haben Sie Zeit, die Anforderungen für B und C zu klären, um uns Geschichten vorzubereiten. “

Das Team von Celeste hat den Großteil von Projekt A in einem Monat abgeschlossen. Die Veröffentlichung von Produkt B dauerte länger - näher an zwei Monaten. Und da das Unternehmen durch die Freigabe der Produkte A und B ausreichende Einnahmen erzielte, verringerte es den Druck auf die Freigabe von Produkt C.

Wissen Sie, welche Note Ihr Manager benötigt. Präsentiere sie, wie er es braucht. Und wenn Sie wenig Zeit haben, machen Sie sich an die Arbeit.

Evaluation von IT-Projekten: Unterricht

• Geben Sie keine bestimmten Zahlen oder Daten an. Geben Sie stattdessen eine Größenordnungsschätzung mit Vertrauen in eine rechtzeitige Veröffentlichung an. Oder schlagen Sie kurzfristige Schätzungen vor, die auf von Ihnen kontrollierten Faktoren basieren.
• Teilen Sie die Projektziele in User Stories ein, die die Softwarefunktionalität definieren. Nehmen Sie dann Ihre Schätzungen basierend auf der Anzahl der User Stories vor, die Sie verarbeiten können.
• Stellen Sie sicher, dass Sie die Anforderungen verstanden haben, bevor Sie Verpflichtungen eingehen.