Software placcato in oro
La prima volta che ho visto la placcatura in oro usata come descrizione per il software è stata in un articolo di Barry Boehm in cui ha dato la seguente causa principale:
Placato in oro. Le specifiche dei requisiti fissi prima della progettazione tendevano a incoraggiare la doratura del software. Gli utenti che chiedevano quali fossero i loro requisiti spesso ragionavano: "Non so se avrò bisogno di questa funzione o meno, ma potrei anche specificarla per ogni evenienza".
Nella sua descrizione, raccomanda di utilizzare i metodi descritti nella sua ricerca, incluso il modello del ciclo di vita del software a spirale in cui i progetti erano mirati a produrre una serie di prototipi uno per ciclo e, man mano che le spirali si ingrandivano, un prodotto completo. Spiral ha avuto un'influenza diffusa tra i ricercatori di software ed è stato un importante ponte tra la cascata e Agile. Un limite critico della spirale è che ogni volta attorno alla spirale i cicli si allungano e diventano più costosi.
Come con Agile, la spirale cerca di evitare la placcatura in oro mirando più restrittivamente e programmando il risultato del progetto abbastanza a lungo da consentire ai team di soddisfare i requisiti, mentre allo stesso tempo è abbastanza breve da consentire di concentrarsi sull'obiettivo dal primo giorno fino al giorno della consegna. Un modo in cui i metodi Agile come Scrum sono superiori è che Scrum corre per un arco di tempo che non si allunga con le iterazioni. Dal documento, la gestione del progetto sembra avere più influenza sulla doratura rispetto ai singoli sviluppatori.
Talento per il pugilato a tempo
Essere in grado di time box è molto importante, ma non è un'abilità binaria. Non ce l'hai o ti manca. Sei migliore o meno bravo con esso. Che provenga dal tuo capo o da te, preferirei se nessuno dicesse che non puoi fermare la doratura. Sembra personale, pervasivo e permanente.
Un'analisi delle cause alla radice potrebbe aiutare a identificare diversi problemi. Sono abbastanza certo che non ti indicheranno tutti e che, a meno che tu non lavori con psicopatici, altri nel tuo team vedranno esigenze simili per migliorare il loro set di abilità Agile. Se conosci qualcuno senza problemi, non li conosci molto bene. Se conosci qualcuno che pensa di non aver bisogno di migliorare, non si conoscono molto bene.
Spero che i miglioramenti che identifichi siano cose che puoi risolvere con la tua consapevolezza e l'aiuto del team. Tuttavia, penso che non sia qui che finisce. La mia aspettativa da parte del supervisore o del responsabile che scrive le tue recensioni sarebbe che possano anche istruire i loro subordinati per avere successo. Ciò è particolarmente critico quando l'organizzazione sta subendo un cambiamento rivoluzionario come il passaggio da pianificato ad Agile (o ad hoc ad Agile).
Prototipo rapido e sporco o gestito a rischio?
Avevo un manager che richiedeva che le attività fossero eseguite in un certo modo.
Veloce e sporco, ma una cosa di bellezza.
Conosceva la stupidità di ciò ed era parte del suo ironico senso dell'umorismo. Molte persone dicono cose come questa e sono molto serie. Da qualche parte, c'è un compromesso o un'opportunità per alleviare il problema con una tecnologia o un approccio migliorati.
Cosa possiamo sacrificare per adattarci al nostro time box?
Nel capitolo uno di Extreme Programming Explained , seconda edizione, Kent Beck parla di ciò che serve per muoversi velocemente. La sua risposta è che "fai solo ciò che devi fare per creare valore per il cliente".
Rischio
Nella prima edizione dello stesso libro, Beck identifica un po 'più da vicino le opinioni di Boehm sul controllo del rischio come critiche per la sua metodologia dicendo:
"Il rischio è il problema di base dello sviluppo del software"
In entrambe le edizioni, Beck elenca e descrive otto rischi comuni, seguiti da un'affermazione che XP (o forse per estensione, Agile) affronta ciascuno in un modo particolare. Per me, la maggior parte della sua spiegazione si riduce all'uso di incrementi più piccoli e iterazioni più veloci ci consentono di riportare le cose sulla rotta prima che i rischi diventino troppo grandi da gestire.
Mentalità di sufficienza
Beck discute le risorse nel contesto di una storia sulla gente di montagna e la gente della foresta e introduce un concetto chiamato "Mentalità della sufficienza". Nel contesto della tua situazione, chiede "Come faresti se avessi abbastanza tempo?" Solo questo primo capitolo, disponibile come anteprima del libro, può fornire un sacco di spunti di riflessione su come XP (e altri metodi Agile) pensano a vincoli come il tempo.
La compulsione potrebbe essere il sintomo, non la malattia
Anni fa ho guardato un libro sulla procrastinazione che affermava che molta procrastinazione ha origine nella paura. Se non inizi, non commetti un errore e forse non sarai criticato. La compassione e il perfezionismo danno qualcosa che il nostro senso morale ci dice che è meglio della procrastinazione, ma probabilmente ha lo stesso risultato. Considera che forse stai riscontrando un problema con la procrastinazione in un'altra forma?
Critica e concorrenza
Nelle metodologie Agili come Scrum, le opportunità di essere criticate o punite per la procrastinazione non sono mai state così alte. Questo è un circolo vizioso. Procrastino perché sono criticato, sono criticato perché procrastino. Con le riunioni di mischia quotidiane, siamo sempre in allerta perché siamo sempre un giorno o meno dal riferire al team ciò che abbiamo realizzato.
In una squadra ideale, Scrum offre un'opportunità quotidiana per correggere la procrastinazione. Gli errori non dovrebbero avere il tempo di diventare grandi prima dell'arrivo dell'aiuto. Le squadre non sono sempre dove dovrebbero essere sagge in termini di fiducia, quindi i leader all'interno del team potrebbero dover affrontare in modo proattivo le critiche o la paura delle critiche per consentire alle cose di andare avanti.
Nel nostro mondo del lavoro, ogni persona in una squadra deve anche competere con gli altri. È un po 'schizofrenico credere di avere un team che condivide il lavoro e la gloria per i risultati, ma poi utilizzare un processo annuale di gestione delle prestazioni che premia il 20% dei suoi membri, punisce o espelle il 10% o più dei membri e finge che la maggioranza del 70% contribuisca al meglio senza incentivi. Penso che questo sia un grande elefante nella stanza che promuove il lavoro di squadra, e per fare riferimento alla storia di Kent Beck, mostra profondi legami culturali con l'essere Mountain People.
La strada davanti
Come membro di un team Agile, sarebbe bene studiare e dialogare con gli altri su ciò che funziona. Se il tuo team sta usando TDD per automatizzare i test unitari con uno strumento, chiedi alla persona che fa di meglio di allenarti. Se il tuo supervisore o manager ha un problema con il tuo approccio alla documentazione, scopri cosa gli piace o chi lo sta facendo come piace a lui e segui il loro approccio. Se si riduce a una velocità di codifica non elaborata, studia cosa serve per codificare più velocemente.
I leader possono compiere passi nella giusta direzione modellando i comportamenti desiderati come chiacchiere sui propri problemi (non quelli di qualcun altro), offrendo e seguendo con aiuto, dialogando su come il team può passare allo stile Agile Marine (cioè nessun uomo lasciato indietro). Non tutti i membri del team hanno le stesse abilità. Potrebbe essere opportuno esplorare i membri del team di accoppiamento o assegnare compiti e ruoli che possano enfatizzare i punti di forza complementari delle persone coinvolte. Pianificare la crescita o il risanamento delle competenze dovrebbe essere una parte gratificante del lavoro sia per il supervisore che per il subordinato, ma deve avvenire presto e spesso per essere efficace.