Come sviluppare un software eccellente con metodi agili?

Il modello Kano di soddisfazione del cliente definisce diverse classi di funzionalità del prodotto. Tra questi ci sono

1. Qualità indispensabili: se non vengono implementate, il cliente non accetterà il prodotto.

2. Qualità interessanti (deliziatori): caratteristiche che il cliente spesso non si aspetta nemmeno in primo luogo, ma che suscitano entusiasmo e gioia quando vengono scoperte.

Le qualità attraenti ovviamente hanno molto valore commerciale. Fanno sì che le persone acquistino una Ferrari per 500.000 quando una Fiat usata per meno di 5.000 soddisferebbe tutti i requisiti indispensabili.

Tuttavia, tutti i processi agili che conosco favoriscono fortemente i requisiti indispensabili. Questi hanno sempre la massima priorità. Non sembra nemmeno esserci un posto per qualità attraenti in agile.

Credo che i processi agili siano molto utili nello sviluppo del software. Ma come possono essere applicati per creare deliziosi prodotti software di alta qualità e non solo il minimo indispensabile che soddisfa a malapena i requisiti indispensabili?

Addendum: come sottolineato dalle prime due risposte, ha senso dare ai requisiti indispensabili la massima priorità. Ma noi (e il cliente) sappiamo davvero sempre in anticipo quali sono i requisiti indispensabili. Ho fatto l'esperienza alcune volte che i requisiti a cui era stata data una priorità all'inizio, si sono rivelati molto meno importanti, se non inutili, in seguito. Pertanto, credo che non si debba focalizzare slavish sui requisiti indispensabili.

La risposta formale è che hai frainteso agile, agile non impone requisiti, le parti interessate lo fanno. Il nucleo di Agile non è scolpire le tue esigenze nella pietra, ma piuttosto farle emergere man mano che procedi, a stretto contatto con il tuo cliente, beneficiando di approfondimenti progressivi.

Ma questa è tutta teoria. Ciò a cui hai assistito è in effetti un tratto comune di molte linee di produzione di software che hanno adottato un modo agile di lavorare.

Il problema è che ascoltare il cliente e rispondere rapidamente alle esigenze del cliente spesso finisce per non pensare al prodotto o progettare. Quello che era un processo proattivo alimentato da visione e competenza può e spesso si deteriora in un processo passivo, totalmente reattivo alimentato dai desideri del cliente. Ciò porterà a fare solo le necessarie necessità che "faranno il lavoro".

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

Questo non rende l'agile male però. È un po 'come il comunismo. Un'ottima idea che non funziona quasi mai bene perché le persone sono solo persone, facendo cose da persone. E il metodo / ideologia / religione li culla nell'idea che stanno andando bene fintanto che stanno attraversando i movimenti e / o seguendo le regole.

[modificare]

Slebetman:

È ironico che l'agile si sia evoluto dall'industria automobilistica (vale a dire la Toyota).

Ricordi la regola d'oro dell'automazione? "Prima organizza, poi automatizza". Se automatizzi un processo interrotto, la cosa migliore che potrebbe accadere è che acceleri tutto ciò che va storto. Le persone alla Toyota non erano idioti.

Il motivo tipico per l'adozione di qualsiasi nuova metodologia è che le cose non vanno bene. La direzione lo riconosce, ma potrebbe non capire i problemi fondamentali. Quindi assumono questo guru che tiene un discorso resiliente su Agile e Scrum. E tutti lo adorano. Per le proprie ragioni.

Gli sviluppatori potrebbero pensare "Ehi, potrebbe funzionare. Saremmo più coinvolti con i problemi aziendali e potremmo fornire input per riempire questo arretrato. Potrebbe essere un'opportunità per far capire alle vendite e al servizio clienti cosa facciamo, perché è necessario, e vorremmo toglierli dai capelli mentre bruciamo in modo trasparente ciò che abbiamo concordato ". Niente più "ferma quello che stai facendo, questo deve essere fatto ora" da un tizio che non vuoi rimandare alla tua scrivania.

Le vendite, il servizio clienti o il proprietario, d'altra parte, possono vederlo come un modo per ottenere (indietro) il controllo su questa scatola nera di un dipartimento che presumibilmente sta facendo cose necessarie. Non vedono cosa sta succedendo lì dentro ma sono abbastanza sicuri che il nocciolo del problema sia 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 Mr. Boss interferisce costantemente e rovina ciò che hanno fatto, o (il più delle volte nella mia esperienza), le responsabilità cruciali non sono state riconosciute o assegnate a nessuno.

