Come sviluppare un software eccellente con metodi agili?

La risposta formale è malintesa, l'agile non determina i requisiti, le parti interessate lo fanno. Il nucleo dell'agile non è quello di scolpire le tue esigenze in pietra ma piuttosto farle emergere mentre vai, a stretto contatto con il tuo cliente, beneficiando di approfondimenti progressivi.

Ma questa è tutta teoria. Quello che hai visto è in effetti un tratto comune di molte linee di produzione di software che hanno adottato un modo di lavorare agile.

Il problema è che, ascoltando il cliente e rispondendo rapidamente alle esigenze del cliente, spesso si finisce presto per non pensare affatto al prodotto o fare alcun progetto. Quello che era un processo proattivo alimentato dalla visione e dall'esperienza può e spesso si deteriora in un processo passivo, interamente reattivo, alimentato dai desideri del cliente. Questo porterà a fare solo le necessità essenziali che "faranno il lavoro".

L'automobile non sarebbe mai stata inventata se i produttori all'epoca fossero stati "agili" perché tutti i clienti chiedevano un cavallo più veloce.

Questo non rende agile il cattivo però. È un po 'come il comunismo. Una grande idea che non funziona quasi mai perché le persone sono solo persone, fanno cose per la gente. E il metodo / ideologia / religione li cullano nell'idea che stanno facendo bene fino a quando stanno attraversando i movimenti e / o seguendo le regole.

[modifica]

Slebetman:

It is ironic then that agile evolved out of the automative industry (namely Toyota).

Ricorda la regola d'oro dell'automazione? "Prima organizza, quindi automatizza". Se automatizzi un processo non funzionante, il meglio che potrebbe accadere è accelerare tutto ciò che va storto. Le persone alla Toyota non erano idiote.

Il motivo tipico per l'adozione di una nuova metodologia è che le cose non stanno andando bene. Il management lo riconosce, ma potrebbe non capire i problemi principali. Quindi assumono questo guru che fa un discorso di resilienza su Agile e Scrum. E tutti lo amano. Per le loro ragioni.

Gli sviluppatori potrebbero pensare "Ehi, questo potrebbe funzionare. Saremmo più coinvolti con problemi di business e potremmo fornire input per riempire questo arretrato. Potrebbe essere un'opportunità per fare vendite e assistenza clienti capire cosa facciamo, perché è necessario, e vorremmo toglierli dai nostri capelli mentre bruciamo in modo trasparente ciò su cui eravamo d'accordo ". Non più "ferma quello che stai facendo, questo deve essere fatto ora" da un ragazzo che non vuoi rimandare alla tua scrivania.

Le vendite, il servizio clienti o il proprietario, d'altra parte, potrebbero vederlo come un modo per ottenere il controllo (posteriore) su questa scatola nera di un reparto che presumibilmente sta facendo cose che sono necessarie. Non vedono cosa sta succedendo lì, ma sono piuttosto sicuri che il nucleo del problema sia stato sepolto da qualche parte lì dentro. Quindi introducono Scrum, installano il proprietario di un prodotto a loro scelta e all'improvviso hanno tutto il controllo, tutte le stringhe sono nelle loro mani. E adesso? ... Ehrr ...

Il vero problema è spesso che il negozio non è stato organizzato bene in primo luogo e questo non è cambiato. Alle persone sono state assegnate responsabilità che non possono gestire, o forse possono, ma il signor Boss interferisce costantemente e rovina ciò che ha fatto, o (il più delle volte nella mia esperienza), responsabilità cruciali non sono state riconosciute o assegnate a nessuno.

A volte col tempo emergerà un'organizzazione informale tra le linee formali. Ciò può quindi in parte compensare la mancanza di una struttura formale. Alcune persone finiscono per fare quello che sono bravi, se hanno un biglietto da visita per dimostrarlo o meno. L'introduzione smussata di Agile / Scrum potrebbe rovinarla all'istante. Perché ora ci si aspetta che le persone giochino secondo le regole. Sentono che quello che erano soliti fare non è apprezzato, ottengono piccoli fogli gialli con piccole storie su di esso, invece, il messaggio sarà: "qualunque cosa stavate facendo, a nessuno importava". Inutile dire che questo non sarà particolarmente motivante per quelle persone. Nel migliore dei casi inizieranno ad aspettare gli ordini e non prenderanno più alcuna iniziativa.

