2009-10-30 14 views
6

Seit einigen Jahren verwende ich agile Ansätze (XP und Scrum) für meine Projekte mit großartigen Ergebnissen. Aber in allen Fällen waren alle Mitglieder des Entwicklerteams zu 100% an dem Projekt beteiligt.Wie agile Entwicklung zu verwalten, wenn das Team nicht stabil ist?

Jetzt bin ich damit konfrontiert, wenn das Team nicht stabil ist. Zum Beispiel können in einer Iteration vier Leute arbeiten, die nächsten vielleicht nur zwei oder drei.

Ich weiß, dass es schwierig (oder unmöglich) ist, mit der normalen Geschwindigkeit Ansatz zu schätzen, da es zu viel schwanken und nicht stabil sein wird. Was folgt ist, dass man nicht wirklich erwarten kann, am Ende jeder Iteration freizugeben.

Vielleicht ist hier ein anderer Ansatz erforderlich. Greife einfach Sachen aus dem Backlog und durchblättere es einfach und lass es los wenn es möglich ist. I wirklich mag das nicht obwohl ...

Irgendwelche Gedanken?

+0

... community wiki ... – joshcomley

+6

Nein, nicht Community-Wiki. Diese Frage wird eine Antwort haben, die für Wic und sein Team unter diesen Bedingungen funktioniert. –

+4

Ich stimme für das Schließen dieser Frage als Off-Topic ab, da es nicht um die Programmierung geht. –

Antwort

3

Von der Frage, die ich annehmen, dass Sie einige Entwickler haben (wahrscheinlich, 2) zu 100% dem Projekt verpflichtet und einige (eine weitere 2-3) nur an mal teilnehmen.

Eine Sache, die Sie tun können, ist einen anderen Prozess für Core-Entwickler, die zu 100% engagiert sind und alle anderen. Verwenden Sie Ihren normalen agilen Prozess für Kernpersonen und geben Sie ihre Arbeit im normalen Iterationszyklus frei. Machen Sie für Nicht-Kern-Leute wenig Planung und gehen Sie davon aus, dass Ihre (und Ihre) Schätzungen zu einer bestimmten Zeit erfolgen würden. Im Idealfall sollten ihre Änderungen isoliert und durch Core-Mitglieder in einen stabilen Code-Zweig zusammengeführt werden, aber nicht die Architektur und die Team-Rollen eines jeden Projekts erlauben dies.

Der Punkt ist zu trennen und zu isolieren Quelle von Chaos und lassen das Herz eines Projekts und Team unberührt.

+0

Ich mag diesen Ansatz. Immer noch in der Lage, mit dem Kern agil zu sein. Die Arbeit der anderen "unstabilen" Teammitglieder wird meistens als Bonus angesehen, denke ich. Ich denke, dass sie nur arbeiten sollten, um das Kernteam zu unterstützen, und vielleicht nur auf peripheren Geschichten. –

0

Lassen Sie den einzelnen Entwickler, der an der Geschichte arbeiten wird, den Aufwand abschätzen, der zur Fertigstellung der Geschichte erforderlich ist. Sie können historische Abweichungen in den Schätzungen dieses Entwicklers berücksichtigen, aber die Idee ist, dass Sie ihre Schätzungen nehmen und dann herausfinden können, wie viele Geschichten Sie in diesem Sprint beenden können.

1

Vielleicht anstelle agiler Ansätze, können Sie die Dinge mit anderen iterative and incremental approaches verlangsamen. Anstatt Iterationen in Wochen zu messen, wären längere Iterationen (vielleicht in Monaten gemessen) besser, wenn Sie weiterhin Personen aus dem Team hinzufügen und löschen.