A volte nel tempo emergerà un'organizzazione informale tra le linee formali. Ciò può quindi parzialmente compensare la mancanza di una struttura formale. Alcune persone finiscono per fare ciò in cui sono bravi, sia che abbiano un biglietto da visita per dimostrarlo o meno. L'introduzione schietta di Agile / Scrum potrebbe rovinarlo all'istante. Perché ora ci si aspetta che le persone giochino secondo le regole. Sentono che ciò che facevano non è apprezzato, ricevono invece piccoli fogli gialli con piccole storie, il messaggio sarà: "qualunque cosa tu stia facendo, a nessuno importava". Inutile dire che questo non sarà particolarmente motivante per quegli individui. Nella migliore delle ipotesi inizieranno ad aspettare gli ordini e a non prendere più alcuna iniziativa.

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

L'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 ragioni sbagliate, può essere più distruttivo.

Non sembra nemmeno esserci un posto per qualità attraenti in agile.

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

Lo stesso accade in Agile. Se le tue esigenze si fermano ai must-have, ottieni una Fiat. Se hai storie per eccellenza, ottieni una Ferrari. Tutto ciò che AGILE realmente fa rispettare è che i must have prima . Non costruire uno spoiler super cool per due anni e poi mancare la scadenza per il motore.

Per farla breve: ottieni ciò di cui hai bisogno. Se pianifichi un'auto sportiva, otterrai un'auto sportiva. Agile non lo cambia affatto. Se il tuo processo agile presenta i requisiti per una Fiat, non dare la colpa a agile, incolpare i ragazzi che richiedono solo una Fiat.

Tuttavia, tutti i processi agili che conosco favoriscono fortemente i requisiti indispensabili. Questi hanno sempre la massima priorità.

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

Non sembra nemmeno esserci un posto per qualità attraenti in agile.

Nulla potrebbe essere più lontano dalla verità.

I processi agili in genere sottolineano questi punti:

• Consegna frequente di un prodotto funzionante su cui è possibile ottenere feedback.
• Dividi le caratteristiche in piccole parti che possono essere completate in breve tempo.
• Implementare quelle parti in ordine di priorità.

Nulla ti impedisce di dare la massima priorità alle funzionalità "deliziose". Dipende completamente dalle persone che hanno il compito di determinare le priorità.

Ora è vero che molte di queste persone preferiscono non correre rischi e quindi potrebbero non dare priorità ai "deliziatori". Ma in un progetto non agile sarebbe ancora così.

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

Ho lavorato con un processo sia Agile che BDUF (Big Design Up Front), e mentre puoi sicuramente ottenere funzionalità innovative e attraenti da entrambi i processi, in BDUF, ovviamente, devi pianificarle in anticipo. Ciò significa che le innovazioni devono generalmente essere proposte o almeno sponsorizzate da persone con un certo peso nel processo di progettazione.

Questo perché hai sei mesi (o qualsiasi altra cosa) fino alla prossima versione e i project manager sono stressati per quello che sta succedendo in quella versione, perché se la loro funzionalità non entra, ci vorranno altri sei mesi fino alla prossima . Quindi c'è un elenco pieno di funzionalità in un programma pieno di jam e se il basso livello viene sorpreso a lavorare per due o tre giorni su qualcosa di interessante, pensano solo che il cliente piacerà, e non è sul lista, 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 funzionalità scivola possono ottenerlo in due settimane. Quindi, se uno sviluppatore torna da una conferenza con una bella idea e trascorre un paio di giorni in qualcosa, non sta mettendo a repentaglio un programma scritto di sangue di sei mesi.

Fondamentalmente, raccogli ciò che semini. Se incoraggi l'innovazione e dai ai team l'autonomia sufficiente per offrire, la otterrai. Se si richiedono costantemente tagli angolari per rispettare le scadenze, si otterrà il software corrispondente, indipendentemente dalla metodologia.

Il software eccellente deriva da due cose:

• Offrire al cliente ciò di cui ha bisogno

• Essere un professionista

Ci sono tutti i tipi di principi da seguire durante lo sviluppo del software. SECCO, leggibile, SOLIDO, ecc. Che non hanno nulla a che fare con le esigenze del cliente. Il cliente ha chiesto un'auto sportiva. Se il cliente capisse cosa serve per rendere fantastica un'auto sportiva non avrebbe bisogno di te. Sta a te capire cos'altro è importante.

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

