it-swarm-eu.dev

Das Team erreicht die Sprintziele ständig nicht

Wir sind ein kleines Softwareunternehmen mit einem Produkt.

Wir verwenden scrum und unsere Entwickler wählen die Funktionen aus, die sie in jeden Sprint aufnehmen möchten. Leider hat das Team in den letzten 18 Monaten nicht einmal die Funktionen geliefert, die es für einen Sprint festgelegt hat.

Ich habe viele Beiträge/Antworten gelesen, in denen es heißt: "Software ist fertig, wenn sie fertig ist, nicht früher, nicht später ... es hilft nicht, Druck auf das Team auszuüben, mehr Leute darauf zu setzen." ... "Ich habe von einem der Entwickler ein ähnliches Feedback zu meiner Frage erhalten, wie wir die Erfolgsquote von Sprints verbessern können. Oh, und ja, wir verwenden Rückblicke .

Meine Frage ist im Grunde:

Wann ist es fair, nach dem Problem in der Qualität der Entwickler zu suchen?

Ich fange an zu denken, dass, wenn Sie Ihre eigenen Arbeiten/Funktionen auswählen und trotzdem jeden Sprint nicht bestehen können: - Sie nicht in der Lage sind, die Komplexität Ihres eigenen Codes zu überwachen; - oder der Code ist so komplex, dass niemand die Komplexität überwachen kann.

Vermisse ich etwas

126
Orca

Sie sollten zuerst fragen: "Wen interessiert das?"

Das Abschließen von Sprints fühlt sich gut an und führt in einigen Unternehmen zu Cookies vom Scrum-Elternteil. Der ultimative Test ist jedoch, ob das Unternehmen seine Ziele erreicht.

Das Obige ist scherzhaft. Wenn das Unternehmen erfolgreich ist, ohne den geplanten Inhalt eines Sprints zu vervollständigen, können Sie stattdessen auch Kanban verwenden: Sie sortieren den Rückstand, arbeiten an den wichtigsten Aufgaben und sorgen sich nicht so sehr um definierte Iterationen.

Einer der Werte definierter Iterationen besteht darin, die Prozessverbesserung voranzutreiben (oder in einigen Mentalitäten Underperformer auszutreiben). Das verstehst du jetzt nicht. Sie können also entweder den Rest des Prozesses übernehmen, der den Prozess verbessert (und schließlich Sprints abschließt), oder Sie können entscheiden, dass Ihnen das gefällt, was Sie haben.

151
bmargulies

Vermisse ich etwas

JA!

Du bist gegangen 18 Monate - oder irgendwo in der Nähe von 36 Sprints mit Rückblick, aber irgendwie konnte ich es nicht reparieren? Das Management hat das Team nicht zur Rechenschaft gezogen und dann ihre Management hat sie nicht dafür verantwortlich gemacht, dass das Team nicht zur Rechenschaft gezogen wurde?

Sie vermissen, dass Ihr Unternehmen durchweg inkompetent ist.

Also, wie man es behebt. Sie (der Entwickler) hören auf, sich auf so viel Arbeit einzulassen. Wenn die Geschichten so groß sind, dass Sie das nicht können, müssen Sie die Geschichten in kleinere Teile zerlegen. Und dann können Sie die Leute dafür zur Rechenschaft ziehen, dass sie das tun, was sie sagen, dass sie erledigt werden. Wenn sich herausstellt, dass sie bei jedem Sprint nur ein winziges Feature ausführen können, finden Sie heraus, warum und verbessern Sie es (was möglicherweise das Ersetzen des Entwicklers beinhaltet). Wenn sich herausstellt, dass sie nicht herausfinden können, wie sie sich auf angemessene Arbeitsmengen festlegen sollen, Sie feuern sie ab.

Aber vorher habe ich mir das Management angesehen, das die Dinge so lange laufen lässt, und herausgefunden, warum sie nicht ihren Job machen.

128
Telastyn

Ich möchte Ihnen vorschlagen, eine kleine Änderung vorzunehmen und Kanban für ein paar Wochen anstelle von Scrum . Es kann besser für Ihr Team funktionieren.

Während Scrum die Produktivität steigert, indem es die im Sprint verfügbare Arbeitszeit begrenzt, steigert Kanban die Produktivität und Geschwindigkeit, indem es die Anzahl der aktiven, gleichzeitigen Probleme begrenzt. Die Zeitschätzung ist nicht mehr Teil des Prozesses. ( Quelle )

Kurz gesagt, was ist Kanban?

Kanban ist auch ein Werkzeug, mit dem die Arbeit aus Gründen der Effizienz organisiert werden kann. Wie Scrum ermutigt Kanban die Arbeit, in überschaubare Teile zerlegt zu werden, und verwendet ein Kanban-Board (das dem Scrum-Board sehr ähnlich ist), um diese Arbeit im Verlauf des Workflows zu visualisieren. Wenn Scrum die Zeit begrenzt, die für die Ausführung einer bestimmten Arbeitsmenge (mittels Sprints) zur Verfügung steht, begrenzt Kanban die Arbeitszeit, die in einer bestimmten Bedingung zulässig ist (nur so viele Aufgaben können ausgeführt werden, nur so viele können erledigt werden -do Liste.)

Wie sind SCRUM und Kanban gleich?

Sowohl Scrum als auch Kanban ermöglichen es, große und komplexe Aufgaben effizient aufzuschlüsseln und zu erledigen. Beide legen großen Wert auf kontinuierliche Verbesserung, Optimierung der Arbeit und des Prozesses. Und beide teilen den sehr ähnlichen Fokus auf einen gut sichtbaren Arbeitsablauf, der alle Teammitglieder über WIP und die kommenden Entwicklungen auf dem Laufenden hält.