Dies bedeutet nicht, dass Sie immer noch einige Agile-Techniken nicht verwenden können. Ich würde immer noch Ihre Backlogs und Burn-Down-Charts behalten, mit der Erkenntnis, dass statt einer Veröffentlichung alle zwei Wochen alle sechs Wochen (ca. 2 Monate) veröffentlicht werden. Wenn Sie neue Entwickler zu erfahreneren Entwicklern hinzufügen, verwenden Sie die Paarprogrammierung, weisen Sie den neuen Entwicklern Bugfixes zu oder weisen Sie die neuen Entwickler den Komponententests zu, um ihnen zu helfen, die Codebasis zu lernen.

+0

Ah, aber agil ist iterativ und inkrementell, ich nehme an, du meinst etwas wie RUP zu benutzen? Habe es benutzt, mag es nicht :-) Ich denke, es wäre nützlich, früh und konsequent zu veröffentlichen (um Feedback zu bitten), aber es ist möglicherweise nicht möglich, genau zu planen, was nur in der nächsten Version enthalten sein wird dass es eine andere Woche geben wird. –

+0

Agile ist iterativ und inkrementell, ebenso wie RUP. Sie können Stücke von allen von ihnen nehmen und wählen und wählen. Stellen Sie sich das wie einen eigenen Prozess vor. –

1

Geschwindigkeit ist nur eine Schätzung.

Naiv, wenn Sie eine bestimmte Geschwindigkeit v mit einem Team von 4 Entwicklern haben, dann mit einer Geschwindigkeit von Ihrer Iteration planen (v/4)*number_of_developers

Sie diesen Wert frisieren kann, wenn die Mitglieder Sie verlieren besonders stärker oder schwächer als der Durchschnitt.

Dies ist im Grunde, was PivotalTracker tut mit seiner Teamstärke Metrik.

+0

Ich dachte darüber nach, aber wenn Sie einen neuen Entwickler (zum Projekt) haben, wird er langsamer sein als ein bestehender Entwickler, einfach weil er die Codebasis nicht kennt. Ich glaube nicht, dass man sagen kann, dass jedes Teammitglied die gleiche Geschwindigkeit hat. –

+0

Einverstanden, weshalb ich denke, Sie müssen es ein bisschen basierend auf den beteiligten Personen täuschen – DanSingerman

+0

Ich glaube nicht, es ist die richtige Antwort. Es ist zu ungenau. –

0

Vergessen Sie nicht, dass die durchschnittliche Geschwindigkeit für die Lookahead-Veröffentlichungsplanung verwendet wird. Das Team ist verantwortlich für die Auswahl in jeder Iteration, wie viele Backlog-Elemente zu übernehmen (obwohl historische Geschwindigkeit kann ihnen helfen).

Wenn Ihre Teamgröße (und damit Geschwindigkeit) von Iteration zu Iteration schwankt, können Sie immer noch nützlich Release-Planung unter Verwendung von Durchschnittsgeschwindigkeiten in den letzten N Sprints, vorausgesetzt, die Teamschwankungen wird sich fortsetzen und damit ihre langfristigen Durchschnitt Geschwindigkeit wird tatsächlich stabil sein.

0

Ihr Hauptproblem besteht darin, dass es dem Team schwer fällt, vorhersehbare Schätzungen und Lieferungen abzugeben, da das Team von Sprint auf Sprint umstellt. Dies kann auch das Engagement und die kontinuierliche Verbesserung des Teams beeinträchtigen.

Dieser Fall könnte tatsächlich gut für einen Kanban-Ansatz geeignet sein. Henrik Knibergs Einführung in Kanban für einen schnellen Überblick.

Viel Glück!

+0

Danke für die Antwort, und ich stimme zu. Aber ich verstehe nicht, wie Kanban dem Team helfen könnte, vorhersagbarere Schätzungen zu geben, obwohl ich mir sicher bin, dass es auf andere Weise hilfreich ist. –

1

