Beste messbare Einheiten für die nicht funktionsübergreifende Teamschätzung

Ich habe ein neues Entwicklungsteam und möchte Story Points für allgemeine Schätzungen verwenden.

Aber ich habe zwei Probleme:

  1. Mein neues Team ist nicht funktionsübergreifend (wir versuchen, dies zu lösen, aber das ist ein langsamer Prozess).
  2. User Stories sind sehr spezifisch und erfordern Detailwissen.

Beim Product Backlog Refinement gehen wir also davon aus, dass in den meisten Fällen eine konkrete Story von einem konkreten Entwickler umgesetzt wird. Offensichtlich wird nur dieser Entwickler seine Story einschätzen (weil nur er das erforderliche Wissen hat).

Aber Story Point sind messbare Einheiten für das gesamte Team, nicht für eine einzelne Person im Team. Wenn wir die Geschichten eines konkreten Entwicklers schätzen, ist ein Story Point eines Entwicklers nicht dasselbe wie ein Story Point eines anderen Entwicklers.

Die Frage ist also:

  1. Ist es eine gute Idee, Story Points in meiner Situation zu verwenden?
  2. Wenn nicht, welche messbaren Einheiten sind besser zu verwenden? Altmodische Mannstunden / ideale Mannstunden oder etwas anderes?
(Frage, bevor ich eine Antwort hinzufüge:) Können Sie Leistungen für jeden Entwickler definieren und diese als Meilensteine ​​verwenden? (Und vergessen Sie nicht, die Integration hinzuzufügen.) Oder probieren Sie das alte EVS-System (Earned Value System) aus. Oder verstehe ich deine Frage falsch?
Können Sie ein Beispiel für eine User Story geben? Bevor ich antworte, möchte ich sicherstellen, dass ich nicht annehme, dass Ihre Stories detaillierte, detaillierte Anforderungen sind und nicht „Als $Typ von Benutzer möchte ich $tun, um $Geschäfte zu machen value"-Format, das Scrum vorschreibt. Schließlich sollen Story Points High-Level-Schätzungen sein, keine detaillierten Schätzungen.
@DannySchoemann Es tut mir leid für die Verzögerung mit meiner Antwort. Wir zerlegen die User Story in technische Aufgaben und trennen Aufgaben in Teilaufgaben (falls erforderlich). Trotz der Tatsache, dass die meisten Stories nicht die parallele Arbeit von zwei (oder mehr) Entwicklern voraussetzen, helfen mir gut getrennte Aufgaben, den Fortschritt gut zu verfolgen. So gibt es kein Problem mit der Überwachung und Steuerung. Das Problem ist, dass wir die Hauptvorteile der Story Points verlieren, wie z. B. ihre relative und universelle Einheit der Kapazität des Teams (mit Hilfe der Hexe können wir nachvollziehen, ob wir die Produktivität des Teams gesteigert haben oder nicht).
@ jmort253 Ich entschuldige mich für die späte Klarstellung. Ja, bei der Schätzung sind unsere Stories bereits gut verfeinert und "detaillierte, tiefgehende Anforderungen". Aber das ist nicht die Wurzel meines Problems. Die Wurzel des Problems liegt darin, dass wir viele technische Systeme und wenige Entwickler haben. Es gibt also viele Fälle, in denen nur ein Entwickler Kenntnisse über das technische System hat und den Arbeitsaufwand damit abschätzen kann.

Antworten (4)

Der Grund für die Verwendung von Story Points ist, dass wir damit die Kapazität des Teams ermitteln können.

Die Frage, die Sie sich stellen müssen, ist, wie das Team, das Sie beschreiben, seine Kapazität am besten ausarbeitet.

Wenn man Grenzen zwischen den Disziplinen erzwingt, dann hat man tatsächlich mehrere Fähigkeiten und nicht nur eine.

Angenommen, das Team besteht aus 5 Entwicklern. 2 Entwickler können nur an Geschichten arbeiten, die sich auf die Datenbank beziehen. 1 Entwickler kann nur am Frontend arbeiten und 2 andere Entwickler können nur an den Webdiensten arbeiten.

In dieser Situation hat das Team eine Kapazität für Datenbankarbeit, eine Kapazität für die Frontend-Entwicklung und eine Kapazität für Webdienste. Das ist noch bevor wir anfangen, über Tests zu sprechen. Gibt es nur einen Tester, der an jedem Bereich arbeiten kann? Führen die Entwickler die Tests durch?

Die Schätzung in Scrum funktioniert am besten, wenn wir davon ausgehen, dass die Teammitglieder an jeder Story arbeiten können. Sie können an einigen Arten von Geschichten besser arbeiten als an anderen, aber sie können immer noch an allen Arten von Geschichten arbeiten. Wenn ein Entwickler nicht weiß, wie man etwas macht, kann er sich schulen lassen oder sich mit einem Entwickler zusammentun, der weiß, wie es geht. Auf diese Weise wird das Wissen im Team geteilt.

Ich würde Ihnen empfehlen, diesen Ansatz für den Wissensaustausch zu übernehmen und jedes Teammitglied bei jeder Geschichte zu schätzen. Sie werden feststellen, dass Entwickler Storys, mit denen sie nicht vertraut sind, hoch und Storys, die sie gut verstehen, niedrig einschätzen. Das ist in Ordnung, lassen Sie das Team einfach zu einer Konsensschätzung kommen, die die Eingaben aller Teammitglieder enthält. Die Art und Weise, wie die Geschwindigkeit berechnet wird, da ein gleitender Durchschnitt dazu neigt, solche Dinge im Laufe der Zeit zu kompensieren.

