Il management del software nelle microaziende/1

La letteratura informatica è piena di ottimi libri sul management del software. Se vogliamo, insieme alle tematiche più pratiche di ingegneria del software, il management costituisce uno di quegli argomenti sempre sulla “breccia dell’onda”. Tuttavia le varie metodologie presentate si scontrano nel caso delle microaziende con una realtà che raramente può essere sovvertita: la mancanza di budget. Ad esempio, nel caso del management dello sviluppo software molte delle ricette proposte si basano non solo su una forte disponibilità di programmatori molto preparati in seno all’azienda, ma anche su una gerarchia interna ben definita.

La scarsa disponibilità finanziaria non può tuttavia essere un alibi per non adottare delle politiche di gestione delle attività o strumenti e tecniche di sviluppo che possono rendere la vita migliore per tutti i componenti del team. Con questo articolo parte una serie in cui scopriremo quali azioni, prevalentemente dettate dal buon senso, possono essere intraprese per una corretta gestione delle attività di produzione software anche in presenza di risorse economiche molto limitate. L’idea, basata sull’esperienza dell’autore, è quella di mostrare che è possibile adottare dei criteri organizzativi semplici ma efficaci, che permettono di migliorare sensibilmente la qualità del lavoro svolto, l’organizzazione dell’azienda e la formazione del personale.

Il management low cost: keep it simple

C’è una regola base del management low cost, che al tempo stesso è ovvia: tenere sempre basso il livello delle attività puntando alla semplicità di gestione e di sviluppo.

Purtroppo, raramente mi è capitato di osservare che ciò avviene, come se ci fosse una sorta di regola non scritta, ma che soprattutto si verifica puntualmente sotto le scadenze di progetto, quando ritardi accumulati, pressing del cliente e altro possono portare ad un clima non troppo “lucido”. È in quel momento che ci si rende conto che una serie di cose non vanno, sia sul fronte dell’organizzazione sia su quello delle procedure da adottare per svolgere un dato compito o attività. Ed è anche quello il momento in cui si sbaglia a prendere decisioni: la scarsa lucidità porta a vedere problemi dove non ce ne sono, ignorarne altri più importanti. In alcuni casi, soprattutto in ambienti lavorativi dove già vi sono pregressi problemi di convivenza sul posto del lavoro, può addirittura succedere che i rapporti interni al team si lacerino in maniera pesante, con ovvie ripercussioni a valanga sulla produttività generale.

Il management ha come scopo di evitare nella maniera più assoluta l’insorgenza di queste situazioni di marasma, e soprattutto ha l’obiettivo di identificarle preventivamente. Le regole “del gioco” devono essere previste sin da subito. Conoscendole e fissandole, è molto difficile che se ne senta la mancanza nei momenti critici e soprattutto serviranno ad affrontare il lavoro quotidiano. Quello che è necessario, però, è che in un’azienda di piccole dimensioni a budget limitato tali regole siano semplici, perché regole difficili sono di dubbia applicazione e possono diventare impossibili da gestire in presenza di scarse risorse e ciclicamente allocate a task diversi. Mai farsi tentare dall’istituire procedure “burocratizzate” o invadenti, e quasi sempre stupide. Mai inseguire le ultime mode del momento semplicemente perché tutti ne parlano. Ma se si capisce che quella cosa è importante, allora bisogna farla, senza trovare alcun alibi. Inoltre, è importante capire dai propri errori, e se necessario non avere paura a tornare sui propri passi.

Organizzare il prodotto: sistemi di SCM

Un’azienda informatica produce tendenzialmente software. E il software deve essere organizzato in modo tale da renderne la gestione il meno onerosa possibile. Purtroppo, in base alla mia esperienza (ma anche da quello che quotidianamente si può leggere in giro su Internet), troppe microaziende ignorano i software di Source Code Management.
Un SCM è un software progettato per tenere traccia dei cambiamenti ad un repository di file, gestendo tutti i cambiamenti effettuati ad un insieme di file e directory inseriti dall’utente sotto il controllo di versione. Con questi strumenti è sempre possibile risalire a tutte le modifiche che un dato file ha subito. 