Se lo stai facendo bene, l'agile tende verso la fiat solo quando questo è ciò che il cliente vuole davvero. Non quando è quello che pensano di dover accontentare.

La cascata è diversa perché una volta che si è verificato un malinteso su un requisito di auto sportiva di fascia alta, tende a rimanere intorno. Agile può far fronte a nuove informazioni e adattarsi se si scopre che ciò 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 è quello di dare al cliente quello che vogliono. Serve anche a prendersi cura di cose per le quali sai di non avere alcun credito. Cose che il cliente non solleverà mai a meno che tu non lasci andare le cose orribilmente male È meglio scegliere queste cose o ti prenderai un sacco di merda per perdere tempo con loro.

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

Pertanto, credo che non si debba focalizzare slavish sui requisiti indispensabili.

Certo che dovresti. Tranne quando si stima il 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. (utilizzando gli sviluppatori di software.)

Per quanto riguarda le "qualità attraenti", dipende dal produttore.

Se il produttore produce un "design sexy", può essere richiesto. Lo sviluppatore non dovrebbe preoccuparsi di queste scelte.

Inoltre, il software è così diverso dai prodotti fisici reali che penso che molto del modello Kano non si applichi. Ad esempio, perché faccio facebook? Unico motivo: perché i miei amici lo fanno. Come metterlo nel prossimo sprint ........ E anche, una delle qualità più interessanti del software, è che in realtà fa quello che dovrebbe fare. (Ed è qui che l'agile aiuta molto: P)

La mia esperienza concorda con i commenti di cui sopra - non c'è nulla di inerente ad Agile che precluda lo sviluppo di software eccellente - tuttavia ci sono diversi aspetti di come Agile viene spesso (mal) praticata che porta a un software che è solo "abbastanza buono" ".

• Agile pone l'accento sul far funzionare qualcosa al più presto; ciò significa tuttavia 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 della correzione delle 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 spedibile, in modo che gli stakeholder e i project manager possano decidere che "quello che hanno" è abbastanza buono da spingere produzione. Ancora una volta, nulla di intrinsecamente sbagliato in questo, sehai eliminato tutto il tuo "debito tecnico" (o hai fatto pace con quanto hai e dove si trova). Tuttavia, nella mia esperienza, troppo debito tecnico va in produzione con la promessa di un manager che "noi lo pulirò una volta che la pressione per la spedizione sarà disattivata ", 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 abbiamo avuto quella esposizione! La prossima volta dobbiamo fare un lavoro migliore! " La lezione di Ben Frankin su "L'amarezza della scarsa qualità rimane molto dopo che la dolcezza del basso prezzo è stata dimenticata" sembra non essere mai appresa;
• Tuttavia, anche con i manager di fiducia e gli sviluppatori ben disciplinati, c'è il problema comune che semplicemente troppo poco corretta analisi, la progettazione, e la revisione del progetto si verifica prima dell'inizio dello sprint in cui è prevista l'implementazione deve essere iniziato e completato. L'incapacità di considerare attentamente l' alternativaLe metafore e i disegni dell'interfaccia utente sono grandi: 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 priorità alla definizione e all'implementazione di tecnologie di infrastruttura come I18N, framework di notifica, logging, sicurezza e strategie di versioning API (ad esempio) significa che alla fine avranno bug più elevati, produttività inferiore e accumulerà più debito tecnico rispetto a se avessero appena trascorso i primi 2-5 sprint in anticipo facendo l'addestramento, l'analisi, la progettazione e la prototipazione richiesti. 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 il tempo di scrivere i loro progetti pianificati, anche al livello più elementare. Il suo ragionamento - "Voglio che le persone parlino tra loro" - che era ironico perché si trovavano in 5 diversi fusi orari e 3 paesi. Inutile dire che ci sono state molte indicazioni su quale squadra avrebbe dovuto lavorare un sacco di notti e fine settimana tardi nel progetto una volta capito che tutti pensavano che l' altro fosse responsabile dell'implementazione di alcune funzionalità (o reimplementazione perché i progetti del fornitore e del consumatore non si sono semplicemente uniti.)

Tutto si riduce al fatto che il project manager e gli stakeholder vogliano fornire un prodotto di alta qualità. Se si impegnano a farlo, Agile lo abiliterà. OTOH, poiché Agile mette il processo decisionale nelle mani esclusivamente degli stakeholder e del project manager, Agile rende difficile per un team di sviluppo fornire un progetto eccellente senza tale supporto. In breve: la responsabilità per la qualità del prodotto è quasi esclusivamente ai piedi dei project manager.

TL; DR

In effetti, lo sviluppo agile ti aiuta ad aumentare la qualità del software, mantenere il cliente soddisfatto e fornire 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 funzionante su documentazione completa
• Collaborazione del cliente sulla negoziazione del contratto
• Rispondere al cambio seguendo un piano

Quindi, lo sviluppo agile non ti impedisce di creare software di alta qualità. Lo sviluppo agile ti supporta nella fornitura di software di alta qualità.

Ma noi (e il cliente) sappiamo davvero sempre in anticipo quali sono i requisiti indispensabili.

Questo è il punto. Concentrandosi sugli individui, il cliente, il software funzionante e le modifiche ai requisiti agili di sviluppo ti aiutano a capire cosa vogliono i clienti prima della consegna del prodotto finale.

Questo è un motivo per cui framework agili come Scrum hanno cicli di iterazione brevi i cui risultati sono prodotti funzionanti. Puoi già validare il tuo lavoro in una fase iniziale rispetto alle aspettative del cliente e adattare gli obiettivi / requisiti su richiesta. Uno sviluppo agile ti aiuta ad assicurarti di realizzare la qualità indispensabile di un prodotto.

Ai tempi - è ancora vero per oggi - molti progetti software sviluppati con approcci tradizionali fallirono, non ebbero successo o causarono dispiaceri ai clienti perché la qualità indispensabile non era stata raggiunta.

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

Vorrei anche menzionare la 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 riconoscerai tali requisiti nel prodotto finale dopo una lunga esecuzione del progetto. Troppo tardi per evitare delusioni dei clienti e per cambiarli è necessario un progetto di follow-up.

Lo sviluppo agile ti aiuta a identificare precocemente i requisiti non lavorativi o insoddisfacenti e a cambiarli durante il progetto.

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

Sono piuttosto in ritardo per questa festa, ma vorrei condividere un'altra prospettiva su questo argomento:

Ma come possono essere applicati per creare deliziosi prodotti software di alta qualità e non solo il minimo indispensabile che soddisfa a malapena i requisiti indispensabili?

Vi è un aspetto temporale nello sviluppo di software agile che deriva dall'approccio iterativo e dalla considerazione del feedback dei clienti , che sono due elementi importanti della metodologia agile. Esempio: le funzionalità identificate come qualità attraente nell'iterazione t potrebbero diventare una qualità indispensabile nella successiva iterazione t + 1.

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

Ho fatto l'esperienza alcune volte che i requisiti a cui era stata data una priorità all'inizio, si sono rivelati molto meno importanti, se non inutili, in seguito.

Con questo aspetto temporale in mente è plausibile che i metodi agili in grado di produrre deliziando prodotti di alta qualità download , mentre concentrandosi sul minimo indispensabile . L' approccio iterativo associato al feedback dei clienti modifica le regole del gioco nel tempo.

Conclusione

Come sviluppare un software eccellente con metodi agili?

Applicare un approccio iterativo e ascoltare il feedback dei clienti . Abbandona uno di questi elementi e otterrai una forma meno efficace di sviluppo software agile.

   > How to develop excellent software with agile methods?

• Quando si produce un singolo software specifico per il cliente :
  • trova un cliente in cui i costi non contano perché la funzione "deliziosa" costa denaro extra e il cliente deve decidere se desidera pagare per questo.
• Quando si producono prodotti software :
  • Le funzioni "deliziose" sono buone 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 Scrum, il Product Owner è responsabile della scelta delle funzionalità da implementare. Quindi spetta a lui (e al suo budget) definire un software "abbastanza buono" o "eccellente"

Sollevi alcuni punti positivi. Ma non credo che questi problemi siano limitati a processi / metodologie agili.

Esistono opinioni diverse su ciò che è essenziale rispetto a quello non essenziale. Per usare il tuo esempio, qualcuno che acquista un'auto potrebbe considerare l'attrazione dell'attenzione come una caratteristica essenziale e quindi considerare una Fiat come non conforme a questo requisito indispensabile.
Più realisticamente, un prodotto software potrebbe essere necessario disporre di determinate funzionalità per soddisfare le esigenze dei suoi attuali utenti finali ... ma potrebbe anche essere necessario disporre di alcune altre funzionalità per essere venduto. Perché la persona che autorizza l'acquisto non è spesso un utente finale.
Quindi una funzione "non essenziale" per l'utente (i) finale (i) potrebbe essere essenziale per la vendita del prodotto ... e quindi essenziale anche per l'azienda che crea il prodotto.

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

È anche importante che i proprietari / parti interessate del prodotto siano autorizzati a prendere decisioni. Se le decisioni del proprietario del prodotto vengono costantemente annullate da qualcun altro, sarei il primo a concordare che si tratta di un problema, ma di nuovo non è un problema con l'agile.

Ci sono altre cose che vuoi nei tuoi proprietari di prodotti ... una descrizione che ho sentito è "CRACK" (collaborativo, rappresentativo, autorizzato, impegnato e ben informato). Un proprietario del prodotto privo di una di queste aree può creare problemi per un progetto. Ma ho sentito per la prima volta questo acronimo in un ambiente a cascata, quindi chiaramente il dolore dei cattivi clienti / proprietari di prodotti non si limita ai negozi agili.

Ciò che l'agile può (aiutare) fare è far emergere alcuni di questi problemi.

Ad esempio, la documentazione di XP è IIRC abbastanza esplicita sull'avere il "cliente" 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 è costituita da deliziatori anziché da funzionalità indispensabili, è molto più facile sollevare quel problema (e molto più facile determinare la causa) quando si distribuiscono software funzionanti o quasi funzionanti ogni 2-3 settimane rispetto a quando le consegne sono distanti mesi o anni.

Se stai lavorando in piccole iterazioni - e rivedendo frequentemente il backlog (inclusa la rivisitazione delle priorità) - questo offre al team l'opportunità di imparare da errori precedenti. "Adesso sembra davvero importante, ma ricordi la navigazione dinamica di cui eravamo sicuri di non aver bisogno?" Come altri hanno sottolineato, tali discussioni sono molto meno probabili se tutto è stato pianificato in anticipo.

Al contrario, la metodologia di progettazione iniziale presuppone (per impostazione predefinita) che la comprensione del prodotto e delle caratteristiche sia statica. Non è stata la mia esperienza: avere qualcosa di tangibile su cui lavorare quasi sempre cambia 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 influirà sulle priorità.)

