Il modo migliore per pianificare la programmazione per piccoli team? [chiuso]

Sono il direttore di una piccola organizzazione di avvio. Al momento abbiamo due programmatori (uno esperto, uno meno esperto) che stanno costruendo una piattaforma di applicazioni web.

Una delle maggiori sfide finora è il processo di pianificazione. I programmatori di solito sono incaricati di pianificare il proprio lavoro, ma continuiamo a superare le scadenze imposte. Ad esempio, un'attività che stimano richiederà 2 giorni, per finire 8 giorni.

Per me è difficile supportarli nella pianificazione, poiché mi manca il know-how tecnico per stimare con precisione la durata di un determinato compito.

Hai qualche idea:

1. Qual è la ragione di ciò, è comune per i programmatori?
2. Cosa posso fare per supportarli nella pianificazione? Esistono metodi o strumenti utili ai programmatori in piccoli team?

Le tecniche generali sono in qualche modo di buon senso, la cosa importante da sapere è che non richiedono molta competenza tecnica.

Il punto di partenza con la pianificazione è identificare il problema esatto che deve essere risolto e avere un requisito chiaro e inequivocabile. Se non lo possiedi, le tue stime saranno errate. Avere questo documentato in una sorta di specifica delle caratteristiche prima che chiunque inizi a scrivere codice significherà che tutte le domande che devono essere poste saranno state poste prima dell'inizio della codifica. Questo è un risparmio di tempo sorprendentemente efficace. Tornare indietro e chiarire i requisiti interrompe il flusso come programmatore e attendere risposte può bloccare i progressi.

Dopo aver identificato il requisito, è necessario identificare le attività lavorative necessarie per risolverlo. Questo è un classico esercizio di divisione e conquista: ogni compito che può essere ulteriormente suddiviso deve essere ulteriormente suddiviso.

In una squadra più grande puoi usare il poker di stima per ottenere una stima basata sull'esperienza di tutti i soggetti coinvolti. Ciò non funziona altrettanto bene in un team più piccolo, ma è comunque utile ottenere una stima indipendente da entrambi i tuoi sviluppatori e magari includerne uno anche da te stesso - la tua mancanza di competenze specifiche può essere utile qui perché nello spiegarti cosa il compito implica dal loro punto di vista, il team di sviluppo probabilmente afferrerà meglio il problema.

Con un team più piccolo può aiutare a ottenere una stima del migliore / previsto / peggiore caso per ogni attività, che ti dà una gamma di valori, ma se stai ottenendo molte stime di superamento, puoi inclinarti verso il caso peggiore fino a quando i tuoi sviluppatori imparare a stimare in modo più accurato.

In un piccolo negozio, gli sviluppatori finiscono spesso per raddoppiare come amministratori di sistema, team di supporto e persino tester (anche se di tutte le cose che potrebbero fare, il test è quello che dovresti cercare di evitare a tutti i costi), quindi devi tenerne conto. Scopri quanto tempo impiegano gli sviluppatori a lavorare su nuove funzionalità e includilo nelle tue stime. Se un'attività è stimata in 2 giorni ma i tuoi sviluppatori sono in grado di lavorare su un nuovo sviluppo solo il 60% delle volte, avrai bisogno di 4 giorni per completarlo. Potresti essere in grado di aiutarti anche controllando la pipeline di altre attività che devono gestire in modo che le attività di amministrazione o supporto non urgenti possano essere raggruppate un po 'insieme piuttosto che essere gestite su base ad hoc. Molti programmatori (certamente incluso me stesso in questo) non sono grandi gestori del tempo, quindi tutto ciò che puoi fare per dare una mano in questo senso sarà di aiuto. Il single-tasking è sempre più facile per i programmatori rispetto al multi-tasking. Anche bloccare il tempo durante il giorno può essere d'aiuto.

