Agile Experts vs Agile Manifesto

Pensi che il tuo "esperto agile locale" abbia letto il Manifesto Agile? Hai? Bene, non è un problema ... se non usi la parola "Agile" su base giornaliera! Ma se lo fai (o il tuo esperto locale lo fa) ... beh, è ​​qualcosa come le persone che parlano troppo della religione, ma non hanno aperto la Bibbia (avviso di correttezza politica) o il libro sacro di loro scelta, sin dalle loro lezioni di letteratura 10 anni fa ... Non ci piacciono. Per una ragione.

Ok ok, non commentiamo le altre persone e le loro opinioni. Esaminiamo invece passo dopo passo la "Bibbia agile".

Saranno fornite citazioni dal Manifesto Agile

questo tipo di blocco di testo

e i nostri commenti verranno forniti in rientro regolare come questo. Andiamo!

Il Manifesto, uno e solo!

La nostra massima priorità è soddisfare il cliente
attraverso consegne anticipate e continue
di software prezioso.

Questa è un'ottima idea! Era davvero rivoluzionario al momento della sua realizzazione! Ma l'esecuzione di questa idea è qualcosa di molto più difficile di quanto queste poche righe avrebbero potuto percepire.

Problema principale: tutti coloro che hanno avuto un contatto diretto con il cliente, sanno che il punto di questo Manifesto è almeno un po 'complicato.

Purtroppo, il cliente non è sempre sicuro di ciò che vuole (o) vuole o vuole troppe cose allo stesso tempo e non può stabilire le priorità in modo corretto! Inoltre, può darsi che alcune di quelle cose che il cliente ha pensato (s) volesse, in seguito non volesse ...

Se lo mettiamo da parte, il punto del Manifesto dimostra il suo valore per il successo del prodotto! Ma queste eccezioni NON devono essere trascurate, in quanto potrebbero essere fatali!

Il prossimo punto riguarda qualcosa di simile, continuiamo qui questo argomento.

Benvenuti a cambiare i requisiti, anche in ritardo
sviluppo. I processi agili sfruttano il cambiamento per
il vantaggio competitivo del cliente.

Questo è fantastico Ma il costante perno e la pressione sul team di sviluppo rendono il prodotto fragile. La codifica veloce con molti reindirizzamenti del progetto, riduce la qualità del codice del prodotto, quindi le modifiche diventano più difficili. Uno sviluppo più razionale e calmo migliora l'efficienza delle modifiche nelle fasi successive dello sviluppo del prodotto. Concordiamo che le modifiche dovrebbero essere accolte favorevolmente, ma anche le altre clausole di contratto / accordo dovrebbero essere modificate in modo proporzionale! In molti casi, il prodotto dovrebbe essere distribuito nello stesso momento in cui sarebbe stato in caso di nessun requisito di modifiche aggiuntive. Non fico.

L'agilità consiste nell'essere pronti per i cambiamenti previsti e non nel cambiare tutto e sempre. Chi è accreditato per comunicare con un potenziale cliente / cliente dovrebbe negoziare un accordo realistico fin dall'inizio. Spesso, 10 minuti con carta e penna al momento giusto (inizio del progetto) risparmiano giorni, settimane e persino mesi di sviluppo (reindirizzamento, rotazione, modifica) nelle fasi successive! Questo rallentamento nell'inizio dei prodotti dovrebbe essere considerato non professionale, perché lo è davvero! La mentalità del "prendiamo solo il cliente, in seguito penseremo a qualcosa per finire il lavoro" non è etica e troppo spesso gli sviluppatori devono "salvare il giorno" (lavoro straordinario, fine settimana di lavoro, lavoro da casa, lavoro in ambiente stressante) ... Non eccezionale. E davvero - nemmeno agile.

Fornire software funzionante
frequentemente, da a
un paio di settimane a un paio di mesi, con a
preferenza per il tempo più breve.

Ho solo buone esperienze con questo. Offre possibilità di feedback precoce per prove di trazione, apprendimento e miglioramento. Grandi cose se il concetto di Agile è applicabile nello sviluppo di software del tipo di prodotto necessario. (Non sempre il caso, che ci crediate o no.)

Uomini d'affari e sviluppatori devono lavorare
insieme ogni giorno durante il progetto.

Ok, forse non tutti i giorni, ma anche - pollice in alto! Noi (persone) non siamo riusciti a rovinare questo negli ultimi 15 anni ... Dacci tempo.

Costruisci progetti intorno a individui motivati.
Offri loro l'ambiente e il supporto di cui hanno bisogno,
e fidati di loro per portare a termine il lavoro.

Questo è dove la maggior parte dei cosiddetti agilisti non riescono ad agire da Agile Manifesto. Spesso mancano di rispetto per le persone che sono, se non per gli esperti, professionisti ancora migliori, considerando il loro campo di competenza, rispetto al project manager "agile". Ciò rende il manager troppo coinvolto nel lavoro degli altri, il che rompe gli importanti "ingranaggi della macchina", uno per uno. Ridurre ulteriormente l'agilità e l'affidabilità della "macchina" per il cambiamento. Che è contro agile.

Il metodo più efficiente ed efficace di
trasmettere informazioni verso e all'interno di uno sviluppo
la squadra è una conversazione faccia a faccia.

Bene, non possiamo dire nulla contro questo. Al contrario, evviva!

Il software di lavoro è la misura principale del progresso.

Sì. Il problema è che molti dei cosiddetti agilisti non rispettano questa clausola.

I processi agili promuovono lo sviluppo sostenibile.
Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado
mantenere un ritmo costante indefinitamente.

Difficile da raggiungere, ma ovviamente - ottima linea guida.

Attenzione costante all'eccellenza tecnica
e un buon design migliora l'agilità.

Ancora una volta, purtroppo, i cosiddetti project manager agili spesso dimenticano di questo, con conseguenze gravi, se non fatali.

Semplicità: l'arte di massimizzare l'importo
di lavoro non svolto - è essenziale.

Ave, semplicità!

Le migliori architetture, requisiti e progetti
emergere da squadre auto-organizzanti.

Ave!

A intervalli regolari, il team riflette su come
per diventare più efficace, quindi sintonizza e regola
il suo comportamento di conseguenza.

Amen!