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

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 non ambiguo. Se non lo hai, le tue stime saranno errate. Avere questo documentato in una specie di caratteristica specifica prima che qualcuno inizi a scrivere il codice significherà che tutte le domande che devono essere poste saranno poste prima che inizi la codifica. Questo è un salvatempo sorprendentemente efficace. Tornando indietro e chiarendo i requisiti, si interrompe il proprio flusso come programmatore e le risposte in attesa possono bloccare il progresso.

Una volta identificato il requisito necessario per identificare le attività lavorative necessarie per risolverlo. Questo è un classico esercizio di divisione e conquista: qualsiasi attività che può essere ulteriormente suddivisa deve essere ulteriormente suddivisa.

In una squadra più ampia 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ù ristretto, ma è comunque utile ottenere una stima indipendente da entrambi i tuoi sviluppatori e magari includerne anche una da te- la tua mancanza di esperienza specifica può essere utile qui perché ti spiega cosa il compito coinvolge dal loro punto di vista, il team di sviluppo probabilmente coglierà meglio il problema.

Con un team più piccolo può aiutare a ottenere una stima migliore / prevista / peggiore per ogni attività, che ti dà una gamma di valori, ma se stai ricevendo molte stime di sovraccarico, puoi inclinare verso il caso peggiore fino a quando i tuoi sviluppatori non impareranno 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 tenere conto per quello. Scopri quanto tempo impiegano i tuoi sviluppatori a lavorare sulle nuove funzionalità e a tenerne conto nelle stime. Se un'attività è stimata in 2 giorni, ma i tuoi sviluppatori sono in grado di lavorare su nuovi sviluppi solo il 60% delle volte, avrai 4 giorni per il completamento. Potresti essere in grado di aiutarti anche controllando la pipeline di altre attività che devono essere gestite in modo tale che le attività di amministrazione o di supporto non urgenti possano essere raggruppate insieme piuttosto che essere gestite su una base ad hoc. Molti programmatori (sicuramente incluso me stesso su questo) non sono grandi manager del tempo, quindi qualsiasi cosa tu possa fare per dare una mano in questo senso ti aiuterà. Il single-tasking è sempre più facile per i programmatori rispetto al multi-tasking. Anche bloccare il tempo durante il giorno può aiutare in questo.

Mantieni 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 aumentare le proprie stime durante la pianificazione eb) per aiutarli a perfezionare le proprie capacità di stima. Alla fine di ogni iterazione (o qualsivoglia equivalente hai) l'intero team dovrebbe rivedere il lavoro svolto e capire perché è stato necessario più tempo del previsto per poterlo incorporare nelle stime future. Questo deve essere un compito irreprensibile - sembra che tu abbia l'atteggiamento giusto qui ma questa risposta potrebbe essere intorno un po 'quindi farò l'osservazione. Se qualcuno dice "Ho fatto un errore qui", puoi trasformarlo in "cosa avresti potuto fare meglio", ma dire alla gente che erano troppo lenti o sbagliare non fa che peggiorare le cose.

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

What is the reason for [their estimate of 2 days taking 8 days], is this common for programmers?

È, se:

• In realtà non è chiaro cosa dovrebbero fare, quindi impiegano più tempo a farlo correttamente (e dovrebbero quindi dirlo, non indovinare quanto tempo ci vorrà)
• Non hanno familiarità con l'attività in corso (quindi dovrebbero menzionarlo e includere la ricerca nel preventivo)
• L'integrazione dell'attività completata 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 mentre l'attività viene implementata, richiedendo un approccio diverso e la ripetizione del lavoro già eseguita
• Gli sviluppatori non lavorano in un ambiente produttivo (quindi quando a casa pensano che ci vorranno due giorni, ma al lavoro ne richiederanno otto per compensare tutte le distrazioni)

Per nominare alcune cose.

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