Siehe den Rest des Details von diesem Link

68
user183296

Meine Frage ist im Grunde: Wann ist es fair, nach dem Problem in der Qualität der Entwickler zu suchen?

Ihr Beitrag enthält nicht genügend Informationen, um diese Frage zu beantworten. Es gibt keine Möglichkeit zu wissen, ob sie versagen, weil sie inkompetent sind, oder ob sie versagen, mehr Arbeit zu leisten, als vernünftig ist.

Wenn ich ein unglaublich begabter Entwickler in einem Team von unglaublich begabten Entwicklern bin und wir X-Storys nicht in zwei Sprints (oder 36!) Beenden können, sind wir dann inkompetent? Oder saugen wir nur an der Schätzung? Das hängt davon ab, ob die Geschichten "einen Anmeldebildschirm erstellen" oder "einen Mann sicher zum Mars schicken" waren.

Das Problem beginnt mit schlechten Geschichten und/oder schlechten Schätzungen

Schätzung ist schwer. Sehr hart. Die Menschen saugen daran, weshalb Scrum uns dazu bringt, die Arbeit in Blöcke zu zerlegen, die nicht länger als ein oder zwei Tage dauern sollten, und kleine Gruppen dieser Blöcke zusammenzustellen, von denen wir sicher sind, dass wir sie in kurzer Zeit fertigstellen können . Je größer die Blöcke und je länger der Zeitraum ist, desto ungenauer sind unsere Schätzungen.

Wie sind deine Läden? Sind sie gut geschrieben und haben gute Akzeptanzkriterien? Sind sie alle klein genug, um in nur wenigen Tagen fertig zu werden? Ohne gut geschriebene Geschichten (was die Schuld des gesamten Entwicklungsteams einschließlich des Produktbesitzers ist) kann nicht erwartet werden, dass das Team eine gute Schätzung vornimmt.

Das Problem wird durch schlechte Rückblicke verschärft

Was Sie anscheinend falsch machen, ist, dass Sie keine Rückblicke nutzen. Sie haben 18 Monate vergangen, ohne dieses Problem zu lösen. Entweder bemerkt das Team das Problem nicht oder es wird in den Rückblicken nicht behandelt.

Endet jede Retrospektive mit mindestens einem Aktionspunkt, den das Team ausführen muss, um beim nächsten Sprint besser abzuschneiden? Umfasst jede Retrospektive das Sprechen über die Aktionselemente aus dem vorherigen Sprint, um festzustellen, ob sie ausgeführt wurden und ob sie wirksam waren?

Die Lösung besteht nicht darin, Schuld zu geben, sondern zu lernen

Der erste Schritt sollte darin bestehen, nicht mehr nach Schuld zu suchen und stattdessen daran zu arbeiten, das Team zu verbessern. Ihr Team ist wahrscheinlich nicht inkompetent, nur schlecht in der Einschätzung und Planung. Zwinge das Team, einen Sprint zu beenden, auch wenn dies bedeutet, dass sie eine einzelne Geschichte auswählen und eine Woche früher beenden. Wenn sie das nicht können, sind sie entweder inkompetent oder die Geschichten sind einfach zu komplex. Die Antwort auf diese Frage sollte offensichtlich sein.

Sobald sie in der Lage sind, die eine Geschichte zu beenden, werden sie mit hinreichender Sicherheit wissen, dass sie X Anzahl von Story-Punkten in einem Sprint erzielen können. Einfache Mathematik hilft bei der Beantwortung der Frage, ob sie mehr Geschichten schreiben können oder nicht.

Kontinuierliche Verbesserung ist die Lösung

Sobald sie eine Geschichte in einem Sprint beendet haben, ist es Zeit zu sehen, ob sie zwei schaffen können. Aufschäumen, ausspülen, wiederholen. Wenn sie anfangen, die Sprintziele zu verfehlen, haben Sie die Grenze ihrer Schätzfähigkeiten gefunden. Gehen Sie zurück zu der Anzahl der Story-Punkte aus der vorherigen Story und bleiben Sie eine Weile dabei.

Nehmen Sie die Rückblicke immer ernst. Wenn sie einen Sprint nicht beendet haben, finden Sie heraus, warum und handeln Sie danach. Hatten sie zu viele Unbekannte? Haben sie die falsche Mischung von Fähigkeiten? Wie gut waren ihre Schätzungen? Wenn sie eine Geschichte auf X Punkte schätzten, erforderte sie einen relativ gleichen Arbeitsaufwand wie Prioratsgeschichten mit einem Wert von X Punkten? Wenn nicht, verwenden Sie dies, um die Punkte der zukünftigen Geschichten anzupassen.

61
Bryan Oakley

Sie sagen, Sie "verwenden Retrospektiven." Aber was macht das Team in diesen Rückblicken tatsächlich? Da Sie 18 Monate vergangen sind, ohne diesen Aspekt Ihres Prozesses einmal angesprochen zu haben, lautet die Antwort vermutlich: nichts sehr Nützliches.

Für mich ist die Retrospektive der wichtigste Teil des Prozesses. Werfen oder ändern Sie alles andere über Scrum, was Sie wollen (natürlich im gegenseitigen Einvernehmen des Teams während einer Retrospektive), aber nehmen Sie sich regelmäßig Zeit, um darüber zu sprechen, wie der Prozess für alle funktioniert, teilen Sie, was funktioniert hat und was nicht funktionieren nicht und schlagen Ideen zur Verbesserung vor. Versuchen Sie immer wieder, Ihren Prozess bei jedem Sprint nach und nach zu verbessern, und früher oder später können Sie etwas haben, das ziemlich gut funktioniert.

