La retorica ci insegna che la risposta è probabilmente sì. Tuttavia ritengo che non saremmo più in relazione con la stragrande maggioranza delle storie di successo di Agile.
Penso che il mio superiore abbia letto la colonna dei benefici di un processo Agile ma abbia dimenticato di leggere i requisiti o il successo ottenuto dalle aziende Agile.
Is it possible to be agile without use cases and tests?
Non secondo me No . Vedi wiki per la definizione completa , ma ecco l'apertura:
Agile Software Development is a group of software development methodologies based on iterative and incremental development...
Significa che stai scrivendo unit test con NUnit; beffarsi con Rhino o Moq? No, ma sarà certamente più difficile produrre tempestivamente applicazioni solide e stabili (i progetti in ritardo danneggeranno sicuramente il budget più del tempo impiegato a scrivere casi d'uso e test).
Inoltre, senza test di unità, è davvero difficile essere agili, provare a modificare i requisiti a metà progetto e dare la caccia ovunque si debbano apportare modifiche ...
Lo sviluppo agile, IMHO, deve essere incrementale. Senza casi d'uso e test ben definiti, lo sviluppo non può essere veramente agile.
Ho trovato che lo sviluppo agile mantiene i progetti focalizzati sui requisiti.
I think that my upper management read the benefits column of an Agile process but forgot to read about the requirements or how successful Agile businesses got there.
Questo è un problema molto comune con Agile ...
Dato che Agile è così leggero su processi rigidi, in molti negozi diventa una scusa per la codifica da cowboy sciatta - una sorta di metodologia che suona come Agile sulla carta, ma non è affatto una metodologia.
Il mio ultimo posto di lavoro era esattamente così. Era praticamente codifica da cowboy. L'unica cosa che salvava era che avevano un reparto di test ufficiali e un sistema di tracciamento dei bug decente, quindi almeno le iterazioni sullo sviluppo di nuove funzionalità erano relativamente formalizzate. Ma in tutti gli altri aspetti, Agile non è stato implementato correttamente. Il 90% del tempo in cui stavi tagliando solo un codice completamente non documentato.
Alla fine della giornata, penso che il problema più grande qui è il buon vecchio " Se non stai scrivendo, non stai lavorando " sindrome. Un sacco di manager non tecnici non sembrano capire che c'è più da programmare che stare seduti alla scrivania a battere il codice. E questi sono gli aspetti di Agile che spesso vengono trascurati. Ad esempio, nel mio ultimo posto di lavoro sembrava essere un po 'un tabù per i programmatori e le BA stare seduti per lungo tempo a discutere di qualcosa, come se non fosse "un vero lavoro". Avremmo solo una descrizione di base di una funzionalità, la implementeremo e quindi non sarebbe accettata dal cliente. Ripetere. Alla fine l'intero codebase diventa un hack su un hack - per non parlare del fatto che dedicare del tempo al refactoring spesso non è considerato un "vero lavoro" in quel tipo di ambiente.
Is it possible to be agile without use cases and tests?
I test sono obbligatori se è necessario verificare ciò che è stato costruito e che a mio parere è una cosa tipica. Non sempre fatto, ma probabilmente il 99,999% delle volte c'è una sorta di test fatto. Nel fare quel test, cosa c'è se non un qualche tipo di caso d'uso? Anche se il test è solo per vedere che funziona come previsto, non è ancora un possibile scenario di esecuzione, che è come definirei un caso d'uso in un modo piuttosto liberale?
Non sarebbe la domanda migliore, "Quanto è utile essere agili senza casi d'uso e test?" A cui risponderei, non molto.
Agile riguarda la costruzione di un sistema in una serie di piccole iterazioni di lavoro. Rivaluta le priorità di business alla fine di ogni iterazione e scopri esattamente cosa costruire dopo. Il caso d'uso è la valuta fondamentale dello sviluppo agile, in quanto ogni iterazione comprende vecchi casi d'uso e un piccolo numero di nuovi casi d'uso.
Se sei in grado di testare completamente il tuo sistema alla fine di ogni iterazione e sapere che non infrangerete alcun codice scritto in precedenza, non avrai bisogno di test programmati. Quindi ... non hai bisogno di test programmati .... all'inizio.
Tuttavia, man mano che il sistema cresce, diventa sempre più difficile testare completamente il sistema, e diventa sempre più difficile ricordare esattamente cosa hai costruito alcune iterazioni prima. A quel punto, smetti di essere agile, perché il test è troppo difficile perché non è automatizzato e ripetibile.
IMHO, la risposta è che nessuno sa cosa sia veramente Agile, quindi in pratica non puoi ottenere la risposta giusta a una domanda astratta su cosa astratta.
MSF vs Scrum vs qualcos'altro è come paragonare le mele alle arance.
E a seconda della metodologia, o meglio ancora, della revisione della metodologia, le ipotesi di base cambieranno.
Alcuni pensano che Agile stia facendo le stesse cose, ma che spedisca più velocemente. Alcuni pensano che Agile sia davvero un processo iterativo con una stretta interazione con il cliente, in cui ogni iterazione vede il 50% in più di modifiche al codice Alcuni pensano che Agile sia cascata, ma senza specifiche. ecc.
Quindi, a seconda di come è agile la tua Agile, la domanda può andare in entrambi i modi.
Leggi altre domande sui tag tdd management agile