Come trattare con i clienti e le iterazioni nella squadra agile? [chiuso]

Question

Questo thread è un follow-up alla mia precedente . E 'infatti 2 domande, quindi spero che nessuno le menti, in quanto sono dipendenti l'uno dall'altro.

Stiamo iniziando un nuovo progetto al lavoro e lo consideriamo come una grande opportunità per provare le tecniche Agile in azione. Abbiamo avuto un brainstorming di idee che abbiamo letto in diversi libri e articoli, e si avvicinò con il concetto che ci si adatti al meglio: 2 settimane di iterazione, seguita dalla chiamata con i clienti che avrebbero scelto di che pasta si desidera avere nella prossima iterazione. Ho solo qualche domanda, che noi non riusciva a capire noi stessi.

Cosa fare nella prima iterazione?

Cosa, in generale, facciamo nelle prime iterazioni se partiamo da zero? Basta dare un mese di sviluppo al core codice dell'applicazione o iniziare con semplici wire-frame con funzionalità limitate pre-codificati? Ciò che di solito i clienti vogliono vedere? roba lucido che non funziona o roba brutta che fa il lavoro?

Come comunicare con i clienti?

Il nostro pensiero iniziale per impostare il processo per qualcosa di simile a questo:

alt text http://img690.imageshack.us/img690/2553/communication .png

E 'una buona idea avere un punto focale sul lato client o è meglio per comunicare direttamente con tutti i clienti per evitare problemi di comunicazione?

---

Tutti i pensieri sono i benvenuti! Grazie in anticipo.

Answer 1

A mio parere, un fattore chiave di successo per lo sviluppo agile è quello di concentrarsi sulla fornitura di valore per il cliente in ogni iterazione. Mi sarebbe sicuramente prendere "roba brutta che fa il lavoro" over "roba lucido che non funziona". Facendo interfacce utente lucidi e cercando di ottenere il cliente a capire la logica di business cappello prende un sacco di tempo per implementare è sempre rischioso, che Joel Spolsky ha scritto un buon articolo su.

Se il cliente vuole miglioramenti per l'interfaccia utente, si può sempre mettere che come requisito per l'iterazione successiva.

Per quanto riguarda la comunicazione con i clienti penso che il vostro scetch dovrebbe essere leggermente regolata. Parlando in termini di mischia vostro "punto focale" si chiama "proprietario del prodotto". Avere una persona di coordinamento con i clienti è buono, come si può prendere un bel po 'di tempo per ottenere le diverse parti interessate concordano sulle necessità. Tuttavia, il proprietario del prodotto (o punto focale) dovrebbero essere a diretto contatto con lo sviluppatore, senza passare attraverso il responsabile del progetto. In realtà, il proprietario del prodotto e il responsabile del progetto ha ruoli ben distinti che guadagnano un sacco per essere divisa su due persone.

Il proprietario del prodotto è la voce degli stakeholder al team di sviluppo. Il project manager d'altra parte è responsabile per il benessere del team di progetto e spesso tiene traccia del bilancio, ecc Questi ruoli volte ha opposti ordini del giorno, e averli divisi su due persone che danno una sana occasione di negoziazione tra interessi contrastanti. Se una persona ha entrambi i ruoli, che la persona spesso tendono a favorire uno di loro, riducendo automaticamente l'altra. Non si vuole lavorare su una squadra in cui il responsabile del progetto mette sempre il cliente prima che le esigenze della squadra. D'altra parte nessun cliente vuole un proprietario del prodotto che mette sempre le esigenze della squadra prima, neglegting il cliente. Dividere le responsabilità su due persone che aiuta a porre rimedio a questa situazione.

Answer 2

sarei d'accordo con Anders risposta. La mia sola osservazione in più è che molti clienti trovano impossibile ignoire il cattivo. Ottengono preoccupati per la presentazione, piuttosto che la funzione. Quindi potrebbe essere necessario stringere i denti e fare almeno una "Nice" schermo per mostrare che si pagherà attenzione ai dettagli di presentazione.

Answer 3

  

Cosa, in generale, facciamo nelle prime iterazioni se partiamo da zero?

Molte squadre utilizzano un Iterazione Zero a:

• l'installazione dell'infrastruttura di sviluppo (controllo del codice sorgente, macchine per lo sviluppo, la generazione automatica, un processo di integrazione continua, un ambiente di test, ecc),
• istruito il cliente e d'accordo con lui sulla metodologia,
• creare un primo elenco di caratteristiche, identificare il più importante e fare una stima iniziale,
• definire il tempo di incontri (riunione di programmazione, demo, retrospettiva), scegliere la lunghezza iterazione.

