L'approccio agile è troppo una comoda scusa per i cowboy?

Credo che un approccio agile sia il migliore per i progetti in cui i requisiti sono confusi e sono necessarie molte interazioni per aiutare a dare forma alle idee dell'utente finale.

Tuttavia ... Nel mio lavoro professionale, continuo a finire in aziende in cui un approccio "agile" è usato come una scusa sul perché nessuno sforzo è stato messo in un design iniziale; quando i requisiti sono ben compresi.

Non posso fare a meno di pensare che se l'approccio agile non fosse in giro, sarei seduto qui con una bella specifica di alto livello e non dovrei rivedere lo stesso schermo e la stessa funzionalità ogni secondo giorno quando qualcos'altro cresce o giù di lì e quindi non ci avevo pensato.

I vantaggi delle metodologie agili sono davvero sufficienti a superare la scusa per essere zoppi che danno ai contatti tecnici del cowboy?

Aggiornamento: Ironia della sorte, ora sono uno Scrum Master certificato. Uno degli articoli presentati sul corso Scrum osservava che il miglior processo di sviluppo era quello in cui un singolo esperto o guru prendeva le decisioni di progettazione, tuttavia ciò ha evidenti punti deboli. Scrum sposta la responsabilità della produzione di software di qualità nel "Team", il che significa che un team di livello inferiore può cavarsela sfornando spaghetti che immagino non siano diversi dagli altri processi di sviluppo Agile e non Agile.

Credo che se stai usando lo sviluppo Agile come una scusa per la programmazione in stile cowboy, allora non stai seguendo lo sviluppo Agile. I cowboy saranno sempre cowboy, indipendentemente dal processo che darai loro.

Agile non è più responsabile delle cattive pratiche di sviluppo di BDUF. Il problema sta nella disciplina, o nella sua mancanza, nell'applicare le pratiche. Lo scopo delle pratiche BDUF è identificare la direzione del progetto e determinare preventivamente i rischi. Lo scopo delle pratiche agili è mantenere lo stato dello sviluppo abbastanza flessibile da cambiare rapidamente direzione. Un progetto agile potrebbe preparare user story altamente dettagliate in modo che il team sia a conoscenza di direzioni future e selezioni ancora solo 2 o 3 per iterazione per implementarle completamente. Il problema rimane lo stesso a prescindere dalla metodologia utilizzata: la direzione sta facendo funzionare i cowboy.

[BDUF: Big Design Up Front]

Agile, come qualsiasi altra cosa , può essere usato per coprire un comportamento scorretto o per cercare di risolvere un problema di cui la squadra pensa di non essere responsabile.

Tuttavia, la magia di alcune metodologie Agile come Scrum è che forniranno molta visibilità sui problemi all'interno dell'organizzazione. Compresi i problemi all'interno della squadra!

Ti verrà quindi data la possibilità di risolverli non appena si presentano.

Se il problema risiede nei cowboy, questo sarà molto visibile dopo la prima iterazione. Se il problema è altrove, lo vedrai molto presto.

Stranamente, dai progetti "agili" con cui sono stato coinvolto, sembra più una scusa di gestione per saltare la fase di raccolta dei requisiti che un desiderio da cowboy di iniziare semplicemente a scrivere codice. I miei progetti sono stati estremamente frustranti perché non abbiamo utenti finali con cui interagire. Invece, abbiamo un regista che parla alle vendite per scoprire cosa pensano che i clienti desiderino, quindi convoca una riunione e la descrive ai gestori, che iniziano quindi ad assegnare compiti agli sviluppatori. Su un "buon" progetto potremmo avere una presentazione in PP a cui fare riferimento, ma di solito finiamo per passare le nostre riunioni di mischia quotidiane chiedendoci come dovrebbe funzionare qualche funzione, e il manager annota le domande e pone al regista. È una grande perdita di tempo, ma è "agile"!

