Ich habe zahlreiche Project Management SE-Fragen zu diesem Thema gelesen und viel gegoogelt. Ich bin mir bewusst, dass verschiedene Inkarnationen dieser Frage bereits angesprochen wurden, aber ich habe nichts gefunden, das mir eine klare Antwort gibt.
Ich bin der PM in einem 20-köpfigen Team, einschließlich einiger Remote-Ressourcen. Wir entwickeln oder pflegen etwa 10 Anwendungen. Etwa die Hälfte des Teams arbeitet an den meisten Anwendungen, die stabil sind und keinen echten Product Owner oder eine Roadmap haben, mit Ausnahme von Produktionskorrekturen oder Verbesserungen, die das Team intern entwickelt. Die andere Hälfte arbeitet an ein oder zwei Anwendungen, die stark betroffen sind und geändert werden müssen, wenn das Unternehmen alle paar Monate ein neues Produkt herausbringt. Diese ein oder zwei Anwendungen haben auch Produktionskorrekturen und Verbesserungen, die das Team intern entwickelt. (Es steht uns grundsätzlich frei, sie nach Belieben zu ändern, solange das Geschäft weiterhin unterstützt wird.) Ich bin neu im Team, daher weiß ich noch nicht, inwieweit diese Anwendungen zukunftssicher zur Minderung sein können die plötzlichen dringenden Änderungen.
Das Team hat einige Monate vor meiner Ankunft versucht, Scrum einzuführen, aber da es praktisch keine Product Owner, keine zusammenhängende langfristige Vision für die Anwendungen als Ganzes und wenig gegenseitige Abhängigkeit zwischen den Breakfixes gibt, weiß ich nicht, ob Scrum ist der richtige Weg. Ich habe über die Kombination von Kanban mit Scrum gelesen, kann mich aber nicht damit abfinden. Scrumban klingt gut, aber es ist so viel neuer und weniger ausgereift, dass ich zögere, es zu übernehmen. Was wäre der beste Weg, um dieses Team zu verwalten, damit die Last auf alle Ressourcen verteilt ist, wir in einem nachhaltigen Tempo arbeiten und wir ein einigermaßen definiertes Ziel haben, das unsere Entwicklungsbemühungen leitet?
Basierend auf früheren Erfahrungen würde ich den anderen obigen Posts zustimmen und empfehlen, mit einem Flow-basierten Ansatz wie einem Kanban-Board für die fortlaufenden Support-Apps zu beginnen und sich vielleicht Scrum für diejenigen in schwerer laufender/Funktionsentwicklung anzusehen. Ich würde auch empfehlen, mit einem Board zu beginnen, das Ihrem tatsächlichen Schritt-für-Schritt-Fluss entspricht und nicht einem idealisierten Fluss, auch wenn es wirklich wackelig aussieht - es wird ein wichtiger Teil der Transparenz sein, die Sie durch Kanban gewinnen. Ich denke auch, dass Transparenz Ihnen und dem Team sofort Diskussionspunkte dafür geben wird, wie man sich besser in Unterteams organisiert usw.
Ich stimme jedoch nicht zu, dass Sie einen designierten Product Owner benötigen, insbesondere für die laufenden Support-Sachen und insbesondere, wenn das Team bereits die Produktverantwortung zeigt. In den letzten Jahren habe ich den verteilten Produktbesitz als eine sehr gesunde Sache erkannt/unterstützt; Ähnlich wie ein guter Scrum Master, der darauf abzielt, sich selbst überflüssig zu machen, indem er einem Team zeigt, wie man Kaizen vollständig annimmt und erfolgreich ist, sollte ein guter (einzelner) PO darauf abzielen, sich durch eine unglaublich starke Vision und die Bereitstellung kontinuierlicher Ausrichtungswerkzeuge, die jeder übernehmen kann, überflüssig zu machen und weiter mit.
Davon abgesehen ist es viel schwieriger, ein Vision-ist-alles-Produkt im Vergleich zu etwas in der Wartung umzusetzen, aber es sollte dennoch ein langfristiges Ziel sein. :)
Scrum ist nicht agil. :) Es ist eine Möglichkeit, agil zu arbeiten, aber es passt nicht zu allen Situationen.
Basierend auf dem, was Sie beschrieben haben, wird ein direkter Kanban-Ansatz für Sie viel besser funktionieren. Wenn Sie bei der Unterstützung eines Live-Dienstes eine Änderung vornehmen müssen, muss diese häufig „gestern“ geändert werden. Das Warten auf den nächsten Sprint, um es zum Backlog hinzuzufügen, wird es nicht schneiden.
Warum Kanban? - Kanban hat keine Iterationen. Die Arbeit wird durch Work in Progress oder "WIP" gesteuert. - Kanban hat kein festgelegtes Planungsmeeting. Sie planen so, wie es nötig ist. - Kanban hat immer noch einen nach Rang geordneten Rückstand. - Neue Elemente können jederzeit zum Backlog hinzugefügt und an das Ende der Warteschlange hinzugefügt werden, wodurch dringenden Problemen Priorität eingeräumt wird. - Die Arbeit wird vom WIP gesteuert. Wenn Sie sechs Entwickler haben, sollte Ihre „Doing“-Spalte wahrscheinlich keinen WIP von mehr als 3 haben. Dies kontrolliert Ihre Zykluszeit und stellt sicher, dass Probleme schnell bearbeitet werden.
Einige Anmerkungen: - Es ist immer noch wichtig, eine gute Erstellung von User Storys zu üben, selbst bei dringenden Themen. Stellen Sie sicher, dass Sie Akzeptanztests im Detail überprüfen, kann dies den Unterschied zwischen der einmaligen und der dreimaligen Behebung eines Fehlers ausmachen. - Das Üben guter XP-Praktiken wie TDD wird Ihnen sehr helfen. Zykluszeiten werden verkürzt, Nacharbeiten reduziert und die Qualität verbessert.
Was wäre der beste Weg, um dieses Team zu verwalten, damit die Last auf alle Ressourcen verteilt ist, wir in einem nachhaltigen Tempo arbeiten und wir ein einigermaßen definiertes Ziel haben, das unsere Entwicklungsbemühungen leitet?
Wenn ich Sie wäre, würde ich mit dem folgenden Strohmann-Vorschlag beginnen und ihn von dort aus verfeinern:
Etwa die Hälfte des Teams arbeitet an den meisten Anwendungen, die stabil sind und keinen echten Product Owner oder eine Roadmap haben, mit Ausnahme von Produktionskorrekturen oder Verbesserungen, die das Team intern entwickelt.
Für das Team, das Wartungsarbeiten durchführt, ist Kanban besser geeignet. Möglicherweise benötigen Sie die folgenden Zustände:
Und Sie können 3 Schwimmbahnen wie folgt betrachten:
Die andere Hälfte arbeitet an ein oder zwei Anwendungen, die stark betroffen sind und geändert werden müssen, wenn das Unternehmen alle paar Monate ein neues Produkt herausbringt. Diese ein oder zwei Anwendungen haben auch Produktionskorrekturen und Verbesserungen, die das Team intern entwickelt.
Für das Team, das hauptsächlich Entwicklungsarbeit leistet, ist Scrum wahrscheinlich besser geeignet.
Sie können eine Person zum Scrum Master und eine andere Person zum Product Owner ernennen. Dies müssen keine Vollzeitstellen sein. Dieser Scrum Master kann auch das Kanban-Board verwalten, beim Festlegen von WIP-Limits helfen, Anpassungen basierend auf dem kumulativen Flussdiagramm vornehmen und dabei helfen, Hindernisse für das andere Team zu beseitigen.
Wenn die Größe dieses Scrum-Teams das Limit des Scrum-Leitfadens überschreitet (siehe entsprechenden Auszug unten), erwägen Sie eine Aufteilung in zwei Teams.
Versuchen Sie, die Teams relativ stabil zu halten, denn Teams brauchen Zeit, um zusammenzuwachsen und produktiv zu werden. Sie können jedoch gelegentlich Anpassungen basierend auf der voraussichtlichen Arbeitsbelastung vornehmen.
Es gibt einige Aspekte in Ihrer Situation, die Sie berücksichtigen müssen, bevor Sie sich für das beste Verfahren in Ihrer Situation entscheiden:
Sie sagten, Sie hätten noch keine Produkteigner identifiziert und keine langfristige Vision für die Anwendungen. Sie müssen eine Vision und einen Plan für die Anwendung erstellen, unabhängig davon, ob Sie die agile oder die Wasserfallmethode für das Management der Entwicklung verwenden – Sie sollten mit den Interessengruppen, insbesondere dem Sponsor, zusammenarbeiten, um die Eigentümer des Produkts zu identifizieren und den Plan zu definieren. Da es sich bei Scrum um einen iterativen Prozess handelt, müssen Sie mindestens genügend Funktionen im Detail definieren, an denen das Team im nächsten Sprint arbeiten kann. Sie sollten auch eine Reihe von Funktionen für zukünftige Sprints lose definiert haben.
Sie haben angegeben, dass Sie ein 20-köpfiges Team haben. Eine optimale Größe eines Scrum-Entwicklungsteams liegt bei 3 bis 9 Personen. Wenn Sie sich für Scrum entscheiden, sollten Sie erwägen, mehrere Scrum-Teams zu bilden, die an separaten Anwendungen oder separaten Funktionen aus dem Backlog arbeiten können.
Das Scrum-Entwicklungsteam sollte während des Sprints Tests der fertiggestellten Funktionen durchführen und alle Fehler beheben, bevor die Iterationen der Anwendung am Ende des Sprints freigegeben werden. Bei Fehlern, die nach der Freigabe der Sprint-Iteration auftreten, müssen Sie jedoch mit dem Product Owner zusammenarbeiten, um festzustellen, ob der Fehler zum aktuellen oder zukünftigen Sprint hinzugefügt werden kann oder ob der Fehler kritisch genug ist, um eine sofortige Lösung zu erfordern, was möglicherweise der Fall ist oft der Fall sein. Für diese dringenden Fehler benötigen Sie einen anderen Prozess außerhalb des strikten Scrum-Prozesses, um dringende Fehler zu behandeln. Kanban eignet sich möglicherweise gut für dringende Fehlerbehebungen und für eine Sichtung aller Fehler, die nach der Iterationsfreigabe erkannt wurden. Sie können einige Ressourcen darauf verwenden, sich auf diese Fehler zu konzentrieren,
Der Unterschied zwischen Kanban und Scrum besteht darin, dass Kanban ein kontinuierlicher „Pull“-Prozess ist, während Scrum eigentlich eine Mischung aus einem „Pull“- und einem „Push“-Prozess ist. Ein „Pull“-Prozess, der vollständig nachfragegesteuert ist, und daher ein „Pull“-Prozess wie Kanban, eignet sich hervorragend für Kundendienstanfragen, bei denen die Bearbeitungszeit von größter Bedeutung ist.
Pedro