Quindi le cose peggiorano e la conclusione sarà che Agile fa schifo.

Agile non fa schifo, è ottimo per i progetti di manutenzione e può anche essere buono per i nuovi sviluppi se applicato con attenzione, ma se le persone sbagliate non lo capiscono o lo adottano per le ragioni sbagliate, può essere molto distruttivo.

There doesn't even seem to be a place for attractive qualities in agile.

Stai confrontando mele e arance. Nella cascata tradizionale, se le tue esigenze dicono che hai bisogno dei must, ottieni una Fiat. Se i requisiti dicono che deve essere di prim'ordine, si ottiene una Ferrari.

Lo stesso accade in Agile. Se i tuoi requisiti si fermano ai must, ottieni una Fiat. Se hai storie per eccellenza, ottieni una Ferrari. Tutto ciò che agisce veramente è che fai il necessario prima . Non costruire uno spoiler super cool per due anni e poi perdere la scadenza per il motore.

Quindi, per farla breve: ottieni quello che ti serve. Se pianifichi un'auto sportiva, prendi un'auto sportiva. Agile non cambia affatto. Se il tuo processo agile soddisfa i requisiti di una Fiat, non incolpare di agilità, dai la colpa ai ragazzi che richiedono solo una Fiat.

However, all agile processes I know strongly favor must-be requirements. These always get the highest priority.

Come dovrebbero - guarda di nuovo il tuo modello Kano: se i requisiti devono essere soddisfatti, il cliente non accetterà il prodotto. E poi i tuoi diletti non contano.

There doesn't even seem to be a place for attractive qualities in agile.

Nulla potrebbe essere più lontano dalla verità.

I processi agili tipicamente enfatizzano questi punti:

• Consegna frequente di un prodotto funzionante su cui puoi ricevere feedback.
• Dividi le caratteristiche in piccole parti che possono essere completate in breve tempo.
• Implementa quelle parti in ordine di priorità.

Niente ti impedisce di conferire alle funzionalità "deliziose" un'alta priorità. Dipende completamente dalle persone che hanno il compito di determinare le priorità.

Ora è vero che molte di queste persone preferiscono non rischiare e quindi non possono dare alte priorità ai "dilettanti". Ma in un progetto non agile sarebbe ancora il caso.

Agile non dice nulla su cosa dovrebbe essere fatto per primo, solo quel codice dovrebbe essere scritto in modo incrementale e mantenuto in uno stato rilasciabile il più spesso possibile, invece di essere inutilizzabile per mesi fino al prossimo stato rilasciabile.

Ho lavorato sia con un processo Agile che con un BDUF (Big Design Up Front), e sebbene sia possibile ottenere caratteristiche innovative e interessanti da entrambi i processi, in BDUF, non sorprendentemente, è necessario pianificare in anticipo. Ciò significa che le innovazioni in genere devono essere proposte o almeno sponsorizzate da persone che hanno influenza nel processo di progettazione.

Questo perché hai sei mesi (o qualsiasi altra cosa) fino alla prossima release, ei project manager sono stressati su ciò che sta accadendo in quella release, perché se la loro funzione non entra in gioco, saranno necessari altri sei mesi il prossimo. Quindi c'è un elenco di funzionalità ricche di jam in un programma pieno zeppo, e se il basso livello e il file vengono catturati lavorando per due o tre giorni su qualcosa di interessante, pensano solo che il cliente apprezzerà, e non è sul elenco, rischiano l'intero programma e ci sarà l'inferno da pagare.

In un processo Agile, ci sforziamo di mantenere il software in uno stato rilasciabile, e i project manager sono meno stressati perché se la loro caratteristica slittata possono essere ottenuti in due settimane. Quindi se uno sviluppatore torna da una conferenza con un'idea interessante e passa un paio di giorni a qualcosa, non sta mettendo a rischio un piano semestrale scritto a sangue.

Fondamentalmente, raccogli ciò che semini. Se incoraggi l'innovazione e offri ai team una sufficiente autonomia da consegnare, la otterrai. Se chiedi costantemente degli angoli di taglio per rispettare le scadenze, otterrai il software adatto, indipendentemente dalla tua metodologia.

Il software eccellente deriva da due cose:

