Di recente mi sono unito a un progetto di sviluppo e mi è stato improvvisamente affidato il compito di capo sviluppatore. La mia principale responsabilità è quella di suddividere la parte di programmazione del progetto in compiti, affidare questi compiti agli altri sviluppatori e quindi assicurarmi che i pezzi funzionino insieme.

Il problema però è che non ho idea di come farlo. Ho trascorso il mio fine settimana con carta e matita cercando di capirlo, ma continuo a presentare un elenco di compiti su cui lavorare in sequenza invece che in parallelo. Ho pensato forse di suddividerlo in funzionalità, ma poi si finisce con attività che richiedono la modifica degli stessi file, che potrebbero richiedere la completa riscrittura di un'intera attività a causa della fase iniziale di sviluppo. Potrei avere alcuni sviluppatori che aspettano che il programma sia un po 'più completo e più facile da creare per le attività, ma poi avrei persone a disposizione per chissà quante settimane.

Ho avuto una conversazione con il mio capo sulle mie qualifiche per farlo e non mi è stata data alcuna scelta in merito. Non ho idea di cosa sto facendo, quindi tutti i consigli e le indicazioni nella giusta direzione sarebbero molto apprezzati.

Una risposta adeguata alla tua domanda riempie diversi libri . Verrò con un elenco puntato di parole d'ordine che mi vengono in mente a riguardo, Google e i libri faranno il resto per te.

1. Nozioni di base

   • Non andare da solo . Cerca di coinvolgere il più possibile i tuoi compagni di squadra.
   • Viaggia leggero .
   • Democrazia, ma non troppo. A volte, non si tratta di ciò che soddisfa il maggior numero di persone, ma di ciò che fa male al minor numero di persone.
   • Tieni cosa (deve essere fatto) e come (è fatto) separato .
   • Informazioni su Scrum ("what"), XP (Extreme Programming, "how"), Kanban ("how much"), Lean ("what not") e DevOps ("with who").
   • Anche il flusso magro riguarda il flusso : per l'efficienza complessiva, l' efficienza del flusso è generalmente più importante dell'efficienza individuale.
   • Scopri di più sull'artigianato software , sul codice pulito e sulla programmazione pragmatica .
   • Una buona architettura consiste nel massimizzare il numero di decisioni non prese .
   • Scrum / XP / Lean / Agile significa massimizzare la quantità di lavoro non svolto : YAGNI .
   • Il valore primario del software è che puoi facilmente cambiarlo . Che faccia quello che dovrebbe fare è importante ma è solo il suo valore secondario.
   • Preferisci un approccio iterativo e incrementale , usa le finestre temporali per quasi tutto, in particolare gli incontri, fai della Parkinson la tua amica perché si applica la Legge di Hofstadter .
   • Equilibrare la struttura del team con una comprensione della legge di Conway e delle fasi di sviluppo del team di Tuckman .
   • La programmazione è una quaternità, è scienza , ingegneria , arte e artigianato allo stesso tempo, e quelli devono essere in equilibrio.
   • Solo perché Scrum / XP / XYZ è buono per qualcuno (incluso me) non significa necessariamente che sia buono per te / si adatta al tuo ambiente. Non seguire ciecamente l'hype, prima capiscilo.
   • Ispeziona e adatta! (Scrum Mantra)
   • Evita la duplicazione : una volta sola! (XP Mantra) aka DRY - Don't Repeat Yourself aka SPOT - Single Point of Truth

2. Processo di suddivisione del lavoro "What world"

   • Raccogliere i requisiti come storie utente / storie di lavoro in un portafoglio ordini di prodotti .
   • Utente (di User Story) simile ad Attore (in UML) simile a Persona simile a Ruolo .
   • Affina le storie degli utenti fino a quando non soddisfano la definizione di pronto del tuo team basata su INVEST (Indipendente, Negoziabile, Prezioso, Stimabile, Piccolo, Testabile). (Scrum Meeting: perfezionamento degli arretrati )
   • Ordina l' arretrato di prodotto per valore aziendale .
   • Non iniziare a lavorare su una Storia prima che sia Pronto (pronto in base alla definizione di pronto).
   • Usa Planning Poker per stimare lo sforzo delle Storie nei Punti Storia . Utilizzare il confronto triangolazione per garantire la coerenza delle stime.
   • Il tempo di ieri è la migliore stima, spero il peggio.
   • Dividi storie se sono troppo grandi.
   • Migliora la cultura della consegna con una definizione di fatto .
   • Non accettare l'implementazione di una User Story prima che sia Fatto (fatto secondo la Definizione di Fatto).
   • Più team sulla stessa base di codice dovrebbero concordare e condividere la stessa definizione di fatto (in particolare gli standard di codifica ).
   • Controlla i tuoi progressi con i grafici Burndown .
   • Controlla regolarmente con i tuoi stakeholder se ciò che il team offre è ciò che è realmente necessario. (Scrum Meeting: Sprint Review )

