L'approccio agile è una buona scusa per i cowboys

Credo che se si sta utilizzando lo sviluppo Agile come scusa per la programmazione in stile cowboy, allora non si sta veramente seguendo lo sviluppo Agile. I cowboys saranno sempre dei cowboys, non importa quale processo gli dai.

Agile non è più da incolpare per le pratiche di sviluppo povere 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 i rischi in anticipo. Lo scopo delle pratiche agili è quello di mantenere lo stato dello sviluppo sufficientemente flessibile per cambiare rapidamente direzione. Un progetto agile può preparare storie utente altamente dettagliate in modo che il team sia a conoscenza delle future direzioni e seleziona ancora solo 2 o 3 per iterazione per implementarle completamente. Il problema rimane lo stesso, qualunque sia la metodologia utilizzata: la gestione lascia correre i cowboys.

[BDUF: Big Design Up Front]

Agile, come qualsiasi cosa , può essere utilizzato per coprire un comportamento errato o per cercare di risolvere un problema di cui il team pensa di non essere responsabile.

Tuttavia, la magia in alcune metodologie Agile come Scrum è che forniranno visibilità a molti problemi all'interno dell'organizzazione. Compresi i problemi all'interno del team!

Ti verrà quindi data l'opportunità di risolverli non appena si presentano.

Se il problema riguarda i cowboys, questo sarà molto visibile dopo la prima iterazione. Se il problema è altrove, lo vedrai molto presto.

Non dirò di essere un fan di Waterfall, visto che anch'io ho a che fare con il sempre più frustrante scope-crawly, ma ho sempre visto Agile come una concessione al problema, non un modo efficace per combatterlo. Un buon design, con test iterativi precoci e molti prototipi di carta sembrano essere molto più efficaci.

Vedo le difese di Agile Development che affermano che non è responsabile dei guasti causati dai cowboys. Il successo con Agile richiede diligenza e intelligenza.

Sembra una posizione ragionevole, purché si applichi la stessa concessione ad altre metodologie. Se non puoi incolpare Agile per i fallimenti del progetto causati dai cowboys, non puoi incolpare le metodologie non Agile per i fallimenti del progetto causati dai cowboys.

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

Naturalmente, se accettiamo che i cowboys non siano distribuiti uniformemente tra le metodologie e accettiamo che i cowboys minano l'uso di successo di un processo, abbiamo reso molto difficile testare se un processo ha avuto successo. L'affermazione che un processo è migliore (all'interno di un contesto) diventa vicino a non falsificabile. Questo è uno dei problemi che mi fa impazzire per la mia professione - la mancanza di sostegno scientifico di molte affermazioni.

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

Agile va bene finché funziona per il tuo team.

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

Mi piacciono molte delle idee dietro l'agile, ma l'errore che vedo di volta in volta è che i manager stanno spingendo un insieme rigido di "processi agili", che sfidano l'intero concetto di agile, che i team dovrebbe essere auto-organizzante.

Per quanto riguarda i "cowboys", trovo che per tutti i team agili in cui sono stato, i processi servano a rallentarli più che lasciarli scatenare. Non ho mai sperimentato una situazione in cui agile serviva per abilitare un "codificatore di cowboy".

Per i buoni team, sembra funzionare bene (anche in questo caso, la maggior parte dei processi sembra funzionare bene quando hai una buona squadra, divertente come funziona non è vero?).

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

Nel complesso, penso che l'importante sia costruire una buona squadra, dire loro di cosa hai bisogno e poi toglierti di mezzo. Non credo che applicare una stringa di parole d'ordine possa risolvere il problema di avere una squadra sbagliata.

(Se non hai capito da quanto sopra, non sono affatto un fan di "Capitol-A Agile". D'altra parte, non credo che sia d'incoraggiamento per i cowboys.)

Agile quando fatto correttamente dovrebbe avere l'effetto di controllare i lead tecnici "da cowboy" e i programmatori "eroi". Se non osservi questo effetto, quello potrebbe essere un segno che qualcosa di importante non è presente nella tua implementazione agile.

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 dei cowboy. Un'altra possibilità è che il lavoro di squadra di un team Scrum ben organizzato lo manterrà sotto controllo.

I codificatori dei cow-boy tendono anche a scrivere codice che non è molto testabile, e tendono a non gradire i test di scrittura. Penso che avere qualcuno che fa TDD possa aiutare a regnare nell'atteggiamento da cowboy e far riflettere gli sviluppatori sull'architettura un po 'di più. Nessuna metodologia è perfetta, naturalmente.

Attualmente sto lavorando in un negozio in cui questo è il caso, eccetto che è più legato alla cultura organizzativa che ai singoli cowboy.

L'organizzazione ha sempre operato su un approccio "informale e agile" relativamente libero. Non direi che è veramente Agile, è più "Agile in name", ma semplicemente una metodologia inesistente nella pratica. Diverse squadre operano in modo diverso, ma dal momento che la cultura organizzativa complessiva non ha alcuna metodologia in atto oltre a un processo molto agile "solo nome", è piuttosto caotico e caotico in generale - specialmente nell'intergration (e c'è molto di questo ).

La morale della storia è - Sì, questo succede. Se fossi in cerca di lavoro al momento, sarei molto attento a questo. Se un negozio afferma di essere Agile, nel colloquio porrei delle domande piuttosto difficili per garantire che venga seguito più che semplicemente un termine improprio di Agile.

Penso 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 una questione architettonica nel senso che l'architettura del sistema dovrebbe rispondere agli attributi di qualità non funzionali, la metodologia dovrebbe affrontare alcuni di quegli stessi attributi (manutenibilità, produttività di sviluppo, trasferimento di conoscenza, et al.)

La visualizzazione della metodologia come controllo per gli attributi del processo implica un paio di cose: 1) senza metrica non possiamo confrontare l'efficacia di una metodologia rispetto ad un'altra, 2) deve essere presa una decisione attiva su quali attributi sono importanti (consegna time vs code quality vs knowledge transfer).

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