Sie haben also ein Projekt mit einer sich ständig ändernden Teamgröße und Ihr Chef möchte, dass Sie ihm eine genaue Schätzung geben, wie lange es dauern wird? Sie können dies tun, solange Sie den Unterschied zwischen genau und präzise beachten. Ihre Genauigkeit hängt weitgehend von der Anzahl der Artikel ab und davon, wie detailliert (zerlegt) jeder Artikel ist; Je mehr Gegenstände Sie haben, desto mehr funktioniert das Gesetz der großen Zahlen für Sie, indem Sie über- und unterschätzt werden.

Ihre Genauigkeit ist eine Funktion des Vertrauens. Beachten Sie, dass Schätzungen keine Einzelpunktwerte sind, sondern ein Bereich mit Zahlen mit einem Prozentsatz an Konfidenz. Zum Beispiel wäre eine richtige Schätzung nicht "2 Wochen", sondern "50% Konfidenz von 2 Wochen, 80% Konfidenz von 4 Wochen".

Wenn ich die Person mit der wenig beneidenswerten Aufgabe war, eine Schätzung für die Fertigstellung eines Projekts zu liefern, das so willkürlich wie im ursprünglichen Beitrag verwaltet wird, würde ich versuchen, einen Bereich basierend auf der minimalen Anzahl zugewiesener Personen zu ermitteln (zB "48 bis 66 Wochen bei 2 Entwicklern [50% bis 80% zuversichtlich]"), und ein Bereich, der mit der durchschnittlichen Anzahl zugeordneter Personen assoziiert ist (zB "25 bis 45 Wochen mit 5 Entwicklern [50% bis 80%] zuversichtlich] "), und verwenden Sie die niedrige Zahl von der durchschnittlichen Zahl zusammen mit der hohen Zahl von der minimalen Anzahl (z. B." 25 bis 66 Wochen gegeben irgendwo von 2 bis 5 Entwickler [50% bis 80% zuversichtlich] "), und selbst dann würde ich einen Haftungsausschluss machen ("plus 10% für die verlorene Zeit wegen Kontextwechsel").

Besser noch, ich würde genau erklären, warum diese Anordnung war, um höflich, suboptimal zu sein, und warum Multitasking ein primärer Wegweiser auf dem Weg zum Projekt Hell ist.

Wie eine andere Person vorgeschlagen hat, könnte die Änderung des Arbeitsablaufs von iterationsbasiert zu flussbasiert (Kanban) eine gute Strategie sein. Mit Kanban bearbeiten Sie wechselnde Projektprioritäten, indem Sie die Priorität von Elementen im Rückstand ändern. Sobald ein Element vom Team erfasst wurde, ist es in der Regel fertig (es fließt den gesamten Workflow durch, Stakeholder dürfen das Team nicht stören, indem sie sich mit der laufenden Arbeit herumärgern). Ich habe Kanban für nachhaltige Ingenieurprojekte verwendet und es hat sehr gut funktioniert. Wie es mit Schätzungen helfen würde, ist der Schlüssel zum kontinuierlichen Fluss, zu versuchen, dass jedes Arbeitselement ungefähr die gleiche Größe hat (1x, 2x, 3x, nicht 10x, 20x, 100x). Sie sollten die Bewegung von Elementen durch den Workflow verfolgen, indem Sie die Daten der Prozessstatusänderungen verfolgen, z. B. Warteschlange 1/15, Entwurf 1/22, Entwicklung 1/24, Test 2/4, Integration 2/7 usw., und dann generieren ein kumulatives Flussdiagramm, um die Zeit-in-Status-Zeitdauern im Zeitverlauf zu bewerten. Das Ausarbeiten, wie lange das Projekt dauern sollte, da Sie die Größe jedes Elements und die Zeit durch den Workflow für Elemente kennen, ist eine triviale Rechenübung, die dem Leser überlassen bleibt.(Die interessantere Frage ist, wie man Constraints erkennt und dann wie man sie entfernt. Tipp: Suchen Sie lange nach Zuständen, da sich Arbeit vor Constraints stapelt.)