Hallo Habr! Mein Name ist Artyom und ich bin Teamleiter bei Skyeng. Mein Entwicklungsteam hat einen Kunden, er ist Produktmanager, er ist nur Wanja. Vanya glaubt, dass unser Bewertungsschema nicht perfekt ist. Zum Beispiel gibt ihm eine zweitägige Note nichts. Er wird seine Aufgabe in einer Woche oder 10 Tagen am Stiel sehen. Oder länger. Oder weniger.
Dies geschieht nicht, weil wir Aufgaben nicht ausführen, sondern weil wir mit der herkömmlichen Schätzung in Wirklichkeit nur die Zeit schätzen, die ein Entwickler zum Schreiben von Code benötigt. Es gibt aber auch Tests und Codeüberprüfungen. Ok, lassen Sie uns das alles in die Bewertung einbeziehen. Aber auch:
- Wir haben eine Linie unmittelbar vor der Entwicklung und dem Testen.
- Es gibt Verbesserungen, wir sind nicht ohne Sünde.
- dringende Aufgaben fliegen ein
- Wenn eine Implementierung mehrere Services betrifft, warten wir auf eine Überprüfung durch verwandte Teams.
Wie lerne ich, die Frage "Wann?" Zu beantworten ? ob Vorhersehbarkeit nicht in Frage kommt?
Wie wir Estimate in Frage gestellt haben
In unserem Team gibt es, wie in vielen anderen Unternehmen, ein sehr nützliches Meeting - Technical Review (oder in Kurzform Tehrevyu ). Es erfordert einen angemessenen Zeit- und Arbeitsaufwand, erhöht jedoch die Vorhersehbarkeit: Wir planen im Voraus eine technische Lösung für das Problem und bewerten es gleichzeitig.
Da wir immer fern sind, passiert in JIRA alles: Es gibt eine Tafel, auf der die Arbeitsschritte visualisiert werden. Die Karte verlässt den Status "Tech Review" und wechselt zu "Bereit zur Entwicklung", nachdem wir alles beschrieben und bewertet haben. In diesem Moment verpflichten wir uns, die Arbeit zu erledigen.
Ready for Development hat ein WIP-Limit - es können nicht mehr als 8 Aufgaben gleichzeitig ausgeführt werden. Es gibt auch die entgegengesetzte Regel: Sobald eine Spalte nur wenige Aufgaben enthält, leiten wir eine neue technische Überprüfung ein.
Fakt: Wir verbringen viel Zeit mit der Bewertung. Die technische Überprüfung findet normalerweise zweimal pro Woche statt, 4 Aufgaben mit detaillierter Ausarbeitung und Bewertung können 1,5 bis 3 Stunden dauern. Aber! Dann können wir uns noch Zeit nehmen, um herauszufinden, warum die Schätzung überschritten wurde.
Weder Bewertung noch Nachbesprechung verleihen unserem Produkt jedoch einen Mehrwert. Vielmehr verschwenden wir Zeit mit ihnen. Und Geld. Ich habe lange an der Notwendigkeit dieser Verfahren gezweifelt und bin irgendwann zu einem ernsthaften Gespräch mit dem Produkt gereift. Und wir haben beide das Problem erkannt.
"Das Shirt ist trocken und komplett ..." nicht XS
Wir haben uns entschieden: Experimentieren wir mit Bewertungsansätzen. Ich schlug vor, bei der T-Shirt-Größe anzuhalten - die Größe der T-Shirts wird bei dieser Technik als Maßeinheit verwendet. Sie müssen die kleinste Aufgabe finden, die Sie erledigen müssen, und sie mit XS verwechseln. Danach werden die verbleibenden Aufgaben anhand von "wie viel größer sie XS sind" bewertet - und abhängig davon werden ihnen die Größen S, M, L oder XL zugewiesen.
Bestach die Gelegenheit, "mit dem Auge" zu bewerten. Die Idee war einfach: Wir sammeln Statistiken darüber, wie lange die Entwicklung eine Aufgabe der einen oder anderen Dimension erfüllt, berechnen den Durchschnitt und können das Timing vorhersagen.
Der Kunde wird uns in ein oder zwei Tagen einen Fehler verzeihen, was bedeutet, dass keine Nachbesprechung mehr erfolgt. Und Sie müssen keine Zeit für technische Überprüfungen und interaktive Abstimmungen aufwenden. Alles ist glatt!
Wir arbeiten seit mehreren Monaten auf diese Weise und sammeln Statistiken. Und nur Ivan sieht uns schief an.
Es stellte sich heraus, dass XS, wie S, wir es in 1 Tag machen, dann in 10. Und auf L verbringen wir 5 oder 15 Tage. Denn in der Tat nehmen wir einige Arbeiten an erster Stelle, einige an zweiter und einige an fünfter Stelle - und Aufgaben derselben Dimension verbringen unterschiedliche Zeiten im Wartestatus. Ups, hier hast du die mittleren.
Kurz gesagt, die Streuung ist in ein paar Tagen nicht da - und für Wanja hat sich wenig geändert. Wir haben das Experiment als erfolglos erkannt, aber dennoch hat sich die Idee, dass die Aufgaben kategorisiert werden können, irgendwie in meinem Kopf festgesetzt. Und ich begann weiter in diese Richtung zu denken.
„Jeder liebt Kuchen. Puff! " Esel aus Shrek
Und ich liebe. Außerdem ist der Geburtstag eines Kindes ein großartiger Anlass! Ich gehe zu meiner Lieblingsseite und beginne zu wählen:
- du kannst so sein, aber du kannst nicht,
- Sie können dekorieren, aber Sie können nicht dekorieren,
- es kann 2 kg sein, aber es kann 5 kg sein.
Ich werde meine Geschmackspräferenzen nicht preisgeben, aber ich habe den Kuchen gewählt. Und sie brachten ihn zum vereinbarten Termin. Als nächstes kommt die Philosophie eines Teamleiters, der zu viel Kuchen gegessen hat.
Natürlich bin ich kein Newton und der Kuchen ist kein Apfel, aber die Einsicht ist gekommen.
Ich konnte aus vielen Optionen wählen, aber was auch immer ich wählte, der Liefertermin änderte sich nicht. Ich brauchte einen Kuchen in einer Woche. Und sie waren bereit, mir diesen Service anzubieten. Und die Größe des Kuchens, das Gewicht und alle Arten von Schnickschnack hatten keinen großen Einfluss auf das Endergebnis - genauer gesagt, in diesem Fall überhaupt nicht. Es geht nicht um Größe, wie sie sagen. Und in was? Im Preis.
Zum Beispiel hatten die Jungs eine Expressbestellung: Gegen eine zusätzliche Gebühr brachten sie mir in nur wenigen Tagen den gleichen ausgetricksten Kuchen und nicht nach 5. Meine Bestellung, die im Vergleich zu anderen die wertvollste war, würde aus dem Ruder laufen. Grundsätzlich hat die Bäckerei zwei SLAs: eine für reguläre Bestellungen und eine für VIP. Es gibt etwas zu denken.
Die SLA-Idee wurde ausgelöst, weil ich im Kanban-Handbuch darüber gelesen habe
Aus Sicht der Kanban-Methode ist alles eine Dienstleistung. Und trotz der Tatsache, dass wir keine Kuchen liefern und unser Produkt nicht berührt oder gegessen werden kann, ist Entwicklung auch eine Dienstleistung. Und wir behandeln Aufgaben auch anders.
Erinnern wir uns an unser Board: Der
Service besteht aus mehreren Phasen (Entwicklung, Codeüberprüfung, Testen), und die Spalte "Bereit für die Entwicklung" ist unser Ziel, sich gegenüber dem Kunden zu engagieren.
Wir machen einige Dinge in unserem üblichen Rhythmus, aber wenn brennende Aufgaben eintreffen, lassen wir alles fallen. Es bleibt zu verstehen, welche SLA wir haben - und es wird möglich sein, eine Vereinbarung mit Vanya zu schließen.
So bewerten Sie die SLA Ihres Teams: Erstellen eines Spektraldiagramms (ganz einfach)
Um zu verstehen, welche Serviceklassen wir haben und welche SLAs sie haben, schlägt Kanban vor, den folgenden Zeitplan zu erstellen:
- Lead Time (LT) — . « » «».
- Y — LT1, LT2, LT3 ..
Wir haben die Aufgaben übernommen, die in den letzten Monaten geschlossen wurden, und haben Folgendes erhalten:
Wir haben 3 Aufgaben an einem Tag abgeschlossen, 6 in zwei, vor allem in 5, und irgendwo haben wir seit mehr als zwei Wochen mit der Aufgabe zu kämpfen ...
Nun, jetzt ist es Zeit zu analysieren. Was sind diese Aufgaben? Warum sind sie hier gelandet? Warum machen wir in einem bestimmten LT mehr als in anderen, die es gibt? Sie können nach Kunden und Darstellern suchen und die Kommentare zur Aufgabe lesen.
Hier ist was wir graben müssen. Dies ist unser regulärer Job .
Der Spread ist ziemlich groß, kann aber analysiert werden.
Im Allgemeinen wurde der Großteil der Aufgaben im Abstand von 7 bis 14 Tagen verteilt, und ein Paar flog sehr weit weg - in diesem Schwanz gab es mehrere Aufgaben (nicht alle) von PR zu anderen Diensten. Aufgaben, die in 3-4 Tagen erledigt wurden, sind eher eine Ausnahme als eine Regel.
, , , 75% 10 .
Und mit einer Wahrscheinlichkeit von 90% dauert es 14 Tage. Wenn sich die Entwicklung auf andere Dienste des Unternehmens auswirkt, müssen Sie etwas länger warten. Wir benötigen eine Codeüberprüfung durch ein anderes Team und anschließend eine weitere Bereitstellung.
Gehen wir weiter. Wir haben diese Klasse "Wichtig" genannt .
Aus irgendeinem Grund werden diese Aufgaben früher als andere ausgeführt: Es gibt entweder mehr Wert oder die Kosten für Verzögerungen sind höher.
Und hier können wir auch die SLA aussprechen: Mit einer Wahrscheinlichkeit von 75% wird die Aufgabe in 5 Tagen zum Verkauf angeboten, mit einer Wahrscheinlichkeit von 90% in 7. Fahren wir fort?
Die Aufgaben, für die wir alles aufgeben und sägen, sägen, sägen, sind Blocker .
In 100% der Fälle handelt es sich um geringfügige Verbesserungen, die wir bei der Implementierung der Hauptfunktion nicht berücksichtigt haben, oder um Fehler, die sich auf die wichtige Funktionalität des Produkts auswirken.
Trotz der Tatsache, dass wir alle diese Situationen in 2 Tagen gelöst haben, werden wir weiterhin das 90. Perzentil bekannt geben. Erstens sollten Sie nicht 100% versprechen - niemals jemandem :) Zweitens müssen Sie Variabilität aufbauen: Erinnern wir uns an den Fall bei der regulären Arbeit, als mehrere Aufgaben in mehr als 20 Tagen wegflogen, weil die Abhängigkeit von anderen Teams auftrat.
Getan! Wir können uns für alle Serviceklassen mit Vanya SLA abstimmen:
Wir haben genau 90% der Zeit ausgewählt - dies ist in der Tat die Toleranz des Kunden gegenüber Verstößen. Das heißt, wenn 1 von 10 Aufgaben die SLA nicht erfüllt, sind sie bereit, uns zu vergeben.
Wenn Ihr Kunde nicht so freundlich ist, ist es beispielsweise besser, das 95. Perzentil auszusprechen.
Anstelle einer Schlussfolgerung
- Was hindert Wanja daran, nur wichtige Aufgaben oder Blocker zu rekrutieren?
- Horizontale WIP-Grenzwerte.
Wir haben vereinbart, die Anzahl der Aufgaben in der Serviceklasse zu begrenzen: Sie können nicht mehr als zwei Blocker übernehmen, Sie können nicht mehr als zwei wichtige Aufgaben übernehmen. Möglicherweise haben Sie andere Nummern - dies ist eine Frage der Vereinbarung mit dem Kunden. Sie können solche Grenzen in JIRA nicht ohne Plugins festlegen, daher ist auf jeden Fall eine mündliche Vereinbarung erforderlich. Werkzeuge sind Werkzeuge, aber ohne menschliche Interaktion nirgendwo.
Vielen Dank für Ihre Aufmerksamkeit und erfolgreiche Planung!