3. Storia

   • Elencare e descrivere utenti / personaggi / attori / ruoli (proprietario del prodotto)
   • Epico -> Storie (User Story o Job Story) (Product Owner)
   • Storia -> Criteri di accettazione (Product Owner)
   • Storia -> Sottoattività (Dev Team)
   • Criteri di accettazione -> Test di accettazione (Spec.: Product Owner, Impl: Dev Team)
   • Inizia con uno scheletro ambulante che è un End-to- (Half-End) minimalista .
   • Creare un MVP - Prodotto minimo valido .
   • Espandi l'MVP usando SMURFS - Set di funzionalità specificamente commerciabili, utili e rilasciabili .

4. Realizzazione "How world"

   • Usa le schede OOA / D , UML e CRC , ma evita il grande design in anticipo .
   • Implementare il più possibile orientato agli oggetti , strutturato e funzionale , indipendentemente dal linguaggio di programmazione.
   • Utilizzare il controllo versione (preferibilmente distribuito ).
   • Inizia con i test di accettazione .
   • Applica TDD , lasciando che le Tre Leggi del TDD ti guidino attraverso il ciclo del refattore rosso-verde , con una regola di asserzione singola , 4 A , GWT (data quando poi) da BDD .
   • " I test unitari sono test che funzionano velocemente ." - Michael Feathers
   • Applicare il SOLID e i principi del pacchetto per gestire l' accoppiamento e la coesione . Esempio: S in SOLID è SRP = Principio di responsabilità singola, riduce significativamente il numero di modifiche. unire conflitti nei team.
   • Conosci la legge di Demeter / Tell, Don't Ask .
   • Utilizzare l' integrazione continua , se applicabile anche la consegna continua (DevOps).
   • Utilizzare la proprietà del codice collettivo in base a uno standard di codifica comune concordato (che dovrebbe far parte della definizione di fatto ).
   • Applica il miglioramento continuo del design (refactoring continuo fka).
   • Il codice sorgente è il design . È ancora indispensabile pensare in anticipo e nessuno si opporrà ad alcuni buoni diagrammi UML chiarificatori.
   • XP non significa che nessun giorno è il giorno dell'architettura, significa che ogni giorno è il giorno dell'architettura. È un focus sull'architettura, non un defocus, e il focus è nel codice.
   • Mantieni basso il tuo debito tecnico , evita i quattro odori di design Fragilità , Rigidità , Immobilità e Viscosità .
   • L'architettura riguarda la logica aziendale, non i meccanismi di persistenza e consegna.
   • L'architettura è uno sport di squadra ( non esiste un 'io' in architettura ).
   • Modelli di progettazione , refactoring e premessa della priorità di trasformazione .
   • Il codice di progetto è l' ATP-Trinità con priorità: 1. Codice di automazione , 2. Codice di prova , 3. Codice di produzione .
   • Controlla regolarmente con i colleghi del tuo team se è possibile migliorare le prestazioni del team. (Scrum Meeting: Sprint Retrospective )
   • I test dovrebbero essere PRIMI : veloci, indipendenti, ripetibili, auto-validanti e tempestivi.

L'elenco sopra è certamente incompleto e alcune parti potrebbero anche essere discutibili!

Se tutto ciò ti spaventa, non preoccuparti, perché dovrebbe spaventarti! Realizzare progetti di sviluppo software in team non è un compito facile, e raramente le persone sono adeguatamente addestrate e istruite in questa arte. Se questo ti spaventa, il tuo intuito funziona correttamente, ascoltalo. Vuoi essere preparato. Parla con il tuo capo, prenditi del tempo e allenati.

Guarda anche

• Chi scrive le "storie degli utenti" tecniche nella mischia

Ulteriori letture (online)

• Portland Pattern Repository di Ward Cunningham et al
• Principi di OOD di Robert "Zio Bob" C. Martin
• Suggerimenti pratici per i programmatori

Ulteriori letture (libri)

