Quanto tempo dedicherò alla pianificazione degli sprint, ecc.? [chiuso]

Penso che dipenda molto dalla natura e dallo stato attuale del progetto:

Ottimista: Tutti i nuovi (5) sviluppatori che si uniscono al team provengono da domini simili e immediatamente affollano le sfide nelle funzionalità che si stanno creando. Dal momento che capisci il dominio e l'architettura (e il progetto non è troppo grande), puoi facilmente rispondere alle domande senza estrarre le sessioni della lavagna ecc. Inoltre il sistema è scritto molto bene (usando TDD) e completamente documentato.

pessimistica: Nel corso degli anni, il sistema è stato costruito da diversi team e ogni team pensava di seguire la loro pratica migliore. Ciò significa che il codice base ora ha diverse strategie per risolvere problemi simili. Inoltre, la gestione del progetto fino ad ora si è concentrata sull'espansione rapida di nuove funzionalità, quindi il debito tecnico si è accumulato. Inoltre, il collaudo delle unità è sempre stato un ripensamento. In aggiunta, il dominio è molto di nicchia e tutti i nuovi sviluppatori avranno bisogno di una formazione approfondita prima che comprendano parti del dominio.

Quindi, nello scenario ottimistico, probabilmente potresti codificare a fianco dei nuovi sviluppatori abbastanza rapidamente. L'unico problema principale sono le personalità e i comportamenti di lavoro quando la squadra si trasforma in un'unità coesa. In uno scenario pessimistico, essendo il collegamento principale sia per il dominio (business) che per l'architettura (tecnica) si avranno conversazioni estese e si scrivono molte voci o documentazione wiki.

Probabilmente puoi vedere dove sta andando, qualcosa come "Spero per il meglio, piano per il peggio" .

Essendo stato in una situazione simile in passato, direi che non dovresti pianificare sul codice per almeno 4-6 mesi. Assumersi la responsabilità sia dell'architettura che del business link per un grande progetto può essere molto lavoro (anche per una squadra di 5). Questo non significa che non si stia codificando affatto. Tuttavia, i tempi di codifica dovrebbero essere interrotti frequentemente da persone che fanno domande. (Potresti voler esaminare aspetti come Tecnica Pomodoro ecc.

Ok, ora un altro paio di cose con il cappello pessimistico mio . :)

Il tuo manager dice che ci vorrà solo il 10% del tuo tempo. Quindi, ciò equivale approssimativamente a 4 ore a settimana. Se è così, perché il tuo manager non gestisce solo il progetto? Probabilmente perché lui o lei sa che finirà per prendere più tempo allora.

Come sviluppatori, IMO, tendiamo a sottovalutare gravemente la buona gestione. Ora, SCRUM è lungi dall'essere perfetto, ma c'è una ragione per cui 2 dei 7 lavori a tempo pieno vanno alla gestione (controllore e proprietario del prodotto).

Ci sono molte cose da considerare nel determinare questa roba:

• stime: queste devono sempre essere bottom-up - se fai un approccio user story, pensa di avere una riunione regolare con il tuo team e le PMI a un certo punto verso la fine di ogni sprint per aggiornare il backlog del prodotto con stime per un numero sufficiente di user story per coprire i prossimi diversi sprint. Immagina una riunione di 2-3 ore per questo nei primi sprint, magari scendendo ad un'ora negli sprint successivi.
• attività amministrative: prova a diffondere (diffondere) il dolore il più possibile, delegare se possibile, magari facendo fare a X un membro del team diverso da ogni sprint. Avere una task board che il team può aggiornare durante ogni sprint.
• enforcement: ovvero, assicurarsi che il team stia aiutando con le stime e aggiornando la task board. Questo richiederà più tempo per iniziare, quindi diventerà banale.
• allenamento / tutoraggio: devi fare tutto ciò di cui ha bisogno la squadra. È molto difficile giudicare da un estraneo.
• rimuovere gli ostacoli: questo può essere un lavoro a tempo pieno, a seconda. Il tuo manager ti sta aiutando?

Quindi, dovresti probabilmente far sapere al tuo manager che inizialmente, trascorrerai il 25-50% del tuo tempo a fare marciare il flusso regolare del progetto, insieme a un po 'di tempo di addestramento / tutoraggio. Spero che, dopo un paio di mesi, questo sarà ridotto al 10-15%. La vera domanda diventa quindi il supporto che otterrete rimuovendo gli ostacoli che il team incontra. Se sei da solo lì, non farai alcun codice.

Ero un architetto di software che passò ad essere un proprietario di un prodotto tecnico per un team. Nella mia esperienza, avevo bisogno di passare un buon 25% del mio tempo o più lavorando strettamente come proprietario del prodotto. Ci è voluto un bel po 'di tempo per fare il lavoro giusto, e quando non l'ho fatto, ha influito sul team.

Alcune settimane ho trascorso il 50% del mio tempo, o più. È difficile dirlo con certezza, perché ho anche fatto l'architetto - questo mi ha permesso di ritagliare le normali riunioni di OP / Architetto da quando mi sono appena incontrata. Tra essere l'architetto ed essere il PO, raramente ho trascorso più di 6-8 ore di codifica a settimana.

Non dimenticare che governare l'arretrato e tenerlo aggiornato prende tempo reale e richiede un reale pensiero. Non è solo un piccolo lavoro in più che devi fare. Inoltre, anche la preparazione per le dimostrazioni di sprint e le retrospettive richiede tempo reale. Per me, nei giorni dimostrativi il mio tempo è stato del 100% speso per attività non codificanti e il giorno prima di un buon 50% -75% o più.

