Wir möchten versuchen, Scrum in einer unserer Entwicklungsabteilungen einzuführen, haben aber eine Reihe von Herausforderungen, bei denen wir nicht sicher sind, wie wir sie lösen sollen. Wenn uns jemand in die richtige Richtung weisen könnte, wäre das sehr nett.
Wir produzieren ein sehr komplexes Unternehmensprodukt und haben 2 Produktbesitzer, 10 Entwickler und 4 Tester.
Wir haben jedes Jahr 4 Releases, die aus 20-30 Änderungsanträgen mit jeweils 10-1500 Stunden bestehen. Wir sind an einen Festpreisvertrag gebunden, der uns verpflichtet, für jede dieser Änderungen einen festen Termin, Umfang und Preis zu haben. Neben den Änderungswünschen führen wir auch Bugfixing durch. Der Release-Zyklus ist festgelegt und wir müssen alle 3 Monate installierbare Pakete + eine Reihe von Service Packs und Hotfixes liefern.
Einige unserer Herausforderungen, denen wir gegenüberstehen, sind:
Fragen:
Der größte Konflikt, den Sie sehen werden, ist wahrscheinlich der feste Umfang und die Frist. Wenn Sie diese beiden einschließen, bleiben Sie nur offen, um Ressourcen und Qualität zu ändern. Das Ändern der Teamzusammensetzung ist im Allgemeinen nicht etwas, das Sie oft tun möchten, aber wenn Sie genügend Raum zum Atmen haben, gibt es keinen Grund, warum Sie nicht sagen können, dass Sie ein Team die ganze Zeit für das Projekt verwenden und das andere nur am Anfang des Release-Zyklus, bis Sie es sind ziemlich sicher, dass Sie die Verpflichtung erfüllen können. Aber all dies wäre auch ein Problem mit Wasserfall.
Wie können wir dringende Hotfixes mitten in einem Sprint behandeln?
Dies ist nicht ungewöhnlich und es gab hier andere Fragen dazu. Kurz gesagt: Halten Sie eine separate Pipeline dringender Bugfixes bereit und erledigen Sie diese einfach, sobald sie auftauchen. Ihre Geschwindigkeit im Gedränge wird vorübergehend leiden, aber auch dies ist nichts, was Sie im Wasserfall nicht gleichermaßen betreffen würde. Wenn Sie mit Bugfixes überschwemmt werden, können Sie den Umfang des Sprints neu verhandeln
Wie gehen wir mit den spezialisierten Technologieentwicklern um, die oft Aufgaben für viele verschiedene Änderungsanfragen haben – was bedeuten würde, dass sie in mehreren Teams sein müssen? Oder kleine 1-Mann-Teams (macht keinen Sinn)?
Idealerweise sollten Sie auf ein Cross-Training in diesen Disziplinen hinarbeiten. (Ich erwähne in solchen Situationen immer das Szenario „Von einem Bus angefahren“.) Wie sie integriert werden können, hängt von der Art ihrer Arbeit ab und davon, wie viel Zeit sie mit spezialisierter Arbeit verbringen.
Wie ist der Delivery Manager in die Scrum-Teams integriert, damit wir Fortschritte, Budgetprobleme usw. mit dem Kunden melden können? Beachten Sie, dass die Product Owner nicht in der Lage sind, diese Aufgabe zu erledigen.
Offiziell gar nicht. Alle für diese Rolle erforderlichen Informationen sollten aus dem normalen Scrum-Workflow verfügbar sein, sodass theoretisch jede interessierte Partei mit Zugriff auf das Scrum-Board, Burndowns usw. in der Lage sein sollte, diese Rolle zu übernehmen. Die POs wären aufgrund ihrer bestehenden Beziehung zum Kunden die logische Ergänzung. Warum sind sie dazu nicht in der Lage? Wenn es an mangelnder Einsicht in das Projekt liegt, kann das behoben werden.
Insgesamt scheint es mir jedoch, dass Sie in einer sehr streng kontrollierten Umgebung operieren. Die Umstellung auf Scrum UND die Beibehaltung Ihres bestehenden Controllings wird wahrscheinlich viel Reibung und doppelten Aufwand verursachen. Dies ist WENN Sie die organisatorische Unterstützung haben, um es überhaupt durchzuziehen. Ich bin mir nicht sicher, wie viel Nutzen Sie von einem solchen Wechsel haben, es sei denn, Ihr Kunde ist bereit, auch zu einem weniger bürokratischen Vertragsmodell zu wechseln (wie "Geld für nichts, Änderungen kostenlos").
Wie können wir dringende Hotfixes mitten in einem Sprint behandeln?
Indem Sie sie zum Sprint Backlog hinzufügen. Machen Sie sich bewusst, dass dies den Wert von Focus beeinträchtigt und aufgrund von Kontextwechseln zu Ineffizienzen führen kann.
Wie gehen wir mit den spezialisierten Technologieentwicklern um, die oft Aufgaben für viele verschiedene Änderungsanforderungen haben – was bedeuten würde, dass sie in mehreren Teams sein müssen? Oder kleine 1-Mann-Teams (was keinen Sinn macht)?
Nicht jeder kann ein Experte für alles sein und sollte es auch nicht sein. Allerdings muss es Wissensüberschneidungen geben. (Siehe auch: Paint Drip People ) Was passiert, wenn dieser einzige „Experte“ von einem Bus angefahren wird?
Wie ist der Delivery Manager in die Scrum-Teams integriert, damit wir Fortschritte, Budgetprobleme usw. mit dem Kunden melden können? Beachten Sie, dass die Product Owner nicht in der Lage sind, diese Aufgabe zu erledigen.
Der Delivery Manager würde über Transparenz, den Product Owner, Sprint Review usw. aktualisiert.
Lesen Sie den Scrum Guide und verstehen Sie das Framework; Ich glaube nicht, dass dies die beste Lösung für Ihre Situation ist.
Aus Prozesssicht wäre Kanban aufgrund der bereitgestellten Informationen wahrscheinlich die bessere Wahl. Hotfixes können einfach an die Spitze der Warteschlange priorisiert werden, um gezogen zu werden. Unterschiedliche Anwendungsfunktionsbereiche können möglicherweise durch separate Kanban-Boards adressiert werden. Der Delivery Manager ist nur minimal betroffen.
Teilen Sie den Monolithen aus technologischer Sicht in viele kleinere, fokussierte Anwendungen auf, die über APIs interagieren. Das hat auch den Vorteil modularer Lösungen, die der Vertrieb nutzen kann.