Come adottare la metodologia di mischia agile per un piccolo team .Net [chiuso]

Sì, la mischia potrebbe essere appropriata, ma è necessario saperne di più. Il libro di Ken Schwaber ti dirà un sacco di cose - come in che modo lo Scrum Master non è affatto un project manager e che il team deve essere auto-organizzante.

Le cose principali di cui hai bisogno se stai percorrendo la strada agile, è una squadra che può auto-motivarsi e raccogliere qualsiasi palla venga lasciata cadere davanti a loro, i clienti che sono disposti a lavorare a stretto contatto con il team durante tutto il processo di sviluppo, e un proprietario del prodotto che ha i mezzi per decidere cosa deve essere all'interno della portata attuale e a lungo termine e la sua priorità.

Quindi, per prima cosa devi imparare di più sulla mischia e decidere se è appropriato. Se decidi di farlo, dovrai parlare con tutte le parti interessate e vedere se sono disposte a dare il via - si spera che uno di loro prenda le redini come Product Owner. Quindi dovrai assumere o diventare uno Scrum Master.

Dici che il tuo "progetto attuale è molto instabile a causa della scarsa organizzazione". In risposta, il tuo capo ha chiesto alla "persona responsabile della pianificazione di tutto" il cui compito principale è uno "Sviluppatore software", ma "non può più gestire il progetto" per effettuare una pianificazione anticipata. Non sto criticando la tua abilità né come sviluppatore software né come project manager, ma sospetto che potrebbero esserci problemi più grandi qui che una metodologia di sviluppo non può risolvere. Permettetemi di speculare su alcuni dei vostri problemi e su come Scrum può o non può aiutare.

Scrum è ottimo per gestire requisiti imprecisi o mutevoli. Il team attua i requisiti e produce una versione che il proprietario del prodotto (cliente) vede e suggerisce miglioramenti negli sprint futuri. È particolarmente utile quando il proprietario del prodotto non sa esattamente cosa è desiderato da "lo saprà quando lo vedrà".

Tuttavia, Scrum non imporrà la creazione di tali requisiti. Se non si ha accesso a un rappresentante del cliente come proprietario del prodotto, alcuni dei vantaggi di Scrum andranno persi.

Scrum è un ottimo modo per dimostrare i progressi. Se le persone perdono la fiducia di poter offrire qualcosa, fornire una cadenza regolare di miglioramenti visibili può essere di grande aiuto.

Tuttavia, Scrum non funziona altrettanto bene quando si hanno scadenze fisse con le caratteristiche richieste. In effetti, non esiste una metodologia di sviluppo. Scrum ti aiuterà a ottenere un sottoinsieme delle tue funzionalità implementate con una buona qualità ma non è un proiettile d'argento.

Scrum può anche essere difficile da spiegare alle persone non tecniche usate per dettare le scadenze e vedere una pianificazione anticipata dettagliata. Molte persone sentono "pianifica mentre si va" come "codifica dei cowboy" e si lamentano per l'apparente perdita di controllo. Se vuoi implementare Scrum, potrebbe essere più facile scegliere un progetto meno critico e dimostrarlo funzionante. Altrimenti, se lo implementate qui e il progetto fallisce, sarà molto più difficile utilizzarlo per progetti futuri.