I programmatori dovrebbero parlare con clienti / utenti in base ai metodi MSF / agili?

1. Il cliente fa parte del team che produce il prodotto, quindi può davvero accumulare desideri su desiderio. Ma fanno anche parte del processo di pianificazione per il quale è inclusa la storia in cui sprint, in modo da ottenere un riscontro immediato su quale desiderio impiegherà quanto a lungo implementare, e quale altro desiderio verrà rinviato a causa di esso. Questo crea un contrappeso naturale. (Mentre nella progettazione e nello sviluppo di requisiti obsoleti e strettamente segregati, tali feedback non avvengono praticamente mai e il cliente non ha idea di quali funzionalità richiederebbero quanto tempo, a volte i rappresentanti del cliente addirittura mentono attivamente su di esso.)
2. Differisce da metodo a metodo, ma in generale, l'obiettivo è di ottenere i requisiti dalle persone più vicine agli utenti effettivi del prodotto finito, piuttosto che dai loro responsabili, dal loro reparto acquisti o anche dai loro rappresentanti di vendita.
3. Praticamente parte della stessa disposizione di (1): il cliente dovrebbe essere presente quando la funzionalità è pianificata, implementata, provata e testata. Se durante tutti questi passaggi, non si accorgono che in realtà non lo vogliono, beh ... alcune persone non possono davvero essere contente, e anche i metodi agili sono incapaci di farlo.

How do agile methods deal with the problem of feature creep

La via principale è che i metodi Agile sono tipicamente basati sull'idea di una pianificazione di rilascio backlog e . Tutto ciò che un utente vuole può andare nel backlog. A intervalli regolari, gli utenti devono dare la priorità al backlog, per impostare le funzionalità su cui lavora il team.

Gli utenti non , tuttavia, possono richiedere nuove funzionalità per l'iterazione corrente. La definizione di "feature" è alquanto sfocata, tuttavia: all'inizio dell'iterazione, il programmatore conosce abbastanza i requisiti per fornire una stima approssimativa del tempo. Durante l'iterazione, lo sviluppatore lavorerà con l'utente per perfezionare i requisiti. In questo caso, la funzionalità concordata potrebbe rivelarsi più complessa di quanto originariamente previsto. In un mondo perfetto, utente e sviluppatore si accontentano di "essere abbastanza bravi" e rinviano i miglioramenti all'arretrato.

Nel mondo reale, gli sprint occasionalmente falliscono (non producono nulla) perché l'utente e lo sviluppatore non possono essere d'accordo su un ambito ragionevole. Dopo alcuni fallimenti, il team (che include gli utenti) deve affrontare la loro disfunzione e trovare un modo per aggirarlo.

Who does the requirements engineering in agile methods

Il team, che include sviluppatori e utenti. L'idea alla base dei metodi Agile è che gli utenti raramente sanno quello che vogliono nel livello di dettaglio necessario per implementare un software di qualità di produzione. Ci sono sempre casi d'angolo, e quelli dovrebbero uscire mentre lo sviluppatore analizza la funzione.

Il grosso problema è come vengono catturati quei requisiti. Non c'è motivo per cui non si possa produrre un documento dei requisiti formali come parte di una metodologia Agile, ma la maggior parte dei team lo vede come anti-Agile. Alcuni team usano i testcase come requisiti e una suite ben scritta di test di integrazione è uno dei migliori documenti formali che è possibile ottenere. Una pagina wiki che cattura la discussione tra utenti e sviluppatori è anche ragionevole.

Sfortunatamente, molti team vedono Agile come "non abbiamo bisogno di alcuna documentazione puzzolente" e finiscono in argomenti sei mesi lungo la strada. Che occasionalmente segna la fine di "Agile" in quella particolare compagnia.

Do you validate in MSF / agile methods if your product does what the customer wants and the user needs before shipping it? How do you do it?

L'utente dice "questo soddisfa i miei bisogni". Questo succede alla fine di ogni iterazione e quando vengono soddisfatte abbastanza necessità, il progetto viene rilasciato. Quindi iniziano i miglioramenti.

Queste due filosofie sembrano contraddirsi l'una con l'altra, ma possono coesistere. Solo perché gli sviluppatori non hanno contatto diretto per gli utenti, ciò non significa che non ci sia comunicazione tra loro.

La comunicazione avviene attraverso le relazioni con i clienti che chiedono ai clienti le loro esigenze, li traducono nella lingua del team di sviluppo e forniscono agli sviluppatori istruzioni chiare che possono seguire. Presentano quindi i prototipi ai clienti, aggregano i loro feedback e li riportano al team di sviluppo. In questo modo gli sviluppatori possono concentrarsi completamente sullo sviluppo.

La filosofia Microsoft si basa sul presupposto che i programmatori e le relazioni con i clienti siano due specializzazioni completamente diverse con una formazione completamente diversa. I programmatori sono addestrati per parlare con le macchine mentre i CR sono addestrati per parlare con gli umani. Ognuno dovrebbe fare il lavoro per cui sono stati formati.

La filosofia agile, d'altra parte, presuppone che uno sviluppatore di software eloquente sia in grado di scrivere codice elegante e avere le abilità sociali per trattare con gli utenti. Eccellere sia a livello sociale che a livello tecnico è un ideale per il quale dovremmo lottare, ma siamo onesti: la maggior parte delle persone è più chiusa per l'una o l'altra o . Quelli che possono fare entrambe le cose sono un'elite rara (ed estremamente preziosa!)

