Cosa rende lo sviluppo del software Agile così attraente?

Requisiti di spostamento, consegna più rapida

Agile è attraente perché offre la possibilità di adattarsi alle mutevoli esigenze più rapidamente (o del tutto) 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 potere (di impostare date di rilascio più veloci e cambiare spesso i requisiti) viene la responsabilità di affidarsi sugli sviluppatori per le stime . Affinché funzioni agile, il gestore deve essere disposto a tagliare l'ambito.

Vogliono il potere di entrambi.

Tendenze seguenti

A volte le persone fanno cose, non per il 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é no? Non siamo lenti, siamo Agili, dannazione!"

Alcune persone non danno un bel cazzo di cosa sia effettivamente agile. È semplicemente un mezzo per giustificare la loro esistenza. Sheeple, peer pressure, ecc.

La codifica in sé non è il motivo principale per cui i manager possono essere convinti di selezionare l'agile come metodo. Il fatto che tu possa reagire più rapidamente ai mutevoli requisiti e priorità è allettante. Il "manager" alla fine deve fornire una soluzione all'utente finale / cliente / al suo manager.

Se la funzionalità che sembrava fondamentale per l'avvio del progetto può essere eliminata dal progetto intermedio e sostituita da nuovi requisiti più rilevanti, questo è un grande vantaggio.

Altrettanto importante è questo (per esempio, come in scrum) ogni consegna intermedia dovrebbe essere 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 alcune decisioni aziendali, la direzione è certa che si finirà con qualcosa che funzionerà e può essere messo in produzione.

Spero che questo aiuti.

Increase visibility on what's is going on, and increase productivity

1. I gestori sono solitamente interessati alla visibilità che porta, specialmente con scrum. È uno dei punti vendita più utilizzati nei seminari rivolti ai manager.

2. Produttività più elevata è anche comunemente usato per attirarli poiché è facile da dimostrare (grazie alla visibilità). Alcuni evangelisti agili promettono loro un'eccezionale produttività dai loro attuali dipendenti. "Cosa? Le sto già premendo come limoni e tu mi dici che posso ottenere anche più " ?

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

Risultato? Molti team in distress . Pensavano che l'agile avrebbe risolto tutti i loro problemi, ma ha fatto l'esatto opposto. Il problema era altrove.

Sto combattendo attivamente contro questo. Ecco perché a volte dove c'è un'alta probabilità di una metodologia agile sarà perverted dal management, suggerisco di non menzionarlo all'interno dell'azienda.

La risposta a questa domanda potrebbe riempire un libro.

Penso che uno dei motivi principali è che lo sviluppo agile si concentra sul deliverable. 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 sulla storia, è un progetto a cui ho lavorato. Per un paio di mesi (prima che adottassimo uno sviluppo agile), il leader del progetto riteneva che avremmo potuto consegnare in tempo, e che era di circa 18 mesi dalla scadenza. Tutti gli sviluppatori avevano la sensazione che fosse probabilmente irrealistico. Dopo aver avviato una pianificazione agile, il capo progetto aveva ancora una valutazione ottimistica della situazione. Ma solo dopo alcuni sprint, il capo progetto si è reso conto che il team semplicemente non aveva la capacità di fornire tutti i requisiti sui tempi previsti. E questo era ancora più di 12 mesi dalla scadenza.

Anche le pratiche così agili rendono la realtà molto più chiara.

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

most managers haven't even touched a piece of code in their life!

Ero uno sviluppatore da 12 anni e ora un manager per 5. Durante i 5 anni ho passato gradualmente da un manager che ancora codificava per essere principalmente un manager puro (continuo a correggere bug o fare esercizi di prototipazione).

what are the biggest reasons for choosing to do Agile development

• Visibilità o successo veloce / Fail veloce - Siamo un negozio di sviluppo prodotto con cicli da 6 a 24 mesi. Lo sviluppo iterativo con funzionalità funzionanti e testate ha fatto un lavoro migliore per riflettere lo stato del progetto.
• Modifica - Nel nostro ambiente, i requisiti e i tempi tendono a essere corretti. Ma, il business su base troppo regolare passa attraverso rapidi, scuotenti cambiamenti di direzione. Lo sviluppo iterativo e visibile ha reso più facile per i progetti cambiare direzione.
• I requisiti basati sulla storia con lo sviluppo iterativo hanno reso più facile lavorare con il business che non sempre comprendeva gli aspetti tecnici dei requisiti o comprendere appieno i driver di business di alcuni dettagli. Nei nostri sforzi passati, le specifiche di alto livello oi documenti dei requisiti di marketing non erano sempre sufficienti. Ora, mentre i progetti si evolvono, possono esserci alcune ricerche sul mercato parallelo e sui clienti.
• Il cambiamento del processo è avvenuto con molti altri attributi di sviluppo come TDD, test automatici o manuali, cicli di test più rigorosi (non abbiamo più un gruppo QC, solo un gruppo QA) e un maggiore apprezzamento e impegno relativi alla qualità ( usiamo molti più strumenti e metriche).