Non dirò di essere un fan di Waterfall, dal momento che anch'io ho a che fare con un creep sempre frustrante, ma ho sempre visto Agile come una concessione al problema, non un modo efficace per combatterlo. Un buon design, con i primi test iterativi e molti prototipi di carta sembra essere molto più efficace.

Vedo che le difese dello sviluppo agile dicono che non è responsabile per i guasti causati dai cowboy. Il successo con Agile richiede diligenza e intelligenza.

Questa sembra una posizione ragionevole, purché applichi la stessa concessione ad altre metodologie. Se non si può incolpare Agile per errori di progetto causati da cowboy, non si può incolpare metodologie non Agile per errori di progetto causati da cowboy.

Possiamo quindi discutere se esiste una correlazione (non causale!) Tra Agile e cowboy. Con solo prove aneddotiche, credo che ci sia. È percepito come un buon modo per cavarsela con le pratiche da cowboy senza essere scoperto dalla direzione?

Ovviamente, se accettiamo che i cowboy potrebbero non essere distribuiti uniformemente tra le metodologie e accettiamo che i cowboy minano l'uso di successo di un processo, abbiamo reso molto difficile verificare se un processo ha successo. L'affermazione secondo cui un processo è migliore (in un contesto) diventa quasi non falsificabile. Questo è uno dei problemi che mi fa vergognare della mia professione: la mancanza di sostegno scientifico di molte affermazioni.

