Wie verwalten Sie Ressourcen in einem agilen Ansatz mit PMI

In einem Fall mit begrenzten Personen wie 5 müssen Sie einen iterativen Prozess durchlaufen.

Wenn Sie die zu entwickelnden Geschichten so gewichten, verteilen und zuordnen, dass alle gut orchestriert sind und Sie in einen 2-Wochen-Sprint gehen und normalerweise die folgenden "Schritte" durchlaufen

Sprint Nr. 1

Geschichte #N

  • Design
  • Code
  • Gerätetest

Nach Unit-Tests hat eine Ihrer Ressourcen die letzte Story aus dem Sprint abgeschlossen, während andere dies nicht tun, und aus irgendeinem Grund bleiben 1 oder 2 Tage übrig. Diese ungenutzte Ressource, was soll sie tun?

Da bei traditionellen Ansätzen alles nacheinander abläuft, ist meistens jeder zu einem bestimmten Termin oder später als geplant fertig. Auch bei traditionellen Methoden riskieren Sie Nacharbeiten und Neuplanungen, aber wie können Sie diese ungenutzte Ressource in einem Sprint verwalten? Wie verfolgen oder machen Sie es mit diesen exzellenten Geschichtenerzählern, die vor der Zeit fertig sind?

Fwiw, die meisten Leute mögen es nicht, als Ressourcen bezeichnet zu werden :)
In agilen Prozessen weist man keine Arbeit zu; Sie verwenden eine Pull-Warteschlange. Sie zielen auch auf Fluss ab, nicht auf hohe Auslastung. Die Praktiken, die Sie beschreiben, sind nicht wirklich „agil“.
@Erik Ich habe meine Frage für diejenigen bearbeitet, die wortwörtlich empfindlich sind! ;)
@ToddA.Jacobs, danke für deinen Kommentar. Effektiv vermische ich vielleicht Konzepte, weil ich allmählich zum Verständnis des agilen Ansatzes übergehe. Ich muss mehr lernen. Das Team, für das ich arbeite, bewegt sich schnell und passt sich der Agilität an. Ich weiß Ihren Kommentar wirklich zu schätzen.
@ToddA.Jacobs, nehmen wir an, wenn Mitglieder des Teams ihre Aufgaben erledigen und keine weiteren Aufgaben mehr zu erledigen sind, kehren sie zu dieser Pull-Warteschlange zurück? (um nicht zu sagen, sie in die Warteschlange zu schieben) für den nächsten Sprint oder das nächste Projekt verfügbar?

Antworten (3)

Generell gibt es für die Leute immer etwas zu tun. Sie können einem Kollegen bei seinen Aufgaben helfen, einen neuen Trick lernen, eine Dokumentation schreiben, Code bereinigen, mit einem anderen Team sprechen, eine Präsentation zu einem nützlichen Thema vorbereiten, Leuten einen Kaffee spendieren, mit einem Product Owner oder Stakeholder über Ziele sprechen , sich über ein vorhandenes Produkt informieren, das Büro aufräumen oder andere Dinge tun, die auf der Liste „Wir sollten das wirklich beheben, wenn wir Zeit haben“ stehen, die jedes Team hat.

Eines der Hauptziele eines selbstorganisierenden Teams ist, dass Menschen, die im Laufe der Zeit etwas übrig haben, etwas Produktives für sich selbst finden. Wenn Sie das nicht sehen, möchten Sie sie vielleicht auf etwas hinweisen, das getan werden kann, aber lassen Sie sie einfach etwas auswählen, damit sie lernen, in diesen Dingen proaktiv zu sein.

Danke für deine Antwort. Ich verstehe, dass sich der agile Ansatz von traditionellem PM unterscheidet, da Agile kollaborative und selbstorganisierende Teams fördern sollte. Und als ToddA. Jacobs sagt, es gehe nicht um Optimierung. Aber was ich zu verstehen versuche, wenn verfügbare Personen nicht mit dem nächsten Sprint beginnen können, bis alle für das Projekt „ernannten“ verfügbar sind, richtig?
Wenn Sie einen Scrum-basierten Sprint ausführen, hat der Sprint eine feste Dauer. Egal was, es endet an einem bestimmten Tag und der nächste beginnt am nächsten Morgen, und Sie kennen diese Daten, wenn Sie den Sprint starten. Selbst wenn alle zwei Tage früher fertig sind, endet der Sprint erst in zwei weiteren Tagen, sodass die Leute nach mehr Arbeit suchen müssen.
+1 für eine solide Liste mit Vorschlägen. Vergessen Sie auch nicht andere Teams: Können Sie dabei helfen, First-Line-Support, Vertrieb, Marketing oder Operations in einigen neuen Funktionen zu schulen?

@Eriks Antwort ist perfekt, wenn die Situation so ist, dass das gesamte Team die Sprintziele vorzeitig beendet hat.

Wenn nur wenige Teammitglieder vorzeitig fertig sind, sollte ihre oberste Priorität darin bestehen, anderen Teammitgliedern zu helfen, ihre Sprintarbeit zu beenden. Sie möchten, dass die Teammitglieder zuerst an das Team denken und nicht nur an ihre individuellen Leistungen.

Abgesehen davon beobachte ich häufig, dass Entwickler sagen, sie seien "fertig", obwohl sie in Wirklichkeit nur den vollständigen Code haben. Gibt es automatisierte Tests? Ist die Dokumentation fertig? Haben Sie alle relevanten Benutzerhandbücher aktualisiert? Haben Vertrieb und Marketing das Zeug zum neuen Feature? Diese Dinge liegen vielleicht außerhalb Ihrer „Definition of Done“, aber sie sind dennoch wichtig und werden die Qualität der Ergebnisse Ihres Teams steigern.

Während des Sprintprozesses ist das Sprintziel das Teamziel. In meinem Fall beginnen wir jede Geschichte mit der folgenden Sequenz:

  1. Entwickler und QA und Prod Owner (oder BA) haben ein kurzes Meeting, um sicherzustellen, dass sie mit den Story-/Akzeptanzkriterien auf derselben Seite sind. (Erspart uns viel Nacharbeit)
  2. Der Entwickler beginnt mit dem Codieren. Die QA-Person beginnt gleichzeitig mit dem Schreiben von Testfällen (automatisiert und manuell). Sie halten sich während des Sprints gegenseitig auf dem Laufenden.

  3. Wenn sie eine Geschichte beendet haben, bewegen sie sich gemeinsam zu einer anderen Geschichte.

  4. Wenn jemand Leerlaufzeit hat, gibt es immer viele Aktivitäten wie Code-Review, Testskript-Review, Build-Prozessoptimierung, Update-Dokumentation usw.

  5. Wenn noch Zeit übrig ist, suchen wir nach neuen Geschichten ODER wir arbeiten zu zweit (Pair Programming)

Hoffe das hilft.

Sicher. Sehr interessant. Vielen Dank für Ihre Antwort.
Wie verwalten Sie Ressourcen in einem agilen Ansatz mit PMI
AntwortenHierDatenschutz-Bestimmungen1y, 0v