• Fornire al cliente ciò di cui hanno bisogno

• Essere un professionista

Ci sono tutti i tipi di principi da seguire nello sviluppo del software. SECCO, leggibile, SOLIDO, ecc. Che non hanno nulla a che fare con i requisiti del cliente. Il cliente ha chiesto un'auto sportiva. Se il cliente ha capito che cosa è necessario per rendere un'auto sportiva meravigliosa, non avrebbe bisogno di te. Spetta a te capire cos'altro è importante.

Parte del nostro lavoro è il mantenimento di standard che il cliente non sperimenta mai a meno che le cose non vadano male.

Se lo stai facendo bene allora agile tende verso il fiat solo quando è ciò che il cliente vuole davvero. Non quando è quello che pensano che debbano accontentarsi.

La cascata è diversa perché una volta che un equivoco su una richiesta di un'auto sportiva di fascia alta si è stabilizzata, tende a restare. Agile può far fronte a nuove informazioni e adattarsi se scopre che quello di cui hanno veramente bisogno è una bici da proiettile.

La cascata è ancora in uso in molti negozi fino ad oggi. Questi negozi hanno successo perché le loro esigenze cambiano meno del 2% in un anno.

Il tuo compito non è solo quello di dare al cliente quello che vogliono. È anche prendersi cura di cose che sai che non si ottiene alcun credito per niente. Cose che il cliente non mostrerà mai a meno che tu non lasci andare le cose in modo orribilmente sbagliato. Queste cose dovrebbero essere ben scelte o farai un sacco di merda per aver perso tempo con loro.

Qualsiasi idiota può costruire un ponte con un budget illimitato. Un professionista costruisce un ponte che non cade quasi mai.

Therefore I believe one shouldn't slavishly focus on the must-be requirements.

Certo che dovresti. Tranne quando valuti il tuo tempo. Perché quei requisiti indispensabili non sono l'unica considerazione.

Ok,

In Agile il programmatore può creare il software, ma alla fine è il produttore che crea il prodotto. (usando gli sviluppatori di software).

Quindi riguardo le "qualità attraenti", è compito del produttore.

Se il produttore del settore conferisce "design sexy", questo può essere reso un requisito. Lo sviluppatore non dovrebbe preoccuparsi di queste scelte.

Inoltre, il software è così diverso dai prodotti fisici reali che penso che molti modelli Kano non siano applicabili. Ad esempio, perché io facebook? Unica ragione: perché i miei amici lo fanno. Come inserirlo nel prossimo sprint ........ E inoltre, una delle qualità più interessanti del software, è che in realtà fa ciò che dovrebbe fare. (Ed è qui che aiuta molto: P)

La mia esperienza concorda con i commenti di cui sopra - non c'è nulla di inerente in Agile che preclude lo sviluppo di software eccellente - tuttavia ci sono diversi aspetti di come Agile è spesso (mal-) praticato che portare a software che è solo "abbastanza buono".