Ora i nay-sayers 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 una serie precisa e significativa (che è la parte difficile) delle metriche di processo sono definite, testate e un feedback tempestivo, 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 di fallimenti nell'usare le stesse metodologie)

Quindi quali sono le metriche? Essi 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à e la qualità di stima. La maggior parte degli sviluppatori può stimare con precisione compiti che durano una settimana o meno. Quindi un approccio è quello di dividere il progetto in compiti di uno sviluppatore lungo una settimana e tracciare chi ha fatto la stima. Mentre il progetto va avanti, possono cambiare le loro stime. Dopo che un'attività è stata completata, se è stata disattivata di oltre il 10% (1/2 al giorno), consideriamo questo come un errore: identifichiamo il motivo per cui la stima è stata disattivata (ovvero una tabella di database non è stata considerata), identifica il azione correttiva (cioè coinvolgere il DBA nella stima), e poi andare avanti. Usando queste informazioni possiamo creare metriche come # di bug di stima a settimana, # di bug per sviluppatore, # di bug per KLOC, # di bug per sviluppatore-KLOC, ecc. Pubblicare questi numeri sul wiki del team fornisce una seria pressione sociale e dal punto di vista gestionale, dopo un paio di settimane, è possibile generare un modello predittivo delle successive settimane di sviluppo.

Quindi cosa? Ecco quando arrivano le metodologie - se si dispone di un modello predittivo che non riesce a soddisfare 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. Effettuando modifiche individuali e misurando il risultato, potresti scoprire che Agile è la metodologia perfetta per la tua squadra, ma potresti trovare facilmente RUP, cascata o solo un miscuglio di best practice per essere l'ideale.

Quindi il mio suggerimento è smettere di preoccuparsi di ciò che chiamiamo il processo, mettere in atto controlli rilevanti per i nostri obiettivi del processo di sviluppo e sperimentare diverse tecniche per migliorare tale processo.

I'd be sitting here with a nice high level specification and not having to revisit the same screen and functionality every second day as something else crops up or so and so hadn't thought of that.

Questo sembra corrispondere all'esperienza del mio collega del progetto "agile" in cui si trova (non ne ho mai visto uno anch'io): gli viene chiesto di scrivere un pezzo di codice per alcune specifiche, quindi proprio mentre ha finito testarlo ed è pronto a passare a un nuovo requisito che gli richiede di cambiarlo e ri-testarlo. Lo trova frustrante.

Non mi sento agile, ho il sospetto che la squadra non stia agendo correttamente - ma come dici tu, il termine "agile" può a volte essere usato dai cowboys per convincere la dirigenza a punta che il design semi-cotto è piuttosto positivo di un negativo.

È divertente come nessuno si consideri come codificatori di cowboy. Sto scommettendo che molti dei poster sono o sono stati uno;)

I codificatori dei cowboy sono buoni perché a loro piace fare le cose velocemente. Spesso non sono così preoccupati per problemi di immagine o qualità del codice, motivo per cui "coder da cowboy" è spesso un epiteto. I loro metodi attenuano i rischi dei costi opportunità della consegna tardiva del progetto.

I codificatori non-cowboy amano svolgere il proprio lavoro in modo sicuro, disciplinato e ordinato. A loro piace costruire bene e costruirlo una volta. Sono conosciuti per aver raccolto per sempre informazioni, considerando cosa, producendo documenti di grandi dimensioni che nessuno legge e che forniscono sistemi in ritardo o molto tardi. I loro metodi cercano di mitigare i rischi di software di scarsa qualità.

La brillantezza delle metodologie Agile è che sfruttano i punti di forza di entrambi i tipi di codificatori forzando brevi iterazioni di lavoro limitate nel tempo che chiedono ai programmatori di produrre rapidamente piccoli pezzi di alta qualità. Ogni iterazione attenua sia i rischi legati ai costi opportunità della consegna tardiva che i rischi di software di scarsa qualità.

La ragione per cui l'agile mette poco in risalto le caratteristiche e le specifiche di progettazione anticipate non è dovuta al fatto che i requisiti potrebbero cambiare. La ragione più profonda è che anche quando i requisiti sono stabili, le specifiche tendono ad essere:

• errato - non riescono a catturare i requisiti.

• incoerenti - pieni di contraddizioni perché contengono informazioni sufficienti a rendere impossibile allo scrittore / lettore di catturarli.

• staccato - non incorporano un prezioso feedback da un sistema in esecuzione (sebbene degenerato).