Kürzlich wurde ich gebeten, das Kanban-System unseres Unternehmens zu inspizieren, und ich habe einige Schwierigkeiten, es zu reparieren. Ich arbeite in einem Startup-Unternehmen und in der Softwareabteilung gibt es 5 Entwickler und 1 Tester. Wir verwenden JIRA für unser Kanban-Board. Aufgaben erscheinen zunächst im Rückstand, und wenn die Aufgabe genehmigt und ein Entwickler zugewiesen wurde, wird sie in die Entwicklung verschoben. Wenn der Entwickler mit der Arbeit an der Aufgabe beginnt, wird sie in den Status „In Bearbeitung“ verschoben und dann in die Überprüfungs-/Test-/Bereitstellungsphase geschickt. Wenn es den Test oder die Überprüfung nicht besteht, wird es wieder zurück in die Entwicklung verschoben, andernfalls ist es erledigt und wird in den Status „Fertig“ verschoben.
Wir haben einen wirklich großen Rückstand, er ist voller Aufgaben, die fast vergessen sind, und es scheint nicht besser zu werden. Beispielsweise ist die älteste Aufgabe seit 3 Jahren dort.
Wir arbeiten hauptsächlich an dringenden Kundenanforderungen oder wichtigen Fehlern. Entwickler beschweren sich, dass nicht genug Zeit bleibt, um einige Arbeiten aus dem Backlog zu entfernen, da sie sich hauptsächlich mit dringenden Aufgaben befassen. Außerdem gibt es einige Verzögerungsarbeiten, die Aufgaben sind, die unser Team nicht bewältigen kann, und diese Aufgaben sind überall – Rückstand, Entwicklung und sogar in der Überprüfung. Aufgaben bleiben in der Überprüfungsphase stecken, weil einige von ihnen lange zum Simulieren oder Testen brauchen, sodass die Entwickler nicht bereit sind, die Testphase zu durchlaufen, weil sie es vorziehen, an dringenden Aufgaben zu arbeiten.
Es gibt kein Limit für WIP, weil sie sagen, dass sie ständig durch ungeplante oder dringende Aufgaben unterbrochen werden und dass es sinnlos wäre, WIP zu begrenzen. Daher kann ich die Anzahl der Aufgaben, an denen Entwickler arbeiten, nicht einschränken.
Ich denke nicht, dass das Entwicklerteam unterdimensioniert ist, ich denke nur, dass ihnen ein System fehlt und sie es mögen, Dinge auf ihre eigene Art und Weise zu erarbeiten. Die Arbeit, die ich bisher geleistet habe, besteht darin, die Kundenanforderungen zu filtern, sodass das Backlog keine redundanten Aufgaben enthält, aber die alten Aufgaben noch vorhanden sind.
Was kann ich dem Team bieten, damit es sowohl dringende Aufgaben als auch Verzögerungsaufgaben bewältigen kann?
Erstens: Es ist klar, dass Ihr Testteam viel zu klein ist . Ein Verhältnis von 5:1 wird einfach (1) einen riesigen Rückstand verursachen und (2) dazu führen, dass Fehler durchschlüpfen. Ihr eigenes Projekt ist der Beweis dafür.
Selbst wenn Sie nachweisen könnten, dass Ihr 5:1-Verhältnis ausreicht, benötigen Sie mindestens einen weiteren Tester. Ein Team von 1 Tester ist keine gute Idee, da Sie niemanden haben, der den Tester testet. Wie Sie selbst geschrieben haben, haben Sie eine ständige Liste wichtiger Fehler ! QED.
Zweitens: Ihr Team verschwendet viel Zeit damit, mit der Liste zu jonglieren. Und ein Teil dieser Liste wird einfach nie fertig werden . Vor lauter Bäumen sieht man den Wald nicht!
Mein Vorschlag ist, sich einen Nachmittag freizunehmen und die Liste zu töten .
Verbringen Sie die erste halbe Stunde damit, die Regeln festzulegen (die Sie im Voraus vorbereiten sollten, aber Sie möchten 80 % Buy-In, um Ihren Verstand zu bewahren).
Ein paar Regeln, mit denen Sie vielleicht beginnen möchten:
Das Ziel dabei ist, die Liste so klein zu machen, dass jeder sehen kann, was er in absehbarer Zeit tun wird. Sie werden aufhören, ihre Zeit damit zu verschwenden, Dinge zu überprüfen, die sie nie tun werden.
Last: Sie denken nicht, dass das Entwicklerteam unterdimensioniert ist . Aber wenn Sie Ihren Beitrag noch einmal lesen, ist es schwer zu glauben. Ich sehe nicht, wie selbst das raffinierteste System der Welt einen Rückstand von mehr als 3 Jahren – der ständig aufgefüllt wird – schrumpfen könnte, ohne zusätzliche Arbeitskräfte hinzuzufügen.
Hier gibt es ein paar Probleme.
Das erste Problem ist der große Rückstand. Dies ist relativ einfach zu lösen - überprüfen Sie die Elemente im Backlog und lösen Sie alles, was nicht mehr erforderlich ist. Die Lösung kann alles Mögliche sein, vom Löschen der Elemente bis zum Markieren als „geht nicht“ oder „veraltet“. Zu diesem Zeitpunkt können auch Duplikate entfernt werden. Dieser kleinere Rückstand sollte einfacher zu priorisieren und in Zukunft allgemein zu verwalten sein. Ich würde davor warnen, bekannte Probleme aus dem Rückstand zu entfernen – es ist möglich, dass Kunden oder potenzielle Kunden Zugriff auf bekannte Probleme oder eine relevante Teilmenge bekannter Probleme anfordern.
Das zweite Problem ist das Fehlen von WIP-Limits. Ich würde empfehlen, diese zu instanziieren. Da Sie jedoch auch an kritischen Themen arbeiten, haben Sie eine „Beschleunigungs“-Zeile auf dem Kanban-Board. Ich würde auch empfehlen, mit dem Sammeln von Metriken zu Durchsatz und Zykluszeit zu beginnen, damit Sie zukünftige Arbeiten vorhersagen können oder wann Sie möglicherweise mit der Arbeit beginnen und sie beenden können, je nachdem, wo sie sich im Rückstand befindet. Ich glaube, dass eines der Dinge, die diese Metriken zeigen werden, ist, dass Sie zusätzliche Mitarbeiter oder eine Änderung des Prozesses benötigen, die es Ihnen ermöglicht, die Arbeit von der Zeit, in der Sie bereit zum Testen sind, schneller fertig zu machen.
Das dritte Problem scheint die Anzahl der kritischen Punkte zu sein. Eine große Anzahl kritischer Probleme, die nicht warten können oder beschleunigt werden müssen, kann auf schlechte Qualität hindeuten. Es könnte auch auf ein schlechtes Produktmanagement und eine schlechte Priorisierung dieser Probleme hinweisen. Zurück zu den Metriken: Wenn Sie Daten darüber haben, wie lange es dauern wird, bis die Arbeit nach einer Platzierung im Backlog erledigt ist, können Sie mit den Beteiligten zusammenarbeiten, um festzustellen, ob die Arbeit wirklich beschleunigt werden muss oder ob sie angemessen priorisiert und befolgt werden kann Ihre WIP-Limits. Im Allgemeinen wäre es auch für das Team und das Projekt von Vorteil, die Anzahl der Fehlerbeseitigungsarbeiten zu reduzieren, die dem Rückstand hinzugefügt werden.
Wir haben einen wirklich großen Rückstand, er ist voller Aufgaben, die fast vergessen sind, und es scheint nicht besser zu werden. Beispielsweise ist die älteste Aufgabe seit 3 Jahren dort.
Ein Ansatz, den ich in der Vergangenheit verwendet habe, ist folgender:
Ich finde, dass dieser Ansatz dazu neigt, den Geist zu fokussieren. Was oft passiert, ist, dass entweder die Personen, die die Arbeit anfordern, zustimmen, die Aufgaben zu archivieren, oder sie drängen auf mehr Ressourcen für Ihr Team, damit die Aufgaben früher erledigt werden.
Es gibt kein Limit für WIP, weil sie sagen, dass sie ständig durch ungeplante oder dringende Aufgaben unterbrochen werden und dass es sinnlos wäre, WIP zu begrenzen.
Dies ist eine Situation, in der WIP wirklich gut funktioniert!
Wenn eine dringende oder ungeplante Aufgabe auftaucht, prüft das Team, ob dadurch das WIP-Limit überschritten wird. Wenn dies der Fall ist, muss etwas anderes aus dieser Warteschlange zurückgezogen werden.
Zum Beispiel kommt eine dringende Fehlerbehebung herein. Das Team hat bereits 5 Elemente in der Spalte „Entwicklung“, was das WIP-Limit ist. Sie sehen in der Liste nach und entfernen ein Element, indem sie es wieder in die Spalte „Warten auf Start“ einfügen.
Als nächstes informiert das Team die Person, die den Artikel angefordert hat, der gerade in die Spalte „Warten auf Start“ zurückgekehrt ist. Sie teilen ihnen mit, dass sich ihre Arbeit aufgrund einer Aufgabe mit höherer Priorität verzögern wird.
Die Vorteile dieses Ansatzes sind:
Schließlich kann es für Sie hilfreich sein, die Auswirkungen der dringenden und ungeplanten Aufgaben zu quantifizieren.
Beispielsweise könnten Sie eine vierzehntägige Status-E-Mail mit folgenden Inhalten versenden:
Aufgrund der dringenden Korrekturen an der Datenbank, die letzte Woche eintrafen, mussten wir die Arbeit an mehreren Aufgaben einstellen. Das Team brauchte fast einen Tag, um auf die neuen Aufgaben umzustellen, und diese Zeit ist effektiv verloren. Wir würden schätzen, dass die Auswirkung auf das Team im Laufe der zwei Wochen eine Effizienzminderung von 10-20 % war.
Auch dies wird helfen, den Geist zu fokussieren.
Die Tatsache, dass Ihre älteste Notiz (Aufgabe) drei Jahre alt ist, ist nicht unbedingt ein Problem, einfach weil Sie, egal wie groß Ihr Team ist, zusammen mit Ihren Kunden immer mehr Ideen für neue Dinge zum Entwickeln/Ändern/Refaktorieren generieren können /fix/etc als die Kapazität Ihres Teams bewältigen kann. Wenn dies von den Teammitgliedern verstanden wird, haben sie weniger Probleme mit einem immer größer werdenden Rückstand. Allerdings möchten Sie vielleicht ein oder zwei Tage pro Jahr damit verbringen, es aufzuräumen; indem Sie einfach die älteren Artikel durchgehen und diejenigen loswerden, die keinen Wert mehr schaffen würden.
Die Vorteile der Verwendung von WIP-Limits sind meiner Meinung nach sehr gut beschrieben https://leankit.com/learn/kanban/benefits-of-wip-limits/ .
Ihre Frage war jedoch, wie Sie sowohl dringende als auch festgefahrene Aufgaben bewältigen können. Lassen Sie mich versuchen, ein wenig darauf einzugehen, wie wir dies in unserer Entwicklung handhaben, die recht gut funktioniert.
Zunächst einmal glaube ich, dass Sie in Betracht ziehen könnten, den Inhalt Ihrer Notizen zu ändern. Sie haben erwähnt, dass Sie Notizen mit Aufgaben haben. In unserem Entwicklungsmodell versuchen wir sicherzustellen, dass jede Notiz eine Leistung beschreibt, die dem Produkt einen Mehrwert verleiht. Um dieses Ergebnis zu vervollständigen (Anmerkung), müssen möglicherweise viele verschiedene Aufgaben durchgeführt werden (Anforderungsanalyse, architektonische Entscheidungen, Design, Implementierung, Dokumentation, Verifizierung, Validierung usw.). Bei der Arbeit mit WIP-Limits haben wir gesehen, dass es effektiver wird, wenn Sie Ergebnisse anstelle von Aufgaben verwenden. Wir haben zwei verschiedene WIP-Limits. Eine für die Notizen auf dem gesamten Board (ohne Notizen im Backlog oder in den Done-Spalten), wir nennen dies das Kanboard WIP Limit (KWL). Das andere ist das WIP-Limit für die einzelnen Phasen auf dem Kanboard, wir nennen das Phasen-WIP-Limit (PWL).
Ein Beispiel: Wenn Ihr Kanboard die Phasen Requirements and Design (RAD), Development and Component Test (DCT), Feature Test (FTE) und Integration Test (ITE) hat, während Ihre Teamgröße 4 beträgt, wäre KWL 3 (Teamgröße). - 1) und PWL <= 3. PWL beginnt bei eins in der Spalte ganz rechts und erhöht sich in diesem Fall um eins bis zu einem Maximum von 3.
Wir versuchen, den geschätzten Aufwand für eine Notiz im Backlog maximal auf das zu beschränken, was innerhalb von 2 Mannwochen erledigt werden kann. Da die Anzahl der in Bearbeitung befindlichen Notizen durch das WIP-Limit begrenzt ist, bedeutet dies, dass mehr als eine Person an mindestens einer der Notizen arbeiten wird; Förderung der Teamarbeit. Da die PWLs allgemein abnehmen, unterstützt es auch die Kernidee von Kanban, den Fluss zu unterstützen (Dinge für die Veröffentlichung vorzubereiten), anstatt viele Dinge gleichzeitig in Gang zu halten (oder ins Stocken zu geraten). Wenn eine Note in der ITE-Spalte stecken bleibt, darf keine andere Note dorthin verschoben werden. Dies unterstreicht noch mehr, dass es für das Team wichtiger ist, die verbleibenden Aufgaben gemeinsam zu erledigen, um diese Note zu erledigen, als etwas Neues zu beginnen. Bei geschätzten Lieferleistungen von höchstens 2 Mannwochen, Wir glauben, dass sie gut genug aufgeschlüsselt sind, um zu unterstützen, dass alle Personen im Team verstehen können, was zu tun ist, um die Notiz in die Spalte „Bereit zur Veröffentlichung“ zu bringen. Wenn die Ergebnisse im Rückstand größer sind, wird in der Regel zu viel Zeit für Dinge aufgewendet, die nicht notwendig sind, oder Dinge werden verpasst, nur weil nicht klar genug ist, was geliefert werden soll.
Angenommen, ein Element ist in der ITE-Spalte blockiert und nur 3 der vier Personen im Team können zur Arbeit daran beitragen, dann sollte die vierte Person an der obersten Notiz in der FTE-Spalte arbeiten (höchste Priorität bei der ganz oben in jeder Spalte, genau wie im Backlog). Vielleicht kann diese vierte Person nicht (leicht) zur FTE-Notiz oder zur DCT-Notiz oder zur RAD-Notiz beitragen. In diesem Fall ist Schlupf aufgetreten (Schlupf im Sinne dessen, was im obigen Link beschrieben ist).
Angehaltene Notizen müssen wie jede andere Notiz vom Team oder den Teammanagern verwaltet werden. Wenn etwas das Team daran hindert, weiter daran zu arbeiten, dann muss ein Manager/Produktmanager/Projektmanager/Scrum Master/Agile Master (oder was auch immer Sie an Ihrem Platz haben) bei der Lösung des Hindernisses helfen. Wenn dies etwas ist, das die Teammitglieder nicht betrifft, sollte die Notiz wieder in den Rückstand zurückgelegt werden (weil niemand im Team aktiv daran arbeitet).
Dringende Aufgaben, wie Sie sagen, können sehr wohl Aufgaben sein (nicht unbedingt zu erbringende Leistungen). Es könnte lauten „untersuche diesen Fehlerbericht“ oder „messe dies“ oder „fasse dies für einen Kunden zusammen“, „ein Fehler, der das Team an der Arbeit hindert, muss behoben werden“ usw. Für diese haben wir einen Krankenwagen eingeführt (nur einen ) auf unserem Kanboard. Eine solche dringende Notiz wird vom Krankenwagen begleitet, wenn er sich über das Brett bewegt, und der Krankenwagen ist der einzige Gegenstand, der das WIP-Limit überschreiten darf. Wenn der Krankenwagen auf der Tafel steht, hat er Vorrang vor den anderen Notizen und möglichst viele aus dem Team sollten dazu beitragen, die dringende Notiz so schnell wie möglich zu beheben.
Wenn Sie dieses Setup verwenden und sich in einer Situation befinden, in der der Krankenwagen immer (oder sehr oft) auf dem Kanboard vorhanden ist, müssen Sie möglicherweise in Betracht ziehen, ein einzelnes spezifisches Team einzurichten, das nur die Krankenwagennotizen verwaltet.