• Agile pone l'accento su come ottenere qualcosa funzionante al più presto; tuttavia ciò significa semplificare le ipotesi e tagliare gli angoli, in particolare nell'infrastruttura non visibile all'utente. Non c'è nulla di intrinsecamente sbagliato in questo, se il costo di correggere le ipotesi di semplificazione è basso; tuttavia, troppo spesso questo "debito tecnico" non viene rimosso prima che un prodotto entri in produzione;
• Agile predica che alla fine di uno sprint, dovresti sempre avere qualcosa che sia il più vicino possibile a renderlo disponibile, in modo che gli stakeholder ei project manager possano decidere che "ciò che hanno" è abbastanza buono per spingere in produzione. Di nuovo, niente di intrinsecamente sbagliato in questo, se hai cancellato tutto il tuo "debito tecnico" (o reso la tua pace con quanto hai e dove si trova.) Tuttavia, nella mia esperienza, lontano troppo debito tecnico entra in produzione con la promessa da parte di un manager che "lo ripuliremo una volta cessata la pressione per la spedizione", che si trasforma rapidamente in "è in produzione, dobbiamo stare molto attenti a ciò che cambiamo ora ", che alla fine si trasforma in" Non mi hai mai detto che avevamo quell'esposizione! Dobbiamo fare un lavoro migliore la prossima volta! " La lezione di Ben Frankin su "L'amarezza della scarsa qualità rimane molto tempo dopo che la dolcezza del basso prezzo è stata dimenticata" sembra non essere mai appreso;
• Tuttavia, anche con i gestori fidati e gli sviluppatori ben disciplinati, c'è il problema comune che semplicemente un'analisi, una progettazione e una revisione del progetto troppo scarse si verificano prima inizio dello sprint in cui è prevista l'implementazione e il completamento dell'implementazione. L'incapacità di considerare metafora e design UI alternative è ampia - di solito è troppo costoso rivederlo in modo significativo dopo l'avvio di un progetto; l'incapacità dei team junior di studiare attentamente i prodotti della concorrenza o di dare la priorità alla definizione e implementazione di tecnologie infrastrutturali come I18N, framework di notifica, registrazione, sicurezza e strategie di versioning API (ad esempio) significa che alla fine avranno bug più elevati, una minore produttività e un maggior debito tecnico, che se avessero appena trascorso i primi 2-5 sprint in anticipo facendo la formazione, l'analisi, la progettazione e la prototipazione necessarie. In breve, i team Agile devono resistere alla licenza di hacking;
• Ho avuto un manager di secondo livello (di oltre 100 sviluppatori) che ha scoraggiato i suoi sviluppatori dal prendere tempo per scrivere i loro progetti pianificati, anche al livello più elementare. Il suo ragionamento: "Voglio che le persone parlino tra loro", il che era ironico perché erano in 5 fusi orari diversi e in 3 paesi. Inutile dire che ci sono state molte indicazioni su quale squadra avrebbe dovuto lavorare molte sere e week-end in ritardo nel progetto una volta capito che tutti pensavano che l' altro ragazzo fosse responsabile dell'implementazione di alcune funzionalità (o della reimplementazione perché il design del fornitore e del consumatore non è stato mesh).

In realtà tutto si riduce al fatto che il project manager e i portatori di interesse vogliono per fornire un prodotto di alta qualità. Se si sono impegnati a farlo, Agile lo abiliterà. OTOH, poiché Agile pone il piano decisionale esclusivamente nelle mani del portatore di interessi e del project manager, Agile rende difficile per un team di sviluppo fornire un progetto eccellente senza quel supporto. In breve: la responsabilità per la qualità del prodotto si trova quasi esclusivamente ai piedi del / i responsabile / i del progetto.

TL; DR

In effetti, lo sviluppo agile consente di aumentare la qualità del software, mantenere il cliente soddisfatto e offrire un prodotto di grande valore.

Lo sviluppo agile è stato introdotto da alcuni ragazzi intelligenti per affrontare i problemi che molti progetti software affrontano nei processi tradizionali.

I valori chiave dello sviluppo agile definiti dal manifesto agile (1) sono,

• Individui e interazioni su processi e strumenti
• Software di lavoro su documentazione completa
• Collaborazione con il cliente per la negoziazione del contratto
• Risposta al passaggio successivo a un piano

Quindi, lo sviluppo agile non impedisce di creare software di alta qualità. Lo sviluppo agile consente di fornire software di alta qualità.

But do we (and the customer) really always know in advance what the must-be requirements are.

Questo è il punto. Concentrandosi sulle persone, sul cliente, sul software di lavoro e sui cambiamenti dei requisiti, lo sviluppo agile aiuta a capire cosa desiderano i clienti prima che il prodotto finale venga consegnato.

Questo è un motivo per cui i framework agili come Scrum hanno cicli di iterazione brevi, i cui esiti sono prodotti funzionanti. Puoi già convalidare il tuo lavoro in una fase iniziale contro le aspettative del cliente e adeguare gli obiettivi / requisiti su richiesta. Uno sviluppo agile ti aiuta ad assicurarti di realizzare la qualità must di un prodotto.

In passato - è ancora vero per oggi - molti progetti software sviluppati in approcci tradizionali sono falliti, non hanno avuto successo o hanno causato dispiacere ai clienti perché la qualità must non è stata raggiunta.

Inoltre, lo sviluppo agile ti aiuta anche a raggiungere Qualità attraente . Riflettere il prodotto dopo ogni iterazione illumina nuovi requisiti che non erano interessati dal cliente all'inizio del progetto (qualità interessanti). Ciò mantiene il cliente soddisfatto.

