Puoi applicare agile / TDD in tutte le circostanze?

2

Non sono contro l'agile / TDD e lo uso nella maggior parte delle circostanze. Tuttavia, in alcune circostanze, sento che non funziona bene.

Ad esempio, l'altro giorno stavo creando un'app di elaborazione dati abbastanza complessa. In un mondo ideale strutturerei le fondamenta, disegnerò i componenti, scriverò test unitari e demo su ogni sprint mentre finisco "feature". In pratica comunque, non penso che funzioni prima che la prima versione sia rilasciata perché:

  • Il design delle fondamenta / componenti cambia frequentemente come immagino come fare le cose meglio e semplici test driver sono molto più utili rispetto ai test unitari più ricchi
    Se stai costruendo un'app MVC., La base non cambierà, ma con un'app. dove più o meno costruisci la struttura tu stesso, e non sai come fare le cose meglio in anticipo questo non è il caso. Mi sento test driver semplici con no le verifiche automatizzate sono molto più utili dei test unitari più ricchi a questo stage.
  • Finché non è disponibile l'infrastruttura di base, è difficile interromperla buttare giù le cose in singole "funzionalità" Se hai già un MVC quadro, questo è facile. Ma immagina come è il primo framework MVC mai stato sviluppato. Deve essere stato molto meno utile da pensare cose come "caratteristiche" individuali nelle fasi iniziali, perché il la cosa più importante era capire il principio e la filosofia della separazione Modella, Visualizza e controlla e come farlo.
  • Le demo aiutano molto poco fino a una parte considerevole dell'app. è fatto
    In un Interfaccia utente, puoi semplicemente creare interfacce e ricevi molti preziosi feedback Tuttavia, ad es. in un web crawler, non puoi davvero fare una dimostrazione significativa a persone non tecniche fino a un bel po ' è fatto, e anche se lo facessi, di solito non saranno comunque in grado di fornire input utili. Sicuro, puoi dimostrarlo ai tuoi colleghi sviluppatori, ma è difficile da dare input basato su qualche output di log. Di solito è molto più produttivo spiega come hai fatto le cose e come pensi di fare le cose, forse mostrando illustrazioni e codice, e ottieni feedback in questo modo.

O sto sbagliando?

    
posta Enno Shioji 12.08.2013 - 10:43
fonte

1 risposta

3

Sembra che tu stia sviluppando in un modo agile molto , in realtà. Un modo non agile sarebbe quello di trascorrere settimane disegnando il disegno su carta e attenendosi ad esso quando lo programmate e (inevitabilmente) scoprirete che il tutto è un castello di carte.

Questo sta parlando del principio generale. Per i significati concreti dei termini come test driver, demo, funzionalità ecc. Sono specifici per la situazione.

Sono sempre specifici per la situazione. Il significato comune è quello applicabile al tipo più comune di applicazione, che è il sistema di informazioni aziendali. Quel tipo di applicazione ha una base generica che hai già e su cui sono costruiti moduli individuali, report e flussi di lavoro, che possono essere aggiunti uno alla volta. Quindi puoi aggiungere le poche cose di base, dimostrarlo, piuttosto che aggiungerne ancora, demo di nuovo ecc.

Ma ci sono molte applicazioni in cui ciò non è vero. È ancora possibile utilizzare il processo agile, ma internamente nel progetto. Le tue "user" story vengono definite in termini di API di programmazione implementate, i tuoi test testano solo quelle API raw e così via. È un processo agile nel senso in cui si implementa la funzionalità minima per ciascun componente e lo si rafforza in quanto richiede più funzionalità da esso, e può essere guidato dal test in quanto si dispone di test unitari per i componenti. Non hai ancora coinvolto l'eventuale cliente, perché non hai nulla da mostrare. Alla fine lo farai e continuerai a rifactoring delle fondamenta, perché alcuni problemi fondamentali possono ancora apparire.

    
risposta data 12.08.2013 - 11:07
fonte

Leggi altre domande sui tag