In Ihrem Fall scheint dieser Prozess nicht zu funktionieren. Da Sprintziele nicht erreicht werden, ist es ratsam, sich nachträglich darauf zu konzentrieren, warum dies der Fall ist. Offensichtlich hat das Team zu viel Arbeit für den Sprint übernommen. Aber warum haben sie das getan?

  • Haben sie die Komplexität der Arbeit unterschätzt?
  • Hat das Management sie unter Druck gesetzt, mehr Arbeit zu übernehmen, als das Team für möglich hielt?
  • Hatten sie zu viele Unterbrechungen/Notfälle, die Ressourcen für die Fertigstellung der geplanten Arbeiten verloren haben?
  • Haben sie Engpässe festgestellt, die den Abschluss der Arbeiten verzögerten (z. B. das Warten auf Assets eines externen Designteams)?
  • Und sogar: Waren ein oder mehrere Teammitglieder überhaupt nicht in der Lage, die Arbeit zu erledigen?

Dies sind die Fragen, die sich das Team in den letzten 18 Monaten bei jedem Sprint hätte stellen müssen. Mit den Antworten können sie dann Vorschläge für Prozessverbesserungen für den nächsten Sprint vorschlagen. Dies können sein:

  • Nehmen Sie im nächsten Sprint weniger Arbeit auf (duh!)
  • Seien Sie konservativer bei Schätzungen
  • Sagen Sie, wer uns unter Druck setzt, mehr Arbeit zu leisten, um Abhilfe zu schaffen, da wir bereits mehr übernehmen, als wir jetzt erreichen können
  • Verwalten Sie Unterbrechungen besser und passen Sie den Arbeitsaufwand im nächsten Sprint an unvermeidbare Notfälle an
  • Beheben Sie die Engpässe oder planen Sie um diejenigen herum, die Sie nicht vermeiden können
  • Weisen Sie Teammitgliedern, die sie nicht erreichen können, keine Geschichten zu (und ermitteln Sie separat die Reaktion des Managements, um eine Situation mit einem Teammitglied mit schlechter Leistung anzugehen, von Schulung und Mentoring bis zur Entlassung).

Dies ist die Art von Unterhaltung, die in den letzten 18 Monaten bei jedem Sprint stattfinden sollte. Es geht nicht darum, Druck auf das Team auszuüben oder mehr Ressourcen hinzuzufügen, sondern darum, Ihre Rückblicke zu nutzen, um Ihren Prozess kontinuierlich zu verbessern. Das passiert hier eindeutig nicht.

Sie würden denken, dass das Team beim 15. Sprint mit verpassten Toren dies in seiner Retrospektive so oft diskutiert hätte, bis zu dem Punkt, an dem es beschlossen hat, nur die minimalsten Sprintziele zu erreichen, nur um eines zu erreichen. Bis zum 25. unvollständigen Sprint würde ich nur einen Sprint mit einem einzigen Saitenwechsel machen und sonst nichts. Wenn das Team das im Sprint nicht schafft, sind die Probleme noch schlimmer als Sie es zulassen.

Um klar zu sein, wie einige hier bereits betont haben, sind Sprintziele Prognosen und keine eisernen Verpflichtungen, und fehlende Ziele sind selbst kein Hinweis auf etwas anderes als ungenaue Prognosen. Ein großartiges Team kann Unmengen von Toren verfehlen, weil es schlechte Prognostiker sind, während ein schreckliches Team jeden einzelnen treffen und keinen tatsächlichen Wert liefern kann. Wenn Ihre Prognosen jedoch 18 Monate hintereinander in die gleiche Richtung falsch sind, funktioniert dieser Teil Ihres Prozesses nicht. Verwenden Sie Ihre Rückblicke, um den Prozess so zu korrigieren, dass Ihre Prognosen der tatsächlichen Realität, die das Team für jeden Sprint liefern kann, ziemlich nahe kommen.

17
Zach Lipton

"Software ist fertig, wenn sie fertig ist, nicht früher, nicht später."

Dies ist wahr, aber für jede Aufgabe, an der Ihre Entwickler zu arbeiten beginnen, versteht jeder in Ihrer Organisation die Definition von Fertig für jede Aufgabe?

Es scheint, dass eines Ihrer größten Probleme die Schätzung ist, aber Entwickler können nur dann eine realistische Schätzung abgeben, wenn sie eine eindeutige und klar spezifizierte Definition von erledigt haben '. (Dazu gehören Probleme mit Unternehmensprozessen - z. B. Benutzerdokumentation, Arbeitspakete für eine formelle Version usw.)

Es ist nicht überraschend, dass eine Überschätzung ein Problem verursacht, da die meisten Entwickler der Ansicht sind, dass die Schätzung der für die Ausführung einer Aufgabe erforderlichen Zeit am schwierigsten ist.

Die meisten Entwickler tendieren jedoch dazu, einen vernünftigen (wenn auch optimistisch) Umgang mit dem Aufwand zu haben, den sie können für einen bestimmten Zeitraum einsetzen.

Das Problem besteht häufig darin, dass Entwickler Schwierigkeiten haben, eine Beziehung zwischen einer Aufgabe und dem Gesamtaufwand herzustellen, der erforderlich ist, wenn sie mit unvollständigen Informationen arbeiten - insbesondere wenn Sie stehen unter Druck, alle Antworten auf eine wirklich große Aufgabe zu finden.

Dies führt natürlich dazu, dass Zeitschätzungen von der Realität getrennt werden und Dinge wie den Erstellungsprozess und die Benutzerdokumentation aus den Augen verlieren.

Die Trennung beginnt in der Regel ganz am Anfang, wenn die Aufgabe beschrieben wird. und es wird normalerweise von einer nicht-technischen Person zusammengestellt, die eine Liste von Anforderungen erstellt, ohne eine Ahnung davon zu haben, wie viel Aufwand erforderlich ist.