Quindi, ecco un po 'di prove aneddotiche che dicono che dovrai impiegare almeno un quarto del tuo tempo, e possibilmente di più a seconda della tua organizzazione, della tua squadra e del prodotto che stai costruendo.

Come altri hanno affermato, ci sono molti fattori al lavoro qui. Credo che mi piacerebbe iniziare cercando di fare una lista di quelli che penso influenzeranno maggiormente il tuo tempo:

• Dove la tua azienda traccia le linee per la gestione dei progetti? Ad esempio, il tuo manager è una qualche forma di project manager che ti aspetti di essere pesantemente coinvolto nella gestione del progetto o tutto ciò che ti riguarda? Più sono coinvolti, meno tempo potresti dover spendere - fino a un certo punto. Il fatto che il tuo manager pensi che questo richiederà solo il 10% del tuo tempo mi sembra una delle tre cose: 1) comunica indirettamente il suo livello di coinvolgimento - che sarebbe piuttosto un po ', 2) è nuovo al ruolo di manager e potrebbe non comunicare aspettative realistiche, o 3) sta cercando di scaricare il lavoro da te e questo è il suo modo di convincerti.
• Quanto è ben definito il progetto? Se si sta aderendo al progetto con requisiti ben ponderati in mano, è molto diverso da quello di aderire agli stadi iniziali. Chi gestisce il documento dei requisiti? Se sei tu o qualcuno della tua squadra e non il tuo manager o un'altra persona, è una buona cartina tornasole delle aspettative per te e il tuo team.
• Quanto è decisivo il cliente? Quanto sono bisognosi? Alcuni clienti (se questo è un progetto esterno) possono essere piuttosto bisognosi e richiedere molto tempo. Anche in questo caso torna anche a come la gestione è divisa nella vostra azienda. Su una nota simile ...
• Quanti diversi clienti sono coinvolti nel progetto? Se è solo la tua azienda e il cliente, fantastico. Ma se ci sono altre entità come, ad esempio, un'azienda di progettazione esterna, preparatevi a molto più churn di comunicazione.
• La dimensione finale della squadra è più di altre cinque? Un team guidato nel mio posto di lavoro segue la regola generale che tende a passare al tempo di gestione quasi del 100% una volta che ha almeno quattro persone nella sua squadra. Per me probabilmente sarebbe circa l'80% con quattro, ma ciò dipende in gran parte anche dalla tua squadra, quindi prendi quello ...
• Quanto sono esperti le persone che ti stanno unendo? Se qualcuno è nuovo, il mio istinto dice che il 10% del tempo per ogni nuovo noleggio dovrebbe essere messo da parte per almeno alcuni mesi. Per nessuno direttamente fuori dalla scuola, prendi quel 20-25% a persona.

Quindi rivedere da un livello elevato. L'agile gestione del progetto non richiede molto tempo, ma personalmente ritengo altamente improbabile che sia tutto ciò che farai in questo ruolo. Ho il sospetto che sarai anche un leader che aiuta il mentore e guida la tua squadra oltre che possibilmente un collegamento con il cliente. Quindi la gestione agile del progetto potrebbe essere fatta in circa il 10% del tempo (anche se almeno il 15% sembra più ragionevole). Ma per il team dirigere una parte da sola, aspettati dal 25 al 75% del tempo a seconda delle circostanze. Per il collegamento con i clienti, questo è estremamente variabile in base al tuo coinvolgimento e può essere qualsiasi cosa, dal 10% a quasi un lavoro a tempo pieno. Nel complesso, trovo il suggerimento del tuo manager del 10% come una risposta lowball. Valuta attentamente la domanda n. 1 e agisci di conseguenza.

Se questa è la tua prima opportunità di avere la possibilità di guidare, ti consiglio di prenderla. Penso che molti tecnici (ma certamente non tutti!) Siano sorpresi da quanto a loro piace il ruolo di protagonista tecnico - so che pensavo di volermi nascondere in una grotta e codice ma la realtà è che ho scoperto di essere una squadra portare ad essere un'esperienza fantastica.

È possibile che ci vorrà solo il 5%.

Sto basandomi sulla mia esperienza in una configurazione seguente: sprint di 2 settimane, la pianificazione richiede mezza giornata, demo + retro richiedono metà della giornata, scrums giornalieri - 15 minuti ciascuno, revisione completa del codice. Tutto ciò che faresti comunque come membro di una squadra, quindi non dovremmo contarli. Qui ci sono cose che differenziano la tua posizione da semplici senior:

• prepararsi per la pianificazione (assicurarsi che il backlog sia in buono stato, con tutti i campi compilati, stampare le carte, fissare una sala riunioni, riunire tutti) - circa 2 ore
• riempire la lavagna dopo aver pianificato (ristampare le carte, preparare il diagramma di burn-down) - circa 1 ora
• preparati per la demo - quasi senza tempo, puoi fare in modo che tutti preparino la sua parte.

E un paio di cose che dovresti stimare:

• interagire con il proprietario del progetto, il supporto, i designer, ecc. In scrum prefetto lo fai direttamente solo sulla pianificazione e dimostrazione e usa il backlog del progetto tutto il tempo. In pratica occasionalmente parlerai con loro durante lo sprint.

• proteggere il tuo team da manager, supporto e proprietario del progetto. Idealmente, questi ragazzi non dovrebbero interromperti durante lo sprint, ma lo faranno, quindi devi ascoltarli e chiedere loro di aggiungere qualsiasi cosa di cui parlano al backlog o aggiungere una nuova attività urgente alla tua scheda.

Entrambe le cose diventano facili e non richiedono molto tempo una volta che hai educato tutti a rispettare il tuo processo.