Qual è l'impostazione minimalista per Agile Development per una piccola squadra?

Il miglior sistema di ticketing è di gran lunga una lavagna bianca con note adesive.

Questo non soddisfa il requisito di integrazione con STS, ma trovo che le note appiccicose superino qualsiasi soluzione software (purché il team non sia geograficamente disperso).

• Sono estremamente facili da visualizzare e utilizzare.
• Aggiungere lavoro a uno sprint significa aggiungere fisicamente un appiccicoso alla lavagna. Questa è una buona barriera contro il creep dell'ambito.
• L'alta visibilità del progresso è motivante.
• È facile mostrare agli stakeholder non tecnici cosa sta succedendo.
• Il forum diventa un punto di incontro in cui le persone parlano tra loro e scambiano informazioni.
• Mi aiuta ad allontanarmi dalla mia scrivania e allungare le gambe. Come desk jockey, posso sfruttare tutti i vantaggi per la salute che posso ottenere!

Come per il controllo del codice sorgente, usa SVN o Git. Se il tuo datore di lavoro ti chiede di utilizzare una sorta di "impresa scm" pesante, impantanata, che ti intralcia, usa comunque Git e spingi al SCM centrale ai limiti dello sprint.

L'integrazione continua in progetti Java viene solitamente gestita da Hudson / Jenkins in questi giorni. È molto veloce da configurare. Assicurati di montare uno schermo per radiatori in un posto visibile!

Consiglierei uno dei due approcci a seconda delle esigenze.

In primo luogo con un piccolo team veloce, in cui lo stato che riporta alla tua gestione può essere fatto in modo informale. In questo scenario prenderei in considerazione gli story board basati su schede, il poker di stima (o come mai si chiama), ecc. Semplicemente perché in tutti i progetti agili che ho lavorato, quelli che hanno funzionato meglio in termini di sviluppatori, tester e clienti stare in sincronia e avere una chiara immagine di ciò che stanno costruendo ed è lo stato, niente batte il muro.

In secondo luogo, se si hanno requisiti per la segnalazione a distanza, lo stato delle e-mail ad altri e gli sviluppatori remoti, allora mi sposterei verso gli strumenti della suite Atlassian. Hanno una varietà di strumenti e strutture online / offline, gratuiti oa prezzi ragionevoli. Il motivo per cui ho consigliato i loro strumenti rispetto agli altri che ho visto e provato è semplicemente perché penso che siano estremamente ben integrati, ma in grado di funzionare da soli e di giocare con gli altri. Ciò significa che sono molto flessibili nel modo in cui li usi. Sono anche molto ben costruiti.

Mi piace l'approccio di Barend.

Se hai squadre disperse geograficamente, è sempre una buona idea definirle in modo che abbiano il minimo sovrapposizioni possibile. È possibile utilizzare i limiti architettonici per questo. Assicurati che ogni team sia collocato in una posizione comune e funzioni trasversalmente, quindi ottieni la migliore produttività.

L'aggiunta di un sistema di ticketing a una piccola squadra equivale ad aggiungere un sovraccarico. La cosa bella di Scrum è che ha solo un overhead del 10% [Ivar Jacobson], che si aggiunge alla grande produttività.

Se disponi di ticket (bug, elementi di lavoro, funzionalità, ecc.) che i cross confini di team / architettonici potrebbero essere utili, allora dovresti dividere questi ticket e creare sottotitoli biglietti che sono squadra singola solo .

Puoi quindi gestirli in modo Barend e aggiornarli / chiuderli nel sistema di ticketing generale quando necessario / applicabile.

L'aggiunta di lavoro durante uno Sprint è discutibile, ma se fai qualcosa di più continuo, puoi utilizzare il sistema di ticketing per rappresentare il backlog del lavoro.