Cosa rende lo sviluppo di software Agile così attraente?

Lo sviluppo di software agile sta diventando una parola d'ordine piuttosto divertente in questi giorni.

Come sviluppatore, comprendo il valore pragmatico dello sviluppo iterativo, ma (molto spesso) non è una scelta degli sviluppatori abbracciare un approccio Agile allo sviluppo del software. È una scelta di gestione top-down! Che si tratti di cristallo, metodi agili, dsdm, rup, xp, scrum, fdd, tdd, lo chiami. Non è una scelta dello sviluppatore.

Per tutti i manager là fuori, quali sono i principali motivi per scegliere di fare lo sviluppo Agile quando (nella mia esperienza) la maggior parte dei manager non ha nemmeno toccato un pezzo di codice nella loro vita!

Requisiti di spostamento, consegna più veloce

Agile è allettante perché offre la possibilità di adattarsi alle esigenze in evoluzione più rapidamente (o affatto) e di consegnare tali modifiche al cliente più rapidamente.

Questo è il motivo per cui molte aziende falliscono quando usano Agile / Scrum: i manager non capiscono che con grande potenza (di impostare date di rilascio più veloci e cambiare spesso i requisiti) viene la responsabilità di fare affidamento sugli sviluppatori per le stime . Perché l'agile funzioni, il manager deve essere disposto a ridurre l'ambito di applicazione.

Vogliono il potere di entrambi.

Seguendo le tendenze

A volte le persone fanno le cose, non a causa del merito della cosa su cui si stanno imbarcando (agile), ma semplicemente perché è popolare e altre persone stanno tentando di fare lo stesso.

"Cosa? Macrojam sta facendo Agile? Perché non lo siamo? Non siamo lenti, siamo Agili, dannazione!"

Alcune persone non danno una buona sorte a ciò che significa essere agili. È semplicemente un mezzo per giustificare la loro esistenza. Pecore, pressione dei pari, ecc.

La codifica stessa non è la ragione principale per cui i manager possono essere convinti a selezionare agile come metodo. È interessante il fatto che tu possa reagire più rapidamente alle mutevoli esigenze e priorità. Il "gestore" alla fine deve fornire una soluzione all'utente finale / al cliente / al suo responsabile.

Se la funzionalità che sembrava fondamentale all'avvio del progetto può essere abolita a metà del progetto e sostituita da nuovi requisiti più rilevanti, questo è un grande vantaggio.

È anche importante che per lo più (ad es. Come nella mischia) ogni consegna intermedia sia quasi pronta per essere messa in produzione. Allo stesso tempo, le funzioni più urgenti sono state sviluppate per prime. Quindi, nel caso in cui il progetto venga annullato a causa di una decisione aziendale, il management è sicuro che finirà con qualcosa che funzionerà e potrà essere messo in produzione.

Spero che sia di aiuto.

Aumenta la visibilità su ciò che sta succedendo e aumenta la produttività

1. I manager sono solitamente interessati dalla visibilità che porta agile, specialmente con la mischia. È uno dei punti vendita più utilizzati nei seminari destinati ai manager.

2. Una maggiore produttività viene anche comunemente utilizzata per attirarli in quanto è facile da dimostrare (grazie alla visibilità). Alcuni evangelisti agili promettono loro un'eccezionale produttività dai loro dipendenti esistenti. "Cosa? Li sto già premendo come i limoni e mi dici che posso ottenere ancora di più " ?

Molti manager usano l'agile per schiacciare un po 'di più il loro dipendente e li ho visti usare il grafico del burn down come una macchina da caccia più debole in una grande azienda.

Risultato? Molti team dentro distress. Pensavano che l'agile avrebbe risolto tutti i loro problemi, ma ha fatto esattamente il contrario. Il problema era altrove.

Sto combattendo attivamente contro questo. Ecco perché a volte dove c'è un'alta probabilità rispetto alla metodologia agile pervertedda parte del management, suggerisco di non menzionarlo all'interno dell'azienda.

La risposta a questa domanda potrebbe riempire un libro.

Penso che uno dei motivi principali sia che lo sviluppo agile si concentri sul risultato finale. Si concentra sempre sul fornire esattamente ciò che è più urgente qui e ora.

Un altro motivo è che le pratiche di pianificazione e stima basate sulla storia che seguono i processi agili forniscono una stima molto migliore di ciò che può essere consegnato e quando.

Un buon esempio di quanto sia efficace la pianificazione basata su storie è un progetto a cui ho lavorato. Per un paio di mesi (prima che adottassimo uno sviluppo agile), il responsabile del progetto ha creduto che avremmo potuto consegnare in tempo, e che era circa 18 mesi dalla scadenza. Tutti gli sviluppatori avevano la sensazione che probabilmente non fosse realistico. Dopo aver avviato una pianificazione agile, il responsabile del progetto ha ancora avuto una valutazione ottimistica della situazione. Ma solo dopo alcuni sprint, il leader del progetto ha capito che il team semplicemente non aveva la capacità di fornire tutti i requisiti nel tempo previsto. E questo era ancora a più di 12 mesi dalla scadenza.

Quindi le pratiche agili chiariscono molto presto la realtà.

Infine, i team agili tendono ad adottare più spesso pratiche che creano una migliore qualità del codice, ad esempio sviluppo guidato da test, refactoring frequente, integrazione continua, revisione del codice peer / programmazione di coppie, ecc. Non che i progetti software tradizionali vietino queste pratiche, tendono solo a non essere così a fuoco.

la maggior parte dei manager non ha nemmeno toccato un pezzo di codice nella loro vita!