Conserva un record : ogni volta che hai una sessione di pianificazione, registra le stime e gli effettivi. È quindi possibile utilizzare questo a) come guida per quanto gonfiare le proprie stime durante la pianificazione eb) per aiutarli a perfezionare le proprie capacità di stima. Alla fine di ogni iterazione (o qualsiasi equivalente tu abbia) l'intero team dovrebbe rivedere il lavoro svolto e capire perché ci è voluto più tempo del previsto in modo che questo possa essere incorporato nelle stime future. Questo deve essere un compito irreprensibile - sembra che tu abbia l'atteggiamento giusto qui, ma questa risposta potrebbe essere in giro un po ', quindi farò l'osservazione. Se qualcuno dice "Ho fatto un errore qui", puoi trasformarlo in "cosa avresti potuto fare di meglio", ma dire alla gente che erano troppo lenti o che sbagliavano non farebbe che peggiorare le cose.

Non sono a conoscenza di proiettili d'argento per questo tipo di problema, ma il fattore più importante è la comunicazione, che in realtà è più facile con un team più piccolo, e l'utilizzo del feedback per affinare le tue capacità collettive.

Qual è il motivo di [la loro stima di 2 giorni che richiede 8 giorni], è comune per i programmatori?

È se:

• In realtà non è chiaro cosa dovrebbero fare, quindi impiegano più tempo a farlo bene (e dovrebbero quindi dirlo, non indovinare quanto tempo ci vorrà)
• Non hanno familiarità con il compito da svolgere (quindi dovrebbero menzionarlo e includere la ricerca nel preventivo)
• L'integrazione dell'attività finita con il prodotto più grande richiede più tempo del previsto (il che potrebbe significare che l'architettura del prodotto è inferiore)
• Lo sviluppatore ama reinventare la ruota, e così facendo inciampa su problemi che sono stati risolti da altri, disponibili gratuitamente in una libreria
• Le modifiche vengono introdotte dal proprietario del prodotto durante l'implementazione dell'attività, che richiede un approccio diverso e la ripetizione del lavoro già svolto
• Gli sviluppatori non lavorano in un ambiente produttivo (quindi quando a casa pensano che occorrerebbero due giorni, ma al lavoro ne richiederanno otto per compensare tutte le distrazioni)

Per citare alcune cose.

Forse è meglio chiedere ai tuoi sviluppatori perché pensano che le loro stime siano lontane. :-)

Non saresti il ​​primo di una lunga serie a cercare di capire il modo migliore per pianificare i tempi di sviluppo. Ciò è in parte dovuto al fatto che è difficile quantificare qualcosa che non si può effettivamente vedere in costruzione, e in parte a causa del mitico mese-uomo , che è in diretto contrasto con l'idea intuitiva che se si hanno 2 programmatori, si dovrebbe essere in grado di svilupparsi due volte più velocemente rispetto a un programmatore.

Come probabilmente avrai già capito, è molto più complicato di così. Un approccio per stimare i tempi di sviluppo è quello di arrotondare un gruppo di persone altamente qualificate per ciò che riguarda lo sviluppo del software e chiedere loro di stimare il tempo necessario per completare un progetto (spiegando il più dettagliatamente possibile). Prendi il più alto di tutte le stime e tu raddoppi . Sì, hai letto correttamente. È doppiola stima più alta e avrai una stima ragionevolmente accurata. Lo so, perché con il tempo, è così che sono stato in grado di dire con precisione ai miei capi quanto tempo ci vuole per fare qualcosa. Raccolgo le opinioni dei miei colleghi programmatori e dei miei e raddoppio la stima più alta. Se questo sembra un valore troppo elevato, considera che testare nuove funzionalità è cruciale e in seguito considera possibili correzioni di bug e sembrerà una cifra più ragionevole.

Nella mia esperienza personale come programmatore, posso dirti che aiuta a scomporre i progetti in pietre miliari. Quanto tempo ci vuole per raggiungere il traguardo 1, quindi dal traguardo 1 al traguardo 2, quindi il traguardo 2 al traguardo 3, ecc.? Se suddivisa in questo modo, la risposta è in genere molto più accurata rispetto al tentativo di stimare l'intero progetto nella sua interezza. Stranamente, se si sommano le stime di tutte queste pietre miliari, di solito sarà più grande della stima originale sull'intero progetto (se il programmatore è comunque onesto con se stesso), il che mi porta solo a pensare che il dettaglio sia la chiave Qui.

