Warum? Können einige Aufgaben nicht bis nächste Woche warten? Ist es so wichtig, absolut alles vor dem Wochenende zu beenden? Nein, das ist nicht so wichtig. Und das alles ist darauf zurückzuführen, dass "das Ausführen von Aufgaben schlecht ist".
Scrum ist keine agile Entwicklungsmethode mehr
Ich bin zu dem Schluss gekommen, dass der Arbeitsprozess in Scrum zu stark betont wird. Oder zumindest schenken die Leute dem zu viel Aufmerksamkeit, was sich im Folgenden ausdrückt:
- Es ist in Ordnung, die User Story am letzten Tag des Sprints zu beenden. Aber die Arbeit am kommenden Montag zu beenden, ist bereits eine "Aufgabenübertragung".
- - ( , ), , , , , .
- , , , . , , , ( , ).
Infolgedessen stellte sich heraus, dass Scrum uns nicht mehr dabei half, das Ziel zu erreichen. Diese Methode des Projektmanagements hat uns jetzt eingeschränkt.
Bei alledem kann ich feststellen, dass meine Teammitglieder anfingen, sich mit dem, was geschah, unzufrieden zu fühlen. Dies wirkte sich auf die Qualität unserer Kreationen aus. Die Programmierer waren mehr daran interessiert, die Fristen einzuhalten als das gewünschte Qualitätsniveau zu erreichen.
Zu diesem Zeitpunkt suchten wir nach anderen Möglichkeiten, die Arbeit zu organisieren, und nach einem anderen agilen Rahmen, der besser zu unserer Arbeitsweise passt.
Dann fanden wir Kanban (Kanban).
Was ist Kanban?
Kanban ist eine Produktionsmanagementmethode, die in den 1950er Jahren bei Toyota entwickelt wurde. Zu dieser Zeit verwendete Toyota ein Board mit drei Spalten: Geplant, In Bearbeitung, Abgeschlossen. Dieser Rahmen ermöglichte es Toyota, Ressourcen in Situationen, in denen irgendwo entlang der Produktionslinie Engpässe auftraten, effizienter zuzuweisen.
Als dann klar wurde, dass die Verwendung von Kanban die Geschwindigkeit der Softwareentwicklung erhöhen kann, wurde Kanban in die Technologiebranche verlegt.
Vergleich von Scrum- und Kanban-Frameworks
In den letzten Jahren haben Scrum und Kanban darum gekämpft, das führende agile Framework zu werden. Trotz der Tatsache, dass Scrum an erster Stelle steht , verbreitet sich Kanban allmählich immer mehr. Was ist, wenn Sie sie vergleichen?
Wenn wir Scrum als Grundlage nehmen und es mit Kanban vergleichen, erhalten wir Folgendes:
- , ().
- .
- «». , .
- , , .
- () -.
Einen detaillierteren Vergleich zwischen Scrum und Kanban finden Sie hier .
Kanban bietet dem Entwicklungsteam ein ziemlich hohes Maß an Flexibilität. User Stories werden im Vergleich zu Scrum freier ausgeführt. Aber Freiheit ist Verantwortung. Während Kanban nicht erfordert, dass sich Entwickler alle zwei Wochen verpflichten, verfügt die Verwendung dieser Methode zur Verwaltung der Entwicklung über eigene Steuerelemente. Dies sind beispielsweise Metriken wie Zykluszeit und Systemdurchsatz.
Es geht nur um Metriken
Es ist unmöglich, die Effektivität (oder Ineffizienz) der Arbeit ohne spezielle Metriken zu bewerten. Werfen wir einen Blick auf die in Scrum und Kanban verwendeten Metriken.
▍Scrum-Metriken
Beim Anwenden von Scrum werden die folgenden Metriken und Diagramme verwendet:
- (velocity). , .
- , , (commitment vs. done). , , .
- (Burndown Chart). , .
Es ist unwahrscheinlich, dass diese Metriken Ihnen helfen, Ihren Workflow zu verbessern.
"Geschwindigkeit" misst nicht die Geschwindigkeit, mit der Subsysteme für fertige Produkte freigegeben werden. Diese Metrik misst nur die Anzahl der abgeschlossenen Arbeitsschritte, die für eine User Story relevant sind. Wenn die Fertigstellung einer Story länger dauert als geplant, ist diese Metrik bedeutungslos.
"Das Verhältnis des Engagements des Entwicklers zum Volumen der erledigten Aufgaben" sollte überhaupt nicht als Metrik betrachtet werden. Diese „Metrik“ vergleicht die Verpflichtung zu Ergebnissen. Dies kann natürlich dazu führen, dass Benutzer Aufgaben schließen und erneut öffnen, um sie zu erledigen.
Das Burnout-Diagramm ist etwas, dem ich persönlich nie viel Aufmerksamkeit geschenkt habe. Dies ist hauptsächlich auf die Tatsache zurückzuführen, dass solche Diagramme häufig wie das folgende aussehen.
Burnout-Diagramm
Warum ist das so? Angenommen, Sie beginnen mit einer leeren Tafel und beginnen parallel zu arbeiten, beispielsweise mit drei User Stories. Diese Geschichten werden wahrscheinlich mit der gleichen Geschwindigkeit bearbeitet, weshalb Sie im Burnout-Diagramm so starke Abwärtsbewegungen sehen können. Wenn es im Team nur einen Tester gibt, der die Arbeitsergebnisse für alle Aufgaben testen muss, ist er der Engpass des Teams.
▍Kanban-Metriken
Ich glaube, dass Metriken die wichtigsten Stärken von Kanban sind. Kanban verfügt über viele verschiedene Metriken, mit denen Sie besser verstehen können, was mit Ihrem Team los ist. Beispielsweise:
- Teamdurchsatz Die Anzahl der User Stories, die innerhalb eines bestimmten Zeitraums abgeschlossen wurden.
- Zykluszeit Die Anzahl der Tage, die seit Beginn der Arbeit benötigt werden, um die Verlaufsarbeit abzuschließen. Hier werden Metriken wie Konfidenzintervalle verwendet. Am häufigsten ist 85% Vertrauen.
- Kumulatives Flussdiagramm Mit einem solchen Diagramm können Sie den Prozess der Problemlösung anhand von User Stories visualisieren. Dieses Diagramm sollte ungefähr so aussehen wie das unten gezeigte.
Kumulatives Flussdiagramm
Es gibt ein Plugin für Jira, mit dem Sie alle diese Metriken nutzen können. Dies ist ActionableAgile für Jira - Agile Metrics . Mithilfe derselben Plattform, die für die Verwaltung der Arbeit verwendet wird, können Kennzahlen ermittelt werden, die für die Teamleistung relevant sind.
Kanban-Anpassung
Die Verwendung von "reinem" Kanban bietet einige der Operationen, die bei der Verwendung von Scrum erforderlich sind, nicht. Diese Methode des Projektmanagements ist jedoch flexibel genug, um, wenn solche Aktionen nützlich erscheinen, dem Workflow hinzugefügt zu werden.
Rückblicke sind eine der wichtigsten Arten von Besprechungen. Bei diesen Treffen können die Teammitglieder darüber sprechen, was sie erreicht haben, was nicht sehr gut gelaufen ist und was verbessert werden kann. Eine Retrospektive ist eine ruhige Veranstaltung, bei der Sie über Ihre Probleme sprechen und denjenigen gratulieren können, die hervorragende Arbeit zu ihrem Erfolg geleistet haben.
Während Rückblenden in Kanban nicht erforderlich sind (sie finden am Ende jedes Sprints in Scrum statt), fanden wir sie wertvoll und wollten sie nicht überspringen. Tatsächlich haben wir sogar angefangen, sie wöchentlich zu machen, anstatt wie früher alle zwei Wochen. Dadurch konnten wir schneller auf auftretende Probleme reagieren. Wir verwenden diese Besprechungen auch, um Teammetriken zu analysieren und Workflows auf Probleme und Engpässe zu überprüfen.
Wir haben ein weiteres Element aus unseren Scrum-Zeiten gespeichert, was bei Verwendung von Kanban optional ist. Es geht darum, die Zeit zu schätzen, die für die Arbeit an einer User Story erforderlich ist. Dies geschieht im Zuge der Klärung der Aufgaben, die in die Geschichte eingehen. Scrum verwendet diese Schätzungen, um besser zu verstehen, was in den Sprint passt. Sie könnten denken, da es in Kanban keine Sprints gibt, ist eine Bewertung der Geschichte nicht erforderlich. Aber eigentlich ist es nicht.
Durch die Schätzung der Zeit, die zum Abschließen einer User Story benötigt wird, wird sichergestellt, dass alle Teammitglieder das gleiche Verständnis für den Umfang der Aufgaben haben, die während der Arbeit an der Story ausgeführt werden müssen. Wenn jemand der Geschichte die Note 8 und jemand die Note 3 gibt, ist es offensichtlich, dass wir dieses Problem weiter diskutieren müssen. Jemand kann bei der Beurteilung des Timings einige Probleme berücksichtigen, von denen andere nichts wissen. Nach dem Verständnis einer Person sollte der Umfang der Arbeit an einer User Story etwas umfassen, das andere nicht als solche betrachten.
All dies treibt die Teammitglieder in Diskussionen.
Wenn so etwas passiert, wird deutlich, dass nicht jeder ein klares Verständnis dafür hat, wie viel Arbeit an einer bestimmten User Story geleistet werden muss.
Ein anderes häufiges Szenario sieht folgendermaßen aus: Das gesamte Team bewertet die Mühsal der Geschichte mit einer ziemlich hohen Bewertung (normalerweise alles, was mehr als 8 Punkte beträgt). Dies spricht von Unsicherheit. Dies bedeutet, dass wir entweder über viel Arbeit sprechen oder über die Lösung sehr schwieriger Probleme, was die Teammitglieder unangenehm macht. In einem solchen Fall ist es am besten, die User Story in mehrere kleinere Storys aufzuteilen und die Ziele der Arbeit klarer zu definieren.
Ergebnis
Scrum wird als erste weit verbreitete agile Methode für immer in unseren Herzen bleiben. Da Unternehmen jedoch auf kontinuierliche Bereitstellungsprogramme umsteigen, ist die Verwendung zeitlich begrenzter Sprints nicht mehr sinnvoll.
Es wird immer spezielle Projekte geben, in denen Scrum gute Leistungen erbringen kann. Angesichts der Tatsache, dass Unternehmen zunehmend agile Methoden einsetzen, wird Kanban nach und nach die Nase vorn haben und Scrum verdrängen.
Was passt am besten zu dir? Scrum oder Kanban?
