Programmazione estrema: per quanto tempo dovrebbero essere le iterazioni?

Question

Programmazione estrema: per quanto tempo dovrebbero essere le iterazioni?

#1 da (6 voti)

4

Stavo facendo ricerche su Extreme Programming e ho iniziato a leggere un libro di Kent Beck intitolato Extreme Programming Explained. Lì ha citato pratiche e principi, uno dei quali mi ha confuso. Ha detto che le iterazioni devono essere brevi.

If iterations are good, we'll make the iterations really, really short - seconds and minutes and hours, not weeks and months and years (Extreme Programming Explained - Preface

Più avanti nello stesso libro, Kent Beck usa iterazioni in settimane:

Within a release, XP uses one- to four-week iterations of customer-requested features for fine-grained feedback about progress. (Extreme Programming Explained - Chapter 1)

Il glossario menziona di nuovo una settimana di 1-4 settimane:

Iteration

A one- to four-week period. At the beginning, the customer chooses the stories to be implemented in the iteration. At the end the customer can run their functional tests to see if the iteration succeeded.

(Extreme Programming Explained - Glossary)

Tuttavia, quando leggo sul sito web di programmazione estrema , si dice che le iterazioni durano da 1 a 3 settimane. Tuttavia, ho trovato un video (che inizia alle 7:09) dove menziona le iterazioni in giorni, minuti e secondi .

In Extreme Programming, quanto durano le iterazioni e come funzionano? Un'iterazione funziona su 1 trama utente per 2 settimane? Sembra molto. Uno dei motivi per cui questo mi confonde è perché Scrum completa più storie di utenti in uno sprint che dura 2 settimane. Quando ho approfondito ulteriormente questo argomento, ho detto che gli sviluppatori preferiscono le iterazioni di 2 settimane. Quindi qual è? Sto confondendolo con qualcos'altro?

agile development-methodologies extreme-programming

posta Evgeny Danilenko 28.12.2015 - 00:51

fonte

1 risposta

Leggi altre domande sui tag agile development-methodologies extreme-programming

Quando l'interfaccia dovrebbe essere di proprietà del cliente? Come evitare il pattern LoadBy?

score 6 · Accepted Answer

Trovo questo un po 'confuso, ma penso che questo paragrafo nella prefazione (che è l'unico posto nel libro di Kent Beck in cui sono menzionate le iterazioni più brevi di settimane) aiuta a chiarire le cose:

When I first articulated XP, I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn all the knobs up to 10 and see what happened. I was a little surprised to find that the whole package of practices was stable, predictable, and flexible.

Le pratiche di Extreme Programming si adattano molto bene.

Prendiamo l'esempio di The Planning Game. Il gioco di pianificazione viene eseguito sia a livello di rilascio (per pianificare le storie che andranno in un rilascio) sia di nuovo a livello di iterazione (per pianificare le attività che verranno eseguite in iterazione). In teoria, puoi continuare a utilizzare il gioco di pianificazione per pianificare e gestire ogni attività, anche se un individuo potrebbe usarlo per pianificare la giornata, ad esempio. Tuttavia, ad un certo punto, inizia a non aggiungere valore.

La Extreme Programming porta davvero all'estremo le buone pratiche di ingegneria del software. La programmazione di coppie è una parte fondamentale di XP e richiede revisioni paritetiche e le rende continue. Test Driven Development (TDD) incoraggia la creazione e l'esecuzione frequente di test unitari (anche prima che il codice sia scritto). I clienti e gli utenti possono fornire feedback dopo ogni iterazione, non solo per ogni versione.

Dal punto di vista del business, non ha sempre senso che un progetto funzioni su iterazioni più brevi di 1 settimana o più lunghe di 4 settimane. Le iterazioni visibili dal cliente che sono più brevi di una settimana possono essere dispendiose: spesso porti il cliente a fornire feedback su quasi tutte le modifiche minori apportate al software. Più di 4 settimane impedisce la reattività ai mutevoli requisiti e all'ambiente (sei meno agile). Ma solo perché un'iterazione non esiste a livello di progetto non significa che le pratiche non portino a cose apparenti agli sviluppatori in pochi minuti o secondi, dove quelle cose sono il risultato di recensioni tra pari (tramite Pair Programming), test falliti (unit test / TDD) o build (integrazione continua). Alcune società, tuttavia, come Google, Amazon e Facebook ( 1 , 2 , 3 , 4 ) può apportare modifiche in tempo reale ai clienti più volte alla settimana, a volte in secondi. Queste aziende sono alla fine più estreme di Extreme Programming.