• Codice pulito di Robert C. Martin
• Sviluppo software agile: principi, schemi e pratiche di Robert C. Martin
• The Pragmatic Programmer - Da Journeyman a Master di Andrew Hunt e David Thomas
• Lavorare efficacemente con Legacy Code di Michael Feathers
• Refactoring: migliorare la progettazione del codice esistente di Martin Fowler
• Refactoring to Patterns di Joshua Kerievsky
• The Ten Day MBA di Steven Silbiger (sic!)
• Design guidato dal dominio di Eric Evans
• Storie utente applicate da Mike Cohn
• Analisi e progettazione orientate agli oggetti con applicazioni di Gray Booch et al
• Design Patterns by the Gang of Four
• Test Driven Development di Kent Beck
• Programmazione estrema di Kent Beck
• [if Java] Java efficace di Joshua Bloch

Agile

Suggerirei quanto segue:

Modifica degli stessi file

Innanzitutto, usa Git (o un sistema di versioning simultaneo simile). Finché stai modificando parti diverse degli stessi file, non otterrai conflitti. Se si verificano conflitti, saranno chiaramente indicati come tali.

Cercare di gestire un progetto multi-sviluppatore senza Git è come provare a fare un budino senza una ciotola di budino. È possibile, ma diventerà piuttosto disordinato abbastanza velocemente.

Come è stato sottolineato nei commenti, Git non è una panacea, ma combinato con i test automatizzati aiuta sicuramente molto.

Elenca tutte le funzionalità

In secondo luogo, suddividere il progetto in funzioni visibili all'utente. Ad esempio "quando l'utente si registra, dovrebbe ricevere un'e-mail" o "L'utente può aggiungere un elemento". Coinvolgi tutte le parti interessate qui. Porta tutti in una stanza e chiedi a tutti di urlare le loro caratteristiche.

Queste dovrebbero essere funzionalità visibili all'utente, puoi parlare della strategia di implementazione in un secondo momento.

Scrivi tutti i suggerimenti sulle schede, anche quelle stupide. Razionalizza rapidamente l'elenco per rimuovere i duplicati e disponi tutte le carte su un grande tavolo o persino sul pavimento.

Aggiungi eventuali carte aggiuntive necessarie. Supponiamo che l'applicazione invierà avvisi di testo SMS. Potresti non sapere come farlo, quindi hai una domanda. Scrivi "Esamina portali SMS" su una scheda. Allo stesso modo per qualsiasi altra grande incognita. Dovrai decomprimere questi in seguito. Queste caratteristiche probabilmente non riusciranno a fare il tuo primo sprint.

Ora ordinare le carte in gruppi, mescolarle circa, ottenere un tatto per loro. Questo è lo scopo del tuo progetto.

Pianificazione del poker

Prova a pianificare il poker. Sempre con tutti insieme, dai a tutti gli sviluppatori le carte che dicono "1 punto", "2 punti", ecc., Fino a "4 punti". Anche una "più" carta. Un punto equivale all'incirca a un'ora.

Scorri l'elenco delle funzionalità uno per uno. Mentre leggi una funzione, tutti devono giocare una carta. Se una persona gioca 1, e un'altra persona gioca 4, c'è un problema di comunicazione lì. Una persona comprende la funzione per significare qualcosa di diverso dall'altra persona. Discuti e scopri cosa intendeva realmente e annotalo sulla carta.

Se si accetta che una funzione è un "altro", tale funzione è troppo grande. Devi rompere quella funzione. Fallo allo stesso modo di prima.

Come concordato, scrivi i numeri sulle carte con una penna di colore diverso.

I punti sono meglio delle ore

L'uso dei punti anziché delle ore toglie il macho "guarda quanto velocemente posso codificare" cosa in cui spesso noi sviluppatori ci impegniamo. È una differenza sottile, ma ho scoperto che funziona piuttosto bene.

Ora componi uno sprint

Uno sprint è un rapido scoppio verso un obiettivo. Decidi la durata dello sprint, forse 5 o 10 giorni. Moltiplicare il numero di giorni per il numero di sviluppatori per il numero di punti al giorno.

Assumi inizialmente 6 punti al giorno per sviluppatore. Questo è un numero raggiungibile. Se hai 5 persone, questo è 5 * 5 * 6 = 150 punti. In collaborazione con tutti gli sviluppatori e la gestione, seleziona le funzionalità dall'elenco, fino a 150 punti. Questo è il tuo sprint.

Non essere mai tentato di spremere più di quanto si adatterà. L'eccessiva promessa fa male a lungo termine a tutti, incluso te.