(A proposito, odio chiamare l'alternativa o le alternative a "cascata" Agile, perché i processi a cascata sembrano essere un uomo di paglia che tutti attaccano, ma pochissime persone hanno mai effettivamente usato senza alcuna iterazione.)

Agile va bene finché funziona per la tua squadra.

Troppi lo stanno vendendo come un modo per trasformare una squadra cattiva in una buona squadra, e semplicemente non funziona in questo modo. Non puoi prendere le persone cattive e applicare un processo per renderle improvvisamente utili.

Mi piacciono molte delle idee alla base dell'agile, ma il fallimento che vedo più volte è che i manager stanno spingendo una serie rigorosa di "processi agili", che vola di fronte all'intero concetto di agile, che i team dovrebbero essere autonomi -organizzazione.

Per quanto riguarda i "cowboy", trovo che per tutti i team agili in cui sono stato, i processi servono a rallentarli più che a lasciarli andare. Non ho mai sperimentato una situazione in cui l'agile servisse per abilitare un "programmatore di cowboy".

Per i buoni team, sembra funzionare bene (poi di nuovo, la maggior parte dei processi sembra funzionare bene quando hai un buon team, divertente come funziona non è vero?).

Per altre squadre, nella mia esperienza, non aiuta mai le persone cattive a fare meglio, ma a volte serve a impantanare le persone produttive.

Nel complesso, penso che l'importante sia costruire una buona squadra, dire loro ciò di cui hai bisogno e poi toglierti di mezzo. Non penso che applicare una serie di parole d'ordine possa risolvere il problema di avere una squadra cattiva.

(Se non ti sei reso conto di quanto sopra, non sono un fan di "Capitol-A Agile" per lo meno. D'altra parte, non penso che incoraggi neanche i cowboy.)

Agile se fatto correttamente dovrebbe avere l'effetto di reinterpretare i lead tecnici "cowboy" e i programmatori "eroi". Se non osservi questo effetto, potrebbe essere un segno che manca qualcosa di importante nella tua agile implementazione.

Voglio aggiungere che "Agile" è davvero un'interfaccia (sto usando una metafora orientata agli oggetti qui) e non puoi istanziarla. Se la tua implementazione concreta è XP , allora devi seguire un sacco di pratiche tecniche con molta disciplina, che lascia poco spazio alla programmazione da cowboy. Un'altra possibilità è che il lavoro di squadra di un team Scrum ben auto-organizzato lo terrà sotto controllo.

Anche i programmatori di cowboy tendono a scrivere codice non molto testabile e tendono a non apprezzare la scrittura di test. Penso che avere tutti a fare TDD possa aiutare a dominare l'atteggiamento da cowboy e far riflettere gli sviluppatori un po 'di più sull'architettura. Nessuna metodologia è perfetta, ovviamente.

Attualmente sto lavorando in un negozio dove questo è il caso, tranne per il fatto che ha più a che fare con la cultura organizzativa che con singoli cowboy specifici.

L'organizzazione ha sempre operato con un approccio relativamente informale, "informale Agile". Non direi che è veramente Agile, è più "Agile nel nome", ma nella pratica è semplicemente una metodologia inesistente. Squadre diverse operano in modo diverso, ma poiché la cultura organizzativa complessiva non ha alcuna metodologia in atto se non un processo molto agile di "Agile in solo nome" - è relativamente caotico e complessivamente caotico - specialmente nell'intergrazione (e ce n'è molto ).

La morale della storia è - Sì, questo succede. Se al momento cercassi lavoro, starei molto attento a questo. Se un negozio afferma di essere Agile, farei alcune domande piuttosto difficili nell'intervista per assicurarmi che più di un semplice nome di Agile venga effettivamente seguito.

Ho scoperto che gli utenti possono darci feedback solo quando hanno un'applicazione che possono usare, schermate su cui possono inserire i dati. Solo allora capiscono veramente cosa stavamo cercando di dire nei documenti dei requisiti (che i clienti firmano ma ognuno ha la propria versione del significato). Se non si tratta di uno sviluppo agile, sarà un progetto a cascata che va oltre il budget ma l'applicazione cambierà una volta consegnata. La tua prima versione non è altro che un prototipo per gli utenti per discutere quali requisiti avrebbero dovuto essere. Quindi preferisco chiamarlo agile piuttosto che sopra il budget.

Penso che sia vero, in alcuni ambienti Agile è usato come una scusa per nessuna disciplina. Il vero problema è che abbiamo perso di vista il motivo per cui abbiamo una metodologia. Personalmente, ritengo che la metodologia sia un problema architettonico nel senso che l'architettura del sistema dovrebbe indirizzare gli attributi di qualità non funzionali, la metodologia dovrebbe affrontare alcuni di quegli stessi attributi (manutenibilità, produttività di sviluppo, trasferimento di conoscenze, et al.)

La visualizzazione della metodologia come controllo degli attributi del processo implica un paio di cose: 1) senza metriche non è possibile confrontare l'efficacia di una metodologia rispetto a un'altra, 2) è necessario prendere una decisione attiva su quali attributi sono importanti (tempi di consegna vs codice qualità vs trasferimento delle conoscenze).

Senza avere entrambe le metriche e un obiettivo tangibile, scegliamo semplicemente una metodologia come la nostra "piuma magica" che se ci teniamo stretti, saremo in grado di fornire software.

Ora i neofiti di Agile, XP, Scrum, ecc. Parlano della fragilità di quella particolare categoria di metodologie. L'argomento è: perché usare una metodologia che può essere sabotata da un individuo privo della disciplina per seguire tutte le regole? La domanda è valida; tuttavia, questo è il sintomo, non la causa. Se un insieme accurato e significativo (che è la parte difficile) di metriche di processo viene definito, testato e tempestivo feedback dato che penso che scopriremo che la particolare metodologia ha poco a che fare con il successo. (Aneddoticamente ho visto progetti di successo che utilizzano una miriade di metodologie e il doppio fallisce usando le stesse metodologie)

Quindi quali sono le metriche? Variano da progetto a progetto, da squadra a squadra e di volta in volta. Utile per quando il programma di consegna è importante, quello che ho usato personalmente è la capacità di stima e la qualità. La maggior parte degli sviluppatori può stimare con precisione attività che durano una settimana o meno. Quindi un approccio è quello di suddividere il progetto in attività per una settimana di sviluppo e tenere traccia di chi ha effettuato la stima. Man mano che il progetto procede, possono modificare le loro stime. Dopo che un'attività è stata completata, se è disattivata di oltre il 10% (1/2 al giorno), trattiamo la stessa cosa come un bug: identifichiamo perché la stima era disattivata (ovvero una tabella del database non è stata considerata), identifichiamo il azione correttiva (cioè coinvolgere il DBA nella stima), e poi andare avanti. Utilizzando queste informazioni possiamo creare metriche come il numero di bug di stima a settimana, il numero di bug per sviluppatore,

E allora? È a questo punto che arrivano le metodologie: se si dispone di un modello predittivo che non soddisfa le qualità del processo, è possibile scegliere di aggiungere o rimuovere alcuni aspetti della metodologia e vedere come influisce sul modello. Certo, nessuno vuole giocare con un processo di sviluppo per paura di fallire, ma stiamo già fallendo a un ritmo costantemente alto e prevedibile. Apportando modifiche individuali e misurando il risultato, potresti scoprire che Agile è la metodologia perfetta per il tuo team, ma potresti anche trovare RUP, cascata o semplicemente un miscuglio di buone pratiche come l'ideale.

Quindi il mio suggerimento è di smettere di preoccuparci di ciò che chiamiamo processo, mettere in atto controlli pertinenti ai nostri obiettivi del processo di sviluppo e sperimentare diverse tecniche per migliorare quel processo.

Starei seduto qui con una bella specifica di alto livello e non dovrei rivedere lo stesso schermo e la stessa funzionalità ogni secondo giorno mentre qualcos'altro si presenta o così e quindi non ci avevo pensato.

Questo sembra coincidere con l'esperienza del mio collega del progetto "agile" a cui sta lavorando (non ne ho mai avuto uno io stesso): gli viene chiesto di scrivere un pezzo di codice su alcune specifiche, quindi proprio quando ha finito di testarlo e è pronto a passare a un nuovo requisito che gli richiede di cambiarlo e testarlo nuovamente. Lo trova frustrante.

Non sto agitando agilmente, sospetto che il team non stia agendo correttamente, ma come dici tu, il termine "agile" a volte può essere usato dai cowboy per convincere i dirigenti a punta che il design a metà cottura è un positivo piuttosto che un negativo .

È divertente come nessuno si consideri un programmatore di cowboy. Scommetto che molti dei poster sono o sono stati uno;)