Gli SCM sono uno strumento indispensabile a prescindere dal numero di risorse allocate per un dato progetto. Non è affatto raro che ci si trovi ad effettuare delle modifiche su un file per un qualche motivo, ed accorgersi dopo una settimana che la nuova strada intrapresa non porta da nessuna parte (o come spesso accade, il cliente ha cambiato idea per l’ennesima volta). Gli scenari che si prospettano a questo punto sono due. Se siete stati sufficientemente zelanti (ma poco furbi perché avete effettuato questa operazione a mano), una settimana prima avete fatto un backup di sicurezza dell’albero dei sorgenti, e quindi potete riportare tutto allo stato precedente. Se, al contrario, non avete fatto ciò, benvenuti sul pianeta di coloro che non hanno mai toccato con mano i benefici di un software di gestione delle versioni.

Quando, invece, lo sviluppo è effettuato in cooperazione con altri, non usare simili tool non è solo poco furbo: è da masochisti. Gestire a mano in contemporanea le modifiche effettuate da altri, che possono essere conflittuali con le proprie, fa perdere tantissimo tempo, ha un’elevata probabilità di inserire errori nel codice e può ritardare nel tempo l’insorgenza di bug che invece potrebbero essere individuati molto più rapidamente.

Un SCM, al contrario, facilita drasticamente lo sviluppo in team. Facciamo un esempio. Lucia e Mario stanno lavorando sullo stesso prodotto. Il caso più semplice è che i due stanno lavorando su due file sorgenti diversi. A questo punto difficilmente ci saranno problemi (a meno di cambiamenti alle specifiche dei moduli che stanno implementando – ma questo è un problema a monte, di progettazione ed organizzazione del lavoro). Tuttavia, ogni qualvolta uno di loro effettuerà un commit del proprio lavoro, l’altro si troverà automaticamente i cambiamenti aggiornati, e sarà più immediato trovare bug (e non una settimana dopo quando i due ritengono di aver “concluso” e decidono di effettuare il merge dei loro sorgenti sotto un unico albero). Il caso successivo si verifica quando entrambi lavorano allo stesso file ma ad aree diverse che non generano conflitti. Una delle possibili strategie, adottate per default da alcuni sistemi di SCM, è quella di effettuare automaticamente il merge del file sorgente dopo il commit, senza doversi preoccupare di farlo a mano (classica domanda del venerdì sera: “Da che punto hai modificato tu?”), segnalando all’utente che è avvenuta tale operazione. L’ultimo caso è quello più complesso da gestire, ma è anche quello in cui si evidenzia tutta la comodità di usare un SCM. Mario e Lucia hanno modificato la stessa parte di codice, senza che uno avvisasse l’altro. Questa operazione genera un conflitto (cfr. figura sotto), e il sistema effettua tre operazioni:

  1. Individua l’area del file sorgente interessata al conflitto.
  2. Genera un nuovo file contenente la parte introdotta da Lucia e quella da Mario (in realtà, il sistema genera un file contenente il codice della revisione generata dal commit di Lucia e della revisione generata dalle modifiche di Mario).
  3. Allega il file originale della revisione precedente a quella che ha generato il conflitto.
Shematizzazione merge/conflict

A questo punto sarà compito dei due programmatori risolvere il conflitto, quasi sicuramente dopo essersi seduti ad un tavolo ed averne discusso.
Questo è il caso in cui due programmatori lavorano allo stesso progetto. È facile immaginare come strumenti del genere diventino essenziali nel momento in cui il numero dei programmatori è maggiore di due.

Tuttavia, l’utilizzo di un software di gestione delle versioni non esclude una componente fondamentale: il dialogo tra gli sviluppatori. Anzi, assicura che tale dialogo ci sia e lo rende costante, migliorando drasticamente la produttività generale. Può essere molto utile, infatti, sfruttare riunioni quotidiane (magari quei 5 minuti durante una pausa caffè) per comunicare agli altri quali file si intende modificare, o almeno effettuarne il lock (tutti i software di SCM permettono una simile operazione) prima di procedere a modifiche che potrebbero essere conflittuali o alterare le specifiche. Ricordatevi che in caso di conflitto il sistema demanda al programmatore la responsabilità di risolverlo: se ci si ritrova a dover gestire decine di conflitti, magari dopo molti giorni di lavoro, allora i vantaggi di uno SCM svaniscono. Un altro modo per evitare ciò, oltre a costituire in generale una buona prassi, è effettuare commit ed update periodici del software: non meno di una volta al giorno nel caso di sviluppo intensivo (update mattutino, commit pomeridiano), o appena effettuato un fix per progetti su cui non ci si sta lavorando attivamente.

