Ho bisogno di questo bambino tra un mese: mandami nove donne!

In quali circostanze - se del caso - l'aggiunta di programmatori a un team accelera effettivamente lo sviluppo di un progetto già in ritardo?

Le circostanze esatte sono ovviamente molto specifiche per il tuo progetto (ad es. Team di sviluppo, stile di gestione, maturità del processo, difficoltà della materia, ecc.). Per chiarire meglio questo aspetto, in modo da poterne parlare in tutto tranne che in ampie semplificazioni, riaffermerò la tua domanda:

In quali circostanze, se del caso, l'aggiunta di membri del team a un progetto di sviluppo software in esecuzione in ritardo può comportare una riduzione della data di spedizione effettiva con un livello di qualità pari a quello se il team esistente fosse autorizzato a lavorare fino al completamento?

Ci sono un certo numero di cose che ritengo necessarie , ma non sufficienti, perché ciò avvenga (in nessun ordine particolare):

• Le persone proposte da aggiungere al progetto devono avere:
  • Almeno una ragionevole comprensione del dominio problematico del progetto
  • Essere competenti nella lingua del progetto e nelle tecnologie specifiche che utilizzerebbero per i compiti che verrebbero assegnati
  • La loro competenza deve / non / essere molto inferiore o molto maggiore del membro esistente più debole o più forte, rispettivamente. I membri deboli prosciugheranno il tuo personale esistente di problemi terziari mentre una nuova persona troppo forte interromperà il team di come tutto ciò che hanno fatto e stanno facendo è sbagliato.
  • Avere buone capacità comunicative
  • Essere altamente motivati ​​(ad es. Essere in grado di lavorare in modo indipendente senza stimoli)
• I membri del team esistenti devono avere:
  • Eccellenti capacità di comunicazione
  • Eccellenti capacità di gestione del tempo
• Il responsabile / gestione del progetto deve avere:
  • Buone capacità di assegnazione delle priorità e di assegnazione delle risorse
  • Un alto livello di rispetto da parte dei membri del team esistenti
  • Eccellenti capacità di comunicazione
• Il progetto deve avere:
  • Una specifica di progettazione software valida, completa e documentata
  • Buona documentazione delle cose già implementate
  • Un design modulare che consente di ritagliare chiari pezzi di responsabilità
  • Processi automatici sufficienti per la garanzia della qualità per il livello di difetto richiesto Questi potrebbero includere elementi quali: unit test, test di regressione, implementazioni automatizzate di build, ecc.)
  • Un sistema di tracciamento di bug / funzionalità attualmente in atto e in uso dal team (ad es. Trac, SourceForge, FogBugz, ecc.).

Una delle prime cose che dovrebbero essere discusse è se la data di spedizione può essere cambiata, se le caratteristiche possono essere tagliate e se alcune combinazioni delle due ti permetteranno di soddisfare il rilascio con il tuo personale esistente. Molte volte si tratta di un paio di funzionalità che stanno realmente sfruttando le risorse del team che non offriranno un valore pari all'investimento. Quindi dai una priorità alle priorità del tuo progetto prima di ogni altra cosa.

Se il risultato del paragrafo precedente non è sufficiente, visitare l'elenco sopra. Se hai preso in anticipo la schedina, l'aggiunta dei membri giusti del team al momento giusto potrebbe salvare il rilascio. Sfortunatamente, più ti avvicini alla data di spedizione prevista, più cose possono andare storte con l'aggiunta di persone. Ad un certo punto, attraverserai il "punto di non ritorno" in cui nessuna quantità di modifica (diversa dalla spedizione del ramo di sviluppo corrente) può salvare la tua versione.

Potrei andare avanti all'infinito, ma penso di aver toccato i punti principali. Al di fuori del progetto e in termini di carriera, il futuro successo dell'azienda, ecc. Una delle cose che dovresti assolutamente fare è capire perché eri in ritardo, se qualcosa avrebbe potuto essere fatto avvisandoti prima e quali misure hai bisogno da prendere per prevenirlo in futuro. Un progetto in ritardo si verifica di solito perché eri:

• Erano in ritardo prima di iniziare (più cose del tempo) e / o
• scivolato 1 ora, 1 giorno alla volta.

Spero che aiuti!

Aiuta solo se hai un progetto guidato dalle risorse.

Ad esempio, considera questo:

Devi dipingere un grande poster, diciamo 4 per 6 metri. Un poster così grande, probabilmente puoi mettere due o tre persone davanti e farli dipingere in parallelo. Tuttavia, mettere 20 persone davanti non funzionerà. Inoltre, avrai bisogno di persone qualificate, a meno che tu non voglia un poster schifoso.

Tuttavia, se il tuo progetto è quello di riempire le buste con lettere pronte per la stampa (come You MIGHT hai vinto! ) Allora più persone aggiungi, più veloce va. C'è un certo sovraccarico nel distribuire pile di lavoro, quindi non puoi ottenere benefici fino al punto in cui hai una persona. busta, ma puoi ottenere benefici da molto più di 2 o 3 persone.