Non saresti il primo di un lungo periodo a cercare di capire il modo migliore per pianificare il tempo di sviluppo. Questo è in parte dovuto al fatto che è difficile quantificare qualcosa che non si può effettivamente vedere essere costruito, e in parte a causa del mitico man-month , che è un contrasto diretto con l'idea intuitiva che se hai 2 programmatori, dovresti essere in grado di svilupparsi due volte più velocemente rispetto a un programmatore.

Come probabilmente hai già capito, è molto più complicato di così. Un approccio per stimare il tempo di sviluppo come arrotondare un gruppo di individui altamente qualificati per quanto riguarda lo sviluppo del software e chiedere loro di stimare il tempo necessario per completare un progetto (spiegando il più dettagliato possibile). Prendi il massimo da tutte le stime e raddoppia . Sì, hai letto correttamente. Tu raddoppia la 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 mi serve per fare qualcosa. Raccolgo le opinioni dei miei colleghi programmatori e il mio e raddoppiamo la stima più alta. Se questo sembra un valore troppo alto, considera che testare nuove funzionalità è fondamentale e prendere in considerazione potenziali correzioni di bug in seguito, e sembrerà una cifra più ragionevole.

Nella mia personale esperienza di programmatore, posso dirti che aiuta a trasformare i progetti in pietre miliari. Quanto tempo ci vuole per raggiungere milestone 1, quindi da milestone 1 a milestone 2, quindi milestone 2 a milestone 3, ecc.? Quando viene analizzato in questo modo, la risposta è in genere molto più accurata rispetto alla tentazione di stimare l'intero progetto nella sua interezza. Stranamente, se riassumi le stime di tutte queste pietre miliari, di solito sarà più grande della stima originale dell'intero progetto (se il programmatore è onesto con se stesso comunque), 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 le svolte che occupano tutto il tempo nello sviluppo di un programma. Quindi, molto probabilmente, maggiore è la funzionalità che desideri includere, più il programma diventerà complicato e, supponendo che questa nuova funzionalità non abbia alcuna influenza sulle sezioni del codice precedentemente implementate, lo sviluppo sarà lineare in base alla quantità di lavoro da eseguire. essere fatto. Molto probabilmente, la nuova funzionalità pesante influenza le sezioni precedentemente implementate e quindi lo sviluppo implica non solo l'implementazione della nuova funzionalità, ma la correzione del vecchio codice, rendendo esponenziale il tempo di sviluppo.

Il mio consiglio a voi sarebbe, senza dire ai programmatori come fare il loro lavoro, cercare di capire come funziona il programma a livello generale e dovreste essere presto in grado di vedere come la nuova funzionalità potrebbe modificare quel comportamento e quindi fornire una stima ragionevole su quanto tempo ci vorrà per farlo. Combina questo con le loro stime (il doppio del massimo) e inizi a farti un'idea migliore di come stimare il tempo di sviluppo.

Spero che ti aiuti!

Una delle ragioni 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 rompere i grandi passi in quelli 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 gioca, presiede la riunione.
• Il Product Manager fornisce una breve panoramica. Al team viene data l'opportunità di porre domande e discutere per chiarire ipotesi e rischi. Un riassunto della discussione è registrato dal Project Manager.
• Ogni individuo depone a faccia in giù una carta che rappresenta la sua stima. Le unità utilizzate variano - possono essere giorni di durata, giorni ideali o punti della storia. Durante la discussione, i numeri non devono essere menzionati affatto in relazione alle dimensioni della feature per evitare l'ancoraggio.
• Tutti chiamano le loro carte contemporaneamente girandole sopra.
• Le persone con stime elevate e stime basse ricevono una scatola di sapone per offrire la loro giustificazione per la loro stima e quindi la discussione continua.
• Ripeti il processo di stima fino a raggiungere un consenso. Lo sviluppatore che probabilmente possiede il deliverable ha una larga parte del "consenso", sebbene il Moderatore possa negoziare il consenso.
• Viene utilizzato un timer per uova per garantire che la discussione sia strutturata; il Moderatore o il Project Manager possono in qualsiasi momento girare il timer dell'uovo e quando si esaurisce tutte le discussioni devono cessare e viene giocato un altro giro di poker. La struttura nella conversazione viene reintrodotta dalle soap box.

