In Software Engineering Radio un’intervista a Karl Wiegers. Si parla di requisiti, casi d’uso, testing e project management. Diversi spunti interessanti.
Come in tutti gli episodi di Software Engineering Radio si può ascoltare, oppure sileggere la trascrizione.
https://se-radio.net/episode-518-karl-wiegers-on-software-engineering-lessons
Agilità vera e falsa. Ora che essere agili è di moda, due riflessioni su cosa implica essere agili davvero.
La prima, stringata e acuta, su The Economist del 5 luglio 2018: The fashion for agile management is spreading, si diffonde la moda del management agile.
Con un commento arguto sull’uso del termine Scrum nel lavorare in gruppi:
Somehow, the teams concept acquired the name “scrum”. This moniker was clearly bestowed by someone who had never seen a real rugby game. An actual scrum involves 16 people pushing hard, getting nowhere and usually ending up collapsing or being penalised by the referee for foul play.
In qualche modo, il concetto di lavoro in gruppo ha acquisito il termine “scrum”. Questo termine è stato chiaramente conferito da qualcuno che non aveva mai visto una vera partita di rugby. Una mischia (scrum) vera coinvolge 16 persone che spingono forte, non arrivano da nessuna parte e di solito finiscono per cascare giù o essere penalizzate dall’arbitro per il gioco scorretto.
La seconda riflessione, più articolata e approfondita, viene da Martin Fowler, uno tra i firmatari del Manifesto Agile del 2001, nell’intervento The State of Agile Software in 2018 (dove si può leggere la trascrizione di una presentazione effettuata nella conferenza Agile Australia).
On the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile’s values and principles. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects). Despite the problems, the community’s great strength is its ability to learn and adapt, tackling problems that we original manifesto authors didn’t imagine.
In superficie, il mondo dello sviluppo agile del software è brillante, dal momento che è ormai accettato ovunque. Ma la realtà è preoccupante, perché gran parte di ciò che viene fatto è finto-agile, ed ignora i valori e i principi dell’agile.
Le tre principali sfide su cui dovremmo concentrarci sono: la lotta contro il Complesso Industriale Agile e l’abitudine di imporre dall’esterno i processi ai gruppi di lavoro; aumentare l’importanza dell’eccellenza tecnica; organizzare i nostri team in base ai prodotti (piuttosto che ai progetti).
Nonostante i problemi, la grande forza della comunità è la sua capacità di apprendere e adattarsi, affrontando problemi che noi autori del manifesto originale non immaginavamo.
Da leggere.
“Requirements Management: a Practice Guide”: https://t.co/cLFI9fPqYe, scaricabile dal Project Management Institute @PMInstitute #baot #BusinessAnalyst #analistasoftware https://lnkd.in/enYnGci
In quali situazioni la collaborazione da remoto può funzionare? Per quale tipo di progetti?
In Remote versus Co-located Work, Martin Fowler analizza pro e contro del lavoro a distanza, le maggiori difficoltà nel comunicare e, sull’altro piatto della bilancia, la possibilità di coinvolgere esperti non disponibili localmente.
Come misurare la produttività dello sviluppo software? McKinsey propone di ricorrere agli Use Case Points, con queste motivazioni:
How do you estimate on an Agile project? è un opuscolo pubblicato da Thoughtworks che mette a confronto diversi punti di vista sulle stime nei processi agili: se, quando e come farle.
“Large Scale Agile” è il titolo del numero monografico di maggio / giugno 2013 di CrossTalk, la rivista sullo sviluppo software delle forze armate USA.
Articoli su come sviluppare in modo agile per progetti di grandi dimensioni e distribuiti in più centri; su come coniugare solidità architetturale e pratiche agili; sulle pratiche di stima di dimensioni e di impegno.
Un articolo del settimanale inglese The Observer cita alcuni casi famosi in cui progetti informatici di grandi dimensioni hanno portato a rischi ingestibili e a fallimenti.
A scopo preventivo, l’articolo raccomanda di rendere obbligatoria per i manager IT la lettura del classico “The Mythical Man-Month” (il mitico mese-uomo), libro di Fred Brooks pubblicato nel 1975 dopo che Brooks aveva guidato il complesso progetto di sviluppo del sistema operativo IBM OS/360.
“The Mythical Man-Month” è in effetti un testo ricco di insegnamenti utili, tra cui il fatto che aggiungere ulteriori sviluppatori ad un progetto in ritardo provoca ritardi ulteriori. Per la sua utilità, nota l’autore dell’articolo di The Observer, il libro di Brooks continua ad essere pubblicato regolarmente dal 1975 ad oggi. Purtroppo, come accade per diversi altri testi fondamentali dell’IT (e non solo), non è mai stato tradotto in italiano.
I progetti sono come i dinosauri, nella vita delle organizzazioni, sostiene Gerry McGovern, esperto di content management.
Certo, si tratta di una generalizzazione molto forzata. In alcuni contesti, la logica progettuale è appropriata, in altri meno (ad esempio nelle continue evoluzioni di intranet e siti web, l’ambito di cui si occupa McGovern).
Ma quando un progetto sarebbe utile, farne a meno è davvero rischioso.
Punto di vista interessante, comunque.
Lord Kelvin: “Se non si può misurare, non si può migliorare”.
Tom DeMarco, in Controlling Software Projects (1986): “Non si può tenere sotto controllo ciò che non si riesce a misurare”.
Phillip G. Armour, su Communications of the ACM, June 2012, rovescia il punto di vista: “Se non si migliorano le cose, è difficile misurarle bene; sotto alcuni aspetti, non possiamo misurare ciò che non controlliamo”.
Alcuni esempi illuminanti di misurazioni dubbie citate nell’articolo: durata, produttività, costo, qualità dei progetti software.