Aggiornamenti

Social Networks

Sponsored by

ilariamauric.it è online dal 2009
16 settembre 2010

CSMA10: il mio bilancio (parte 3/3).


Ho imparato che durante le fasi di sviluppo di un progetto, i quattro aspetti che entrano in gioco sono il budget, il tempo, la qualità e lo scopo la portata (n.d.r.: corretto dopo il commento di Jacopo e comprensione in progress :P). Sono tutte variabili, ma è più comune che budget e tempo rimangano fissi. Lavorando in team, occorre trovare un linguaggio comune per definire i termini della qualità che si vuole, si può oppure ha senso offrire, non solo dal punto di vista tecnologico. Anche questo è un punto su cui ho trovato spesso difficoltà perché, di fronte a un bivio, si preferisce un’applicazione funzionante che una grafica bella (semplifico, per ora). Anche questo sembra ovvio, ma non lo è: funzionante, per uno sviluppatore, potrebbe essere non solo un blocco del sistema ma anche la pulizia del codice, l’accessibilità e non so cos’altro. Spesso mi trovo a “combattere” contro questo approccio talebano sul software. Su questo punto vorrei cercare di alzare lo sguardo andando per un attimo oltre le metodologie.

Terza lezione: la qualità va definita secondo i valori giusti da apportare al progetto.

Dato che non sono sviluppatrice, mi fido del fatto che chi scrive codice stia facendo un buon lavoro. Ma a volte temo che ci sia uno sbilanciamento quasi nerd su questo punto, che però l’utente non percepirà mai come valore aggiunto. E magari si chiede all’interaction designer o al grafico di risparmiare sull’interfaccia o sulla presentazione. Basta che funzioni, insomma. Quando questo accade, significa che è di nuovo mancato il dialogo nel team, cioè la definizione della qualità e innovazione giusti da offrire per un determinato progetto. Quando si pianifica, uno degli obiettivi è di far emergere il sapere tacito del cliente ma anche del team. È così che si definiscono chiaramente requisiti e funzioni. O almeno, è la strada giusta per farlo.

Una necessaria conseguenza: anche la comunicazione e grafica vanno assorbite dal team.

È ormai chiaro per tutti che lo studio dell’interfaccia è un tesoro per il progetto. Ma dove sono la comunicazione e la grafica? Quando lavoriamo su progetti fortemente orientati alla comunicazione, è d’obbligo mettersi d’accordo con il team per fare in modo che gli sviluppatori non si limitino ai soli aspetti tecnologici. Può sembrare che si chieda di lavorare offrendo una qualità inferiore, ma in realtà si chiede di lavorare offrendo una qualità bilanciata e più opportuna, perché la presentazione impatta sull’emozione e il gradimento visivo o esperienziale di un utente e quindi contribuisce a far funzionare il sistema.

Sono tutti aspetti da chiarire in fase di definizione di un progetto: se si parla di un software, il sistema deve funzionare perfettamente e l’utente deve riuscire a usarlo senza difficoltà; ma su molti progetti web pubblici (e penso anche a molte applicazioni per smartphone), lo scopo (il ROI) non è solo l’esperienza dell’utente ma anche l’obiettivo di business che l’azienda vuole raggiungere, attraverso uno studio accurato della comunicazione.

Riguardando il grafico di Jacopo, noto immediatamente l’assenza dei loop legati al progetto grafico o all’aumento di fedeltà dell’interfaccia: (dalla ux al visual). Il wireframe ha un piccolo loop iniziale e poi vedo molti loop di sviluppo. Io credo che un flusso del genere funzioni molto bene quando si parla di software o comunque di applicazioni molto tecniche. Ma i progetti sui quali lavoro io stanno quasi sempre a metà strada tra la comunicazione e lo sviluppo. La sfida, per me, sarà trovare il modo di integrare il flusso individuato da Jacopo con il mio flusso di lavoro. Cioè come inserire il discorso “comunicazione” (quando c’è) in tutto questo sistema. Questo punto è fortemente sentito dal team con cui lavoro e stiamo cercando di capire come risolverlo.