Vorrei anche menzionare Qualità inversa - attributi che portano all'insoddisfazione - del modello Kano.

In ogni progetto ci sono requisiti che sembrano essere buone idee all'inizio del progetto. Dopo un po 'cambiano al contrario e causano delusioni.

In un processo di sviluppo software tradizionale riconoscerete tali requisiti nel prodotto finale dopo una lunga esecuzione del progetto. Troppo tardi per evitare le delusioni dei clienti e per cambiarli è necessario un progetto di follow-up.

Lo sviluppo agile consente di identificare tempestivamente i requisiti non lavorativi o insoddisfacenti e di modificarli durante il progetto.

Come ho detto, lo sviluppo agile consente di aumentare la qualità del software, mantenere il cliente soddisfatto e offrire un prodotto di grande valore.

Sono piuttosto in ritardo per questa festa, ma mi piacerebbe condividere un altro punto di vista su questo argomento:

But how can they be applied to create delighting high quality software products and not just the bare minimum that barely fulfills the must-be requirements?

Esiste un aspetto temporale nello sviluppo di software agile risultante dall'approccio iterativo e considerando feedback dei clienti , che sono due elementi importanti di la metodologia agile. Esempio: le funzionalità identificate come qualità attraente nell'iterazione t potrebbero diventare qualità must nella successiva iterazione t + 1.

L'applicazione di metodi agili può modificare dinamicamente la categoria di qualità di una funzione. Se si confrontano le caratteristiche pianificate dell'iterazione t con le funzionalità finite di alcune iterazioni successive t + n si verificherà esattamente ciò che ha menzionato:

I have made the experience a few times that requirements which were given a high priority in the beginning, turned out to be much less important, if not useless, later.

Tenendo presente questo aspetto temporale, è plausibile che i metodi agili possano produrre deliziando prodotti di alta qualità per il sofware mentre concentrandosi su il minimo indispensabile . L'approccio iterativo associato a feedback dei clienti modifica le regole del gioco nel tempo.

Conclusione

How to develop excellent software with agile methods?

Applica un approccio iterativo e ascolta feedback dei clienti . Elimina uno di questi elementi e otterrai una forma di sviluppo software meno efficace.

   > How to develop excellent software with agile methods?

• Quando produci un singolo software specifico per il cliente :
  • trova un cliente in cui il costo non è importante perché la funzione "deliziosa" costa denaro extra e il cliente deve decidere se vuole pagare per questo.
• Durante la produzione di prodotti software :
  • Le funzionalità "deliziose" sono utili per attirare nuovi clienti e il costo per implementare una funzione "deliziosa" non è così importante se il prodotto viene venduto più di 1000 volte.
• In un ambiente in cui "abbastanza buono (il più economico) è il migliore" non avrai i soldi per implementare funzionalità "deliziose"

In un team di Scrum il Product-Owner è responsabile di scegliere quali funzionalità implementare. Quindi spetta a lui (e fino al suo budget) definire un software "abbastanza buono" o "eccellente"

Hai sollevato dei buoni punti. Ma non credo che questi problemi siano limitati a processi / metodologie agili.

Ci sono opinioni divergenti su cosa sono le caratteristiche essenziali e non essenziali. Per usare il tuo esempio, qualcuno che acquista un'auto potrebbe considerare l'attenzione come una caratteristica essenziale e quindi considerare una Fiat come non soddisfare questo requisito indispensabile.
Più realisticamente, un prodotto software potrebbe dover disporre di determinate funzionalità per soddisfare le esigenze dei suoi utenti finali ... ma potrebbe anche essere necessario disporre di alcune altre funzionalità per poter essere venduto. Perché la persona che autorizza l'acquisto spesso non è un utente finale.
Quindi una funzionalità "non essenziale" per l'utente finale potrebbe essere essenziale per vendere il prodotto ... e quindi anche essenziale per la società che crea il prodotto.

Tutto ciò si riduce al fatto che è fondamentale avere un buon team di sviluppo prodotto per stabilire requisiti e priorità in modo appropriato. Ma questo non è solo vero per i negozi agili.

È inoltre importante avere il / i proprietario / i del prodotto / i soggetti interessati che sono autorizzati a prendere decisioni. Se le decisioni del proprietario del tuo prodotto vengono continuamente ignorate da qualcun altro, sarei il primo a convenire che si tratta di un problema, ma, ancora una volta, non è un problema con l'agile.

