Ivar Jacobson: ecco cosa non insegnano ai programmatori

Viene inoltre sottolineato un altro problema, ritenuto particolarmente grave. Molte aziende tendono a formare gruppi di lavoro molto grandi, suddividendoli poi in micro-gruppi che spesso non sono a conoscenza di cosa facciano gli altri. Questo genera inevitabilmente problemi e ritardi.

La soluzione proposta da Ivar Jacobson prevede la creazione di gruppi inferiori alle 10 unità, ed ogni team di sviluppo deve sapere esattamente cosa fanno gli altri, al fine di concentrare idee e forse per lo sviluppo di un progetto funzionante e competente su tutta la linea. Perché un numero così basso di persone? Per il semplice fatto che il team risulta più affiatato.

Presa di mira è anche la struttura dell'intero progetto, che mette in risalto i problemi sia della mancanza di comunicazione dei team, sia una quantità di problemi spesso ingestibile per chi si trova alla fine della catena. Un esempio: una volta analizzati i requisiti (team1), il tutto passa ad almeno due stati di definizione del progetto (team2 e team3), per poi passare il tutto a chi deve tradurre le idee in codice.

Si possono benissimo immaginare le conseguenze di un approccio di questo tipo, dove il team di programmatori di trova a dover accontentare esigenze magari inconciliabili fra loro decise da team differenti, creando una mole di lavoro e problemi di impostazione difficilmente gestibili. Problemi che poi verranno inevitabilmente moltiplicati ad ogni passaggio. Sembra quasi assurdo, ma queste situazioni sono molto più comuni di quel che si pensi.

Nelle pratiche consigliate da Ivar Jacobson e dalla sua azienda ne troviamo una che riguarda proprio i progetti. L'idea, molto semplificata, è quella di lavorare in team per creare un progetto snello, al quale aggiungere man mano funzionalità in base alle esigente, il tutto concordato dalle parti. L'idea base è dunque quella di procedere un passo alla volta, senza definire tutto sulla carta prima, per poi rincorrere a colpi di "toppe" nei passaggi successivi.

Molti capi-progetto ed alcuni committenti impongono di raggiungere certi risultati ad un certo costo, avendo basato i loro calcoli sulla pura teoria. Si tratta di un modo di ragionare logico e molto diffuso, ma che nella quasi totalità dei casi è disatteso dalla realtà.

Anche in questo caso, il consiglio è: be smart. Partire con un progetto base, molto snello, con le principali richieste. Stabilite le priorità, si deve procedere passo a passo pensando al miglior modo in cui procedere.