Quando si comincia ad utilizzare un software di gestione delle versioni diventa molto utile aggiungere uno o più Changelog all’albero dei sorgenti. Tipicamente, un Changelog è un file in cui ogni sviluppatore annota tutte le modifiche effettuate sulla struttura del codice, con una breve descrizione e motivazione della modifica. In questo modo si ha anche uno storico esplicito e documentato delle azioni svolte sull’albero dei sorgenti.
Il Changelog è un file dove ogni record ha la seguente struttura:

YYYY-MM-DD Carmine Noviello cnoviello@hotmail.com

* myfile.ext (myfunction): cambiamenti fatti alla funzione, con breve descrizione

* anotherfile.ext (somefunction): altri cambiamenti

Un Changelog è un file monotono strettamente crescente: si aggiunge sempre in testa, senza eliminare alcuna voce. Questo significa che se ad un certo punto ci si rende conto che una modifica è improduttiva non si torna indietro cancellando la voce del Changelog in cui se ne dichiarava l’inserimento, ma si aggiunge una nuova voce in cui si dichiara l’annullamento della modifica, motivandola. Il Changelog può essere sostituito anche dal log dell’SCM: in questo caso è opportuno effettuare commit frequenti, e motivare dettagliatamente nel messaggio di commit cosa è stato modificato e perché.

Con un SCM può essere messo sotto revisione (ed è auspicabile che ciò avvenga) qualunque componente soggetta a produzione. Se la software house sviluppa portali web per clienti terzi, avrà senso inserire nel repository anche le immagini della grafica del sito. Altro uso importante è quello relativo alla documentazione: anch’essa può cambiare, e risalire a versioni precedenti (ad esempio, documentazioni relative ad una particolare versione del prodotto) è estremamente utile.

I sistemi di SCM trovano ottima applicazione anche quando si gestiscono diverse versioni dello stesso progetto, dette branch. Non è raro, infatti, di aver sviluppato un prodotto e venderlo a terzi con personalizzazioni specifiche. Spesso si tratta di piccoli aggiustamenti isolati, ma che comunque riguardano parti di codice sorgente dello stesso albero. Gli SCM permettono di derivare nuove branch del codice (magari solo della parte soggetta a modifica), in modo da tenere sotto controllo tutte le versioni e tutti i cambiamenti richiesti. Attenzione però: ricordarsi sempre di documentare quali modifiche subisce una branch, altrimenti dopo saranno dolori e diverse ore di diff sui sorgenti.

In genere, i benefici dell’adozione di un SCM risultano tangibili sin da subito, ma nella totalità dei casi a cui ho assistito, una volta introdotto un simile prodotto non è stato più abbandonato.

Esistono diversi prodotti, commerciali ed Open Source, per la gestione delle versioni. Una loro recensione esula dagli obiettivi di questo articolo. Tra i più famosi spiccano sicuramente Subversion (SVN), che negli ultimi anni ha rimpiazzato CVS, ma anche altri prodotti più recenti, come Mercurial, che appartengono alla categoria dei Distributed SCM, di cui si è già parlato in precedenza su stacktrace.it.

Organizzare il lavoro: sistemi di issue and bug tracking e knowledge base

Altro aspetto cruciale che distingue un lavoro organizzato da uno che procede in maniera disarticolata è la capacità di tenere traccia di informazioni vitali per l’andamento del progetto. Spesso accade che durante la fase di sviluppo si presentino delle condizioni o delle richieste che non possono essere immediatamente soddisfatte: un incremento di funzionalità, una possibile limitazione d’uso del prodotto, un cambiamento ai requisiti utente a seguito di una rinegoziazione del prodotto con la committenza. Poter tenere traccia in maniera persistente e strutturata di tali informazioni è un vantaggio enorme sia sul piano della produttività sia su quello dell’organizzazione del lavoro. Nelle aziende a risorse limitate purtroppo capita troppo spesso di trovarsi davanti alla lavagna o alla bacheca piena di annotazioni, o di vedere i monitor cosparsi di post-it. Se il post-it è molto utile per ricordarsi di passare dal salumiere prima di tornare a casa, diventa uno strumento impreciso, soggetto ad errori e troppo “volatile” per annotare aspetti lavorativi. Un analogo discorso riguarda il tenere traccia di bug che possono insorgere nella messa in esercizio del prodotto o durante la stessa fase di sviluppo. Qui la cosa è ancora più critica, perché spesso la risoluzione di un bug è associata ad una qualche priorità, che comporta lo spostamento nel tempo dell’azione per risolverlo.