I bit importanti qui sono chiarificazione, discussione, chiamata simultaneamente la stima, così come non viene introdotto alcun pregiudizio e consenso.

PERT

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

• tempo più ottimistico per finire (se si verificano meno problemi del previsto)
• tempo più pessimistico per finire (se tutto va storto - escludendo catastrofi gravi)
• molto probabilmente il tempo di finire (se tutto va come previsto) < - questo è quanto probabilmente stimano i tuoi sviluppatori in questo momento

Ponderando queste tre stime ottieni 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 potrebbe riflettere ancora di più l'incertezza del mondo reale. Distribuzione beta e Distribuzione triangolare sono scelte importanti. Usando questo puoi ora applicare statistiche come "quanto è probabile che finisca alla data x data la stima attuale" o "se voglio la certezza del 95%, in quel momento sarà finito".

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

È un dato di fatto che se non stai mantenendo le metriche storiche, non puoi neanche avvicinarti a dare stime ragionevoli con un ragionevole grado di accuratezza. E chiedere a qualche altra compagnia / persona quanto tempo vorrà prenderli non aiuta neanche loro. 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à tempi diversi per eseguire esattamente lo stesso compito.

La cosa migliore da fare è 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 le funzionalità, altre semplicemente provano una sensazione istintiva. Inoltre, devi tener conto anche se questo è simile a qualcosa che gli sviluppatori hanno già costruito o qualcosa di nuovo, come la nuova tecnologia, una nuova funzione mai creata prima dal team, ecc ... Inoltre, se è integrata o reale- sistema temporale quindi la complessità generalmente aumenta un po '.

A meno che non raccolgano dati reali, indipendentemente dal numero di volte in cui i tuoi sviluppatori ti hanno fatto delle stime, tireranno davvero dei numeri da dietro ogni volta che li chiedi. Sì, raccogliere dati reali è un problema e in un primo momento non fornisce molte informazioni utili, ma nel tempo inizia a fornire stime ragionevolmente accurate.

Vorrei anche sottolineare che le stime sono generalmente valide solo per il quadro generale e non per le misurazioni a breve termine. Ad esempio, lo sviluppatore stima 2 giorni ma ne occorrono 8. Bene, lo sviluppatore non ha tenuto conto dell'impostazione di un ambiente di test e dello sviluppo di un simulatore o della presenza di una tecnologia completamente nuova che hanno dovuto apprendere o sono rimasti bloccati su un bug non potevano capire o la funzionalità richiedeva 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ù potrebbero essere sbiaditi da altre attività che richiedono una durata inferiore di 6 giorni.

Sono stato un unico sviluppatore su alcuni piccoli progetti e ho avuto esperienze industriali lavorando con una grande squadra. Ho notato che le tecniche utilizzate da una grande azienda non necessariamente funzionano per una piccola squadra. 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 una visione approfondita) 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 - Un ottimo programma per tenere traccia delle storie e incoraggia ad abbattere i compiti, è un fulmine veloce nell'inserire storie e deduce automaticamente la velocità. link .

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

-A un'azienda che ero solito lavorare per un incontro per ogni singola storia che abbiamo iniziato, questo incontro doveva includere un programmatore esperto, dal momento che sarebbe stato più bravo a giudicare la durata di un compito. Sarebbe anche più bravo a giudicare quale potrebbe essere la parte difficile in un compito.

In sintesi, credo che la chiave per lavorare in piccoli gruppi sia quella di avere un solido piano di pianificazione veloce e fluido. Inoltre, qualsiasi difficoltà con la storia può essere identificata in anticipo in modo che la pianificazione di un compito possa tenerlo a mente (ciò potrebbe portare alla costruzione di qualcosa di diverso).

Spero che questo aiuti