Non vorrei che l’agile diventasse un rigido paravento di pratiche dietro cui lo sviluppatore si può trincerare, perdendo di vista l’opportunità richiesta dal progetto.

La metodologia agile secondo me ci aiuta a costruire questo terreno comune di fiducia reciproca, avendo rispetto dei nostri ruoli e bilanciandoli in base alle opportunità. In pratica, mi sembra un buon sistema per arrivare insieme a un approccio più maturo sul nostro lavoro. Vorrei che gli sviluppatori smettessero di guardare i visual designer come a fighetti che aggiungono fighetterie inutili. E io non voglio più vedere alcuni sviluppatori come nerd concentrati esclusivamente sul codice.

Breve nota: in questo paragrafo ho volutamente usato il termine “processo” (forse impropriamente) e non metodologia. Mi sembra però che questo territorio sia piuttosto nuovo e quindi non so se esistano parole più corrette. Ad ogni modo processo mi piace, perché mi ricorda un bel commento di Cristiano.

Dopo il CSMA10.

Inizio a tirare qualche filo di una ricerca che ho iniziato appena ho potuto muovermi da libera professionista. Non intendo dire che ho trovato il modo giusto di fare le cose, ma penso di aver iniziato a vedere e capire (uso intenzionalmente questi due verbi) quali sono le attività che devo svolgere per portare un valore sensibile al team di sviluppo. È curioso ed è anche un grande classico: nel momento in cui ho iniziato a capire, mi sono chiesta come mai non riuscissi a vedere prima determinate situazioni. Credo che sia dovuto a un insieme di fattori che a un certo punto, semplicemente, maturano. Diventa più chiara la comunicazione con gli altri, al punto che all’improvviso sembra di parlare tutti la stessa lingua. Diventa spontaneo il tentativo di visualizzare o verbalizzare le criticità, guardandole nelle loro componenti atomiche. Perché è lì, quando le spezzetti, le mostri, le avvicini tra loro e chiedi “intendevi fare una cosa del genere?” che ci si accorge che forse manca una parte o avevi dimenticato o valutato male un aspetto. Capisco quanto mi stanno tornando utili tutte le discussioni a cui ho partecipato nell’ultimo anno. Dall’Agile Day 2009, all’IA Summit di Pisa, dal Whymca allo Experience Camp di Lugano fino al seminario DotNet. Sarà che ho iniziato a scrivere questi post mentre sono ancora pervasa dall’atmosfera che si è creata al CSMA10, però provo un sincero senso di gratitudine verso tutte le persone che negli ultimi mesi hanno condiviso tante delle loro esperienze, conoscenze e punti di vista. Mi hanno scritto in privato, mi hanno fatto riflettere prima, durante e dopo un evento, hanno scritto un post sui loro blog.

Abbiamo bisogno gli uni degli altri. Suona banale, ma è così. Mai come quest’anno, da quando parlo direttamente con gli attori che lavorano su un progetto, ho potuto sentire una voglia reale di spiegare le esigenze e risolvere i problemi. E tutto il gruppo esce vincente, Cliente compreso. :)