Dovrai tenere conto delle dipendenze qui. Ad esempio, l'installazione ambientale deve ovviamente essere inclusa nel primo sprint. Questo è in realtà relativamente facile da fare quando tutti sono presenti. Hai 6 cervelli nella stanza, tutti dicendo "questo dipende da questo", ecc. Puoi quindi mescolare le carte per dimostrare le dipendenze.

Una volta che hai lo sprint, non è possibile aggiungere nulla ad esso, è bloccato per i 5 giorni. Il creep stresserà la squadra, danneggerà il morale e rallenterà tutti. Alla fine, il creep bloccherà un progetto. Come capo squadra devi proteggere la tua squadra dallo scorrimento delle funzionalità. Se arriva una nuova richiesta di funzionalità, deve essere aggiunta allo sprint successivo. Se il prossimo sprint è già pieno, qualcos'altro deve essere eliminato.

Non essere mai tentato di spremere in extra. Una promessa eccessiva ti dà un cliente felice di circa 1 giorno, seguito da 4 giorni di stress del team e, probabilmente, molti clienti infelici quando il team non riesce a consegnare in tempo.

Adesso vai.

Distribuisci le carte, chiedi a chi vuole fare cosa. Hai piena visibilità su ciò che viene fatto e puoi contare i punti che scorrono fino a zero. Avere uno standup all'inizio di ogni giorno in modo che tutti sappiano chi sta lavorando su cosa e cosa è stato fatto.

5 o 6 sviluppatori decenti e motivati ​​che lavorano insieme come unità su obiettivi gestibili chiaramente definiti possono raggiungere una quantità piuttosto grande di cose in uno sprint di 5 giorni.

Mantieni visibilità

Assicurati che tutti possano vedere qual è lo stato del progetto. Bluetack tutte le carte sul muro. A sinistra ci sono carte che non sono ancora state lavorate. Sulla destra sono fatte le carte.

Quando uno sviluppatore sta lavorando su una carta, la toglie dal muro e la mette sulla propria scrivania. Ciò mantiene la visibilità e impedisce alle persone di calpestarsi troppo.

Esistono alternative tecnologiche alle schede, ma niente di meglio che avere un enorme display di carta dello stato del progetto sul muro.

Se possibile, avere tutti nella stessa stanza per la durata del progetto. Avere le parti interessate il più possibile, idealmente ogni giorno.

Bruciare

Puoi rappresentare graficamente i tuoi punti avanzando verso lo zero su un grafico di burndown. Se la tua linea di migliore adattamento attraversa lo zero prima di raggiungere il limite di tempo, sei probabilmente sulla buona strada. In caso contrario, potrebbe essere necessario informare il cliente ora, prima di avvicinarsi troppo alla scadenza.

Se fallirai, fallisci presto.

Puoi eseguire un burndown utilizzando il software, ma preferisco solo un grosso pezzo di carta sul muro. Disegna e scrivi dappertutto.

Test automatizzati

Quando hai più sviluppatori che lavorano sulle stesse cose allo stesso tempo, probabilmente si romperanno il codice a vicenda di volta in volta. La comunicazione e la visibilità aiutano in questo, ma probabilmente vorrai introdurre alcune tecnologie per aiutarti a trovare i problemi.

Il test unitario è il processo di scrittura dei test per ogni singola parte del tuo codebase (idealmente ogni metodo). I test unitari devono essere eseguiti spesso, con ogni salvataggio, se possibile. Ci sono molti strumenti che possono aiutarti in questo, ad esempio Karma o Rspec.

I test end-to-end prevedono il test del progetto nel suo insieme, trattando gli interni come una scatola nera. Basare questi test sui requisiti aziendali di alto livello, ad esempio: "L'utente può iscriversi" o "L'utente può visualizzare un elenco di articoli". Il goniometro è un bell'esempio di un framework di test basato sul web end-to-end.

Ci sono interi libri scritti sui test, ma avere almeno alcuni test di accettazione in atto può aiutare a assicurarsi che nulla si rompa mentre lavori al tuo progetto.

Evitare il debito tecnico e fare il proprio dovere

Il debito tecnico è un concetto che descrive cose che dovranno essere ripulite in seguito. Una fonte comune di debito sono le caratteristiche che sono state contrassegnate come completate, ma che non sono mai state "completate". Una funzionalità completata viene archiviata in Git, è stata approvata dalle parti interessate e ha un test.