Sono stato uno sviluppatore per 12 anni e ora un manager per 5. Durante i 5 anni sono passato gradualmente da un manager che ancora programmava per essere principalmente un manager puro (a volte risolvo ancora bug o faccio esercizi di prototipazione).

quali sono i principali motivi per scegliere di fare lo sviluppo Agile

• Visibilità o successo veloce / Fallimento veloce - Siamo un negozio di sviluppo prodotto con cicli da 6 mesi a 24 mesi. Lo sviluppo iterativo con funzionalità funzionanti e testate ha fatto un lavoro migliore nel riflettere lo stato del progetto.
• Cambiamenti - Nel nostro ambiente, i requisiti e i tempi tendono ad essere fissi. Ma il business su base troppo regolare subisce rapidi cambiamenti di direzione. Lo sviluppo iterativo e visibile ha reso più facile per i progetti cambiare direzione.
• I requisiti basati su storie con sviluppo iterativo hanno reso più facile lavorare con l'azienda che non sempre comprendeva gli aspetti tecnici dei requisiti o comprendeva appieno i driver di business di alcuni dettagli. In passato, le specifiche di alto livello o i documenti relativi ai requisiti di marketing non erano sempre sufficienti. Ora che i progetti evolvono, possono esserci ricerche parallele sul mercato e sui clienti.
• Il cambiamento di processo è arrivato con molti altri attributi di sviluppo come TDD, test automatizzati rispetto a test manuali, cicli di test più rigorosi (non abbiamo più un gruppo QC, solo un gruppo QA) e un apprezzamento e uno sforzo più elevati legati alla qualità (utilizziamo un molti più strumenti e metriche).

Avremmo potuto raggiungere questo obiettivo in altri modi, ma sfruttare metodologie e idee agili ci ha aiutato immensamente.

Continuiamo anche a perfezionare il nostro processo. Ad esempio, l'equilibrio tra il lavoro di progettazione frontale e il design appena prima dell'implementazione. Esaminiamo regolarmente tutte le nostre decisioni per determinare se avremmo potuto differire le decisioni di progettazione passate. E, quando le cose vanno male, quanto più lavoro iniziale sarebbe stato necessario fino a quando l'errore non sarebbe stato identificato. Spesso i fallimenti sono casi angolari che richiedono un'analisi approfondita. Lo sforzo per ottenere questo dettaglio è spesso uguale al costo di capirlo lungo la strada e il refactoring. Le squadre non sono penalizzate per questo tipo di errori e sono incoraggiate ad essere più aggressive.

Ho visto un certo numero di aziende "fare" agili. Sfortunatamente, pochissimi adottano agili. Quello che voglio dire è solo fare lo sviluppo iterativo e standup giornalieri (dove la maggior parte del team si siede) non rende Agile il team. TDD, refactoring, integrazione continua, presenza dei clienti, pratiche SOLID rendono agile un team. Senza quelli, stai solo girando in tondo.

C'è molto appello che porta il messaggio di Agile. L'adattabilità al cambiamento è la più grande. Sfortunatamente, il tuo codice non diventa più adattabile solo perché cambi il modo in cui gestisci il progetto. Fino a quando più aziende non lo capiranno, sentiremo solo parlare di un progetto agile sempre più fallito.

Non conosco la parte della parola d'ordine. Lo sto facendo da sempre in un processo non così formalizzato o identificato. Ho avuto clienti che mi guardavano letteralmente alle spalle mentre costruivo il loro sito web. Ho salvato circa 50 e-mail e il cliente ha imparato qualcosa su questo processo - non è facile.

L'idea che ci vorrà un lungo periodo di tempo per annotare tutto ciò che l'utente vuole che faccia il software, quindi impiegare un periodo di tempo più lungo per costruire ciò che pensiamo che vogliono scoprire solo entro 2 secondi dal tentativo dell'app che questo non è quello che si aspettavano è nauseabondo. Quanto è difficile scomporre qualsiasi progetto o applicazione in alcuni pezzi ragionevoli per costruire e ottenere un feedback prima di costruire un altro pezzo?

So che si tratta di una semplificazione eccessiva e non affronta le pratiche degli sviluppatori reali, ma non è difficile vendere anche al manager o al cliente più non tecnico. Quale altro approccio è più attraente? I clienti adorano davvero il fatto che i programmatori non abbiano più capelli per 6-12 mesi mentre si sviluppano durante un progetto a cascata? Assumeresti qualcuno per costruire una casa in questo modo?

La direzione non spinge queste cose sugli sviluppatori. Gli sviluppatori e i team dovrebbero prendere l'iniziativa e impegnarsi per fare meglio il proprio lavoro. Il compito della direzione è fornire supporto per queste iniziative.

Come manager che ha scritto una buona dose di codice nella mia carriera, potrei non essere quello che stai cercando di rispondere. In ogni caso, penso che l'attrazione di Agile in questi giorni abbia più a che fare con la risposta alle esigenze dei clienti più rapidamente, nonché abbreviando il circuito di feedback tra specifiche, codifica, test e cliente. Stiamo muovendo verso uno sviluppo più agile proprio per questi motivi.

Penso che non dovresti confondere il processo Agile e le pratiche di codifica / sviluppo. Ad esempio, Scrum non ti dice come dovresti sviluppare il tuo codice, ma riguarda tutto il processo che accoglie le modifiche.

Alla fine, si tratta di responsabilizzare lo sviluppatore; si tratta di riconoscere il fatto che quei ragazzi che sono in fondo alla gerarchia sono gli unici che comprendono veramente l'entità di ciò che deve essere fatto e come farlo, quindi se li hai già assunti per la loro esperienza - perché non lasciare che prendano il pieno controllo o meglio, perché distanziarli dall'effettivo processo decisionale?