Hallo. Lassen Sie mich über meine Erfahrungen bei der Bewertung von Softwareprodukten berichten. Ich mache das jetzt seit 15 Jahren ohne Unterbrechung und möchte meine Erfahrungen und die Entwicklung meiner Ansichten zur Bewertung teilen. Ich bin sicher, dass es nützlich sein wird. Beginnen wir mit der Zielsetzung. Warum überhaupt messen? Wer braucht das?
Die Antwort ist eigentlich sehr einfach - die Leute wollen Sicherheit, insbesondere die Antwort auf die Frage "Wann wird es fertig sein?" Wann kann ich in den Urlaub fahren, wann der Verkauf beginnt, wann eine verwandte Aufgabe zu erledigen ist? Auf der anderen Seite - Sie wissen nie, was die Leute wollen, warum, weil andere ihre Zeit mit dieser Aktivität verschwenden wollen?
Aber letztendlich möchten wir alle ein Gehalt erhalten, und das Gehalt erscheint nicht aus dem Nichts, das Unternehmen nimmt es aus dem Erlös, in einem separaten Fall - aus Investitionen. Und damit genau dieser Umsatz erzielt werden kann, müssen wir ein Geschäftsziel erreichen. Und Menschen, die Geschäftsziele formulieren, mögen alle Arten von Finanzformeln - ROI, LTV und anderes EBITDA. Und diese Formeln enthalten ständig Fristen. Ohne sie wird das Krokodil nicht gefangen, die Kokosnuss wächst nicht.
Es gibt auch einen zweiten, etwas weniger wichtigen Grund: Wenn die Schätzungen für Features klar sind, wirkt sich dies auf deren Priorität aus. Einfachere Aufgaben erhalten tendenziell eine höhere Priorität. Da beim konventionellen agilen Ansatz der Rückstand regelmäßig aufgerüttelt wird, tragen die Eingabeinformationen zu den Aufgabenbewertungen dazu bei, den Repriorisierungsprozess effizienter zu gestalten.
Als Konsequenz: Höchstwahrscheinlich müssen Sie noch bewerten. Demütige dich .
Lassen Sie uns nun darüber sprechen, wie dies zu tun ist, um nicht alles und jeden im Prozess zu verfluchen. Wie bewerten Leute, die nicht wissen, wie man IT-Inhalte bewertet, normalerweise? So:
- Wir bewerten alle Arbeiten in Personentagen.
- Fügen Sie 10% für alle Fälle hinzu.
- Teilen Sie durch die Anzahl der Entwickler.
- Wir addieren die resultierende Anzahl von Tagen zum aktuellen Datum und erhalten das endgültige Datum.
- Das ist alles.
Aus diesem Grund blinken immer noch vietnamesische Rückblenden aus dem Titelbild vor meinen Augen: Zu viele meiner Nerven gingen in diesem Krieg verloren. Und es wird für Sie sterben, wenn Sie anfangen, auf diese Weise zu bewerten. Das Problem ist, dass dies genau die Art von Einschätzung ist, die von Ihnen erwartet wird:
„Spielen Sie nicht mit Ihren Storypoints herum, zeigen Sie Ihre Hand.“
Welche Probleme werden bei der Bewertung auftreten?
Beginnen wir mit einer idealen Situation:
- Wir haben eine atomare (einfache, unteilbare) Aufgabe.
- Es gibt keine Abhängigkeiten von anderen Aufgaben, es besteht keine Notwendigkeit, etwas zu koordinieren.
- Es gibt eine 100% engagierte Person für die Aufgabe, die weiß, wie es geht.
Auch in diesem Fall stellt sich die Frage: "Wer wird die Bewertung vornehmen?" In diesem Moment startet die unversöhnliche Kontrollmaschine. Erstens denkt der Manager: Wenn der Entwickler dies tun wird, was hindert ihn daran, enorme Arbeitskosten anzugeben, um herumzuspielen? -> Daher bewertet der Manager die Aufgabe selbst. -> Der Manager versteht das Thema jedoch nicht tief genug und sieht die Fallstricke nicht (oder will sie nicht sehen). -> Die Schätzung wird als irreparabel unterschätzt. -> Das Team hält die Frist nicht ein. -> Tod und Verfall.
Die oben beschriebene Situation ist ein klassisches Problem der Unternehmenskultur des Misstrauens gegenüber seinen Mitarbeitern. Die meisten Entwickler haben jedoch eine intrinsische Motivation, interessante Probleme zu lösen. Für sie ist es viel attraktiver als den Narren am Computer zu spielen, daher gibt es keinen Grund für weit verbreitetes Misstrauen. Im Allgemeinen sollte ein Unternehmen auf der Grundlage der Vertrauensvermutung seiner Mitarbeiter aufgebaut werden und normale Geschäftsprozesse nicht so verdrehen, dass sie wie schwarze Schafe aussehen.
Eine Kultur des Misstrauens ist in Verbindung mit einer Unternehmenskultur der Angst sehr verbreitet: Selbst wenn ein Entwickler eine Aufgabe bewertet, was passiert in seinem Kopf während der Bewertung? Er beantwortet die Frage: "Wie reagiert mein Unternehmen auf die Diskrepanz zwischen geplanten und tatsächlichen Terminen?" Wenn der Entwickler wegen der fehlgeschlagenen Fristen beschimpft wird, wird er diese überschätzen. Wenn die weiteren Bewertungen des Entwicklers für die vorab erledigten Aufgaben abgeschnitten werden, wird er die Aufgaben nicht im Voraus übergeben.
Das neueste Beispiel für eine Kultur der Angst ist die Veröffentlichung von Cyberpunk 2077. Das Spiel wurde in ekelhafter Qualität auf Konsolen der vorherigen Generation veröffentlicht. Der CEO des Unternehmens sagte in einer Erklärung, dass "wie sich herausstellt, viele der Probleme, auf die Sie im Spiel gestoßen sind, beim Testen nicht gefunden wurden". Was natürlich eine totale Lüge ist. Probleme waren mit bloßem Auge sichtbar, die Tester konnten dies physisch nicht übersehen. Dies ist eine typische Situation in einer Kultur der Angst: Probleme werden vertuscht. Die Informationen auf dem Weg in die oberste Etage des Managements gingen von „Spiel nicht auf Basiskonsolen spielbar“ zu „Loslassen“.
Wenn dies nicht der Fall ist, können Sie weiter auswerten. Wenn Sie mit der Unternehmenskultur Pech haben, lesen Sie nicht weiter, da Sie Bewertungen nicht zur Genauigkeit, sondern zur Minimierung von Tritten durch die Behörden abgeben müssen. Dies ist eine völlig andere Aufgabe.
Und so haben Sie zum Beispiel eine Schätzung abgegeben - 1 Woche. Dies ist nur Ihre Vermutung, nichts weiter. Die Auswertung bestimmt das geplante Abschlussdatum einer Aufgabe, kann jedoch nicht bestimmen, wann sie tatsächlich abgeschlossen wird. Wo genau der tatsächliche Zeitpunkt der Fertigstellung der Aufgabe angegeben wird, wird durch eine Normalverteilung beschrieben. Erinnern wir uns vorerst nur an dieses Axiom, am Ende wird es eine Wendung in der Handlung geben.
Alles wird noch komplizierter durch die Tatsache, dass einige Aufgaben nicht grundlegend in Teile unterteilt sind und es auch vorkommt, dass sie nicht parallelisiert werden können. Es gibt auch voneinander abhängige Aufgaben, die Sie in den Kontext von Aufgaben eintauchen müssen. Außerdem muss das Team bei der Entwicklung kommunizieren, um seine Aktivitäten zu synchronisieren.
Wir wissen auch nicht, wie wir die Zukunft sehen sollen. Infolgedessen entstehen ständig Aufgaben, die wir nicht vorausgesehen haben und nicht voraussehen konnten. Was könnte es sein?
- Kundenwünsche oder Product Owner.
- Plötzliche Probleme, für die etwas verbessert werden muss.
- Unerwartet legal.
- Und jede Menge Zeug.
Am unvorhersehbarsten ist das Problem der unterschiedlichen Geschwindigkeit der Entwickler.
Für echte Entwickler auf demselben Niveau und mit demselben Gehalt kann sich die Produktivität um eine Größenordnung unterscheiden:
- Jemand wird den Code eine Woche lang ausschneiden und debuggen, und jemand wird die offene Bibliothek in einem halben Tag vermasseln.
- Jemand wird einen Stapelüberlauf rauchen, und jemand hat solche Probleme bereits gelöst und wird sofort davon profitieren.
Infolgedessen verwandelt sich unser Gaußscher in so etwas (die Schätzung sieht gleich aus, wenn die Aufgabe nicht ausreichend groß ist):
Im Allgemeinen ist alles kompliziert, wir graben hier keine Gräben. Wie kann man unter solchen Bedingungen eine gute Note machen?
Gute Notenkriterien:
- Hohe Bewertungsgeschwindigkeit - Die Bewertung selbst hat keinen geschäftlichen Wert. Daher ist es logisch, sie so schnell wie möglich durchzuführen, um nicht von der Entwicklung abgelenkt zu werden.
- Die Bewertung liegt in der Verantwortung des gesamten Teams, und es gibt ein gutes Prinzip „Sie bewerten, Sie tun es“, das das Team vor Höchstmarken schützt.
- Vergessen Sie nicht alle Komponenten der Ausgabe eines Features in der Produktion - Analyse, Entwicklung, Komponententests, Autotests, Integrationstests, Entwickler. All dies muss bewertet werden.
Wie Sie sehen, habe ich nichts über Genauigkeit geschrieben. In den 15 Jahren, in denen ich Schätzungen vorgenommen habe, habe ich nicht gelernt, wie man sie genau erstellt. Seien wir also bescheidener und versuchen Sie, zumindest annähernd zu schätzen. Der gesamte Bewertungsprozess sieht folgendermaßen aus:
- Aufgaben in das Product Backlog aufnehmen.
- Wir bewerten die Storys mit der höchsten Priorität im Backlog mit einer beliebigen Methode (es gibt viele Methoden, über die ich im Folgenden berichten werde).
- Wir fangen an zu arbeiten (zum Beispiel an Scrum - durch Sprints).
- Nach mehreren Sprints messen wir, wie viele Story-Punkte wir durchschnittlich pro Iteration erhalten. Dies ist unsere Geschwindigkeit - durchschnittliche Teamentwicklungsgeschwindigkeit.
- . burndown chart. , .
Da die Welt jedoch nicht perfekt ist, legen wir fest, wie viele neue Funktionen (auch in Story Points geschätzt) unser Product Owner für jeden Sprint generiert. Die rote Linie zeigt das Wachstum des Rückstands an, jetzt ist der Schnittpunkt der roten und blauen Linie das gewünschte Datum.
Wenn der Product Owner sehr kreativ ist, kann es sogar so sein:
Und jetzt erinnern wir uns, dass die Bewertung den Gesetzen der Normalverteilung entspricht, aber die Handlung verdreht - solche Gaußschen summieren sich perfekt. Daher stellt sich Folgendes heraus (dies wird als verbessertes Burndown-Diagramm bezeichnet):
Es scheint, dass der Traum eines jungen Mathematikers wahr geworden ist: Aus einem Haufen Chaos haben wir eine schöne Grafik erhalten und können mit einem cleveren Blick senden, dass „ Mit einer Wahrscheinlichkeit von 50% werden wir im Sprint 14 abschließen, mit einer Wahrscheinlichkeit von 80% im 17. von 95% - im 19. ".
Es gibt eine Reihe von Fallstricken in diesem gesamten Prozess.
Zunächst möchte ich sofort auf den Elefanten im Raum eingehen: Der Rückstand ist groß, es gibt viele Aufgaben, über die nichts bekannt ist, außer der Beschreibung im User Story-Format, sodass die Schätzung in jedem Fall sehr ungefähr ist. Ich habe oben bereits gezeigt, wie eine grobe Schätzung in der Sprache der Mathematik aussieht.
Zweitens ist das Problem "Entwickler arbeiten mit unterschiedlicher Produktivität" im Prinzip in keiner Weise gelöst ... Dies bedeutet, dass wir einen sehr flachen Anstieg der Wahrscheinlichkeit erhalten, was nicht viel dazu beiträgt, Managemententscheidungen zu treffen: „Mit einer Wahrscheinlichkeit von 50% werden wir im 14. Sprint mit einer Wahrscheinlichkeit von 80% abschließen - im 27. mit 95% - in the 39th “- in der Sprache der Mathematik klingt es also wie„ ein Finger zum Himmel “.
Daher maximiere ich persönlich die Metrik "Bewertungsrate" und erkläre Ihnen jetzt die Methoden, die ich ausprobiert habe.
Planung der Pokermethode
Dies ist eine der beliebtesten Bewertungstechniken, wahrscheinlich weil es die älteste ist.
- Die Teilnehmer des Prozesses verwenden Karten, die speziell mit Fibonacci-Nummern nummeriert sind.
- Der Product Owner macht eine kurze Ankündigung der nächsten Geschichte und beantwortet Fragen des Teams.
- Nach Erhalt der Informationen wählen die Teilnehmer des "Pokers" eine Karte mit einer ihrer Meinung nach geeigneten Bewertung aus und zeigen sie niemandem.
- Dann werden alle zusammen enthüllt und die Teilnehmer mit den niedrigsten und höchsten Punktzahlen geben kurze Kommentare ab, in denen sie ihre Wahl der Punktzahl erläutern.
- Als Ergebnis des Diskussionsprozesses trifft das Team eine einzige Entscheidung und fährt dann mit der nächsten Geschichte fort.
Während einer einstündigen Sitzung können Sie auf diese Weise 4 bis 8 Geschichten auswerten. Dies ist das größte Problem bei dieser Methode - es ist lang, die Leute langweilen sich und werden abgelenkt. Nicht umsonst habe ich den Satz "Alle werden zusammen offenbart" verwendet.
Die "Bauordnung" -Methode
Dies ist der Ansatz, den wir derzeit bei der Arbeit verwenden. Es geht darum, Aufgaben relativ zueinander zu bewerten. Auf diese Weise wird eine nach Schwierigkeitsgraden sortierte Abfolge von Aufgaben erstellt. Für diese Methode müssen Sie zuerst einen Pool ausgewerteter Aufgaben sammeln und auf der Waage platzieren.
- Wenn es Zeit für eine Bewertung ist, wechselt sich jedes Teammitglied ab (wie in einem Brettspiel). Die Bewegungen können wie folgt sein: Legen Sie die Aufgabe auf die Waage, verschieben Sie die Aufgabe entlang der Waage, diskutieren Sie die Geschichte mit Kollegen, überspringen Sie Ihre Bewegung.
- Infolgedessen bewegen sich die Aufgaben ständig im Vorstand, und ihre Bewertung im Verhältnis zueinander wird verfeinert, bis ein Zustand erreicht ist, der das gesamte Team zufriedenstellt.
- Wenn alle Teilnehmer nicht an der Reihe sind, sind Sie fertig.
Dies ist eine schnelle Technik. Mit seiner Hilfe können Sie 15 bis 20 Geschichten pro Stunde schätzen, was normalerweise völlig ausreicht.
Große / kleine / obskure Methode
Ich habe es mehrmals benutzt, aber es hat keine Wurzeln geschlagen.
- Auf der Tafel sind drei Zonen markiert: "große Aufgabe", "kleine Aufgabe" und "unzureichende Informationen".
- , «/». « » = « ».
- .
Die Methode hat ein großes Plus - sie ist super schnell. So können Sie 50 User Stories pro Stunde verarbeiten.
Hier gibt es ein Problem bei der Übersetzung dieser Schätzungen in Story-Punkte. Wenn jedoch die Teamgeschwindigkeit bereits bekannt ist, wissen wir, wie viele Story-Punkte eine Person pro Sprint in Jira kaut und kleine Aufgaben rund um diese Metrik bewertet.
Wie für den Rest der Aufgaben. Ich habe Aufgaben aus dem Bereich "Unzureichende Informationen" an Analytics und Aufgaben aus dem Bereich "Große Aufgabe" an die Zerlegung gesendet, damit sie bei der nächsten Sitzung neu bewertet werden können.
Aus diesem Grund zeichnen wir in unserem Produkt einfach eine Roadmap mit Funktionen, von denen wir glauben, dass wir in naher Zukunft Zeit zum Schreiben haben werden. Wenn wir keine Zeit haben, passiert es. Und wir verwenden Schätzungen nur für die unmittelbaren Aufgaben, die wir normalisiert haben, und selbst dann nicht immer.
Vielleicht bin ich damit beschäftigt, meine Inkompetenz im Bereich der Bewertung pseudowissenschaftlich auszudrücken, aber für mich persönlich sieht der Prozess selbst ziemlich dumm aus, wie ein seltsamer Frachtkult, den wir spielen, um so zu tun, als wären wir gleich stabil und vorhersehbare Industrie. Wie jede andere wirklich stabile und vorhersehbare Industrie. Ich würde gerne über Ihre Erfahrungen in diesem Bereich lesen, vielleicht fehlt mir etwas.