Ci sono altre cose che vuoi nel / i proprietario / i del tuo prodotto ... una descrizione che ho sentito è "C.R.A.C.K." (collaborativo, rappresentativo, autorizzato, impegnato e ben informato). Un proprietario di un prodotto che non ha una di queste aree può significare problemi per un progetto. Ma ho sentito per la prima volta questo acronimo in un ambiente a cascata, quindi chiaramente il dolore dei clienti / proprietari di prodotti non è limitato ai negozi agili.

Ciò che Agile può (aiutare) è portare alcuni di questi problemi in superficie.

Ad esempio, la letteratura di XP è IIRC abbastanza esplicito sul fatto che il "cliente" sia ben informato, accessibile al team e autorizzato a prendere decisioni. Il termine "proprietario del prodotto" implica un certo livello di conoscenza, impegno e autorità.

Se ti trovi in una situazione in cui la maggior parte delle funzionalità fornite consiste di dilettanti invece di funzioni indispensabili, è molto più facile sollevare quel problema (e molto più facilmente determinarne la causa) quando stai lavorando o quasi software operativo ogni 2-3 settimane rispetto a quando le consegne sono mesi o anni.

Se stai lavorando in piccole iterazioni e rivedi spesso l'arretrato (inclusa la revisione della priorità) - questo dà al team l'opportunità di imparare dagli errori precedenti. "Sembra che sia davvero importante ora, ma ricorda la navigazione dinamica di cui eravamo sicuri di aver bisogno per non essere stati utilizzati?" Come altri hanno sottolineato, quelle discussioni sono molto meno probabili se tutto è stato pianificato in anticipo.

Per contro, la metodologia di progettazione iniziale presuppone (di default) che la comprensione del prodotto e delle caratteristiche sia statica. Questa non è stata la mia esperienza: avere qualcosa di tangibile con cui lavorare cambia quasi sempre la comprensione del problema da parte degli uomini d'affari. Da qui l'enfasi sul feedback rapido. (Anche la comprensione degli sviluppatori cambia, ma ciò non influenzerà le priorità.)

Anche differire parte della pianificazione consente di rispondere ai cambiamenti delle esigenze aziendali. "Conosci quel sito web che stai costruendo? Abbiamo davvero bisogno che sia un'app mobile, capace di operazioni disconnesse." Questo non è qualcosa che è stato chiesto specificamente ... ma non vorresti che il tuo processo fosse in grado di rispondere ai cambiamenti nel panorama del business (almeno in teoria)?

Agile non dice "non creare funzionalità non essenziali". Dice "Consenti al business di decidere quali funzionalità (non) creare".
... e (altrettanto importante) "permetti ai tecnici di dirti quanto tempo ci vorrà per costruire una funzione da costruire".

1. Must-be qualities sono spesso difficili da determinare. Le persone li hanno in subcoscienza. Le iterazioni agili e la partecipazione dei clienti aiutano a trovare la maggior parte dei must-be. Questo è il potere di agile ed è sciocco trascurarlo .
2. One-dimensional qualities che significa promesse che devono essere soddisfatte, sono supportate da cascata OK, fino a quando non stanno cambiando. Qui essere agili aiuta solo, ma non così potente.
3. Attractive qualities sono belle funzionalità. Potrebbero diventare must-have nella prossima generazione. Ma nella generazione attuale non sono neanche nell'accordo - altrimenti sarebbero qualità Unidimensionali. Quei metodi agili che suppongono la partecipazione rappresentativa del cliente supportano molto bene queste qualità. Perché possiamo cambiare leggermente il raggio d'azione durante il lavoro. Possiamo negoziare sul miglioramento di un posto per una compensazione in un altro. In cascata è praticamente impossibile. Senza un grande ritardo organizzativo, potremmo aggiungere solo funzionalità gratuitamente. È possibile, se prima è stato messo un po 'di tempo in più nel budget.

Quindi, i processi agili possono supportare il modello Kano, alcuni lo fanno molto e sicuramente molto meglio dei migliori progetti di cascata.

Per farlo in grande misura, dovresti impostare processi agili con un partecipante rappresentante responsabile.