Per questo motivo sono stati sviluppati negli anni dei prodotti per la raccolta di annotazioni relative a nuove funzionalità o bug. Si parla di sistemi di issue and bug-tracking, ed oggi esistono diversi prodotti anche Open Source che è possibile integrare nel proprio ciclo di lavoro. Si parte dal famoso Bugzilla, sviluppato da Mozilla Foundation, passando per prodotti che forniscono una migliore integrazione con i software di SCM, soprattutto SVN, fornendo template predefiniti per la navigazione tra le revisioni dei sorgenti, la documentazione, la gestione delle milestone del progetto. Giusto per citarne qualcuno: trac, implementato con il linguaggio di programmazione Python, mentre tra la categoria dei prodotti non Open Source c’è Jira, scritto in Java e che può essere rilasciato ad uso gratuito per progetti Open Source (l’Apache Software Foundation lo usa, ad esempio).

Tutti i sistemi di issue and bug tracking forniscono un proprio workflow che stabilisce il ciclo di vita di un ticket sottomesso nel sistema. I sistemi più semplici ne hanno uno preimpostato ed è l’unico adoperabile, quelli più complessi permettono di personalizzarlo in base alle proprie esigenze. Ad esempio, in trac fino alla versione 0.10 veniva fornito un unico workflow di base (oggettivamente troppo semplicistico), che prevedeva soltanto 3 stati (nuovo, assegnato e chiuso) e pochissime transizioni. Dalla versione 0.11 è diventato possibile definire il proprio workflow. Un lifecycle minimale dovrebbe integrare almeno gli stati e le transizioni riportate in figura.

Esempio di workflow minimale per un ticket

Con questi sistemi è anche possibile strutturare ed etichettare le informazioni per ricavare il maggior numero di “meta informazioni” possibili. Ad esempio, è possibile catalogare le informazioni per aree funzionali (interfaccia utente, database, logica di applicazione, ecc) o per particolari versioni di prodotto, o per la provenienza del dato (bug emerso in fase di testing, segnalazione del cliente, ecc). Quando si collezionano questi dati è importante contestualizzare quanto è più possibile la loro origine. Ad esempio, se si scopre un bug in una condizione particolare di utilizzo è importante riportare la procedura per ricostruire quella situazione. Se si inserisce una nota per un incremento di funzionalità è importante argomentarne la motivazione. Se ci si rende conto che in una versione successiva una certa parte del software deve essere soggetta a refactoring è essenziale argomentare, motivare e descrivere cosa non va e come va cambiato. E questo per un motivo molto semplice: è importante poter tenere traccia anche dell’esperienza.

Questo ultimo punto ci porta ad un altro aspetto tutt’altro che banale: come si conserva e si trasferisce il know how? Una risposta a caldo potrebbe essere: il know how è frutto di esperienza (guarda caso siamo ritornati al punto di cui prima). Certo, ma è anche vero che reinventare la ruota non è salutare. A volte può succedere che la frammentazione interna di un’azienda, soprattutto in assenza di una guida tecnica dedicata a ciò al 100%, provochi che gruppi disgiunti si trovino ad affrontare in momenti diversi lo stesso problema, spesso proponendo soluzioni differenti e senza che nessuno sapesse che già altri avevano affrontato la stessa cosa. Faccio un esempio pratico di cui sono stato testimone. Un gruppo di lavoro di un’azienda si trova a dover affrontare il problema di pubblicare sul web documenti con caratteri non contemplati dallo standard ASCII a 7bit. Non possedendo l’adeguato know-how, si individua la soluzione nel frapporre uno script tra l’interfaccia utente e il database ASCII che, individuate delle stringhe di byte “tipiche” in una non ben specificata codifica, converte le lettere accentate dell’alfabeto italiano in entità HTML. Successivamente, un altro gruppo è incaricato di interfacciare questo database via Web: si creano delle form di inserimento e si scopre che c’è un classico problema di gestione di codifica. Si individua la soluzione banalmente nel forzare la codifica del DB a latin1. Tutto ok. Peccato che Internet Explorer, in assenza di direttive esplicite nel codice HTML, preferisce adoperare la cp1252 di Windows (fin qui in realtà tutto ok), ma un altro gruppo di utenti su Linux/Firefox comincia ad inserire stringhe di byte UTF-8. La tragedia è ormai compiuta, ma il peggio deve ancora venire. Un altro gruppo, quasi 1 anno dopo, si accorge dei problemi nel momento in cui presentano via web i contenuti, e procede ad una ricodifica forzata a ISO-8859-15 di tutto il DB, con una perdita consistente dei dati. Vi tralascio la fine della storia (molto triste e fatta di algoritmi euristici per risolvere la faccenda), ma passo alla morale:

  1. capire Unicode per un italiano è obbligatorio;
  2. se i gruppi della stessa azienda avessero “parlato” sin da subito si sarebbero accorti che qualcosa non andava.

