Il tempo di ciclo è una misura di quanto tempo impiega per ottenere una nuova funzionalità in un sistema software program dall’thought alla produzione in produzione. Nei circoli agili, cerchiamo di ridurre al minimo il tempo di ciclo. Lo facciamo definendo e implementando funzionalità molto piccole e minimizzando i ritardi nel processo di sviluppo. Sebbene la nozione approssimativa di tempo di ciclo e l’importanza di ridurlo sia comune, ci sono molte variazioni sul modo in cui viene misurato il tempo del ciclo.
Una caratteristica chiave dello sviluppo del software program agile è un passaggio da a
Processo a cascatadove il lavoro viene scomposto in base all’attività (analisi, codifica, take a look at) a un processo iterativo in cui il lavoro si basa su un sottoinsieme di funzionalità (prezzi semplici, sconto in blocco, sconto valutato per il taglio). In questo modo genera un ciclo di suggestions in cui possiamo imparare mettendo piccole funzionalità di fronte agli utenti. Questo apprendimento ci consente di migliorare il nostro processo di sviluppo e ci consente di comprendere meglio dove il prodotto software program può fornire valore ai nostri clienti.
Questo suggestions è un vantaggio fondamentale di un approccio iterativo e, come la maggior parte di tali circuiti di suggestions, più veloce ricevo il suggestions, più sono felice. Pertanto, le persone agili mettono molta enfasi sulla velocità con cui possiamo ottenere una funzione attraverso l’intero flusso di lavoro e in produzione. La frase Tempo del ciclo ne è una misura.
Ma qui ci imbattiamo in difficoltà. Quando iniziamo e fermiamo l’orologio sul tempo di ciclo?
Il tempo di arresto è il più semplice, più afflitto è quando la funzione viene messa in produzione e aiuta i suoi utenti. Ma ci sono circostanze in cui questo può diventare fangoso. Se una squadra sta usando un file Rilascio canarinodovrebbe essere quando usato dalla prima coorte o solo quando rilasciato alla popolazione completa? Contiamo solo quando l’App Retailer ha approvato la sua versione, aggiungendo così un ritardo imprevedibile che è principalmente al di fuori del controllo del crew di sviluppo?.
L’ora di inizio ha ancora più varianti. Un marcatore comune è quando uno sviluppatore si impegna per questa funzione, ma che ignora qualsiasi tempo trascorso nell’analisi preparatoria. Molte persone tornerebbero indietro e dicevano: “Quando il cliente ha l’thought per una funzione”. Questo va molto bene per una funzione di alta priorità, ma che ne dici di qualcosa che non è così urgente, e quindi si trova in un’space di triage per alcune settimane prima di essere pronto a entrare in sviluppo. Iniziamo l’orologio quando il crew colloca per la prima volta la funzione sul muro della carta e iniziamo a lavorarci seriamente?
Incrocio anche nella fase tempi di consegnaa volte invece di “tempo di ciclo”, ma spesso insieme – dove le persone fanno una distinzione tra i due, spesso in base a un tempo di inizio diverso. Tuttavia, non vi è alcuna coerenza tra il modo in cui le persone distinguono tra loro. Quindi, in generale, tratto il “tempo di lead” come sinonimo di “tempo di ciclo” e se qualcuno sta usando entrambi, mi assicuro di capire come quell’individuo sta facendo la distinzione.
Le various bande del tempo di ciclo hanno tutti i loro vantaggi, ed è spesso utile usare bande various nella stessa situazione, per evidenziare le differenze. In quella situazione, userei un aggettivo distintivo (advert es. Primo commit Cycle Time “contro” Thought Cycle Time “) per distinguere. Non ci sono termini generalmente accettati per tali aggettivi, ma penso che siano migliori che cercare di creare una distinzione tra “tempo di ciclo” e “tempo di consegna”.
Ciò che queste domande ci dicono è che il tempo di ciclo, sebbene un concetto utile, è intrinsecamente scivoloso. Dovremmo diffidare di confrontare i tempi di ciclo tra i crew, a meno che non possiamo essere certi di avere nozioni coerenti dei loro tempi di arresto e inizio.
Ma nonostante ciò, pensare in termini di tempo di ciclo e cercare di minimizzarlo è un’attività utile. Di solito vale la pena costruire una mappa del flusso di valore che mostra ogni passo dall’thought alla produzione, identificando i passaggi nel flusso di lavoro, quanto tempo viene trascorso su di loro e quanto attesa tra di loro. Comprendere questo flusso di lavoro ci consente di trovare modi per ridurre il tempo del ciclo. Due interventi comunemente efficaci sono ridurre la dimensione delle caratteristiche e (contropurreno) aumenta Lento. Fare il lavoro per comprendere il flusso per migliorarlo vale la pena perché più velocemente otteniamo idee in produzione, più rapidamente otteniamo i benefici delle nuove funzionalità e otteniamo il suggestions per apprendere e migliorare i nostri modi di lavorare.
Riconoscimenti
Andrew Harmel-Legislation, Chris Ford, James Lewis, José Pinar, Kief Morris, Manoj Kumar M, Matteo Vaccari e Rafael Ferreira hanno discusso di questo put up nella nostra mailing checklist