Forse ti manca il know-how tecnico, ma dovresti comunque provare a seguire un livello più generale. I programmatori non hanno problemi con la ripetizione. Sono i colpi di scena che occupano tutto il tempo nello sviluppo di un programma. Quindi molto probabilmente, più funzionalità si desidera includere, più complicato diventerà il programma e supponendo che questa nuova funzionalità non abbia influenza su sezioni del codice implementate in precedenza, lo sviluppo sarà lineare in base alla quantità di lavoro da svolgere essere fatto. Molto probabilmente, le nuove funzionalità influenzano fortemente le sezioni implementate in precedenza e quindi lo sviluppo comporta non solo l'implementazione delle nuove funzionalità, ma anche la correzione del vecchio codice, rendendo esponenziale il tempo di sviluppo.

Il mio consiglio per te sarebbe di, senza dire ai programmatori come fare il loro lavoro, provare a capire come funziona il programma a livello generale e presto dovresti essere in grado di vedere come le nuove funzionalità potrebbero modificare quel comportamento e quindi fornire una stima ragionevole del tempo necessario per farlo. Combina questo con le loro stime (il doppio del più alto) e inizi a farti un'idea migliore su come stimare i tempi di sviluppo.

Spero che aiuti!

Uno dei motivi per cui le stime sono spesso lontane è perché la stima è in realtà piuttosto difficile e richiede esperienza e conoscenza del sistema da modificare. Molto spesso è utile suddividere i grandi passi in più piccoli.

Ora hai molte possibilità di quelle che menzionerò due:

• Pianificazione del poker
• PERT (tecnica di valutazione e revisione del programma)

Pianificazione del poker

Funziona abbastanza bene in piccoli team agili.

Estratto da Wikipedia:

• Un moderatore, che non giocherà, presiede l'incontro.
• Il Product Manager offre una breve panoramica. Il team ha l'opportunità di porre domande e discutere per chiarire ipotesi e rischi. Un riassunto della discussione è registrato dal Project Manager.
• Ogni individuo pone una carta coperta che rappresenta la sua stima. Le unità utilizzate variano - possono essere la durata dei giorni, i giorni ideali o i punti della storia. Durante la discussione, i numeri non devono essere menzionati affatto in relazione alla dimensione della caratteristica per evitare l'ancoraggio.
• Tutti chiamano le loro carte contemporaneamente girandole.
• Le persone con stime alte e stime basse ricevono una scatola di sapone per offrire la loro giustificazione per la stima e poi la discussione continua.
• Ripetere il processo di stima fino a raggiungere un consenso. Lo sviluppatore che probabilmente possedeva il risultato finale ha una larga parte del "voto di consenso", sebbene il Moderatore possa negoziare il consenso.
• Un timer uovo viene utilizzato per garantire che la discussione sia strutturata; il Moderatore o il Project Manager possono in qualsiasi momento capovolgere il timer delle uova e quando si esaurisce ogni discussione deve cessare e si gioca un altro giro di poker. La struttura nella conversazione viene reintrodotta dalle scatole di sapone.

I bit importanti qui sono il chiarimento, la discussione, la chiamata simultanea della stima, in modo da non introdurre alcun pregiudizio e il consenso.

PERT

Spesso è difficile dare una stima esatta. Ciò che è più facile è dare una probabilità. PERT utilizza 3 valori per la stima:

• il tempo più ottimistico per finire (se sorgono meno problemi del previsto)
• il tempo più pessimistico per finire (se tutto va storto - escluse le grandi catastrofi)
• molto probabilmente il tempo di finire (se tutto va come previsto) <- questo è ciò che i tuoi sviluppatori stimano molto probabilmente in questo momento

Ponderando queste tre stime si ottiene una stima più affidabile.

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

E / o sei in grado di utilizzare questi tre valori per costruire una distribuzione di probabilità che possa riflettere ancora di più l'incertezza del mondo reale. La distribuzione beta e la distribuzione triangolare sono scelte importanti. Usando questo puoi ora applicare statistiche come "quanto è probabile che finisca alla data x date le stime attuali" o "se voglio il 95% di certezza, in quale momento sarà finito".

