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

Sono in un nuovo lavoro in cui il progetto deve soddisfare rigorosi standard di qualità, essere ampiamente documentato, gestito in modo molto dettagliato, diagrammi UML e tutte quelle cose che sono opposte alla "codifica da cowboy" in cui la maggior parte della mia esperienza lavorativa passata è stata . Pensa al modo in cui viene sviluppato il software aerospaziale o per dispositivi medici su larga scala.

Sono felice di lasciare il caos della codifica da cowboy e sono curioso di vedere come vanno bene i metodi di ingegneria dei pesi massimi. Ma come si può rapidamente acquisire esperienza con i metodi pesanti?

Oltre a essere semplicemente al lavoro per un certo numero di mesi / anni, cioè.

Con un linguaggio semplice o una nuova API, si può hackerare un programma di test giocattolo, leggere, deliberatamente fare errori per vedere cosa succede, ecc. Come diventare bravi in ​​bicicletta o suonare uno strumento musicale, la pratica è essenziale. È facile prendere un flauto e passare mezz'ora ogni giorno; non è necessario unirsi a un'orchestra o essere un consulente di flauto a tempo pieno. Ma come esercitarsi nelle attività di ingegneria del software che sono grandi, complesse, coinvolgono i team e in gran parte riguardano la comunicazione e la pianificazione, evitando comunicazioni errate e superando i limiti di pianificazione e budget?

Questo non sembra possibile fare da solo. C'è un modo in cui un piccolo numero di persone potrebbe simulare la progettazione di un grande progetto su piccola scala in breve tempo (un giorno)?

C'è un modo in cui un piccolo numero di persone potrebbe simulare la progettazione di un grande progetto su piccola scala in breve tempo (un giorno)?

Sì, questo è possibile in una certa misura. Circa 10 anni fa ho partecipato a un seminario alla conferenza OOP a Monaco in cui 16 persone avevano il compito di fare un'analisi approssimativa e progettare un software per piccole imprese. La prima metà della giornata riguardava principalmente la ricerca di una struttura di squadra per risolvere l'attività con 16 persone, e la seconda metà della giornata si è concentrata sulla risoluzione dell'attività con questa squadra.

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 della squadra (sotto la pressione del tempo), successivamente è stato applicato un processo di sparatoria per decidere quale struttura della squadra potrebbe essere la migliore e dovrebbe essere utilizzata per la seconda parte del seminario .

Sfortunatamente, durante la prima parte, abbiamo commesso l'errore di provare a dare a ciascuna delle 16 persone un lavoro all'interno della struttura del team prevista. Quell'errore porta al caos nella seconda metà, perché 16 persone sono troppo per risolvere un simile compito. Una soluzione funzionante potrebbe essere stata quella di dividere nuovamente le 16 persone in team più piccoli, oppure scegliere 3 o 4 persone per svolgere il lavoro principale, ma nel fervore del momento ci siamo persi di vederlo.

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

Inizia con una lista di controllo . (Sapevi che era il primo passo, giusto?)
Assicurati che l'elenco di controllo elenchi tutta la documentazione standard per il tuo progetto attuale. vale a dire. Diagramma UML, specifiche funzionali, progetti di alto e 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 trovarne uno, google "code katas" o controlla l'archivio di sfide codejam di Google. O semplicemente costruisci una calcolatrice. :-)

Crea le specifiche funzionali per il tuo programma di esempio. Quindi passa al design di alto livello, al diagramma UML, ecc ... Costruiscilo secondo le specifiche. Provalo. Ogni volta che trovi un difetto significativo nelle tue specifiche (come definito dalle tue attuali pratiche di lavoro), devi tornare a quella fase dell'SDLC e rivedere prima di procedere di nuovo.

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

Dopo aver ripetutamente ripetuto il ciclo di progettazione / costruzione / test / ripetizione, avrai acquisito abilità ed esperienza nei componenti "pesanti" che ora ti preoccupano. Le iterazioni mostreranno anche l'interconnessione tra le varie fasi e la documentazione generata. La lezione preziosa sta dimostrando come una modifica del codice di 5 minuti può avere un effetto a catena di più ore altrove a causa degli aggiornamenti dei documenti e dei requisiti di test.

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

Tuttavia, non tutte le pratiche che vedi o studi sono necessariamente positive. Lo sviluppo del software è fluido e ciò che oggi sembra rigido e rigoroso può sembrare sciocco e ridondante domani. Ciò accade sia attraverso nuovi strumenti sia attraverso esperienze sperimentali che si diffondono dalle startup alle organizzazioni più conservatrici.

Fondamentalmente, la gestione dei cambiamenti e dei rischi sembra avere una forma unica per ogni organizzazione. La tua scommessa migliore è mantenere una mente aperta, ma non portare troppi presupposti da squadra a squadra.