Avremmo potuto ottenere questo risultato in altri modi, ma sfruttare metodologie e idee agili ci ha aiutato enormemente.

Continuiamo anche a perfezionare il nostro processo. Ad esempio, l'equilibrio tra il design del design anteriore e il design è appena precedente all'implementazione. Esaminiamo regolarmente tutte le nostre decisioni per determinare se potremmo avere rinviato le decisioni di progettazione passate. E, quando le cose vanno male, quanto altro lavoro 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 quello dettagliato è spesso lo stesso del costo di capire lungo la strada e refactoring. Le squadre non sono penalizzate per questi tipi di errori e incoraggiate ad essere più aggressive.

Ho visto un certo numero di aziende "fare" agile. Sfortunatamente, pochissimi di loro adottano agili. Quello che voglio dire è solo fare uno sviluppo iterativo e stare in piedi quotidianamente (dove la maggior parte della squadra si siede) non rende la squadra agile. TDD, Refactoring, Integrazione continua, Presenza al cliente, pratiche SOLID rendono Agile una squadra. Senza di loro, stai andando in circolo.

C'è un sacco di fascino che il messaggio di Agile porta. Adattabilità a cambiare essendo il più grande. Sfortunatamente, il tuo codice non diventa più adattabile solo perché cambi la modalità di gestione del progetto. Fino a quando le aziende non si renderanno conto di questo, sentiremo parlare di un progetto agile sempre più fallito.

Non so della parte della parola buzz. Ho sempre fatto questo in un processo non così formalizzato o identificato. Ho avuto clienti che mi guardavano letteralmente alle spalle mentre creavo il loro sito web. Salvato circa 50 e-mail e il cliente ha imparato qualcosa su questo processo - non è facile.

Tutta la nozione che impiegheremo un lungo periodo di tempo per scrivere tutto ciò che l'utente vuole che il software faccia, quindi impiegare un periodo di tempo più lungo per costruire ciò che pensiamo di voler scoprire solo entro 2 secondi dal tentativo di app che questo non è quello che si aspettavano è nauseante. Quanto è difficile suddividere qualsiasi progetto o applicazione in alcuni pezzi ragionevoli da costruire e ottenere un feedback prima di costruire un altro pezzo?

So che questa è una semplificazione eccessiva e non affronta le pratiche di sviluppo effettive, ma non è difficile da vendere nemmeno al manager o al cliente più tecnico. Quale altro approccio è più allettante? I clienti amano davvero il fatto che i programmatori sono fuori di testa per 6-12 mesi mentre si sviluppano durante un progetto a cascata? Vuoi assumere 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 sforzarsi di fare il loro lavoro meglio. Il lavoro della direzione è di fornire supporto per queste iniziative.

Come manager che ha scritto un bel po 'di codice nella mia carriera, potrei non essere quello che stai cercando di rispondere a questo. In ogni caso, ritengo che il sorteggio di Agile in questi giorni abbia più a che fare con la risposta alle esigenze dei clienti più rapidamente e abbreviare il ciclo di feedback tra specifiche, codifica, test e clienti. Stiamo andando verso uno sviluppo più agile proprio per queste ragioni.

Penso che non dovresti pasticciare il processo Agile e le pratiche di codifica / sviluppo. Ad esempio, Scrum non ti spiega come dovresti sviluppare il tuo codice: è tutto incentrato sul processo che accoglia i cambiamenti.

Alla fine della giornata, si tratta di potenziare lo sviluppatore; si tratta di riconoscere il fatto che quei ragazzi che sono in fondo alla gerarchia sono gli unici a comprendere veramente l'estensione di ciò che deve essere fatto e come farlo, quindi se li hai già assunti per la loro competenza - perché non lasciare che prendano il pieno controllo o meglio, perché allontanarli dal processo decisionale effettivo?