Manchmal legen leitende Angestellte Aufgaben fest und ignorieren Probleme mit Unternehmensprozessen vollständig. Es ist nicht ungewöhnlich, dass die Geschäftsleitung denkt, dass Dinge wie das Definieren von Tests, das Erstellen eines formalen freigegebenen Builds oder das Aktualisieren eines Benutzerdokuments auf magische Weise ohne Zeit und Aufwand geschehen. erforderlich.

Manchmal schlagen Projekte fehl, bevor ein Entwickler überhaupt eine Codezeile geschrieben hat, weil jemand irgendwo seine Arbeit nicht richtig macht.

Wenn das Entwicklungsteam nicht an der Vereinbarung von Anforderungen oder der Erfassung von Akzeptanzkriterien beteiligt ist, ist dies ein Fehler des Managements. Dies bedeutet, dass jemand, der den Code und die technischen Probleme nicht ausreichend versteht, das Unternehmen zu unvollständigen Anforderungen verpflichtet hat. und ließ das Projekt offen für Fehlinterpretationen, Scope Creep, Vergoldung usw.

Wenn das Entwicklungsteam an der Erfassung und Vereinbarung von Anforderungen beteiligt ist, kann dies ein Versagen des Teams sein, das für die Klärung der Details (und der Akzeptanzkriterien) verantwortlich ist - dh "Wie sieht das Ergebnis aus? Wann ist es done? "). Das Entwicklungsteam ist auch dafür verantwortlich, [~ # ~] nein [~ # ~] zu sagen, wenn es andere gibt Blockieren von Problemen im Weg oder wenn eine Anforderung einfach unrealistisch ist.

Wenn die Entwickler an der Erfassung der Anforderungen beteiligt sind:

  • Hat das Team die Möglichkeit, sich mit dem Produktmanager zusammenzusetzen, um die Anforderungen/Definitionen von erledigt zu klären?
  • Stellt das Team genügend Fragen, um implizite/angenommene Anforderungen zu klären? Wie oft werden diese Fragen zufriedenstellend beantwortet?
  • Fordert das Team Akzeptanzkriterien (Definition von erledigt), bevor eine Schätzung abgegeben wird?
  • Wie gut werden Akzeptanzkriterien normalerweise für jede Aufgabe erfasst? Handelt es sich um ein vages Dokument mit wenigen Details oder beschreibt es konkrete Funktionen und Formulierungen, die ein Entwickler eindeutig In einen Test übersetzen könnte?

Die Chancen stehen gut, dass die Produktivität Ihres Teams kein Problem darstellt. Ihr Team ist wahrscheinlich und setzt alle Anstrengungen ein, die es in Bezug auf die Entwicklung unternehmen kann. Ihre wirklichen Probleme können eines oder mehrere der folgenden sein:

  • Unvollständige und vage Anforderungen.
  • Anforderungen/Aufgaben, die in erster Linie einfach zu groß sind.
  • Schlechte Kommunikation zwischen dem Entwicklungsteam und dem oberen Management.
  • Fehlen klar definierter Akzeptanzkriterien, bevor die Aufgaben an das Team übergeben werden.
  • Unvollständige oder vage/mehrdeutige Spezifikation der Abnahmetests. (d. h. Definition von Fertig)
  • Unzureichende Zeit für die Definition/Vereinbarung von Akzeptanzkriterien.
  • Entwickler haben keine Zeit in Betracht gezogen, um vorhandenen Basiscode zu testen oder vorhandene Fehler zu beheben
  • Die Entwickler haben den vorhandenen Basiscode getestet, die Fehler jedoch nicht als Blockierungsprobleme ausgelöst, bevor sie Schätzungen zu den Anforderungen bereitgestellt haben
  • Das Management erkannte die Probleme/Fehler und entschied, dass Fehler nicht behoben werden müssen, bevor neuer Code geschrieben wird.
  • Entwickler stehen unter dem Druck, 100% ihrer Zeit zu berücksichtigen, obwohl möglicherweise 20% (oder eine ähnliche Anzahl) ihrer Zeit wahrscheinlich von Besprechungen, Ablenkungen, E-Mails usw. beansprucht werden.
  • Die Schätzungen werden zum Nennwert vereinbart und niemand passt den Spielraum für Fehler oder Eventualitäten an (z. B. "Wir haben beschlossen, dass dies 5 Tage dauern sollte, also erwarten wir, dass dies in 8 erledigt wird.").
  • Schätzungen werden von allen (Entwicklern und Management) als einzelne Zahlen anstelle realistischer "Bereichs" -Nummern behandelt - d. H.
    • Best-Case-Schätzung
    • Realistische Schätzung
    • Worst-Case-Schätzung

... die Liste könnte viel länger dauern.

Sie müssen einige "Fakten ermitteln" und genau herausfinden, warum die Schätzungen konsequent von der Realität getrennt sind. Ist die vorhandene Basissoftware schlecht? Fehlt es an Unit-Test-Abdeckung? Vermeiden Ihre Entwickler die Kommunikation mit dem Management? Vermeiden Sie die Kommunikation mit Entwicklern? Gibt es eine Trennung zwischen den Erwartungen des Managements und den Erwartungen der Entwickler, wenn es um "Definition of Done" geht?

5
Ben Cottrell

Mein Rat, das Team neu zu starten, ist, die kleinstmögliche Story pro Team und Sprint auszuwählen und diese eine Story und nur diese eine Story zu vervollständigen!

Ich stimme den anderen Postern zu, entweder ist das Team inkompetent oder sie versuchen zu viel zu tun.

Beginnen Sie mit den kleinsten Dingen, den reduziertesten Geschichten und absolvieren Sie einen einzelnen Sprint. Bringen Sie das Team dazu, einen Sprint zu beenden und erfolgreich zu sein, und es wird ihnen helfen, herauszufinden, wie sie ihre Zeit- und Arbeitsverpflichtungen priorisieren können. Mit der Zeit wird das Team mehr und mehr Arbeit übernehmen können, bis die maximale Produktivität erreicht ist.

4
bakoyaro

Sie sollten Daten sammeln und ein Vertrauensniveau aufbauen, das auf der Leistung der Vergangenheit basiert.

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

Das einfachste Beispiel sind Sprints mit konstanter Zeit, beispielsweise alle zwei Wochen. Schätzen Sie, wie viele Story Points das Team innerhalb der zwei Wochen beenden wird. Dann, nachdem der zweiwöchige Sprint vorbei ist, sehen Sie, wie viele Story-Punkte tatsächlich abgeschlossen wurden. Mit der Zeit werden Sie vielleicht 15 Punkte schätzen, aber nur 10 Punkte erreichen. In diesem einfachen Fall können Sie mit einer Geschwindigkeitsanpassung beginnen, sodass Sie nur 10 Punkte pro Sprint planen. Oder dass Sie planen, 66% der geschätzten Arbeit zu erledigen.

Indem Sie das Vertrauensniveau mit Standardabweichungen aufbauen, können Sie dem Management mitteilen: Gemäß den aktuellen Projektzielen erwarten wir nur 50% Vertrauen, das wir in 3 Wochen erreichen können, aber 95% Vertrauen, das wir in 5 Wochen beenden können.

4
Rich Remer

Die Idee hinter Agile und Scrum ist es, eine enge Rückkopplungsschleife aufzubauen, damit Sie Ihren Prozess beurteilen können. Sie müssen fragen "Wo ist das zusammengebrochen?", Da es völlig zusammengebrochen zu sein scheint.

  1. Planen Sie, was Sie tun werden, und erstellen Sie eine Liste davon
    • Dies sollte darin bestehen, Elemente aus einem Rückstand von Elementen auszuwählen, die abgeschlossen werden müssen. Bevor etwas in die To-Do-Liste für den Sprint aufgenommen wird, muss das Team zustimmen, dass es es vollständig versteht und ungefähr schätzt, dass es weniger als einen Sprint dauert.
    • Im Idealfall ist der Rückstand nach Priorität (für das Unternehmen) geordnet, und Sie können die Prioritätsreihenfolge abrufen.
    • Wenn Elemente aus dem Backlog zu groß sind, teilen Sie sie in kleinere Teile auf. Teilen Sie die Teile dann in einzelne Aufgaben auf, die in einem Tag oder weniger erledigt werden können.
    • Erwarten Sie nicht, dass diese Planung einfach oder schnell ist.
  2. Für einen definierten Zeitraum für Elemente aus der Liste ausführen (Sprint)
  3. Überprüfen Sie, was Sie erreicht haben
    • Welche Geschichten wurden beendet?
    • Wenn keine Geschichten fertig waren, welche Aufgaben, aus denen Geschichten bestehen, waren dann fertig?
    • Wenn keine Aufgaben erledigt waren, was genau haben dann alle letzten Montag getan? Letzten Dienstag?, Etc. - an diesem Punkt ist es Zeit für strenge Selbstbeobachtung ...
  4. Beheben Sie die Probleme (analysieren Sie das Feedback und passen Sie es an)

    • Wie lange haben die Dinge gedauert, die fertig waren?
    • Was hat verhindert, dass Aufgaben erledigt wurden?
    • Teilen Teammitglieder Storys (Features) in Aufgaben auf, die innerhalb eines Tages oder weniger erledigt werden können? Wenn nicht, tun Sie dies und machen Sie es zu einem Teil der Aufgabenliste.
    • Welche Änderungen an der Aufgabenliste oder den Elementen in der Aufgabenliste wurden während des Sprints vorgenommen? War dies ein Grund, nicht fertig zu werden? Wenn dies der Fall ist, ändern Sie weder die Liste noch die Funktionen. Werfen Sie die geänderte Funktion in das Backlog, bis sie stabil ist.
    • Wie können Sie die Größe und den Umfang einiger Elemente auf etwas reduzieren, das in einem Sprint beendet werden kann? Wählen Sie etwas Winziges wie eine Verbesserung der Protokollierung, eine einfache Fehlerbehebung oder einen Tippfehler, um einige Dinge zu erledigen, damit das Team einen Eindruck davon bekommt, was es tun kann. Wenn Sie dies nicht tun können, dann hören Sie auf zu sprinten und planen Sie ne.
  5. Zurück zu Schritt eins und bis zur Freigabe wiederholen ...

Gibt es Dokumentationshindernisse, Kopplungsprobleme, die zu Abhängigkeiten führen, Kommunikationsprobleme, nicht genügend Informationen in den Anforderungen? ... Was? Haben die Entwickler ihre Zeit damit verbracht, neue Technologien zu erlernen? Haben sie viel Zeit mit Design verbracht? Wurden Dinge wie Lernen in der Sprint-Aufgabenliste berücksichtigt?

Dachten Sie, Ihr Team hätte gedacht, sie hätten ihre Probleme in jeder Retrospektive isoliert? Hat das Team gehandelt, um die Probleme zu beheben? Hat das Team nicht reagiert und das Management hat lediglich die Lösungen und die Vorgehensweise diktiert?

Angesichts der langen Zeitspanne stimmt systemisch etwas nicht, nicht nur mit den Entwicklern. Irgendwann (bevor ein Jahr vergangen war) hätte jemand im Team (einschließlich des Scrum Masters) fragen sollen, was, wie klein es auch sein mag, können wir erreichen?

3

Scrum macht ein paar Dinge.

Erstens wird die Priorisierung gefördert. Der Arbeitslieferant muss sagen, was er zuerst tun möchte, und nicht "alles ist gleich wichtig".

Zweitens erzeugt es ein etwas brauchbares Produkt, auch wenn nicht alles fertig ist. Dies ist der Punkt, an dem am Ende jeder Iteration ein "potenziell versandfähiges Produkt" vorhanden ist.

Drittens ergibt sich eine engere Rückkopplungsschleife. Indem Sie darauf bestehen, dass die Dinge am Ende eines Sprints "erledigt" werden, vermeiden Sie das Problem "90% -Funktion abgeschlossen, aber nur zur Hälfte erledigt". Wenn Sie auf Fristen drängen, können Sie Dinge, die erledigt werden müssen, beiseite schieben, sodass es so aussieht, als hätten Sie fast die Frist erreicht, oder Sie können sie vortäuschen. Wenn Sie eine Definition von erledigt haben und darauf bestehen, dass Dinge erledigt werden, wissen Sie, ob etwas schwieriger ist, als es früher statt später aussieht.

Viertens wird Inventar vermieden, indem die detaillierte Planung in die Nähe der Arbeit gebracht wird. Die Planung weit entfernter Dinge ist eine Form des Inventars: Kapital, das für Ressourcen ausgegeben wird, die nicht zum Verkauf an Kunden oder zur sofortigen Verwendung durch Kunden verfügbar sind. Solches Inventar kann verrotten (Pläne ändern sich unter den Füßen, neue Informationen machen es veraltet), sich nicht an den Bedürfnissen ausrichten (es stellt sich heraus, dass wir kein verteiltes Netzwerk benötigen, weil das, was es verwendet, es nicht wert war) und den Wert der versendeten Waren verringern (Wenn Sie im letzten Jahr die Hälfte Ihrer Zeit für die Planung für das nächste Jahr und darüber hinaus aufgewendet hätten, hätten Sie doppelt so viel Versand erhalten können, wenn Sie stattdessen an Dingen gearbeitet hätten, die für den Moment bereit sind). Wenn Sie die Planung ohne Verlust näher an die Ausführung bringen können (schwierig!), Können Sie den Lagerbestand verringern.

Dies ist nicht der einzige Weg, um diese Probleme zu lösen. Sie scheinen Scrum zu verwenden, bei dem Entwickler einen Arbeitsstrom erhalten, an dem sie für jeden Zeitraum arbeiten können. In regelmäßigen Abständen werden neue Aufgaben hinzugefügt und der Fortschritt überprüft.

Dies ist eine nützliche Methode, um scrum-artige Muster zu verwenden. Es hält den Arbeitsfluss aufrecht, es plant in der Nähe der Produktion, es bietet einige Rückkopplungsschleifen usw. Es hat sogar den Vorteil, dass es die Entwicklung und das Testen nicht verzerrt, um sie an das System anzupassen (wenn das Testen am besten durchgeführt wird, ist die Arbeit im Grunde abgeschlossen Der Versuch, die Dinge im selben Sprint fertig zu stellen und zu testen, zwingt das Back-End des Sprints dazu, keine Neuentwicklung zu beinhalten!)

Das Versäumnis, genau das, was sie tun werden, in einen Sprint zu stecken, ist kein Beweis dafür, dass Ihre Entwickler keine großartige Arbeit leisten. Dies bedeutet, dass sie SCRUM nicht von oben verfolgen, sondern Teile des Frameworks verwenden.

Wenn sie halbiert (oder geviertelt) hätten, wie viel sie für jeden Sprint eingesetzt hätten, aber alles andere gleich gehalten hätten, wären sie mehr fertig geworden als für jeden Sprint! Sie würden die gleiche Menge an Code produzieren lassen. Offensichtlich sind die "Sprintfehler" nicht der wichtige Teil, da dies nur ein internes Prozessdetail ist. Das Ziel der Firma ist es, Scheiße zu machen, und diese Scheiße ist gut; einem bestimmten Prozess nicht zu folgen, es sei denn, Ihr Ziel ist eine bestimmte Art der ISO-Prozesszertifizierung.

Der Prozess ist dem Ziel der erledigten Dinge unterworfen.

Auf der anderen Seite erhalten Sie nicht die gleichen Art Rückmeldungen, da sie nicht den Regeln von SCRUM entsprechen. Sie sollten das resultierende Material untersuchen, um festzustellen, ob die Art der erzeugten Fehler die Fehler sind, für die SCRUM entwickelt wurde. Gibt es Geschichten, die für immer wie Zombies weiterleben und erst viel zu spät getötet werden? Gibt es Geschichten, die einfach erscheinen, explodieren und in einer Retrospektive die gesamte Arbeit nicht wert sind? Ist das Produkt tatsächlich zu den Zeiten versandfähig, zu denen Sie es benötigen/möchten?

2
Yakk

In Ihrer Situation sind Rückblicke zu spät.
Halten Sie tägliche Stand-up-Meetings ab und erhalten Sie wirklich Status von Leuten darüber, was sie in den letzten 24 Stunden getan haben?
Verwendet der Scrum Master diese Meetings, um den Fortschritt jedes Entwicklers an seinen Zielen zu messen?
Sie müssen diesen Teil der Scrum-Methodik verwenden, um den Fortschritt zu überwachen. Es sollte Ihnen einen guten Einblick geben, was die Leute tun.
Sind sie abgelenkt? Verbringen Sie zu viel Zeit mit Kaffee oder helfen Sie anderen Menschen bei SE/SO, lesen Sie die Nachrichten oder führen Sie Inspektionen durch, die nicht berücksichtigt werden? Oder sind sie wirklich mit dem Kopf nach unten, mit voller Kraft voraus und völlig überfordert? Die tägliche Ansicht sollte Ihnen eine gute Idee geben. Es wird auch helfen, die Entwickler auf die anstehende Aufgabe zu konzentrieren, damit sie nicht zugeben müssen, dass sie gestern nichts getan haben.
Und natürlich, wenn sie während des gesamten Sprints stetige Fortschritte melden und am Ende immer noch nicht liefern, dann haben sie gelogen und es könnte Zeit für einen neuen Entwickler sein.

2
Sinc

Es ist schwierig, den Aufwand und die Zeit abzuschätzen, die erforderlich sind, um eine komplexe Aufgabe wie den Programmiercode auszuführen. Wie Joel Spolsky sagt es:

Softwareentwickler erstellen keine Zeitpläne. Normalerweise versuchen sie, ohne einen davonzukommen. "Es wird getan, wenn es fertig ist!" Sie sagen, in der Erwartung, dass solch ein mutiger, lustiger Zinger ihren Chef auf ein Kichern reduzieren wird, und in der folgenden Gemütlichkeit wird der Zeitplan vergessen.

Unternehmen benötigen jedoch Fristen, um operieren zu können. Versuchen Sie, wie Joel vorgeschlagen hat, Evidence Based Scheduling zu verwenden, um Zeitschätzungen mit der damit verbundenen Wahrscheinlichkeit zu erhalten, auf die sich das Management als jede Art von Risiko beziehen kann.

2
hakanc

Oh, und ja, wir verwenden Retrospektiven.

Oh gut, du weißt also warum dein Team versagt, oder? Sie hatten 36 Möglichkeiten, darüber zu sprechen, was funktioniert hat und was nicht. Die Scrum-Meister sollten also genau verstehen, wie sie die Probleme lösen können, oder?

Ich habe aufgrund der von Ihnen gegebenen Beschreibung die Vermutung, dass Ihr Unternehmen in die Mentalität "SCRUM macht uns produktiv" geraten ist. Die Wahrheit ist, dass SCRUM Ihre Produktivität nicht steigert. Es ist vielmehr ein Werkzeug, mit dem Sie sich selbst auf eine Weise produktiv machen können, die die Realität identifiziert der Entwicklung, die von Management und Entwicklern oft übersehen werden.

Was hat der Scrum Master als potenzielle Probleme mit dem Team identifiziert? Weisen sie ständig doppelt so viel Arbeit zu, wie sie bewältigen können? In diesem Fall sollte der Scrum Master vorsichtig vorschlagen, weniger Arbeit zu übernehmen, da der Scrum Master die Geschwindigkeit des Teams überprüfen kann.

Wann ist es fair, nach dem Problem in der Qualität der Entwickler zu suchen?

Die Zeit, in der man nach dem Problem in der Qualität der Entwickler suchen sollte, ist der Moment, in dem Sie sicher sind, dass dies das Problem ist. Dies ist kein neues Problem, das von SCRUM erstellt wurde. Dies ist die Realität des Geschäfts. SCRUM sollte Ihnen erheblich mehr Informationen über die Fähigkeiten Ihrer Teammitglieder geben als herkömmliche Ansätze. Sie sollten wissen, ob das Problem "Softwareentwickler sind nicht gut genug" im Vergleich zu "Managementerwartungen sind unrealistisch" in einem weitaus besseren Maße ist, als Sie es mit einem herkömmlichen Ansatz verstehen würden. Dies ist die Zeit für Management, um das zu tun, was das Management am besten kann: Finden Sie die richtigen Leute für den Job heraus, damit das Unternehmen Geld verdienen kann. Wenn Sie nicht sagen können, wo das Problem liegt, stellen Sie sich vor, wie schwer es wäre, ohne all diese Rückblicke zu sagen!

Wenn Sie der Meinung sind, dass die Leute gut genug sind (was bedeutet, dass ihre Einstellung kein Fehler des Managements war), dann wäre mein Rat, über den Tellerrand hinaus zu denken. Wenn die Arbeit nicht erledigt wird, sollten Sie die Form der Arbeit für die Entwickler ändern. Eine der einfachsten Möglichkeiten, Sprint-Abschlussfristen einzuhalten, besteht darin, die DONE-Kriterien so anzupassen, dass Sie mit dem Ergebnis zufrieden sind, unabhängig davon, wie es ausgeführt wird. So wird die Fertigstellung zu einer Tautologie.

Dies stellt die Verantwortung für das Management dar, insbesondere für den SCRUM-Master. Der Trick besteht darin, Aufgaben zu schreiben, die, wenn sie erledigt sind, sehr wertvoll sind, aber wenn sie unvollständig bleiben, bieten sie dem Unternehmen dennoch einen ausreichenden Mehrwert, um ihren Gehaltsscheck wert zu sein. Nach 18 Monaten würde ich Ihre erwarten Rückblicke, um dir etwas beigebracht zu haben. Wenn dies nicht der Fall ist, sollten Sie die Geschichten möglicherweise mit der ausdrücklichen Absicht schreiben, dass fehlgeschlagene Geschichten etwas aufdecken, das in Ihrem Unternehmen nicht stimmt, und es ans Licht bringen. Dies würde dem Unternehmen immense wertvolle Daten liefern, wenn man bedenkt, wie frustriert das Unternehmen mit dem Entwicklungsteam zu sein scheint. Das Problem können in der Tat die Entwickler sein, wie Sie fragen. Oder das Problem kann eine Pathologie in der Denkweise des Unternehmens sein, von der Sie bis jetzt keine Ahnung hatten!

Wenn das Problem tatsächlich beim Unternehmen und nicht bei den Entwicklern liegt, sind die Informationen, die Sie aus diesen unvollständigen Geschichten entnehmen, möglicherweise mehr wert als das Produkt, das Sie von den erfolgreichen sammeln! Es können die Informationen sein, die Ihr gesamtes Unternehmen retten ! Das scheint mir wirklich eine wertvolle Information zu sein, und Sie können SCRUM als Werkzeug verwenden, um sie zu sammeln.

1
Cort Ammon

"Software ist fertig, wenn sie fertig ist, nicht früher, nicht später" ist ein Rezept für einen Fehler, wenn Sie nicht definiert haben, wie "erledigt" aussieht.

Die meisten Ingenieure werden versuchen, die bestmögliche Lösung zu finden, dies kann jedoch leicht zu einer Vergoldung führen, insbesondere bei weniger erfahrenen Ingenieuren. Die einzige Verantwortung des Managements besteht darin, genau zu definieren, wo das Ziel liegt, und Ihre Ingenieure in diese Richtung zu lenken. Ingenieure werden häufig versuchen, Seitendrehungen vorzunehmen, um die Funktionen zu verbessern, und es ist Sache des Managements, zu entscheiden, ob diese Seitendrehung die Dinge langfristig beschleunigt oder ob sie sich nur verbessert, um sie zu verbessern.

Der Punkt der agilen Entwicklung ist, dass jede neue Arbeit so gut wie erforderlich sein sollte, um diesen Sprint zu erfüllen UND KEIN BESSER !!!!!! Ja, das ist ungefähr die größte Betonung, die ich in StackOverflow hinzufügen kann - und es ist immer noch nicht genug Betonung. Wenn Sie feststellen, dass Leute Dinge hinzufügen, die nicht benötigt werden genau in dieser Sekunde , dann müssen sie geschult werden, wie man agile Entwicklung richtig macht .

1
Graham

Es gibt bereits mehrere ausgezeichnete Antworten. Insbesondere schlechte Einschätzung, übermäßiges Engagement und/oder außerplanmäßige Arbeit sind häufige Ursachen für Schlupf.

Aber ich bin gespannt, warum "[Ihre] Entwickler die Funktionen auswählen, die sie in jeden Sprint aufnehmen möchten". Die Entwickler sollten in der Regel zuerst an den Funktionen mit der höchsten Priorität arbeiten - und Priorität ist eine Geschäftsentscheidung, d. H. Diese sollte vom Product Owner kommen, der als Proxy für die Geschäftsinteressenten fungiert.
(Es gibt Ausnahmen. Insbesondere werden Funktionen mit hohem Risiko im Allgemeinen früher ausgeführt. In einigen Fällen kann eine benutzerbezogene Funktion von anderen Funktionen abhängen, z. B. "Wir müssen wirklich eine Datenbank hinzufügen, bevor wir." kann X implementieren ".)

Auf der anderen Seite sind Schätzungen technische Entscheidungen und sollten nicht von Geschäftsleuten getroffen (oder hinterfragt) werden. Sie sagen nichts dazu - ich spreche das nur an, weil es meiner Erfahrung nach bei der Auswahl von Entwicklern ziemlich häufig vorkommt, dass Geschäftsleute versuchen, zu bestimmen, wie lange es dauern soll.

Es hört sich so an, als hätten Sie einen ziemlich dysfunktionalen Prozess. Ich würde empfehlen, zumindest vorerst keine Entwicklerberater hinzuzuziehen, da sich dies wahrscheinlich negativ auf die Moral auswirken wird. Es hört sich jedoch so an, als könnte Ihre Organisation Hilfe auf der Seite des Projektmanagements gebrauchen. Hier würde ich anfangen, indem ich einen erfahrenen, agilen Coach hinzuziehe - wenn nicht für ein mittel- bis langfristiges Engagement, dann zumindest für eine Beurteilung oder einen "Gesundheitscheck". Ein guter Coach wird Ihnen sagen, ob Sie unterdurchschnittliche Entwickler haben, aber zumindest auf diese Weise wird das gesamte Team (nicht nur die Entwickler) unter die Lupe genommen.


Eine weitere Beobachtung: Nach meiner Erfahrung ist es sehr schwierig, Scrum als Projektmanagementmethode zum Erfolg zu führen, wenn Sie nicht auch gute Entwicklungsprozesse verfolgen. Führen Sie automatisierte Unit-Tests durch? oder noch besser, automatisierte Abnahmetests? Koppeln Ihre Entwickler oder führen Sie zumindest häufige Codeüberprüfungen und/oder exemplarische Vorgehensweisen durch? Üben Sie eine Form der kontinuierlichen Integration?

0
David

"Wann ist es fair, die Qualität der Entwickler zu betrachten?"

Die ganze Zeit. Offensichtlich sind einige Leute produktiver als andere. Sie brauchen keine Entschuldigung als Arbeitgeber, um ihre Leistung zu messen.

Das Knifflige ist, wie Sie es machen. Mein Rat ist, einige erfahrene Auftragnehmer einzustellen, die zusammen mit Ihren Dauerwellenmitarbeitern an denselben Aufgaben arbeiten, die von Ihren Dauerwellenmitarbeitern geschätzt werden, und prüfen, ob sie eine höhere Geschwindigkeit haben.

Dies gibt Ihnen einen guten Vergleich mit dem aktuellen Markt, ohne Sie an eine langfristige Einstellung zu binden.

Es könnte auch den Dauerwellen-Jungs einen Kick in den Arsch geben.

Wenn sie sich darüber beschweren, dass die Auftragnehmer auf Qualität usw. verzichten, um an Geschwindigkeit zu gewinnen, führt dies zu einem Gespräch darüber, wo der Geschäftswert liegt. Langfristige Wartbarkeit oder kurzfristige Produkte werden ausgeliefert.

Wenn es sich um das Langzeitmaterial handelt, werden Sie gezwungen sein, es zu quantifizieren und es als Voraussetzung in den Sprint zu setzen!

0
Ewan