Agile concorda con il ciclo di vita dello sviluppo del software tradizionale

Non vedo cosa ci sia di pesce nel processo che descrivi. Se si dispone di uno sviluppo iterativo con cicli di rilascio brevi (anche se si tratta solo di versioni interne) e di un continuo feedback del proprietario del prodotto e rivalutazione dei piani in base alle conoscenze acquisite da ciascuna versione, direi che sei agile.

Il vantaggio dello sviluppo iterativo è noto da molto tempo. Ad esempio la legge di Galls afferma:

A complex system that works is invariably found to have evolved from a simple system that worked.

Questo è stato scritto nel 1975, 25 anni prima del Manifesto Agile, e abbatte la "cascata" prima che il termine fosse persino inventato!

SCRUM è qualcosa di molto più specifico di agile. SCRUM non richiede solo lo sviluppo iterativo, ma pone anche richieste come team interfunzionali, non distinti ruoli di sviluppo vs QA e così via. SCRUM è più polemico che agile. In molti casi non è pratico (perché non puoi solo addestrare rapidamente un QA per diventare uno sviluppatore), ei suoi benefici sono dubbi.

Le metodologie sono soluzioni ai problemi . I problemi con la cascata sono ben noti: si costruisce un sistema partendo dalle specifiche, ma quando il sistema è finito, ci si rende conto che le specifiche erano sbagliate e insufficienti, e ora è troppo tardi per cambiare. Lo sviluppo iterativo è la soluzione a questo problema.

Quindi, invece di chiedere se il tuo attuale processo è "completamente agile" dovresti considerare se ci sono dei problemi osservabili con il tuo processo corrente. In questo caso, analizza se il cambiamento del processo in qualche modo può essere d'aiuto.

La più grande paura per alcuni potrebbe essere il fatto di chiamarti agile quando non lo sei davvero. Stiamo facendo Scrum se seguiamo solo la metà dei principi? Cosa penseranno i miei amici sviluppatori riguardo a questa ipocrisia?

Il Manifesto Agile non è molto specifico. Questo è stato fatto intenzionalmente. Preferiscono semplicemente fare alcune cose rispetto ad altre, ma non suggeriscono nemmeno di evitare gli altri (Sì, dovresti comunque fare la documentazione. Forse non tanto inizialmente.) Non danno una ricetta completa come Scrum o Xtreme. fare. È più di uno chef che dice "cucini con ingredienti freschi e rendi il cibo adatto alla gente".

La tua domanda è che sono agili? Dimentica pratiche e tecniche. Penso che dovresti confrontare il precedente (cascata) con l'approccio corrente (che tu lo consideri agile o meno) e determinare:

• Possiamo gestire le modifiche più rapidamente.
• Stiamo rilasciando le funzionalità più rapidamente.

Molti ti diranno che questo non è misurabile, ma ciò che intendono veramente è che è difficile essere precisi. Ci sono modi indiretti per farlo. Basta chiedere ai clienti. Pensi che stiamo rilasciando le funzionalità più velocemente? Ci sono altri bug? È abbastanza veloce? Stai facendo piacere alla gente del software; non complicarlo.

Se non pensi che le cose siano migliorate in queste aree, allora puoi suddividere il processo e iniziare alcune pratiche specifiche (consigliato da una metodologia consolidata o scoprirlo da solo).

L'approccio allo sviluppo sopra descritto non contraddice affatto i punti agili del manifesto? Le aziende lo utilizzano nel definirsi "agili"?

La compagnia che stai descrivendo è in contraddizione con uno dei quattro punti del manifesto agile:

• Risposta al passaggio successivo a un piano

Fornire una specifica completa prima che lo sviluppo sia un processo a cascata diretto. Se la specifica è impostata, il progetto difficilmente può accogliere cambiamenti (che è uno dei dodici principi agili). Agilisti condanna il grande design in anticipo (a.k.un grande requisito in anticipo) perché molto probabilmente porterà allo spreco perché i clienti non sanno quello che vogliono e i requisiti probabilmente cambieranno.

Le aziende potrebbero contraddire uno, due o tre punti del manifesto agile, ma ciò non significa che non possano definirsi società agili in via di sviluppo. Direi che un'azienda potrebbe chiamarli agili fintanto che praticano pratiche agili o seguono principi agili con qualsiasi metodo agile. Tuttavia, se lo stanno facendo bene o no è un'altra domanda.

Quali vantaggi offre "piena agilità / mischia" rispetto a questo approccio?

Scrum influenzerà la parte organizzativa dei progetti e fungerà da grande disciplina con le sue regole e pratiche. Una manciata di quelli buoni sono

• User story scomposto in attività nel backlog di iterazione che descrive il lavoro da svolgere. Se eseguito correttamente, non devi più inseguire i requisiti di BA o dei clienti. Tuttavia, non è in grado di coprire completamente il caso di determinate funzionalità come fa una specifica completa dei requisiti.

• Regola a finestra chiusa - proibisce severamente a chiunque di aggiungere funzionalità e contribuirà a ridurre la creep dell'ambito. La funzionalità può essere valutata quando lo sprint è finito e spesso non sarà così brillante come il momento in cui nasce l'idea. Tuttavia, se è veramente critico , il proprietario del prodotto può annullare lo sprint per aggiungerlo.

• Riunione di mischia quotidiana - Le tre domande "che cosa ho fatto il giorno precedente?", "cosa farò oggi?" e "eventuali impedimenti?" darà ai membri del progetto una grande panoramica su cosa sta succedendo nel progetto.

No, un processo di sviluppo a cascata come quello che hai descritto non è ciò che le persone che fanno lo sviluppo Agile chiamano Agile. Ma a chi importa cosa si chiama, davvero?

La vera domanda è: perché stai facendo Agile? Se è solo perché è una parola alla moda che suona bene, chiamando il processo attuale Agile è certamente abbastanza buono. Le persone usano molto la parola chiave e nessuno deve cambiare il modo in cui stanno lavorando.

Se hai altri obiettivi *, non importa se il tuo processo è chiamato Agile o se è Agile. Ciò che conta è se questi obiettivi vengono raggiunti.

In altre parole " quali vantaggi offre" piena agilità / mischia "rispetto a questo approccio? " è una domanda che il management dovrebbe porsi molto prima di ottenere Agile, non dopo.

* Meno costoso per cambiare le priorità, risultati precedenti, qualità superiore, morale migliore, clienti più soddisfatti, costi inferiori, maggiore produttività, maggiore trasparenza, sono alcune delle cose che di solito sono associate ad Agile. Ma quelli che puoi ottenere in qualche modo dipendono dal processo da cui vieni.

Esistono pratiche diverse che potrebbero rendere la tua azienda più agile. Quando leggo che alla gente viene assegnato un lavoro, inizio a ricevere i brividi sulla mia spline, ma se funziona non è anti-Agile persee.

Dai un'occhiata al modello Agile Fluency . Sembra che ti stai avvicinando al livello uno, ma c'è ancora molto da guadagnare salendo la scala.