Questo è da un punto di vista agile

1. Feature Creep Caratteristica insinuante in sé non è un problema ed è in realtà incoraggiata in modo agile. Il cliente dovrebbe essere in grado di richiedere nuove funzionalità nel momento in cui si verificano. L'ambito dovrebbe essere in grado di cambiare, e occuparsi di quel cambiamento è un tenant principale di agile.

Dove si trova diventa un problema è se il team si è impegnato in una serie di lavori (ad esempio uno scrum sprint) e i requisiti cambiano. Spero che nel momento in cui la riunione di pianificazione terminerà, la funzionalità è ben definita e può essere impegnata e, si spera, non cambierà nelle prossime 2 settimane. Prima della riunione di pianificazione, la funzione dovrebbe essere autorizzata a cambiare quanto desidera.

La mia opinione è che il team dovrebbe essere in grado di assorbire una piccola piccola modifica durante l'itterazione. Se è solo un lavoro aggiuntivo sulla funzionalità, aggiungilo al backlog. Se non ha più senso fare la funzione, inserirla o rimuoverla tutti insieme. Se la funzione è già stata eseguita, aggiungi la modifica al backlog. Qualsiasi cosa tu faccia, non implementare una funzione che non è più necessaria. In ogni caso, il Product Owner dovrebbe essere coinvolto in quanto sono quelli che devono "accettare" una funzione come è stata fatta

Un modo per limitare il cambio di scope è scrivere buone storie di utenti. Una buona user story indica chiaramente di cosa si tratta. È anche piccolo (vale a dire < ~ 2 giorni di lavoro), quindi ha bisogno di cambiare drasticamente per avere un impatto.

2. Raccolta dei requisiti Agile tende ad essere piuttosto tranquillo su chi fa la raccolta dei requisiti. Potrebbe essere il proprietario del prodotto, gli sviluppatori, i BA o gli utenti finali. Ciò che è importante è che esiste un unico arretrato (programma di lavoro) e che è prioritario da una singola persona (il proprietario del prodotto). Il proprietario del prodotto può ricevere input dagli altri e organizzarlo utilizzando qualsiasi metodo che preferisce, ma il buck deve fermarsi con lui / lei.

3. Validazione Se si utilizza un metodo iterativo (ad es. Scrum), la convalida viene in genere eseguita alla fine della presentazione di iterazione. Se si utilizza un metodo continuo (ad esempio kanban), la convalida viene eseguita continuamente. L'attività non viene eseguita finché non viene convalidata. Di solito faccio in modo che la mia squadra entri regolarmente nelle persone giuste e dia l'occhiata alla funzione.

Un'alternativa è semplicemente spedire la funzione e regolarla in base al feedback. Puoi farlo solo se spedisci il software spesso (ogni giorno e ogni due settimane).

Lavoriamo in una grande azienda in cui il nostro cliente è il nostro dipartimento dei servizi clienti e il nostro Product Owner è a capo di quel dipartimento. Ha una "sottotesta" che la assiste con tutto.

Per rispondere alla domanda degli sviluppatori che parlano al cliente: in Scrum / Agile il 'client' sarebbe il Product Owner (PO). È MOLTO importante per il cliente entrare in contatto con gli sviluppatori che lavorano sul loro prodotto. Aiuta in Sprint Planning e Backlog Grooming per ottenere la comprensione degli sviluppatori alla pari con quella del cliente. In modo che ciò che costruiamo è dannatamente vicino a ciò che il cliente si aspetta. Ma a volte la natura del cliente o l'ambiente della relazione è tale che le due parti non dovrebbero parlare tra loro. In casi come questo si ottiene un Proxy PO che può comunicare con entrambe le parti. Qualcuno che può ancora dare agli sviluppatori la connessione personale con il "cliente" mantenendo il cliente aggiornato su ciò che sta accadendo con il loro prodotto.

Cercherò di rispondere alla tua domanda secondaria, di gestire la funzionalità creep, spiegando come affrontarla: con il backlog grooming possiamo imparare cosa ha aggiunto il client al backlog e quali sono i loro le priorità sono Qui possono aggiungere cosa, perché nell'ambiente aziendale l'unico prodotto su cui lavoriamo è a lungo termine. Ma se iniziano ad aggiungere cose durante uno sprint (dopo che ci siamo impegnati con X-quantità di storie / punti effort), semplicemente ridimensioniamo il nuovo lavoro e lo etichettiamo come "non pianificato". Il lavoro non pianificato può essere aggiunto allo Sprint, ma poi rimuoviamo una quantità uguale di punti dall'elenco iniziale o li aggiungiamo come punti negativi al nostro grafico Sprint. Ciò consente al cliente di vedere l'impatto della propria decisione su ciò che desiderava per lo sprint. Se non ricevono tutte le funzionalità originali o se l'impegno originale non viene rispettato alla fine dello sprint, è chiaro che è stata colpa loro.

Questo succede ma una o due volte e poi smettono di farlo. :) Ma è necessario che il team di sviluppatori si attenga alle proprie armi e non lasci che il lavoro non pianificato "cada attraverso il crack" e venga comunque eseguito.