Scrum - Wie sollte Teilzeit Entwickler Fortschritt im Burndown Diagramm visualisiert werden

Question

Wir haben bis zu mehreren Teammitgliedern, die nicht 100% in unserem Team arbeiten. Sie könnten argumentieren, dass dies in erster Linie eine schlechte Idee ist, aber nehmen wir an, wir können nichts dagegen tun. Ich hatte eine Diskussion mit einem der anderen Teammitglieder, und mein Argument ist, dass die Burndown-Tabelle uns "lügt". Lassen Sie mich Ihnen ein Beispiel geben.

Sagen wir, wir haben einen Sprint, der 2 Wochen dauert. Wir haben 6 Mitglieder, von denen 2 nur 50% arbeiten. Wenn beide Teilzeitmitglieder 100% in der ersten Woche und 0% in der zweiten Woche arbeiten, ist mein Argument, dass der Burndown nach einer Woche viel besser aussehen wird als die Realität. Scrum sagt, dass es Zeit ist, dem Sprint Features hinzuzufügen.

Ich habe einen alternativen Weg gesehen, dies zu tun, wo Sie vorher die Tage eingeben, die Sie verfügbar sind, und dann eine nichtlineare ideale Linie haben. Mein erster Vorschlag war Platzhalter zu haben, auch wenn Sie nicht verfügbar waren, aber das wurde ziemlich schnell abgeschossen.

Also frage ich mich; Sollten wir etwas mit dem Burndownchart machen? Ist das Diagramm sogar nützlich? Gibt es andere gute Praktiken, um diese Behinderung zu überwinden?

Wir sind derzeit Städtische Turtle

Answer 1

In Bezug auf die Zeit Entwickler Teil - offensichtlich, es keine ideale Situation, aber es ist nicht wirklich viel von einem Problem mit ihm. Würde Scrum scheitern, wenn einer Ihrer Teammitglieder einen Tag frei nehmen wollte und in nur einer Woche für nur 32 von 40 Stunden zur Verfügung stand? Würde Scrum scheitern, wenn in der Weihnachtswoche niemand arbeiten würde? Nein - auf beiden Konten.

Hier ist der einfachste (und meiner Meinung nach beste) Weg, um mit Ihrer Situation umzugehen: Sie addieren einfach die Stunden, die alle Teammitglieder für die Arbeit in diesem Sprint verfügbar sein werden, z. Wenn Sie ein Team von , mit einem Mitglied bei 100% und zwei bei 50% haben, und der Sprint ist pro Woche, werden Sie 40 + 40/2 + 40/2 = 80 summieren Wie viele Arbeitsstunden muss das Team haben. Es ist nicht anders als wenn Sie zwei Vollzeitmitglieder hätten.

In Bezug auf die Burn-Down-Tabelle - ich denke, dass das Plotten eines nicht-linearen "idealen" Burn-Down ist sowohl eine Verschwendung von Anstrengung, als auch fehlgeleitet. Es gibt einen Grund, warum es heißt ideal. Es ist nicht, weil Sie sich bemühen müssen, an dieser Linie zu arbeiten, aber zu demonstrieren, wie der Abbrand aussehen würde, wenn Sie in einem konstanten Tempo arbeiten würden (könnten).

Erinnern Sie sich an die Funktion dieses Graphen - es gibt dort mögliche Probleme in der Entwicklung. Nicht jede Abweichung vom Ideal ist schlecht. Das Leben ist nicht ideal, und Sie machen sich selbst etwas vor (und schaden sich selbst), wenn Sie sich über den Unterschied aufregen. In der Tat, versuchen, für jede Abweichung Rechnung zu tragen, ist genau die Vorhersagemethode, für die Wasserfall berühmt scheitert, und dass agile Methoden versuchen, von wegzukommen.

Was Sie tun können, ist jede wichtige Abweichung zu notieren, die Sie hatten, verstehen sie und sehen, ob es etwas gibt, was Sie über sie tun können, und passen Sie dann Ihren Prozess an. Das ist besser als zu versuchen, den aktuellen Zustand zu modellieren.

So, um die letzte Frage zu beantworten - Gibt es andere gute Praktiken, um die Behinderung zu überwinden - die Antwort ist, es ist nicht ein Hindernis. Überwinde es, indem du deine Realität akzeptierst und das, was verschwenderisch ist, ignorierst.

Answer 2

Ihre Situation ist ein perfekter Kandidat für Story-Punkte über Stunden. Die relative kombinierte Anstrengung, eine Geschichte zu vervollständigen, wäre für die Fähigkeit Ihres Teams, im Laufe der Zeit einen Wert zu liefern, sinnvoller, unabhängig davon, wie viel Zeit in der Vergangenheit für ähnliche Geschichten ausgegeben wurde.

Es gibt eine sehr bekannte Anekdote über diese Situation, die die Situation auf den Kopf stellt. Stellen Sie sich vor, Sie hätten ein Vollzeit-Team und Sie wüssten genau, welche Stunden sie arbeiten könnten. Stellen Sie sich vor, Ihr Team hätte die besten Scrum-Praktiken und Sie erreichten eine Geschwindigkeit, mit der alle einverstanden waren, mit der sie zufrieden waren. Sind sie jetzt für immer auf diese Geschwindigkeit beschränkt? Ist es denkbar, dass, wenn Sie dasselbe Team zum Ziel haben, die gleiche Geschwindigkeit in weniger Stunden zu erreichen und den Anreiz bietet, einfach früh nach Hause zu gehen, könnte es erreicht werden?

Die Antwort ist ja. Tatsächlich passierte ein echtes Lebensszenario wie dieses in einem großen US-Softwarehaus und dieses Team hat seine Arbeitswoche tatsächlich auf 16 Stunden reduziert !! Ja, 16 Stunden !! Sie taten es, indem sie fortwährend nachjustierten, wie sie sich die Mühe ansahen. Denn wenn Sie Stunden brauchen, um Geschichten zu vergleichen, anstatt komparative Komplexität, wie denken Sie über Dinge wie wiederverwendbare Komponenten oder bewältigen Sie unerwartete Anforderungen von einer Funktion zur nächsten?

Wechsle zu Story-Punkten, werden Sie nie wieder sehen: 0)