È uno strumento o una suite di strumenti migliori per Scrum? [chiuso]

Question

Buongiorno,

Modifica Stiamo usando Scrum con successo per molti anni in diversi progetti di varie dimensioni. In realtà, il nostro team ha sviluppato il progetto di successo iPlayer per la BBC con un approccio classico Scrum.

Dopo aver usato varie combinazioni di strumenti, alcuni high-tech, un po 'low-tech, tra questi progetti ora vogliamo provare l'adozione di una suite di strumenti adatti. Il nostro manager è in una certa misura il tentativo di forzare l'adozione di un'unica suite di strumenti per Scrum.

Ho guardato la questione SO " Miglior Scrum " e la maggior parte delle persone sembrano raccomandare uno:

1. una suite di soluzioni low-tech, per esempio lavagne, post-it, schede, ecc, o
2. uno strumento monolitico che cerca di soddisfare il più possibile del processo, ad esempio Agilo, si mescolano, ScrumWorks, processo di destinazione, ecc.

Il nostro team sta valutando diversi strumenti Scrum differenti. Tuttavia, siamo di fronte a selezione di un unico strumento monolitico, per esempio Agilo.

Tutte le soluzioni "one-stop" hanno i loro punti di forza e di debolezza con le gravi soluzioni di tipo enterprise che sono il miglior tipo di forma. Ma tutti hanno alcune carenze.

Dopo aver letto il giornale " Peer Code Review:. un processo Agile " sopra a SmartBear ho iniziato a chiedersi se stavamo cercando di forzare l'adozione di uno strumento su una 'best fit base'

Credo che si può prendere un paio di manufatti di riferimento del processo di sviluppo Scrum, dire

1. le storie degli utenti, epopee e temi, e
2. il codice di base che deve utilizzare uno SCM noto, ad esempio SVN, Hg, ecc.

Quindi se prendiamo che come punti di riferimento comuni per gli attrezzi impiegati allora ci sarebbe in grado di utilizzare un gruppo di strumenti per gestire i diversi aspetti del processo Scrum anziché provare a forzare un attacco di un unico strumento farebbe è un po 'come forzare un piolo quadrato nel foro rotondo.

In questo modo, fornendo hai accettato i tuoi punti di riferimento comuni, è possibile utilizzare diversi strumenti, ogni svolgere il loro ruolo di meglio di una potrebbe essere fatto da un singolo componente di una suite di strumenti monolitico.

E 'questo un approccio più sensato?

sono i due punti di riferimento che ho citato sopra indicato, oppure è la loro una scelta migliore di punti in cui gli strumenti si incontravano?

applausi,

Answer 1

Beh, la risposta agile a che è "dipende". Provare qualcosa, se funziona per la tua squadra, persistono altro adattamento / cambio.

Spiegazione: strumenti di bassa tecnologia sono raccomandati per il vantaggio principale di costringere la gente a scendere loro sedie, muoversi, parlare-n-interagiscono e si sentono coinvolti in corso delle squadre. Tuttavia la mia esperienza personale è che l'adozione dipende l'esatta composizione e l'atteggiamento dei membri del team. Se la squadra nel suo complesso non piace muoversi / accordarsi su post-it, non continuare con esso; provare qualcosa di diverso. Anche se il più delle volte, vedo che le squadre "bloccati" presentano questa resistenza. Si finisce con un bordo mischia multicolore che ha post-it che solo il maestro di mischia si preoccupa.

Gli strumenti di alta tecnologia sono preferiti dal tute / gestione in primo luogo perché possono premere un paio di pulsanti e hanno rapporti pronti. Il rovescio della medaglia è che i periodici di inserimento dati / humongous per tenerlo in sincronia. Ora, con gli strumenti di gestione dei progetti agili, i progressi (o la mancanza di esso) è più evidente (inizio), quindi scommetto su più di questo in futuro. Se il management ha già scelto un 'ampia serie organizzazione', allora sei bloccato con esso.

Al momento sto sperimentando con un foglio di lavoro condiviso, che ha l'elenco delle storie / compiti per questo sprint accoppiato con burndowns calcolati. Questa scheda è proiettato su un muro durante mischie + messo su una condivisione di rete se qualcuno vuole vederlo. Gli aggiornamenti vengono eseguiti durante daily scrum da parte della SM.

Answer 2

Personalmente Posso consigliare il TargetProcess, http://www.targetprocess.com/

Ho imparato un sacco MISCHIA da solo lavorando con questo strumento.

Answer 3

ci fai MISCHIA in questo momento? Hai fatto molte iterazioni?

Se no, allora vi consiglio che probabilmente non sai quello che ti serve ancora. MISCHIA può essere fatto con lavagne o fogli di calcolo per cominciare con, passare a strumenti se si decide che sarà prezioso.

Answer 4

Sembri più avanti nell'adattamento allora siamo. Ho cercato di spostare la mia squadra per un processo agile per un paio di anni e siamo sempre meglio a questo. Abbiamo utilizzato alcuni strumenti di livello enterprise in passato. Principalmente da Rational. Mi è sempre sembrato a complicare su quello che avrebbe dovuto essere una semplice procedura. Per noi, lo ottengono lo strumento più semplice per soddisfare l'esigenza sembra funzionare. Un sacco di schede bianche, spontanea alzarsi di incontro per chiunque ne faccia richiesta uno. CVS e script di build automatizzati con Lunt (di trasferirsi a Hudson). Jira per tutto il progetto di gestione divertente. Siamo davvero stati in grado di aumentare la produttività e il costo tagliare. Siamo un piccolo team e tutto collocato.

Answer 5

Cosa c'è di sbagliato con il nostro attuale set di Scrum strumenti?

Questa è una buona domanda che non può essere chiesto qui come la gestione può solo avere soldi da spendere e vogliono comprare un po 'grande pacchetto strumento lucido come un segno che si preoccupano della squadra e vogliono che le cose siano meglio. Non che sia una brutta cosa nel voler buttare soldi in un problema, ma potremmo almeno essere intelligenti a fare questo?

Answer 6

Vi consiglio JIRA GreenHopper in quanto ha un consiglio di pianificazione, una scheda di un'attività e un grafico burndown che sembra colpire tutti i concetti SCRUM