Non disattivare le funzionalità fino a quando non sono state completate. Non massaggiare mai il grafico. Ancora una volta, questo a lungo termine fa male a tutti, incluso te.

Questo è uno dei motivi per cui inizialmente citiamo solo 6 punti per sviluppatore, al giorno. Il lavoro fatto richiede un lavoro extra, ma è fantastico e dà una spinta alla squadra.

La modifica degli stessi file non è di per sé un problema. È solo un problema se modifichi la stessa funzione per fare due cose diverse.

Fondamentalmente quello che vorrei fare è, dividere il progetto in "caratteristiche" che sono separate. Uno potrebbe essere qualcosa legato alla gestione del protocollo di rete e un altro a un file di configurazione, e ancora un altro alla gestione del DB. Le caratteristiche sono grandi cose.

Successivamente, si desidera dividere tali funzioni in attività (storie). Dovrebbero essere cose semplici, come "quando l'utente fa clic su un pulsante, il programma caricherà il file", "all'avvio del programma, caricherà il file di configurazione" ecc.

Alcune attività dovranno essere completate in sequenza ("il programma analizzerà tutti i campi nel file di configurazione" dovrà venire dopo "il programma caricherà il file di configurazione"). Altri no (puoi lavorare sul DB e sulla rete contemporaneamente).

Ma molto probabilmente, sbaglierai, ed è qui che entra in gioco l'esperienza. Fallirai solo un po '(o molto), sbaglierai le stime del tempo e il tuo progetto impiegherà un po' più di tempo di quanto dovrebbe. La prossima volta starai meglio.

Vorrei anche suggerire di leggere "Extreme Programming" di Kent Beck. Ottimo libro che mi ha aiutato quando stavo per diventare un project manager.

Ciò che si riduce è che è necessario suddividere l'applicazione in moduli funzionali e quindi introdurre contratti (interfacce e contratti dati) tra i diversi moduli. Ogni modulo può quindi essere consegnato a uno sviluppatore diverso. Quando rimetti tutto insieme i contratti assicureranno che questi moduli comunichino correttamente tra loro.

Assicurati di applicare TDD agli sviluppatori, al fine di garantire che tutti i moduli funzionino individualmente.

Per darti un esempio di cosa intendo:

Supponiamo che tu voglia che uno dei tuoi sviluppatori costruisca un logger SQL.

Definisci un'interfaccia e chiedi a uno dei tuoi sviluppatori ( o crei una storia se stai usando Agile ) che desideri un logger specifico per SQL in base alle seguenti specifiche:

interface ILogger
{
    void Log(string message, int level);
}

Quello che poi mi aspetto da uno sviluppatore è il seguente:

1. L'implementazione specifica di SQL per il logger

   class SqlLogger : ILogger
   {
       private readonly SqlLogRepository _logRepository;
   
       public SqlLogger(SqlLogRepository _logRepository)
       {
           this._logRepository = _logRepository;
       }
   
       public void Log(string message, int level)
       {
           _logRepository.CreateLog(message,level);
       }
   }

2. Qualsiasi codice dipendente, come un'implementazione per SqlLogRepository

3. Test di unità o simulazione a seconda di ciò che è stato richiesto. Un finto test nel caso sopra (dove abbiamo altre dipendenze esterne), o se si tratta ad esempio di una semplice funzione di utilità come String.ReverseCharacters(string input), allora mi piacerebbe semplicemente vedere unit test che testano alcuni scenari diversi.

Ciò significa che:

Ora tu e il tuo team potete continuare lo sviluppo usando questa interfaccia. per esempio

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

e se devi eseguire il tuo codice prima che SqlLoggersia attivo, puoi semplicemente creare un NullLogger:

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