L'iterazione Zero è molto speciale perché non fornisce alcuna funzionalità per il cliente, ma concentrarsi su ciò che è necessario per eseguire i prossimi iterazioni in modo agile. Ma iterazioni successive dovrebbe iniziare a fornire valore al cliente.

  

Basta fare un mese di sviluppo al core codice dell'applicazione o di iniziare con semplici wire-frame con funzionalità pre-codificati limitata?

No, non sviluppano il nucleo della vostra applicazione durante un mese. Invece, iniziare a generare fetta verticale della domanda (dall'interfaccia utente al database) immediatamente, fette non orizzontali. Questo non significa che uno schermo deve essere completa (per esempio implementare un solo campo di ricerca in una schermata di ricerca), ma dovrebbe idealmente essere rappresentativo del look & feel finale (a meno che non concordato con il cliente su un passo intermedio). La parte importante è quello di costruire le cose che forniscono valore immediato al cliente in modo incrementale .

  

Ciò che di solito i clienti vogliono vedere? roba lucido che non funziona o roba brutta che fa il lavoro?

Per la mia esperienza, che vogliono vedere progressi dimostrabili e si desidera ottenere un feedback il più presto possibile.

  

E 'una buona idea avere un punto focale sul lato client o è meglio per comunicare direttamente con tutti i clienti per evitare problemi di comunicazione?

È necessario una persona per rappresentare i clienti (che è chiamato il Product Owner in Scrum):

• egli fornisce una sola voce autorevole
• ha una perfetta conoscenza del business (vale a dire che può rispondere alle domande)
• sa come massimizzare il ROI (vale a dire il modo di dare la priorità funzionalità)

Answer 4

Agile vuole in generale di fornire al cliente qualcosa di prezioso, in modo rapido.

Così ho certamente sarebbe non spendere "mese di sviluppo al core codice dell'applicazione". Per me, che sa di "grande disegno up front" anti-modello. Inoltre, vedere YAGNI .

ottenere quante più informazioni da parte dei clienti su ciò di cui hanno bisogno più presto, e implementare che nella prima iterazione. "Prezioso" è negli occhi del cliente. Thet sapranno se vogliono vedere la chiazza di petrolio UI (forse vogliono dare una proiezione di diapositive sul prodotto in una fiera, in modo da funzionalità può essere falso) o caratteristiche di lavoro semplici (forse si sta sviluppando qualcosa di cui hanno bisogno per iniziare < em> con ASAP). Business Value è ciò che dicono li aiuterà a fare il loro lavoro.

mi piacerebbe fare le mie iterazioni più breve posso (i tuoi 2 settimane potrei lavorare, vi suggerisco di considerare 1 settimana) Se proprio non può avere il vostro team di sviluppo ei vostri clienti co-locati, invece di avere una chiamata con i clienti, mi suggeriscono una riunione. Demo quello che hai fatto sul precedente iterazione e feedback sollecitazione su ciò che dovrebbe restare, cosa dovrebbe cambiare, e ciò che dovrebbe essere aggiunto.

Come altri hanno detto, il tuo "punto focale" suona come un Product Owner. Ciò che mi preoccupa è che se il disegno si intende implicare che gli sviluppatori non interagiscono con il PO o dei clienti. Una cosa che rende il lavoro Agile è quando c'è un sacco di comunicazione. Avere la comunicazione da / per il team di sviluppo sempre filtrata attraverso il Project Manager è quasi certamente destinato a causare problemi di comunicazione, lavoro inutile, e dettagli perse.

Answer 5

Sono d'accordo con le due risposte date, ma vorrei solo aggiungere una cosa per esperienza personale. I vostri clienti hanno acquistato per il cambiamento verso iterazioni rapide? Oltre a fornire un feedback dopo ogni iterazione che sta per richiedere al cliente di eseguire test di usabilità su ogni funzione.

Ora io non so che cosa i vostri gruppi rapporto è con il cliente, ma la sua non è inusuale per i clienti a prendere una "richiesta di Put in - ottenere sistema di lavoro" atteggiamento nel senso che sono entusiasti quando dare requisiti, ma non così forthoming con momento in cui si tratta di testare la funzione.

Ora, questo può essere del tutto inadeguato alla vostra situazione, ma la sua sempre la pena di considerare come il vostro cliente flusso di lavoro dovrà cambiare così come i vostri gruppi.

Saluti