Tutto questo per dire che tanto più si è piccoli tanto più è fondamentale condividere la conoscenza. Ma ciò deve essere fatto in maniera semplice, e ll modo per farlo è quello di ricorrere ad un knowledge base. 

Una knowledge base (KB) può essere realizzata con la logica dei Document Management System, ossia un prodotto (che tipicamente consente l’interazione attraverso il web) il cui obiettivo è contenere informazioni organizzate in maniera sistematica e ‘tipizzata’ (ossia documenti che hanno solo una struttura ben definita). Le KB funzionano con la logica dei percorsi gerarchici: si definiscono delle macro aree e le si specializza in base alle proprie esigenze. La KB è anche uno dei pochi strumenti concreti per ridurre l’impatto del turnover: un nuovo programmatore avrà una base di conoscenza da cui attingere, senza dover reinventare la ruota o scontrarsi su problematiche già risolte, il tutto a vantaggio della riduzione dei tempi di formazione. Ricordarsi la regola aurea: la scrittura è l’unico modo dopo l’esperienza diretta di tramandare la cultura.

Esistono diversi sistemi Open Source di gestione delle KB. Il più ricco di funzionalità è KnowledgeTree, che punta ad essere un vero e proprio CMS, completo di tutte le funzionalità di gestione e workflow che un simile sistema deve offrire. Tuttavia, tale potenza si paga al costo di una maggiore complessità di integrazione nel ciclo di lavoro, e di utilizzo vero e proprio del sistema. Un prodotto che, invece, può rappresentare una valida alternativa, per l’uso che se ne sta delineando in questo articolo, è KnowledgeRoot, di elevata semplicità d’uso ed installazione.

Nella scelta di un software di KB bisogna anche prendere in considerazione l’utilizzo di un buon sistema di wiki. I wiki sono di facile utilizzo e, non ponendo vincoli sulla strutturazione dei contenuti, possono essere adattati in base alle proprie esigenze, senza obbligare i programmatori a complessi schemi di utilizzo. Inoltre, non bisogna ignorare che molti sistemi di issue and bug tracking ne integrano già uno al proprio interno, come ad esempio trac. In questo modo, è possibile ottenere da un unico strumento una piattaforma completa per l’intero ciclo di produzione del software, riducendo la complessità di gestione e semplificando la vita dei programmatori.

A volte, il wiki può assolvere anche ad un altro compito importante: tenere traccia dall’andamento generale delle attività. Le persone tendono molto facilmente a perdere di vista il percorso generale. Questa di per sé non è una défaillance dei singoli ma è, in generale, una diretta conseguenza della verticalizzazione delle singole attività (cosa tipica della programmazione). Lavorare su un singolo aspetto porta a distrarsi dall’intero progetto, soprattutto se si adotta una progettazione modulare e la realizzazione di moduli è demandata a persone diverse. Poter avere un posto in cui è possibile osservare l’andamento globale delle attività (senza ricorrere a GANTT o altre diavolerie, per carità) è utile ai programmatori e al tempo stesso semplifica la vita di chi coordina le attività.
L’unica pecca del wiki, a voler essere pignoli, è che l’assenza di una strutturazione e categorizzazione obbligata, che invece è imposta nei DMS, può portare ad uno sviluppo caotico dei contenuti se non se ne controlla bene il processo di inserimento e classificazione.

Conclusioni

In questo primo articolo abbiamo visto quali strumenti e politiche di gestione è possibile introdurre in un’azienda per migliorare la produttività e l’andamento del lavoro, anche in presenza di risorse economiche e di personale limitate. Nel prossimo articolo analizzeremo altri aspetti importanti sia tecnici, come il testing del software, sia di carattere gestionale come la formazione dei nuovi programmatori. A presto.

