Trascorrere una fortuna su un certificato con Scrum Master o un allenatore Veteran XP?

Sono fermamente convinto dell'idea di No Silver Bullet . Le due persone che stai descrivendo - lo Scrum master e il coach XP - appaiono (in base alla tua descrizione) per spingere la loro metodologia preferita come soluzione al problema della tua organizzazione.

Nessuna idea migliorerà significativamente i tempi di consegna, qualità, prevedibilità o qualsiasi altro aspetto del tuo ambiente di sviluppo durante la notte. I miglioramenti del processo e i programmi di qualità richiedono molto tempo (non settimane, probabilmente non mesi, ma anni) per progettare, implementare e istituzionalizzare.

Ci sono molti strumenti là fuori per aiutare a migliorare la capacità di un'organizzazione di fornire software, ognuno con i propri vantaggi e svantaggi. La soluzione corretta sarebbe quella di coinvolgere qualcuno che abbia familiarità con un certo numero di metodologie, tecniche e strumenti per valutare il tuo stato attuale e la tua cultura e sviluppare un processo che risolva i problemi chiave dell'azienda.

In questo momento, stai solo considerando qualcuno che difende Scrum e qualcun altro che difende XP. Che mi dici di CMMI? Lean Software Development? Sei Sigma? PSP / TSP? Cristallo? RUP? Qualche altro processo su misura che sfrutta una collezione di tecniche tradizionali di qualità di prodotto / processo e moderni metodi di ingegneria del software?

Non guardare verso questi venditori olio di serpente . Credo che sia XP che Scrum offrono buone idee, ma non sono giuste per tutti. Guarderei altrove le persone che lo capiscono e possono aiutarti a costruire ciò che è giusto per te.

Questa è una risposta prevenuta poiché credo nella qualità sopra ogni altra cosa.

Direi di andare con l'allenatore XP a mani basse. Sembra che la squadra non sappia come rifattorizzare o implementare veramente un codice ben organizzato, l'allenatore di XP li aiuterà a mantenere uno standard più elevato su questi punti.

Sono incline a pensare che la mischia sia ottima nell'organizzare la macchina della produttività per far sì che inizino a sfornare le cose a una velocità costante. Tuttavia, se non hanno imparato a rifattorizzare e seguire buone pratiche di codifica e scrivere codice manutenibile leggibile, allora la maggior parte degli sprint sarà spesa consistentemente sfornando software buggy o correzioni di bug per quello che hanno fatto lo sprint scorso. E quella velocità sarà molto bassa a causa del tempo necessario per lavorare con il software che hai descritto.

Qualcuno potrebbe dire che Scrum può risolvere questi problemi, ed è vero, ma ecco come: Scrum amplierà le inefficienze nel processo, cioè renderà loro problemi visibili, problemi non più grandi. Quando la mischia rende questa gestione abbastanza a lungo visibile può essere incline a iniziare a spingere gli ingegneri fuori dalla porta ea cercare sostituzioni che non mostrano gli stessi problemi.

Questa non è (sempre) la soluzione migliore. Un po 'di coaching su migliori pratiche di implementazione può risolvere questi problemi in cui i processi Scrum li renderanno semplicemente evidenti.

Detto questo, se riescono a scatenarsi, chiedigli di andare per entrambi, ma in primo luogo dovrei iniziare con il buco XP.

Developers are far from capable of doing agile programming practices at the moment. No unit tests, no pair programmings, no CI (huh? what is it?) ... you get the idea.

Il problema non sono i tuoi sviluppatori. Con un prodotto ventennale, i tuoi non hanno sviluppatori. Hai programmatori di manutenzione. Per quanto detesti i programmatori di manutenzione (lo scempio che provocano su un sistema splendidamente architettato è un crimine), hanno un posto in questo mondo. Alla maggior parte dei programmatori di sviluppo non piace quel posto. Vorrebbero essere inseriti nel mondo dello sviluppo. Dai loro la possibilità!

