Was ist Vorlaufzeit?

Ich habe Mühe, wirklich zu begreifen, was Vorlaufzeit bei einem Kanban-Projekt bedeutet.

Ich habe in mehreren Büchern darüber gelesen, aber ich kann es immer noch nicht fassen.

Kann es jemand erklären.

Antworten (2)

Wiki hat die gemeinsame Definition dieses Begriffs:

Eine Vorlaufzeit ist die Latenzzeit zwischen der Initiierung und Ausführung eines Prozesses.

Wenn Ihr Arbeitsbereich die Softwareentwicklung ist, dann ist die Definition aus dem JIRA-Glossar für Sie vielleicht verständlicher:

Die Vorlaufzeit ist die Zeit, die von der Erfassung eines Problems bis zum Abschluss der Arbeit an diesem Problem vergeht.

Mit anderen Worten (Beispiel für den Softwarebereich): Eine Vorlaufzeit ist die Zeit zwischen dem Zeitpunkt, an dem Sie ein Problem registriert haben, und dem Zeitpunkt, an dem Sie die neue Version der Software mit dem behobenen Problem geliefert haben (neue Version wird bereitgestellt/neuer Patch freigegeben wird/etc):

  Issue                                                          Issue 
requested =================================================>>> delivered

   |                    Activity                       Activity    |
   |---------------|---------------|---------------|---------------|---------------|
   |    List of         List of          List of        List of    |   List of     
   |    created         issues         implemented     delivering  |  delivered    
   |    issues           under           issues         issues     |   issues      
   |                 implementation                                |               
   |                                                               |               
   |                                                               |               
   |                                                               |               
   |<--------------------------Lead Time-------------------------->|

Verwechseln Sie diesen Begriff nicht mit dem ähnlichen Begriff „Zykluszeit“:

Die Lieferzeit beginnt mit der Anfrage und endet mit der Lieferung. Die Taktzeituhr beginnt, wenn die Bearbeitung der Anfrage beginnt, und endet, wenn der Artikel versandbereit ist. Die Zykluszeit ist ein eher mechanisches Maß für die Prozessfähigkeit. Die Lieferzeit ist das, was der Kunde sieht.

  Issue                                                          Issue 
requested ================================================>>>> delivered

   |                    Activity                       Activity    |
   |---------------|---------------|---------------|---------------|---------------|
   |    List of    |    List of    |     List of        List of    |    List of    
   |    created    |    issues     |   implemented     delivering  |   delivered   
   |    issues     |     under     |     issues         issues     |    issues     
   |               | implementation|                               |               
   |               |               |                               |               
   |               |<-Cicle  time->|                               |
   |                                                               |
   |<--------------------------Lead Time-------------------------->|

Werfen Sie auch einen Blick auf diesen Artikel: Kanban: Definition von Durchlaufzeit und Zykluszeit. Es geht um die gleichen Anliegen, aber mit schönen Bildern.

Und noch ein weiterer Artikel mit gleichem Inhalt (falls Sie die Swimlanes und ASCII-Grafiken von JIRA nicht mögen): Cycle Time [and Lead Time] .


Wenn Sie immer noch ein Problem haben, den Begriff "Vorlaufzeit" zu verstehen, hinterlassen Sie bitte einen Kommentar, ich werde versuchen, es zu klären.

Was ist mit der Vorlaufzeit in Scrum-Projekten? Es wäre das Sprint-Backlog, wenn es richtig fertig ist? In einem Scrum-Projekt hätten also alle Arbeitselemente dasselbe Startdatum für die Vorlaufzeit?
@TheLearner - Gute Frage. Kurz: Nein. "Zeitvorlauf" und "Zykluszeit" nehmen in den meisten Fällen unterschiedliche Zeiträume ein. Aber leider ist es schwer, es kurz zu erklären (im Rahmen der Kommentare). Ich denke, es wird für die Community wertvoll sein, wenn Sie neue Fragen erstellen. Ich beantworte sie gerne.
@TheLearner - Entschuldigung für die Verzögerung bei der Beantwortung. Ok, ich habe meine Antwort durch Hinzufügen von Bildern verdeutlicht. So wird es einfacher sein, Ihre Frage jetzt zu beantworten. Zunächst einmal ist Lead Time keine Scrum-Metrik. Die Vorlaufzeituhr beginnt, wenn PBI in PB erstellt wird (nicht, wenn BPI von PB zu SB geht).
@TheLearner - Das bedeutet, dass alle PBIs im aktuellen Sprint nur dann dieselbe Zeit haben, wenn 1) Alle PBIs zu Beginn des Projekts erstellt wurden 2) BPIs während des PBR nicht in mehrere PBIs aufgeteilt wurden 3) Um Am Ende aller Sprints erstellen Sie ein Release mit Implementierungen aller prognostizierten PBIs. In der realen Welt ist diese Situation sehr selten oder sogar nie aufgetreten.
@SergeyKudryavtsev, messen Sie nur die fertigen Artikel? Was ist der beste Weg, um Artikel zu berücksichtigen, die sich im Produkt-Backlog befinden, aber einfach nicht priorisiert werden? Wenn Sie sie nie tun, zählen sie dann? In diesem Fall werden sie effektiv gelöscht, richtig? (Angenommen, Sie haben der Person nein gesagt, verfolgen es aber trotzdem, nur für den Fall?)
@TheLearner, wenn Sie Scrum nach Vorschrift verwenden, beträgt Ihre Vorlaufzeit mindestens 1 Sprint. Einer von vielen Gründen, warum Scrum aufgegeben werden sollte.

Laut David Anderson beginnt die Durchlaufzeit, wenn ein Arbeitselement in das Kanban-System eintritt, und endet, wenn es die erste unendliche Warteschlange erreicht . Mit anderen Worten, es beginnt, wenn man sich verpflichtet, das Arbeitselement zu liefern, und endet, wenn es zur Lieferung bereit ist.

In der Softwareentwicklung liegt die Zusage vor, wenn sich das Team und PO/PM auf die Arbeit an einem Arbeitselement einigen, und die Lieferung erfolgt, wenn das Arbeitselement zur Bereitstellung oder Lieferung bereit ist.

Es spielt keine Rolle, ob das Team sofort mit der Arbeit beginnt oder nicht, da die Durchlaufzeit aus Sicht des Anforderers gemessen wird. Wenn das Team also andere Dinge zu tun hat und nach 3 Tagen mit der Arbeit an der Arbeitsaufgabe beginnt und 2 Tage für die Fertigstellung benötigt, beträgt die Vorlaufzeit 5 Tage. Wenn die Bestellung/PM das Arbeitselement erst nach 4 Tagen annimmt, beträgt die Vorlaufzeit nicht 9 Tage, da die Uhr aufgehört hat zu ticken, als sie die Lieferung erreicht hat.

Ich habe Mühe, dies im Kontext eines hierarchischen Rückstands zu verstehen. Wenn wir also ein Epic mit dem großen Ticketelement „Benachrichtigungen an Benutzer personalisieren“ haben, zu dessen Lieferung wir uns verpflichten, beginnt die Uhr, wenn wir das Epic in das Backlog setzen, und endet, wenn das letzte Ticket geliefert wird, oder beginnt es mit dem Epic aufgeschlüsselt in Sub-Epics oder einzelne Tickets?