In realtà PERT consiste in più di questi aspetti citati qui, che ho omesso per brevità.

È un dato di fatto che se non si mantengono metriche storiche non si può nemmeno avvicinarsi a fornire stime ragionevoli con un ragionevole grado di accuratezza. E chiedere ad un'altra compagnia / persona quanto tempo impiegherà non aiuta neanche. Il problema è che ogni azienda e sviluppatore ha il proprio modo di fare le cose. Pertanto, ogni azienda avrà tempi diversi per svolgere esattamente lo stesso compito. Ogni sviluppatore avrà diversi periodi di tempo per svolgere esattamente lo stesso compito.

Il miglior modo di agire è iniziare a tenere traccia del tempo e in qualche modo capire come classificare il grado di difficoltà per l'attività. Alcune aziende usano linee di codice, alcune usano funzionalità, altre semplicemente sono fatte di buon gusto. Inoltre, devi anche tener conto se questo è simile a qualcosa che gli sviluppatori hanno già costruito o qualcosa di nuovo, come una nuova tecnologia, una nuova funzionalità mai creata prima dal team, ecc ... Inoltre, se è un prodotto incorporato o reale- il sistema temporale quindi la complessità generalmente aumenta un po '.

A meno che tu non raccolga dati reali, non importa quante volte i tuoi sviluppatori ti diano delle stime che tireranno davvero numeri da dietro ogni volta che lo chiedi. Sì, la raccolta di dati reali è una seccatura e all'inizio non fornisce molte informazioni utili, ma col tempo inizia davvero a fornire stime ragionevolmente accurate.

Vorrei anche sottolineare che le stime sono generalmente buone solo nel quadro generale e non per misurazioni a breve termine. Ad esempio, lo sviluppatore stima 2 giorni ma ci vogliono 8. Beh, lo sviluppatore non ha tenuto conto della necessità di impostare un ambiente di test e sviluppare un simulatore o che c'era una tecnologia completamente nuova che dovevano imparare o sono rimasti bloccati su un bug non sono riusciti a capire o la funzionalità ha richiesto un refactoring del sistema esistente. Non è sempre possibile prevedere questo tipo di cose per piccoli compiti. Tuttavia, nel corso di un intero progetto quei 6 giorni in più possono essere slavati da altre attività che richiedono una durata in meno di 6 giorni.

Sono stato uno sviluppatore unico di alcuni piccoli progetti e ho una certa esperienza industriale lavorando con un grande team. Ho notato che le tecniche utilizzate da una grande azienda non funzionano necessariamente per un piccolo team. A un certo punto stavo facendo più pianificazione e documentazione piuttosto che scrivere codice. Ti suggerisco di provare a trovare un buon modo di lavorare prima provando diverse tecniche (le altre risposte forniscono alcune informazioni approfondite) e strumenti, questo ti costerà un po 'di tempo e fatica ma ne trarrai beneficio in seguito. Alcuni strumenti / tecniche che ho trovato utili sono:

-Pivotal Tracker - Ottimo programma per tenere traccia delle storie e incoraggia a rompere le attività, si alleggerisce rapidamente quando si inseriscono le storie e deduce automaticamente la velocità. https://www.pivotaltracker.com/ .

-Gdocs per la documentazione in quanto è facile avere più utenti che modificano e discutono allo stesso tempo.

-All'azienda in cui lavoravo per una volta avevamo un incontro per ogni storia che avevamo iniziato, questo incontro doveva includere un programmatore senior poiché sarebbe stato più bravo a giudicare quanto tempo avrebbe richiesto un compito. Sarebbe anche migliore nel giudicare quale potrebbe essere la parte difficile in un compito.

In sintesi, credo che la chiave per lavorare in piccoli gruppi sia avere un solido regime di pianificazione che sia veloce e fluido. Inoltre, eventuali difficoltà con la storia possono essere identificate in anticipo in modo che la pianificazione di un'attività tenga conto di ciò (questo potrebbe portare a costruire qualcosa di diverso).

Spero che sia di aiuto