Quindi, se il tuo progetto può essere facilmente diviso in piccoli pezzi e se i membri del team possono accelerare rapidamente (come ... istantaneamente), quindi aggiungere più persone lo farà andare più veloce, fino a un certo punto.

Purtroppo, non molti progetti sono così nel nostro mondo, motivo per cui il consiglio di Docgnome sul libro Mythical Man-Month è davvero un buon consiglio.

Forse se si applicano le seguenti condizioni:

1. I nuovi programmatori comprendono già il progetto e non hanno bisogno di alcun tempo di accelerazione.
2. I nuovi programmatori sono già competenti con l'ambiente di sviluppo.
3. Non è necessario tempo amministrativo per aggiungere gli sviluppatori al team.
4. Non è richiesta quasi alcuna comunicazione tra i membri del team.

Ti farò sapere la prima volta che vedo tutti questi in una volta.

Secondo il Mythical Man-Month, la ragione principale per cui le persone vengono aggiunte a un progetto in ritardo è che in seguito è il sovraccarico di comunicazione O (n ^ 2).

Ho sperimentato un'eccezione principale a questo: se c'è solo una persona in un progetto, è quasi sempre condannato. L'aggiunta di un secondo lo accelera quasi ogni volta. Questo perché la comunicazione non è sovraccarica in quel caso - è un'opportunità utile per chiarire i tuoi pensieri e fare meno errori stupidi.

Inoltre, come ovviamente sapevi quando hai pubblicato la tua domanda, i consigli del Mythical Man-Month si applicano solo ai progetti in ritardo . Se il tuo progetto non è già in ritardo, è possibile che l'aggiunta di persone non lo farà in seguito. Supponendo che tu lo faccia correttamente, ovviamente.

Se i programmatori esistenti sono totalmente incompetenti, può essere utile aggiungere programmatori competenti.

Posso immaginare una situazione in cui tu avessi un sistema molto modulare e il / i programmatore / i esistente / i non fosse nemmeno partito su un modulo molto isolato. In tal caso, potrebbe essere utile assegnare solo quella parte del progetto a un nuovo programmatore.

Fondamentalmente i riferimenti al Mese dell'uomo mitico sono corretti, tranne in casi inventati come quello che ho inventato. Brooks ha svolto solide ricerche per dimostrare che dopo un certo punto, i costi di rete e di comunicazione derivanti dall'aggiunta di nuovi programmatori a un progetto supereranno tutti i vantaggi che si ottengono dalla loro produttività.

• Se le nuove persone si concentrano sui test
• Se riesci a isolare funzionalità indipendenti che non creano nuove dipendenze
• Se è possibile ortogonalizzare alcuni aspetti del progetto (in particolare attività non di codifica come progettazione / layout visivi, ottimizzazione / indicizzazione del database o impostazione del server / configurazione della rete) in modo che una persona possa lavorarci su mentre gli altri proseguono con il codice dell'applicazione
• Se le persone si conoscono, la tecnologia, i requisiti aziendali e il design, abbastanza bene da essere in grado di fare le cose con una conoscenza di quando si calpesteranno e come evitare di farlo (questo, ovviamente, è piuttosto difficile organizzare se non è già il caso)

Solo quando hai in quella fase avanzata alcune attività indipendenti (quasi lo 0% di interazione con altre parti del progetto) non ancora affrontate da nessuno e puoi portare nel team qualcuno che è uno specialista in quel dominio. L'aggiunta di un membro del team deve ridurre al minimo l'interruzione per il resto del team.

Invece di aggiungere programmatori, si può pensare di aggiungere aiuto amministrativo. Tutto ciò che rimuoverà le distrazioni, migliorerà la concentrazione o migliorerà la motivazione può essere utile. Ciò include sia il sistema che l'amministrazione, oltre a cose più prosaiche come pranzare.

Ovviamente ogni progetto è diverso, ma la maggior parte dei lavori di sviluppo può garantire una certa collaborazione tra gli sviluppatori. In questo caso, la mia esperienza è stata che risorse fresche possono effettivamente rallentare involontariamente le persone su cui fanno affidamento per renderle più veloci e in alcuni casi possono essere le persone chiave (di solito sono le persone "chiave" che prenderebbero il tempo di educare un newb). Quando sono pronti, non ci sono garanzie che il loro lavoro si adatti alle "regole" o alla "cultura del lavoro" stabilite con il resto del team. Quindi, di nuovo, può fare più male che bene. A parte questo, queste sono le circostanze in cui potrebbe essere utile:

1) La nuova risorsa ha un compito stretto che richiede un minimo di interazione con altri sviluppatori e un set di abilità che è già stato dimostrato. (ad es. il porting del codice esistente su una nuova piattaforma, il refactoring esterno di un modulo morto attualmente bloccato nella base di codice esistente).