Ed è così che potresti testarlo nel frattempo (suggerisco di guardare un ICO per l'iniezione di dipendenza)

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

Sommario

Non ho idea delle dimensioni del tuo progetto, ma questo potrebbe essere un compito piuttosto scoraggiante e se non hai mai guidato lo sviluppo prima, suggerirei di prendere questo compito molto sul serio e passare le prossime settimane a leggere quanto te possibile sulla progettazione e l'archiviazione del software. E sii molto trasparente sul tuo lavoro ( qualità del software, ecc. ) Altrimenti ti ritroverai rapidamente in un caos profondo da cui non sai come uscire.

Consiglio anche vivamente di leggere il design e il paradigma orientato agli oggetti. Per questo progetto farai molto affidamento su OOP.

Le altre risposte hanno parlato degli aspetti di programmazione, ma volevo solo menzionare l'aspetto di gestione del programma. Inizierò con una dichiarazione di non responsabilità: non sono un gestore di programmi. Ho seguito un corso a livello universitario per la gestione dei programmi e la mia esperienza lavorativa prevede ore di offerta per piccoli progetti che di solito sono inferiori a 500 ore e mai superiori a 1000 ore.

Ma ho dovuto aiutare a definire il compito per un laboratorio in cui dovevo tenere 2-3 persone occupate per 2-4 mesi (part-time e full time). Una cosa che mi ha davvero aiutato è stato l'utilizzo di software di project management come Microsoft Project (non sono sicuro che esista una versione freeware, ma il tuo datore di lavoro probabilmente ha qualcosa del genere ... chiedi al tuo supervisore che tipo di software di gestione del programma viene utilizzato presso la tua azienda). In particolare, uso un po 'i grafici di Gantt, che è la vista predefinita in Microsoft Project. Definendo tutti i compiti e quanto tempo pensi che impiegheranno, puoi ottenere una visualizzazione con cui giocare.

Il diagramma di Gantt mi aiuta di più a causa della sua visualizzazione. Vedere le attività su carta non mi aiuta molto, ma vedere delle belle immagini e un grafico sicuramente lo fa. Microsoft Project consente inoltre di impostare i predecessori e le date di inizio, con l'idea principale di "Trovare la quantità minima di attività necessarie per essere completata per l'avvio dell'attività X". Almeno nei miei piccoli progetti, la quantità di predecessori "reali" è piuttosto piccola. In effetti, in un progetto avevo il problema che quasi tutto poteva essere fatto contemporaneamente e dovevo sintetizzare due percorsi simultanei che erano in qualche modo coesi. Ad esempio, ho cercato di assicurarmi che se lo sviluppatore A avesse mai toccato la GUI, avrebbero lavorato anche su attività vicine alla GUI.

Sembra che tu stia facendo molto di questo già per quanto riguarda carta e penna, ma trovo sempre molto utile vedere effettivamente le carte di Gantt. Osservare le attività in sequenza in sequenza mi fa davvero pensare "Aspetta, l'attività X deve davvero essere eseguita prima dell'attività Y? (Nella mia esperienza finora, sono rimasto sorpreso da quanto spesso la risposta è in realtà 'no')"

Sembra che ti sia laureato da sviluppatore a ingegnere del software. Comprendi che la gestione del lavoro non è un esercizio di progettazione, ma i due vanno di pari passo. Devi gestire il lavoro svolto e questo dipende da come la tua azienda fa lo sviluppo. Se hai il tempo e le risorse, osserva l'adozione di una metodologia agile: ci sono montagne di materiale scritto su Internet. Trova quello che funziona per te, ma tieni presente che, come tutto il resto, non è gratuito. L'adozione di qualsiasi tecnica comporta l'addestramento, l'apprendimento e il fallimento prima che tu abbia successo. Se non si dispone della larghezza di banda per gestire l'adozione di una tecnica più completa, la pianificazione delle pietre miliari potrebbe essere la risposta per te. Se si dispone di un elenco di attività sequenziali, è possibile che non siano state trovate sequenze in grado di farloessere parallelizzato. Potrebbe anche essere il caso in cui desideri segmentare il tuo sviluppo in attività più generali come test e implementazione. Questo da solo non risolve il problema di segnalazione, ma stai gestendo la qualità. La tua progressione può essere un elenco sequenziale, ma i tuoi ruoli sono paralleli. Solo un suggerimento. Un progetto che si associa al lavoro svolto dalle persone è chiamato struttura di suddivisione del lavoro.

Ci sono molti buoni suggerimenti che altre persone hanno offerto, ma ricorda che stai gestendo il lavoro. A volte puoi mappare i concetti di lavoro nel design / architettura, a volte non puoi farlo così facilmente. C'è sempre un modo per strutturare il lavoro in modo che sia tracciabile. Suggerisco di tornare dal tuo manager e chiedergli cosa è importante per lui quando si tratta di comunicare lo stato del progetto. Questo inizierà a dirti come affrontare ciò che stai facendo. Se è pianificato, ti consigliamo di concentrarti sull'avanzamento dei rapporti. Se è di qualità, allora vuoi riferire su una serie di metriche che dovrai inventare. Se i suoi costi, probabilmente vorrai guardare lo sforzo. Tutte queste cose possono anche essere mappate all'interno o all'esterno delle attività.