I programmatori di cowboy sono bravi perché a loro piace fare cose in fretta. Spesso non sono così preoccupati per i problemi del quadro generale o per la qualità del codice, motivo per cui "cowboy coder" è spesso un epiteto. I loro metodi mitigano i rischi in termini di opportunità derivanti dalla consegna tardiva del progetto.

Ai programmatori non cowboy piace fare il proprio lavoro in modo sicuro, disciplinato e ordinato. A loro piace costruirlo nel modo giusto e costruirlo una volta. Sono conosciuti per aver sempre raccolto informazioni, considerando what-ifs, producendo documenti di grandi dimensioni che nessuno legge e consegnando sistemi in ritardo o molto tardi. I loro metodi cercano di mitigare i rischi di software di scarsa qualità.

La genialità delle metodologie Agile è che sfruttano i punti di forza di entrambi i tipi di programmatori forzando iterazioni di lavoro limitate nel tempo che chiedono ai programmatori di produrre rapidamente piccoli lavori di alta qualità. E ogni iterazione mitiga sia i rischi in termini di opportunità derivanti dalla consegna tardiva sia i rischi di software di scarsa qualità.

La ragione per cui l'agile sta dando poca enfasi al design / alle specifiche iniziali non è solo perché i requisiti possono cambiare. Il motivo più profondo è che anche quando i requisiti sono stabili, le specifiche tendono ad essere:

• errato: impossibile acquisire i requisiti.

• incoerente - pieno di contraddizioni perché contengono abbastanza informazioni da rendere impossibile allo scrittore / lettore catturarle.

• distaccato: non incorporano feedback preziosi da un sistema in esecuzione (sebbene degenerato).