2) Il progetto è gestito in modo tale da poter condividere il tempo degli altri membri del team più anziano per aiutare ad accelerare il novizio e guidarlo lungo il percorso per garantire che il suo lavoro sia compatibile con ciò che è già stato fatto.

3) Gli altri membri del team sono molto pazienti.

Suppongo che l'aggiunta di persone verso la fine del lavoro potrebbe accelerare le cose se:

1. Il lavoro può essere svolto in parallelo.

2. La quantità risparmiata dalle risorse aggiunte è maggiore della quantità di tempo persa facendo in modo che le persone con esperienza nel progetto spieghino cose a coloro che non hanno esperienza.

EDIT: ho dimenticato di menzionare, questo genere di cose non succede troppo spesso. Di solito è roba abbastanza semplice, come le schermate dell'amministratore che fanno un semplice CRUD a un tavolo. Al giorno d'oggi questi tipi di strumenti possono comunque essere per lo più generati automaticamente.

Fai attenzione ai manager che si affidano a questo tipo di lavoro da distribuire però. Sembra fantastico, ma in realtà di solito non è abbastanza per tagliare un significativo periodo di pausa dal progetto.

• Moduli autonomi che devono ancora essere avviati
• In mancanza di strumenti di sviluppo che possono integrare (come un gestore di build automatizzato)

In primo luogo sto pensando a cose che li lasciano fuori dal modo in cui le persone si stanno sviluppando. Sono d'accordo con Mythical Man-Month, ma penso anche che ci siano eccezioni a tutto.

Penso che l'aggiunta di persone a un team possa accelerare un progetto più che aggiungerli al progetto stesso.

Incontro spesso il problema di avere troppi progetti simultanei. Uno di questi progetti potrebbe essere completato più rapidamente se potessi concentrarmi solo su quel progetto. Aggiungendo membri del team, ho potuto passare ad altri progetti.

Ovviamente, questo presuppone che tu abbia assunto sviluppatori capaci e auto-motivati, che sono in grado di ereditare grandi progetti e apprendere in modo indipendente. :-)

Se la risorsa extra completa il tuo team esistente, può essere l'ideale. Ad esempio, se stai per configurare l'hardware di produzione e verificare che il database sia effettivamente ottimizzato anziché restituire solo buoni risultati (che il tuo team conosce come esperti di dominio) impiegando tempo da un buon dba che lavora al progetto successivo ai tuoi puoi velocizzare la squadra senza costi di allenamento eccessivi

In poche parole. Si tratta di confrontare il tempo rimanente e la produttività che si otterrà da qualcuno, escludendo il tempo impiegato dalle risorse aggiuntive per accelerare, essere produttivi e sottrarre il tempo investito nell'insegnare loro dalle risorse esistenti. I fattori chiave (in ordine di significato):

1. Quanto è brava la risorsa a raccoglierla. I migliori sviluppatori possono accedere a un nuovo sito ed essere produttivi correggendo i bug quasi istantaneamente con poca assistenza. Questa abilità è rara ma può essere appresa.
2. La segregabilità dei compiti. Devono essere in grado di lavorare su oggetti e funzioni senza inciampare sugli sviluppatori esistenti e rallentarli.
3. La complessità del progetto e della documentazione disponibile. Se si tratta di un'applicazione ASP.Net di best practice vaniglia e di scenari aziendali ben documentati comuni, un buon sviluppatore può rimanere bloccato immediatamente. Questo fattore più che altro determinerà quanto tempo le risorse esistenti dovranno investire nell'insegnamento e quindi l'impatto negativo iniziale delle nuove risorse.
4. La quantità di tempo rimanente. Anche questo è spesso mal valutato. Spesso la logica sarà che ci restano solo x settimane e ci vorranno x + 1 settimane per velocizzare qualcuno. In realtà il progetto sta per scivolare e in effetti mancano 2 settimane allo sviluppo e ottenere più risorse prima che dopo aiuterà.

Laddove un team è già utilizzato per accoppiare la programmazione, l'aggiunta di un altro sviluppatore che è già esperto nell'associazione potrebbe non rallentare il progetto, in particolare se lo sviluppo procede con uno stile TDD.

Il nuovo sviluppatore diventerà lentamente più produttivo man mano che comprenderanno di più la base di codice e qualsiasi malinteso verrà colto molto presto dalla loro coppia o dalla suite di test che viene eseguita prima di ogni check-in (e idealmente dovrebbe esserci un controllo almeno ogni dieci minuti).

Tuttavia, è necessario tenere conto degli effetti delle spese generali di comunicazione aggiuntive. È importante non diluire troppo la conoscenza esistente del progetto.

L'aggiunta di sviluppatori ha senso quando la produttività fornita dagli sviluppatori aggiuntivi supera la produttività persa durante la formazione e la gestione di tali sviluppatori.