12 Commenti
  • I processi agili *sono* il terreno comune per costruire fiducia reciproca. Questo trovo sia un punto essenziale ed un ottimo traguardo. Se ho contribuito solo con mezzo spunto in questo anno a tutto ciò, io sto a posto così ;-)

  • Il software value feedback loop *attende* di essere integrato con nuovi archi. Quello che hai pubblicato esce dal mio cervello di sviluppatore, ma so che può e deve essere integrato, a valle di attente e maturate riflessioni.
    Vediamo un po’ che gli succede passato un altro anno. ;-)

  • Caspita se ci sei riuscito! E grazie anche per l’errata corrige: ho tradotto Scope (inglese) erroneamente in “Scopo” (italiano). Traducendo in “scopo”, mi tornavano i conti con lo schema mentale che mi ero fatta…. e cioè scopo come obiettivo. Se i 4 punti sono variabili, può esserlo anche l’obiettivo.

    Se invece “Scope” significa “portata” o “estensione” puoi dirmi meglio cosa intendi? giusto per rifarmi lo schemino in testa….

    Come dice Quèlo: la risposta era dentro di me, ma era sbagliata. ^_^

  • Claudio Cicali
    set 17, 2010 alle 7:24

    In software programming, lo “scope” è spessissimo tradotto come “visibilità”, inteso come “ambito/contesto all’interno del quale una cosa è valida/visibilie”. Nel contesto del post, io lo tradurrei come “contesto”.

  • Per me sarebbe un termine più comprensibile rispetto a portata. Rispetto alle altre tre variabili, questa mi rimane molto sfuggente.

    Intendo dire: tempo, qualità e budget sono chiaramente individuabili, anche nella loro variabilità. Se sono anche i contesti a variare… ecco, questa variabile mi sembra pesare come un macigno sulla percezione che ho del progetto, cioè del senso che gli do e, una volta di più, del taglio comunicativo che devo dargli.

    O forse no, devo solo digerire il nuovo significato. :)

  • Sebbene “scope” sia una parola usata molte volte nel senso di visibilità nell’informatica, come dice Claudio, nel contesto del post va intesa nell’accezione solita e propria nell’ambito del management.
    Se immaginate che tutte le funzionalità di un software nel loro insieme formino un ‘territorio’, bene, rimuovere o aggiungere funzionalità significa alterare l’estensione di questo territorio. Questa estensione è quindi lo ‘scope’ del sistema o del progetto.

    Se io tengo fissi budget e scadenze e non sono disposto ad abbassare la qualità, l’unica chance che ho è di manipolare lo ‘scope’.

  • Philip Schwarz
    ott 18, 2010 alle 22:24

    This may be of interest: The “Broken Iron Triangle” Software Development Anti-pattern http://www.ambysoft.com/essays/brokenTriangle.html#Impact

  • Philip Schwarz
    ott 18, 2010 alle 22:36

    Riguardo ‘design quality’, Folwer’s Design Stamina Hypothesis may be of interest: http://www.martinfowler.com/bliki/DesignStaminaHypothesis.html

  • Philip Schwarz
    ott 18, 2010 alle 22:41

    See also Ron Jeffries’ “Quality-Speed Tradeoff — You’re kidding yourself” http://xprogramming.com/blog/quality-speed-tradeoff-youre-kidding-yourself/

  • Philip Schwarz
    ott 18, 2010 alle 23:00

    Kent Beck nella prima edizione di Extreme Programming Explained:

    We will control four variables in our projects—cost, time, quality, and scope. Of these, scope provides us the most valuable form of control …

    Here is a model of software development from the perspective of a system of control variables. In this model, there are four variables in software development:

    * Cost

    * Time

    * Quality

    * Scope

    The way the software development game is played in this model is that external forces (customers, managers) get to pick the values of any three of the variables. The development team gets to pick the resultant value of the fourth variable.

    Some managers and customers believe they can pick the value of all four variables. “You are going to get all these requirements done by the first of next month with exactly this team. And quality is job one here, so it will be up to our usual standards.” When this happens, quality always goes out the window (this is generally up to the usual standards, though), since nobody does good work under too much stress. Also likely to go out of control is time. You get crappy software late.

    The solution is to make the four variables visible. If everyone—programmers, customers, and managers—can see all four variables, they can consciously choose which variables to control. If they don’t like the result implied for the fourth variable, they can change the inputs, or they can pick a different three variables to control…

    Lots of people know about cost, quality, and time as control variables, but don’t acknowledge the fourth. For software development, scope is the most important variable to be aware of. Neither the programmers nor the business people have more than a vague idea about what is valuable about the software under development. One of the most powerful decisions in project management is eliminating scope. If you actively manage scope, you can provide managers and customers with control over cost, quality, and time…

    If we created a discipline of development based on this model, we would fix the date, quality, and cost of a piece of software. We would look at the scope implied by the first three variables. Then, as development progressed, we would continually adjust the scope to match conditions as we found them.

    …Quality is terrible as a control variable. You can make very short-term gains (days or weeks) by deliberately sacrificing quality, but the cost—human, business, and technical—is enormous.

  • Philip Schwarz
    ott 18, 2010 alle 23:07

    Kent Beck nella seconda edizione di Extreme Programming Explained:

    As a young software engineer, I learned three variables by which to manage projects: speed, quality, and price. The sponsor gets to fix two of these variables and the team gets to estimate the third. If the plan is unacceptable, the negotiating starts.

    This model doesn’t work well in practice. Time and costs are generally set outside the project. That leaves quality as the only variable you can manipulate. Lowering the quality of your work doesn’t eliminate work, it just shifts it later so delays are not clearly your responsibility. You can create the illusion of progress this way, but you pay in reduced satisfaction and damaged relationships. Satisfaction comes from doing quality work.

    The variable left out of this model is scope. If we make scope explicit, then:

    * We have a safe way to adapt.
    * We have a way to negotiate.
    * We have a limit to ridiculous and unnecessary demands.


    Sacrificing quality is not effective as a means of control. Quality is not a control variable. Projects don’t go faster by accepting lower quality. They don’t go slower by demanding higher quality. Pushing quality higher often results in faster delivery; while lowering quality standards often results in later, less predictable delivery.

    One of my biggest surprises since the first edition of Extreme Programming Explained was released has been just how far teams have been able to push quality as measured in defects, design quality, and the experience of development. Each increase in quality leads to improvements in other desirable project properties, like productivity and effectiveness, as well. There is no apparent limit to the benefits of quality, only limits in our ability to understand how to achieve higher quality.

    If you can’t control projects by controlling quality, how can you control them? Time and cost are most often fixed. XP chooses scope as the primary means of planning, tracking, and steering projects. Since scope is never known precisely in advance, it makes a good lever. The weekly and quarterly cycles provide explicit points for tracking and choosing scope.

  • Philip Schwarz
    ott 18, 2010 alle 23:31

    From “Quality Doesn’t Matter That Much” — Jeff and Joel http://blog.objectmentor.com/articles/2009/01/31/quality-doesnt-matter-that-much-jeff-and-joel ….’Chris’ and ‘Uncle Bob’ discuss what Jeff and Joel said:

    Uncle Bob: “Chris, please point out the dishonesty. Be specific please.”

    Chris: You claim that Joel and Jeff said flat out that, “Quality just doesn’t matter that much.”

    Uncle Bob: It wasn’t a claim, it was a statement of fact. Jeff said: ”…quality really doesn’t matter that much…” He’s wrong. He’s dead wrong. And so is Joel for not jumping on that statement with both feet.

    Chris: What they actually said was that quality was one element that has to be traded off against things like time to market, and delivering features to customers.

    Uncle Bob: They said that too, but they are wrong about that as well. Quality vs. Speed is a false dichotomy. You don’t go faster by making a mess. THAT is my real beef with this whole thing. If you want to go fast, you do the best job you can! High quality is a lubricant not an impediment.

    Chris: To expand the quoted section from less than one sentence to two: “But there’s multiple axes you’re working on here; quality is just one axis. And I find, sadly, to be completely honest with everybody listening, quality really doesn’t matter that much, in the big scheme of things.”

    Uncle Bob: Dead wrong. Quality is not an axis. Quality applies to all axes.

  • Lascia un Commento

    L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *

    È possibile utilizzare questi tag ed attributi XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

    Informazioni e licenza


    Questo blog utilizza Wordpress è basato sul tema Gutenberg, modificato da me con i preziosi consigli di Nicolò e il fondamentale supporto di Luca
    Eccetto dove diversamente specificato, i contenuti del mio blog sono pubblicati con Licenza Creative Commons Attribuzione Non commerciale - Condividi allo stesso modo 3.0 (Italia License).