Comments

  1. Vincenzo Acinapura says:

    Ciao Carmine, complimenti per l’articolo molto interessante e drammaticamente veritiero (ho molto riso quando hai fatto l’esempio di Unicode).
    Mi permetto di segnalare “Assembla”, un servizio web che riassume tutte le buone pratiche di lavoro che hai annoverato e che mi sembra decisamente adatto a gestire piccoli team di lavoro.

  2. Lawrence Oluyede says:

    Gia`, Assembla non e` male. Lo usiamo anche noi di Stacktrace 🙂

  3. L’articolo è molto interessante, però tratta quasi esclusivamente l’aspetto tecnico di un progetto minimal, mentre il titolo mi lasciava sperare in qualche buon suggerimento per la gestione del progetto anche nelle fasi di analisi, documentazione, rilascio…
    Io sono abbastanza convinto che un gruppo di 3-5 persone sia in grado di gestire progetti anche molto grossi, usando gli strumenti in parte citati in questo articolo. Nell’ambito Java, Maven, Andromda e un pugno di bravi sviluppatori ci ha permesso di reggere un progetto da 100 e più entità (cito solo quelle persistenti, il progetto intero ne conteneva almeno il doppio, + i vari VO, webservice, blablabla)
    Però abbiamo cozzato duramente con le fasi non puramente tecniche: come gestire la documentazione quando si è così in pochi? Come si fa con i test (per non parlare di quelli funzionali)? Come conviene strutturare il progetto?

  4. Sto notando che questo è in realtà il primo di una serie di articoli. Mi auguro che l’autore vorrà discutere anche dei dubbi di cui ho scritto poco fa.

  5. @vincenzo: conosco da poco Assembla e per il momento non l’ho ancora integrato nel ciclo di lavoro. Né francamente so se farlo. Innanzitutto perché in genere preferisco (e consiglio) di costruire progressivamente la propria piattaforma in base alle reali esigenze, considerando che con molte distribuzioni di Linux, ad esempio Ubuntu, tutti i tool presentati si installano con qualche click. Poi c’è un fattore non banale di cui tener conto: l’impatto che tali strumenti ha nel ciclo di lavoro. Per esperienza questo è un fattore che va minimizzato per evitare di essere sopraffatti: ma di questo parlerò più approfonditamente nella seconda parte.
    Non c’è dubbio, però, che se si vuole evitare di gestire da zero il tutto, Assembla può essere un’ottima soluzione.

    @pietro: l’intento di questa miniserie non è quello di fornire un’analisi esaustiva del management del software. Per quello esistono ottimi riferimenti, di cui proverò ad elencarne qualcuno nel prossimo articolo. Più che altro l’idea è quella di convincere il lettore che è possibile introdurre dei meccanismi “virtuosi” almeno nella fase di codifica e mantenimento del software, che è la fase che una qualunque microazienda che sviluppa software deve avere.
    I punti che sollevi tu non sono banali. Il testing è un aspetto critico, che tratterò a grandi linee nel prossimo articolo, che però ha un trade-off non banale: costa, e non poco se lo si vuole fare bene. La documentazione è un altro punto annoso, soprattutto perché io devo ancora trovare un programmatore contento di documentare quello che ha scritto 🙂 Nel caso della documentazione destinata all’utente finale, spesso il programmatore non è proprio la persona adatta a scriverla: in un ultimo progetto abbiamo trovato estremamente utile “internalizzare” un addetto della committenza, che integrato durante la fase di testing e messa a punto ha saputo cogliere gli aspetti tecnici per poi trasferirli nel modo opportuno nella documentazione. Ma ammetto che questo non è sempre possibile, anche se riduce drasticamente i problemi per il team di sviluppo e per la committenza stessa. Non mi è ben chiaro cosa intendi esattamente per 100 unità (se uomo/lavoro o unità funzionali del prodotto software) ma pretendere da quei poveri 5 pure la documentazione esterna mi sembra un po’ troppo 😉

  6. ilochab says:

    … sull’onda c’è la cresta, mon la breccia 😉

  7. Ho usato Assembla con soddisfazione persino per micro-progetti, svolti solamente da 2-4 persone e per motivi meramente universitari: inutile dire che semplifica tantissimo la gestione del progetto, davvero un ottimo servizio.

    Bell’articolo, complimenti! Adesso sono in attesa di quello sul testing, un aspetto che non ho ancora affrontato con rigore ma che mi incuriosisce parecchio.

  8. @Carmine: le domande le ho scritte un pò di getto, e forse ho complicato + di quanto volessi. Il problema della letteratura sul PM è proprio quella di volere essere esaustiva. Io invece vorrei conoscere le soluzioni pragmatiche che ha scovato chi si ritrova a lavorare in un discreto progetto con un piccolo team. Da me, pur senza risultati eclatanti, abbiamo perlomeno tenuto a bada la fase di implementazione sfruttando Maven e Andromda (non approfondisco, ma se qualcuno è curioso, possiamo parlarne).
    Sui test è probabilmente vero quanto dici, farlo bene comporta aumentare il team. Però ho ancora dei dubbi, aspetterò l’articolo a riguardo.
    Per documentazione non intendevo quella per l’utente finale, ma quella interna. Per la mia esperienza, non siamo mai riusciti a tenere allineati codice e documentazione tecnica (diagrammi UML, documenti di analisi, ecc). Questi ultimi diventano presto obsoleti, a malapena si riesce ad allineare il Javadoc.
    Mi chiedo se esistano tecniche, tool, pratiche, per minimizzare questo disallineamento. Voglio chiarire che queste non sono domande che rivolgo espressamente a te, e forse non esistono neanche risposte definitive. In realtà le chiedo a me stesso, sperando in qualche suggerimento esterno 🙂
    PS: non parlavo di unità, ma di entità UML; 100 e rotti su DB mi sembrano una quantità niente male

  9. @pietro: Io personalmente nell’UML non c’ho mai creduto. E il motivo l’hai scoperto tu stesso: l’UML è un linguaggio, e come tale ha senso adoperarlo se si sfruttano tutte le sue caratteristiche come si deve. Questo richiede tempo, tantissimo tempo, e costi non facilmente sostenibili da una piccola azienda che deve ridurre il tempo di produzione al massimo per massimizzare il guadano. Dopo l’euforia iniziale, si finisce con il tenere il tutto disallineato, con la conseguenza che o si investe molto tempo per riallineare tutto o (tipicamente) si lascia così com’è. Inoltre, questi formalismi andrebbero adoperati a monte in fase di progettazione, ma per mia esperienza è molto difficile prevedere il tutto a priori: ci sarà sempre qualche cosa soggetta refactory che cambia il tuo modello.
    No, io decisamente preferisco buona documentazione interna possibilmente accompagnata da testing o meglio ancora doctesting, perché non c’è migliore documentazione per un programmatore che il codice ben scritto, e se poi questo ‘parla da sé’ con ottimi commenti e doctesting, difficilmente si ricorrerà a diagrammi UML.
    Ho adoperato onestamente UML solo una volta nella vita di recente: abbiamo venduto un nostro framework composto da alcune decine di classi e dovevamo dare al cliente una visione d’insieme generale di come queste classi interagivano. Abbiamo realizzato un poster 100x80cm con tutte le classi, anche se non eccessivamente dettagliate. C’abbiamo messo 15gg / uomo per realizzarlo (calcola i costi, praticamente è costato 1200 euro….). Bellissimo, figo. L’azienda acquirente dopo un po’ ha calorosamente ammesso di non usarlo e di preferire il codice e il doctesting 🙂

  10. @carmine Proprio perche` e` un linguaggio, considererei UML in altro modo: e` una maniera comune per descrivere rapporti tra oggetti, flussi, non solo in fase di progettazione ma in qualunque momento emerge la necessita` di parlare di un progetto software. Avere un formalismo standard e consolidato per farlo secondo me e` un aiuto. E in questo senso UML puo` tornare utile senza essere un costo

  11. Hai parlato di documentazione interna al posto di UML, ma il problema non rimane quello? Se non ho il tempo di aggiornare i diagrammi UML, figurati se posso prendere un pò di documenti in testo naturale e ritoccarli per riflettere le modifiche nel codice. Eppure qualcosa ci vuole, e non possiamo negare che un diagramma delle classi/di sequenza/di stato è molto + espressivo di un documento anche ben scritto.
    Sono d’accordo che la documentazione migliore è il codice, io cerco sempre di scrivere metodi che rientrino in una sola videata. Con Java è ancora + semplice grazie a Javadoc.
    Forse un buon compromesso sarebbe ispirarsi alla literate programming e includere nel codice anche dettagli di + alto livello.
    Effettivamente anche noi usiamo UML nel modo sbagliato, come strumento di postdocumentazione, ma ogni tanto è anche utile come strumento di analisi per abbozzare una struttura difficile da concepire nella testa o in un foglio di carta.
    Secondo me UML rimane cmq utile se lo si usa per dare la visione architetturale, magari con qualche artificio grafico (per es. disegnare + grandi le classi con maggiore responsabilità) e rimuovendo tutto ciò che non è strettamente necessario a capire com’è organizzato il software.

  12. Michele Simionato says:

    Se ho bisogno di fare un grafico delle classi per spiegare del codice a qualcuno io lo estraggo direttamente dal codice in maniera
    automatica con trucchi tipo quelli spiegati qui:

    http://www.linuxdevcenter.com/pub/a/linux/2004/05/06/graphviz_dot.html

  13. Io resto dell’opinione che un linguaggio o lo si sfrutta fino alla fine (compreso la semantica) oppure è meglio lasciare perdere. Io non ho mai visto un diagramma UML che sfrutta tutti i dettami dell’UML, anche perché il vero problema è che, tranne gli esempi didattici che si trovano nei libri, i modelli di applicazioni reali tendono a diventare molto complessi sia da gestire sia da leggere (oserei dire criptici).
    Detto questo concordo sul fatto che almeno per la visione architetturale l’UML è un buon linguaggio di ‘convenzione’, ma a quel punto non spenderei molto nel tenere allineato il tutto, soprattutto i metodi, attributi e altro. Ripeto: molto ma molto meglio il doctesting. Ma capisco che quando negli anni sono stati scritti decine e decine di libri sugli effetti miracolosi dell’UML, asserire il contrario non è molto facile 😉

  14. Paolo "Dickinson" Acampa says:

    cit. Abbiamo realizzato un poster 100x80cm con tutte le classi, anche se non eccessivamente dettagliate. C’abbiamo messo 15gg / uomo per realizzarlo (calcola i costi, praticamente è costato 1200 euro….). Bellissimo, figo.
    —————————————————-
    No, erano 14gg 🙂 Incombe sulla mia postazione, a volte mi opprime, mi fa paura, mi inibisce. E’ come se mentre aggiungo un metodo ad un classe sia pronto per aggredirmi e dirmi: “COSA STAI FACENDO? COME OSI MODIFICARE LE MIE CLASSI?”
    —————————————————
    —————————————————
    cit. Hai parlato di documentazione interna al posto di UML, ma il problema non rimane quello?
    —————————————————
    Io credo che UML e doc interna servano per scopi diversi. L’UML serve per formalizzare il design del software realizzato, tant’è vero che il poster di cui prima lo modifichiamo ad ogni milestone, giusto per avere davanti agli occhi la struttura del software, allo scopo di poter individuare qualche aspetto sul quale lavorare. Il problema è fino a che punto conviene spendere tempo (molto) per pura formalizzazione. La doc interna invece credo sia fondamentale. Per me fare documentazione interna è un po’ un’attività, come dire, “egoistica”. Tipicamente si scrive documentazione interna pensando che potrebbe essere utile a chi leggerà il codice. Io invece reputo quest’attività utile per me stesso e per chi lavora (purtroppo 🙂 ) a stretto contatto con me. A volte un metodo, un blocco di codice o cos’altro può risultare complesso da interpretare. Con la giusta documentazione interna, scritta in modo chiaro e sintetico, è possibile anche ritornare a modificare le parti di codice interessate, senza dover bruciare tanti neuroni per ricordare cosa faceva il blocco interessato. Parlo per esperienza personale, ma la doc interna mi ha davvero salvato molte volte.
    Tutto questo per dirvi che sono disposto a perdere tempo e piangere per scrivere doc interna, ma non tanto per formalizzare in UML qualcosa che ho già fatto.

  15. @pietro bonanno: perché non ci fai un articolino anche tu, per quanto minimale, spiegando cosa hai trovato di buono e potente nei tool che hai usato?

    A riguardo dell’UML: visto che siete in javalandia (deduco dall’uso di maven) avete considerato tool che permettano un editing integrato di UML e codice Java?

    @Carmine: bell’articolo attendo il prossimo 😀

  16. Bell’articolo, complimenti.

    Avendolo usato per un periodo, posso confermare l’utilità e la qualità di Trac, sia come strumento di knowledge base che come issue tracking (oltretutto integrabile con il proprio SCM).

  17. Buon articolo, parlerete anche di continuous integration nel post sucessivo?
    Strumenti che davvero aiutano la scrittura di codice attraverso la modellazione UML esistono ma non sono freeware, mi riferisco al Rational Software Architect. In ambito Java ti permette di tenere sincronizzato le Class diagram con le classi java, è molto utile quando il progetto è articolato e le dipendenze sono numerose. UML è un linguaggio di modellazione e visto fuori da un contesto model-driven perde gran parte delle sue potenzialità, per questo usare UML per documentazione pone tanti dubbi come quelli citati sopra. Questa è la mia esperienza con UML se vi può interessare:
    http://gfrison.com/2008/06/26/7-steps-to-mda-revolution/

Policy per i commenti: Apprezzo moltissimo i vostri commenti, critiche incluse. Per evitare spam e troll, e far rimanere il discorso civile, i commenti sono moderati e prontamente approvati poco dopo il loro invio.