Il tuo problema è quasi certamente di gestione, non dei tuoi sviluppatori. Prove prima facie: circa 20 programmatori e un numero molto maggiore di personale manageriale dietro la società. Quello che è successo al tuo prodotto è che il cliente X ha chiesto la caratteristica A, il cliente Y ha chiesto la caratteristica B, il cliente Z ha chiesto per la funzionalità C. Tutto ASAP, il tutto a un costo minimo, e il tutto con zero preoccupazioni su come la funzionalità A è in conflitto con la funzionalità C. I programmatori di manutenzione sono diventati piuttosto agili nel covare la spazzatura nel prodotto. Il risultato, dopo vent'anni di incertezza di manutenzione, è un prodotto che è il 99,44% di spazzatura pura.

Non lo cambierai durante la notte. Qualcuno che dice che puoi, sta semplicemente vendendo un tipo diverso di spazzatura.

La prima cosa che deve accadere è che la tua gestione deve vedere che sono il problema principale. Se ciò non accade, facci sapere il nome dell'azienda in modo che possiamo venderli in breve prima di andare in bancarotta. Se ciò accade e hai un buy-in di gestione, disattiva i tuoi programmatori di manutenzione. Ciò richiederà un cambiamento di mentalità, e alcuni non saranno in grado di farlo. Che si tratti di programmazione agile, programmazione estrema o qualcos'altro, la maggior parte di loro salterà in questa occasione. È un'opportunità irripetibile che durerà almeno alcuni anni.

La cosa importante non è l'approccio che prendi ma come ti assicuri di avere un prodotto di qualità perpetuamente alta. Devi mantenere (migliorare!) Quella qualità piuttosto che lasciarla degradare. Altrimenti affronterete esattamente gli stessi problemi dopo alcuni anni, dopo che la bella riscrittura è tornata ad essere una spazzatura pura al 99,44%.

Questo è opinabile, ma basato sull'esperienza personale.

Penso che l'allenatore di XP sia più propenso a fornire valore rispetto al maestro di mischia. È molto più probabile che crei una buona programmazione di quella che il maestro di misericordia creerà probabilmente una buona gestione.

Se ciò non ti persuade, usa il buon senso. Dice che girerà intorno alla tua gestione e si definisce un "scrum master". Questo suono come B.S. a te?

Se "l'allenatore XP" si definiva uno "zar di casa", allora non sarebbe nemmeno di confidenza.

OK, quello era uno scherzo, in parte, (più l'XP coach non è un termine BS-free) ma c'è una migliore possibilità per i programmatori di implementare le modifiche senza che la gestione sia davvero dietro a ciò che c'è se la gestione è dietro di esso ma i programmatori non sanno come farlo.

Inoltre, una volta che la gestione è stata eliminata per l'allenatore XP, probabilmente puoi giustificare, facendo alcune delle cose che ti hanno insegnato. Quindi ottieni alcuni dei benefici del maestro di mischia. Il contrario non sarebbe vero - il maestro di mischia non ti insegnerà come fare questa roba di programmazione agile, anche se le tue riunioni di stand-up fanno piangere gli spettatori sulla loro bellezza.

Nessuna delle due opzioni si avvicina ad essere sufficiente per risolvere il problema, ma l'allenatore XP è migliore se devi rispettare le scelte presentate nella domanda.

Non penso che questo sia un "XP o Scrum?" domanda. La domanda potrebbe essere formulata nel modo migliore come "Come posso migliorare la qualità di questo prodotto esistente?"

In secondo luogo, come sottolineato da un altro poster, il tuo prodotto sembra essere in "modalità di manutenzione" piuttosto che nello sviluppo di nuovi prodotti. Raramente consiglierei Scrum per compiti puramente di manutenzione.

Quindi, penso che un approccio a due punte possa servire al meglio.

Per quanto riguarda la qualità, direi che aiutare il team a implementare cose come test unitari, Test Driven Development, Behavior Driven Development e Refactoring sarebbe un ottimo punto di partenza. Istruzione prima, poi pratica.

Successivamente, per aiutare a gestire il modo in cui il prodotto viene corretto, prova qualcosa come Kanban.