Il differimento di parte della pianificazione consente inoltre di rispondere ai cambiamenti nelle esigenze aziendali. "Conosci quel sito web che stai costruendo? Abbiamo davvero bisogno che sia un'app mobile, in grado di disconnettersi." Questo non è qualcosa che è stato chiesto in particolare ... ma non vorresti che il tuo processo fosse in grado di rispondere ai cambiamenti nel panorama aziendale (almeno in teoria)?

Agile non dice "non creare funzionalità non essenziali". Dice "consentire all'azienda di decidere quali funzioni (non) costruire".
... e (altrettanto importante) "consenti ai tecnici di dirti quanto tempo impiegherà una funzione che vuoi costruire".

1. Must-be qualitiessono spesso difficili da determinare. Le persone li hanno in subconscio. Le iterazioni agili e la partecipazione dei clienti aiutano a trovare la maggior parte dei must. Questo è il potere dell'agile ed è sciocco trascurarlo .
2. One-dimensional qualitiesciò significa che le promesse che devono essere soddisfatte, sono supportate da cascata OK, fino a quando non cambiano. Qui essere agili aiuta solo, ma non così potentemente.
3. Attractive qualitiessono belle caratteristiche. Potrebbero diventare indispensabili nella prossima generazione. Ma nell'attuale generazione non sono nemmeno d'accordo - altrimenti sarebbero qualità monodimensionali. Quei metodi agili che suppongono la partecipazione rappresentativa del cliente supportano molto bene queste qualità. Perché possiamo cambiare leggermente lo scopo durante il lavoro. Possiamo contrattare sul miglioramento di un posto per un compenso in un altro. In cascata è praticamente impossibile. Senza un grande ritardo organizzativo abbiamo potuto solo aggiungere funzionalità gratuitamente. È possibile, se in precedenza è stato inserito un budget aggiuntivo.

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

Per farlo in modo comprensibile, è necessario impostare processi agili con un partecipante rappresentativo del cliente responsabile.