Agilità
Voglio solo segnalare un piacevole articolo sull'agilità.
Il temrine Agile è abbastanza in voga nello sviluppo software, indicando quelle metodologie che privilegiano la comunicazione, l'immediatezza, al sovraccarico di documentazione e formalismi.
Si tratta di metodologie charming, perché danno sicuramente più enfasi all'individuo; nell'articolo viene spiegato come questa filosofia può applicarsi anche ad altri contesti, ad esempio la scrittura di libri di argomento tecnico.
Personalmente mi sento istintivamente favorevole alle metodologie agili, ma dobbiamo tener presente un fatto: la produzione di software richiede un articolato bagaglio di conoscenze che solo in piccola parte vengono "travasate" nel codice sorgente che si sviluppa. La filosofia dell' extreme programming (la metodologia agile più nota) tende invece a privilegiare proprio il codice sorgente - l'artefatto principale del lavoro di sviluppo - come "contenitore" della documentazione.
Credo che questo approccio comporti il rischio che la conoscenza sul software sviluppato rimanga in pratica nella testa degli sviluppatori, e non effettivamente ricavabile dal codice e dalla (poca) documentazione a contorno. In questo modo, il software non è proprietà dell'azienda che ne ha promosso lo sviluppo, ma tende a rimanere proprietà del team di sviluppo: questo non è corretto per una sana governance del servizio IT.
Per me è quindi sicuramente valida l'idea (soprattutto nel caso di sviluppo in house) di ridurre al minimo la "documentazione", ma è necessario controllarne la qualità, esattamente come si controlla la qualità del software. Un test della documentazione, si può ad esempio effettuare verificando se risponde a determinate "domande":
Il temrine Agile è abbastanza in voga nello sviluppo software, indicando quelle metodologie che privilegiano la comunicazione, l'immediatezza, al sovraccarico di documentazione e formalismi.
Si tratta di metodologie charming, perché danno sicuramente più enfasi all'individuo; nell'articolo viene spiegato come questa filosofia può applicarsi anche ad altri contesti, ad esempio la scrittura di libri di argomento tecnico.
Personalmente mi sento istintivamente favorevole alle metodologie agili, ma dobbiamo tener presente un fatto: la produzione di software richiede un articolato bagaglio di conoscenze che solo in piccola parte vengono "travasate" nel codice sorgente che si sviluppa. La filosofia dell' extreme programming (la metodologia agile più nota) tende invece a privilegiare proprio il codice sorgente - l'artefatto principale del lavoro di sviluppo - come "contenitore" della documentazione.
Credo che questo approccio comporti il rischio che la conoscenza sul software sviluppato rimanga in pratica nella testa degli sviluppatori, e non effettivamente ricavabile dal codice e dalla (poca) documentazione a contorno. In questo modo, il software non è proprietà dell'azienda che ne ha promosso lo sviluppo, ma tende a rimanere proprietà del team di sviluppo: questo non è corretto per una sana governance del servizio IT.
Per me è quindi sicuramente valida l'idea (soprattutto nel caso di sviluppo in house) di ridurre al minimo la "documentazione", ma è necessario controllarne la qualità, esattamente come si controlla la qualità del software. Un test della documentazione, si può ad esempio effettuare verificando se risponde a determinate "domande":
- per quale motivo sono state prese certe scelte di implementazione?
- Con chi e quando sono state condivise queste scelte?
- Perché i dati vengono elaborati in un certo modo?
- Da dove arrivano i dati elaborati dal programma? Quando? Come?
- ecc..
Molto spesso vedo della documentazione che "trascrive" quello che il programma fa, oppure guide utente che dicono: "Nel campo Codice cliente si deve inserire il codice del cliente"; questa è senz'altro documentazione inutile, se a qualcuno servisse veramente, vuol dire che è così stupido che è meglio tenerlo lontano dal sistema!
