Quali sono i modi per mitigare gli effetti di Mythical Man Month?

Legge di Brooks: l' aggiunta di manodopera a un recente progetto software lo rende più tardi.

Nel suo libro No Silver Bullet - Essence and Accidents of Software Engineering Frederick Brooks definisce il concetto di Mythical Man Month :

L'ipotesi di Brooks è che progetti di programmazione complessi non possano essere perfettamente suddivisi in compiti discreti su cui lavorare senza comunicazione tra i lavoratori e senza stabilire una serie di complesse interrelazioni tra compiti e lavoratori che li eseguono .

Dal 1982 siamo sicuramente andati avanti e abbiamo acquisito un po 'più di esperienza nel mitigare questo problema. Quali sono alcune delle soluzioni che hai applicato con successo sul tuo lavoro per aggiungere risorse a un progetto senza creare più problemi.

Cos'è l'MMM

Innanzitutto voglio spiegare il contesto della legge di Brook. Qual è stato il presupposto che lo ha portato a crearlo nel 1975?

Un mese-uomo è un'ipotetica unità di lavoro che rappresenta il lavoro svolto da una persona in un mese; La legge di Brooks afferma che è impossibile misurare il lavoro utile in mesi-uomo.

^{fonte: https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

Ai giorni nostri, complessi progetti di programmazione avrebbero significato grandi sistemi monolitici. E Brooks afferma che questi non possono essere perfettamente suddivisi in compiti discreti su cui è possibile lavorare senza comunicazione tra gli sviluppatori e senza stabilire una serie di complesse interrelazioni tra i compiti e le persone che li svolgono.

Questo è molto vero nei monoliti software altamente coesivi. Indipendentemente dalla quantità di disaccoppiamento, il grande monolito richiede ancora tempo per i nuovi programmatori per conoscere il monolito. E un overhead di comunicazione aumentato che consumerà una quantità sempre crescente del tempo disponibile.

Ma deve essere davvero così? Dobbiamo scrivere monoliti e mantenere i canali di comunicazione n(n − 1) / 2dov'è nil numero di sviluppatori?

Sappiamo che ci sono aziende in cui migliaia di sviluppatori stanno lavorando a grandi progetti ... e funziona. Quindi ci deve essere qualcosa che è cambiato dal 1975.

Possibilità di mitigare MMM

Nel 2015 PuppetLabs e IT Revolution hanno pubblicato i risultati del Rapporto 2015 sullo stato di DevOps . In quel rapporto, si sono concentrati sulla distinzione tra organizzazioni ad alte prestazioni e non ad alte prestazioni.

Le organizzazioni ad alte prestazioni mostrano alcune proprietà inaspettate. Ad esempio, hanno le migliori prestazioni in scadenza del progetto in fase di sviluppo. Migliore stabilità operativa e affidabilità nelle operazioni. Così come il miglior track record di sicurezza e conformità.

Una delle cose sorprendenti evidenziate nel rapporto è la metrica delle distribuzioni al giorno. Ma non solo le distribuzioni al giorno, hanno anche misurato deploy / day / developer e qual è l'effetto dell'aggiunta di più sviluppatori in organizzazioni ad alte prestazioni rispetto alle prestazioni non elevate.

Questo è il grafico di quel rapporto -

Mentre le organizzazioni a basso rendimento si allineano alle ipotesi del Mese dell'uomo mitico. Le organizzazioni ad alte prestazioni possono ridimensionare il numero di deploy / day / dev in modo lineare con il numero di sviluppatori.

Un'eccellente presentazione a DevOpsDays London 2016 di Gene Kim parla di questi risultati.

Come farlo

Innanzitutto, come diventare un'organizzazione ad alte prestazioni? Ci sono un paio di libri che parlano di questo, non abbastanza spazio in questa risposta, quindi mi limiterò a collegarmi a loro.

• Buono a grande: perché alcune aziende fanno il salto ... e altre no di Jim Collins
• The High-Velocity Edge: come i leader di mercato sfruttano l'eccellenza operativa per battere la concorrenza di Steven Spear
• The New Economics for Industry, Government, Education di W. Edwards Deming

Per le organizzazioni software e IT, uno dei fattori critici per diventare un'organizzazione ad alte prestazioni è: attenzione alla qualità e alla velocità .

Ad esempio Ward Cunningham spiega il debito tecnico come tutte le cose che ci hanno permesso di rimanere non risolte. Questo è accettato dalla direzione perché ha sempre la promessa che verrà risolto quando c'è tempo.

Non c'è mai abbastanza tempo e il debito tecnico peggiora sempre di più.

Quali sono queste cose che fanno crescere il debito tecnico?

• codice legacy
• configurazione manuale degli ambienti
• test manuale
• distribuzioni manuali

Codice legacy Come definito in Lavorare in modo efficace con il codice legacy di Michael Feathers è un codice che non ha test automatizzati.

Ogni volta che vengono utilizzate scorciatoie per portare il codice in produzione; le operazioni sono gravate dal mantenimento di questo debito per sempre. Quindi il processo di distribuzione diventa sempre più lungo.

Gene racconta una storia nella sua presentazione di un'azienda che ha distribuzioni di sei settimane. Coinvolgere decine di migliaia di passaggi noiosi estremamente inclini all'errore, legando 400 persone, e lo farebbero quattro volte all'anno.

Uno dei principi di DevOps è che l'affidabilità deriva dal fare piccole implementazioni più frequentemente.

Esempio

• Jon Jenkins a Velocity 2011 : Amazon sta eseguendo 15.000 distribuzioni / giorno
• Ken Exner all'AWS Summit 2015 : Amazon sta eseguendo 136.000 distribuzioni / giorno

Queste due presentazioni mostrano tutto ciò che Amazon ha fatto per ridurre il tempo impiegato per distribuire il codice in produzione.

Secondo Gene, l'unica cosa che è cambiata nel tempo in queste organizzazioni ad alte prestazioni è il numero di sviluppatori. Quindi, dall'esempio di Amazon, si potrebbe dire che in quattro anni hanno aumentato le loro implementazioni dieci volte semplicemente aggiungendo più persone.

Ciò significa che, in determinate condizioni, con la giusta architettura, le pratiche tecniche giuste, le norme culturali giusti, la produttività degli sviluppatori possono scalare come il numero di sviluppatori è aumentato. E DevOps è decisamente nel mezzo di tutto questo.

Quello che ho fatto (e questo è solo soggettivo) è il seguente:

Quando un manager che pensa a una data di scadenza desidera aggiungere persone nel mio team per ridurre il tempo necessario e sembra sotto MMM, per prima cosa discuto con lui sul perché questo potrebbe essere negativo. La mia analogia preferita per questo è ricordare loro che se una donna può avere un bambino in nove mesi, nove donne non avranno un bambino in un mese, ma avranno nove bambini in nove mesi. Il tempo non è ridotto, solo l'elaborazione parallela è migliore.

Quando la decisione viene forzata sul nostro team, di solito proviamo a dividere ulteriormente alcune attività e quando ciò non è possibile di solito facciamo affidamento sulla programmazione di coppia , in cui un programmatore è responsabile della digitazione e l'altro detta il codice (e cambia periodicamente ).

La scrittura del codice in sé è più lenta, ma ci sono meno errori di battitura / linting e bug durante i test a causa dell'inevitabile revisione fatta durante la scrittura. Ritengo che anche la qualità complessiva del codice sia leggermente migliore, ma non ho metriche per supportare tale affermazione.

Parlando esclusivamente dal punto di vista della CI, l'aumento del numero di sviluppatori che lavorano su un progetto si traduce in genere in più persone che lavorano nello stesso ramo.

I sistemi di CI tradizionali presentano un problema di scalabilità a questo proposito: la probabilità di rotture / regressioni / blocchi aumenta il rallentamento della velocità di integrazione e invita i team più piccoli a staccarsi e passare alle filiali secondarie (vale a dire ulteriori rallentamenti). Vedi In che modo l'integrazione continua può essere scalata per progetti / team di grandi dimensioni? . Questo si svolge proprio secondo il concetto del Mese dell'uomo mitico.

La soluzione che suggerisco nella mia risposta a questa domanda, un sistema di CI altamente scalabile consentirebbe la migrazione verso un vero CI - integrazione basata su singolo ramo / trunk per interi team più grandi (anche con dimensioni enormi).

Con tutti gli utenti della stessa pagina, utilizzando gli stessi strumenti / processi automatizzati e la stragrande maggioranza delle verifiche di controllo qualità automatizzate all'interno del sistema CI stesso, diventa molto più semplice cambiare ruolo e concentrarsi tra i membri del team. L'intero processo di sviluppo diventa più fluido, più prevedibile, più rilassato.

Portare a bordo nuove persone in un tale ambiente, renderle produttive semplicemente scaricando compiti meno difficili dai membri del team più esperti che possono quindi assumere quelli più difficili è quindi più facile.

Tutto ciò, a mio avviso, può essere visto come un effetto calmante degli effetti concettuali di Mythical Man Month.