Wenn das Team nicht funktionsübergreifend werden möchte, sollten Sie besser auf Aufgabenebene als auf Story-Ebene schätzen. Möglicherweise stellen Sie fest, dass die Schätzung in idealen Stunden bei diesem Ansatz nützlicher ist als Story Points.

Das Team möchte zwar funktionsübergreifend werden, aber wir haben derzeit nicht genügend Ressourcen dafür. Zu viel Arbeit, zu viel Wissen zum Teilen und nur wenige Entwickler. Ich hoffe, dass der Fortschritt des Teilens schneller voranschreiten wird, wenn wir mehr Entwickler einstellen können, aber es wird einige Zeit dauern. Ich denke, die Trennung der Kapazitäten für verschiedene Bereiche ist eine interessante Idee, aber ein bisschen kompliziert. Ich neige dazu, Arbeitsstunden anstelle von Story Points zu verwenden, wie Sie in Ihrem letzten Absatz vorgeschlagen haben.
Ich würde das Buch „Agile Estimating and Planning“ von Mike Cohn empfehlen. Es enthält ein Kapitel über das Schätzen idealer Tage.

Story Points sind immer eine gute Idee, die Herausforderung besteht darin, eine Aufgabe zu finden, die alle Teammitglieder verstehen und die dann als „Referenzpunkt“ fungieren kann.

Bei der Schätzung einer Geschichte auf der Grundlage dieser Referenzaufgabe sollte die Person, die über fundierte Kenntnisse zu dem Thema verfügt, nach bestem Wissen und Gewissen erklären, welche Faktoren in der zu schätzenden Geschichte eine Rolle spielen, damit die anderen Teammitglieder dies tun können Schätzen Sie angemessen ab, wie komplex sie im Vergleich zur Referenzaufgabe ist.

Am Anfang wird dies schwierig sein, da das domänenübergreifende Wissen noch begrenzt ist, aber wenn das Team weiter zusammenarbeitet, werden Sie feststellen, dass die Genauigkeit der Schätzungen schnell zunimmt. Das setzt voraus, dass Sie nach jedem Sprint ein retrospektives Meeting abhalten, bei dem sich das Team etwas Zeit nimmt, um zu analysieren, was während des Sprints gut und was schief gelaufen ist, wobei ein Teil davon die anfänglichen Schätzungen der Stories mit der tatsächlich benötigten Zeit vergleicht vervollständigen sie.

Ich befürchte, dass es immer die gleiche Situation sein wird: Der Typ, der genug Wissen über das System hat, wird eine Schätzung abgeben, und alle anderen Teammitglieder werden ihm nur zustimmen. Selbst wenn jemand mit der Einschätzung des bekanntesten Mannes nicht einverstanden ist, wird er kein Wissen haben, mit dem er seine Position argumentieren könnte.

Dies ist wahrscheinlich nicht Ihre Situation, aber dies ist ein inhärentes Problem mit Spieleentwicklungsteams (mein Haupterfahrungsbereich), da es normalerweise keine Überschneidungen in den Fähigkeiten gibt und niemals geben wird, wenn das Projekt größer als ein paar Scrum-Teams ist. In diesen Fällen habe ich in jeder Abteilung separate Story-Point-Schätzungen verwendet, aber es gibt ein paar Nachteile. Erstens kann es die Silo-Mentalität und -Kultur (schlecht) verbessern, und zweitens macht es die Planung sauberer Sprints und Veröffentlichungen viel rätselhafter. Ich muss oft "kleine Lücken füllen" mit möglichen Überschneidungen wie Tests oder Shadowing, um zu erfahren, wie die anderen Abteilungen arbeiten, oder persönliche Ziele zu erreichen. Positiv ist, dass es schnell zeigt, wo Teile des Release-Plans schief sind und/oder Sie möglicherweise Expertenkapazitäten benötigen.

Abgesehen davon (und bevor Sie mich ablehnen :) ), würde ich den Rat von Barnaby Golden empfehlen, mit Betonung auf einem konkreten und greifbaren Plan zum Cross-Training und Paaren mit dem Ziel gemeinsamer Einzelwertschätzungen.

Wie ich Barnaby Golden gesagt habe, ist die Trennung verschiedener Arten von Story Points eine interessante Idee, aber kompliziert für uns. Und Sie haben Recht mit Ihren Bedenken: Die Planung wird viel schwieriger.

Dies ist ein weit verbreiteter Irrtum. Die Leute denken, dass ein funktionsübergreifendes Team ein Team ist, in dem jede Person alle erforderlichen Fähigkeiten besitzt, um die Arbeit zu erledigen.

Ein funktionsübergreifendes Team hat Mitglieder mit unterschiedlichen Fähigkeiten, aber das bedeutet nicht, dass jedes Mitglied über alle Fähigkeiten verfügt.

Mike Cohn sagte einmal:

Wenn mein Team den weltbesten Datenbankentwickler umfasst, möchte ich, dass diese Person erstaunliche Dinge mit unserer Datenbank tut. Ich brauche nicht den weltbesten Datenbankentwickler, um JavaScript zu lernen.

Mein Team besteht normalerweise aus 2 BE-Entwicklern, 2 FE-Entwicklern und 2 QA. Jedes Teammitglied ist in den Schätzprozess eingebunden. Wir machen Scrum Poker komplett. Alle machen mit und geben Input, über die finalen Punkte entscheiden wir im Team.

Das einzige, was Sie beachten müssen, ist:

  • Wenn Sie eine ausgewogene Menge an FE- und BE-Arbeit haben, können Sie mehr Story Points erreichen
  • Wenn die zu erledigende Arbeit auf einer Ebene über einer anderen gewichtet wird, können Sie weniger Story Points erreichen
Beste messbare Einheiten für die nicht funktionsübergreifende Teamschätzung
AntwortenHierDatenschutz-Bestimmungen1y, 0v