Come acquisire pratica personale nelle metodologie di sviluppo dei pesi massimi?

Is there a way a small number of people could simulate engineering a whole big project on a small scale in a short time (one day)?

Sì, questo è possibile in una certa misura. Circa 10 anni fa ho preso parte a un seminario alla conferenza OOP a Monaco di Baviera, dove a 16 persone è stato affidato il compito di fare un'analisi approssimativa e progettare un software per piccole imprese. La prima metà della giornata si è concentrata principalmente sulla ricerca di una struttura di team per risolvere il problema con 16 persone e la seconda metà della giornata si è concentrata sulla risoluzione del compito con questo team.

Durante la prima parte siamo stati guidati a dividere le 16 persone in gruppi di quattro. Ogni squadra di quattro persone ha dovuto elaborare suggerimenti per la struttura del team (sotto la pressione del tempo), successivamente è stato applicato un processo di shoot-out per prendere una decisione sulla struttura del team che potrebbe essere la migliore e dovrebbe essere utilizzata per la seconda parte del workshop .

Sfortunatamente, nonostante la prima parte, abbiamo commesso l'errore di provare a dare a ciascuna delle 16 persone un posto di lavoro all'interno della struttura del team prevista. Questo errore porta al caos nella seconda metà - perché 16 persone sono troppo per risolvere un simile compito. Una soluzione di lavoro potrebbe essere stata quella di dividere nuovamente le 16 persone in squadre più piccole, o scegliere 3 o 4 persone per fare il lavoro principale, ma nella foga del momento abbiamo perso la vista.

Ho ancora l'impressione di aver imparato molto sui problemi tipici che si possono incontrare in organizzazioni di progetto più grandi quel giorno. Non so dove puoi visitare questo tipo di laboratorio da qualche parte vicino a te, o chi offre una cosa del genere al giorno d'oggi, ma se ne hai la possibilità, consiglio vivamente di frequentarlo.

Inizia con un lista di controllo . (Sapevi che era il primo passo, giusto?)
Assicurarsi che l'elenco di controllo elenchi tutta la documentazione standard per il progetto corrente. vale a dire. Diagramma UML, specifiche funzionali, disegni di alto livello e di basso livello, ecc ... L'ingegnere dei sistemi in me suggerirà di utilizzare un RTVM (matrice di verifica della tracciabilità dei requisiti)

Scegli un programma di esempio su cui lavorare. Se non riesci a trovare uno, google "code katas" o controllare l'archivio di sfide codejam di Google. O semplicemente costruisci una calcolatrice. : -)

Costruisci le specifiche funzionali per il tuo programma di esempio. Quindi spostati nel design di alto livello, nel diagramma UML, ecc.. Costruiscilo sulle specifiche. Provalo. Ogni volta che trovi un difetto significativo nelle tue specifiche (come definito dalle tue attuali pratiche di lavoro), allora devi tornare a quello stadio dell'SDLC e rivederlo prima di andare avanti di nuovo.

Per il tuo primo turno, vai avanti e tienilo piccolo. Ciclare attraverso il processo è più importante dell'overkill in ogni particolare fase. Per i round successivi, aggiungi le funzionalità che hai interrotto. Tracciamento, registrazione, analisi delle prestazioni, scaffold di test, ecc. Ciò che vorrete aggiungere dipenderà da ciò che il vostro datore di lavoro si aspetta per il vostro vero lavoro.

Dopo aver iterato più volte il ciclo design / build / test / repeat, avrai acquisito abilità ed esperienza nei componenti "pesanti" che ti preoccupano ora. Le iterazioni mostreranno anche l'interconnessione tra le varie fasi e la documentazione generata. La preziosa lezione è che mostra come un cambio di codice di 5 minuti può avere un effetto di ripple su più ore altrove a causa degli aggiornamenti dei documenti e dei requisiti di test.

L'esperienza con le pratiche "pesanti" viene solo dal fare la cosa vera. Non c'è modo di praticarlo efficacemente in isolamento. Puoi, tuttavia, studiarlo. Ci sono molti casi di studio e fonti che puoi studiare e meditare.

Tuttavia, non tutte le pratiche che vedi o studi sono necessariamente positive. Lo sviluppo del software è una cosa fluida, e quello che sembra rigido e rigido oggi può sembrare sciocco e ridondante domani. Ciò avviene sia attraverso nuovi strumenti che esperienze sperimentali che vanno dalle startup alle organizzazioni più conservative.

Fondamentalmente, il cambiamento e la gestione del rischio sembrano avere una forma unica per ogni organizzazione. La soluzione migliore è mantenere una mente aperta, ma non portare troppe convinzioni da un team all'altro.