Mi piace l’odore del Napalm la mattina…

 

Smaltiti i bagordi natalizi (sì, siamo bravini ma lenti), torniamo a noi. Dove eravamo rimasti? Ah sì, parlavamo di fallimenti!

Progetti consegnati in ritardo, obiettivi mancati, budget sforati, team demotivati, mail di avvocati, scuse, migliaia di scuse, montagne di scuse.

kanban3-2

“Ti prego, ti prego, non mi uccidere. Ti prego baby, lo sai che ti amo. Non avrei mai voluto lasciarti, non è stata colpa mia. Davvero, sono sincero. Quel giorno finì la benzina. Si bucò un pneumatico. Non avevo i soldi per il taxi! Il mio smoking non era arrivato in tempo dalla tintoria! Era venuto a trovarmi da lontano un amico che non vedevo da anni! Qualcuno mi rubò la macchina! Ci fu un terremoto! Una tremenda inondazione! Un’invasione di cavallette!…”

 

Generalmente al nobile e profondo animo dei commerciali è affidato il delicato e gravoso compito di comunicare al cliente le drammatiche derive assunte dalla commessa. Il capo progetto, una bella mattina, senza lasciar trasparire emozione alcuna, entra nel tuo ufficio. Da quell’anaffettivo grave che è (perché è dimostrato, gli IT non provano sentimenti) ti consegna questa bella novella: “Devi chiamare il cliente, fa parte del tuo lavoro, non t’invidio”. Devi dirgli nell’ordine che:

  • siamo in ritardo e per la fiera non se ne fa nulla (c’è sempre una cazzo di fiera)
  • il sistema va in crash e non è colpa nostra (ovviamente), stiamo cercando di capire cos’è. Brancoliamo nel buio, prendiamo tempo
  • ci sono state chieste 28.567 implementazioni che non erano nel contratto. Non gliele facciamo. Diglielo. Ciao

 

Il dialogo prosegue con commenti che scendono sul personale. Chiaramente quello del cliente:

  • quello non lo sopporto
  • non capisce nulla di web, poco in generale comunque
  • l’avevamo avvisato

 

Il capo progetto, senza nessuna comprensione, ti lascia solo.  La stanza lascia spazio a silenzio e sconforto, rimangono solo le tue paure e quella telefonata da fare. Queste dinamiche ormai sono un ricordo del passato, quando si stimavano i progetti dalla genesi sino alla presunta fine, ci si accapigliava per una riga di codice con il cliente, si lavorava a corpo (non al corpo…a corpo).

Domani si va tutti all’Agile Day!

Ma domani sarà sabato! Replicavi con tono fantozziano.

Fa niente, l’azienda viene prima di tutto

Al netto dell’ironia più bassa che si possa spendere all’indirizzo di una metodologia che nei propositi dovrebbe salvarti la vita e di nome fa AGILE  – agile de che…. – ci troviamo un giorno tutti coinvolti in questa gita lavorativa sabatina.

Ecco il resoconto:

  • mangiato male come neanche su una compagnia aerea del Burkina Faso (nessun si offenda, ma sulle libagioni occorre lavorare. Molto e anche agile)
  • introiettati milioni d’informazioni, dati, case history al limite della lesione cerebrale irreversibile
  • intravisto la luce: Io cliente, tu fornitore: peace and love. Si può fare.

kanban3-3

 

Al termine di otto estenuanti ore di erudimento, lasciamo l’Alma Mater di Ancona con la percezione, lontana, di poter un giorno firmare un contratto senza aver la chiara e netta sensazione di star compiendo un’enorme e irrimediabile minchiata.

La mia personalissima definizione di Agile trova la più fedele rappresentazione in:

kanban3-4

“inizio presto, finisco presto e di solito non pulisco il water…”. 

 

Come a dire:

“S’inizia a lavorare subito, generalmente si finisce in fretta, se siamo stati bravi non facciamo troppi danni cui dobbiamo riparare”.

L’uso del termine agile per riferirsi a metodi di sviluppo software fu introdotto dal Manifesto Agile pubblicato nel 2001.

I principi sottostanti al Manifesto Agile (come dire…non avrai altro Agile all’infuori di me…), sono diventati il nostro vangelo, nostro padre e nostra madre.

Scorriamo e commentiamo (con occhi e lingua biforcuta da account), come in una lenta omelia, i sacri principi del Manifesto agile…

 

  • La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.

Subito e Continuo: Musica per le orecchie un commerciale… Liberi dal giogo delle giornate uomo, a obiettivo unico viene issata la soddisfazione del cliente, il quale non è più costretto ad aspettare giorni, mesi, anni per dare un’occhiata a qualcosa che non comprende neanche minimamente, ma può iniziare da subito a mettere qualcosa sotto i denti (odio le metafore, qui ci stava): un mock up, un’interfaccia grafica, l’installazione di un CMS, ecc.;

Il progetto, infatti, è realizzato per unità incrementali dette iterazioni. Il tempo di sviluppo di ciascuna iterazione è generalmente rarefatto (in media due settimane), fisso e rigorosamente rispettato. Ogni iterazione rappresenta un incremento delle funzionalità del sistema. La lavorazione della prossima iterazione, ha inizio solamente ad approvazione incassata della precedente.

 

  • Accogliamo i cambiamenti nei requisiti anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.

I cambiamenti come un vantaggio: estasi pura! Nella vita precedente il cambiamento in corso d’opera era visto come il male assoluto, Lord Broke di Sandokan, la lebbra, la fine. Infiniti e snervanti triangoli capo progetto – account – cliente, calati obtorto collo, nel patetico e a tratti ridicolo, reciproco gioco delle parti. Il progetto, tirato per la giacchetta, non procedeva, lo faceva ma come monco, sfociava in un compromesso squallido e inefficace. Ora – da Agili – è visto con favore…

 

  • Consegnamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.

Consegnamo, è già questo è (come dicono i giovani) tanta roba. Lo facciamo di frequente, arrivando a preferire i periodi brevi. Vabbè…ciaone (sempre i giovani).

 

  • Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.

In questo passaggio, quelli del Manifesto l’hanno messa giù un po’ dura. Sovraintendere un’intesa pressoché quotidiana, tra cliente e sviluppatori, nella migliore delle ipotesi porterebbe alla demenza anche il più centrato dei venditori. Vero è però, che è richiesto un frequente e costante confronto tra le parti, per consentire al progetto di rimanere intimamente fedele alle esigenze del committente, evitando pericolose e disfunzionali derive.

 

  • Fondiamo i progetti su individui motivati. Diamo loro l’ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.

Le società di servizi come la nostra, affidano le loro sorti agli uomini, non hanno molto altro. Team che lavorano per obiettivi, che hanno autodeterminato i modus di sviluppo. È l’unica strada per ottenere risultati efficaci. Tutto ciò che viene imposto dall’alto sarà avvertito come un’imposizione e sarà svolto in modalità “compitino” e la responsabilità sarà sempre di qualcun altro.

 

  • Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team e all’interno del team.

Lo sviluppo delle iterazioni, gli atomici dell’Agile, prevede una modalità di lavoro in team e disincentivano l’utilizzo di strumenti tecnologici per comunicare con essere umani che risiedono a 25 cm lineari dalla tua postazione;

 

  • Il software funzionante è il principale metro di misura di progresso.

Se funziona è buono, se non funziona è male. Molto bianco e nero, poco grigio. Ci si misura su un univoco e difficilmente controvertibile metro di valutazione, il lavoro svolto, preordinato di comune accordo con il committente.

 

  • I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.

Secondo il noto adagio “poco e bene”. Stiamo fuggendo da progetti con proiezioni incerte e difficile da sostenere. Le iterazioni condivise con il cliente, devono essere ben definite nei tempi e nei modi, così da non ricadere in pericolose e nefaste derive di lavorazione non sostenibili. Risultato? L’irritante “mi serviva ieri” è quasi estinto.

 

  • La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità.

Lavoriamo in un ambiente protetto. Fuori dalla porta dovremmo aver lasciato snervanti discussioni sui tempi, i modi, i costi, elevando a massimo obiettivo la riuscita tecnica e tecnologica del progetto.

 

  • La semplicità – l’arte di massimizzare la quantità di lavoro non svolto – è essenziale.

Montagne di giornate uomo che finiscono non si sa bene dove, rimpalli sulle imputazioni: commerciali, supporto al cliente scatenano cruente guerre intestine, evitare gli sprechi. Stringendo: in Agile si fa, non si parla. E se si scrive, si scrive codice. Non si lavora sul lavoro.

 

  • Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.

Onori e oneri. Lavorare per obiettivi, assunzione di responsabilità, autogestione del team, come a dire “tanto a sbagliare siamo capaci da soli…”.

 

  • A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.

S’impara da se stessi, innescando un circolo virtuoso che non ha mai fine e che genererà una sorta di selezione Darwiniana nelle organizzazioni. Questa metodologia spinge i componenti del team a collaborare e prendere decisioni veloci ed efficaci. Il team vivrà di vita propria, in una dimensione che travalica il singolo:

“Se lanci la maglia, sei fuori”. Mourinho docet.

 

Chiudiamo con i conti della serva. Con questa metodologia, trova impiego anche la formula del “lavoro, guadagno, spendo e pretendo”.

Il cliente al termine di ogni iterazione ha l’opportunità di:

  • Accettare il lavoro, accettare la fattura, pagare (anche le funzioni amministrative sono oggetto di accelerazione)
  • Evidenziare criticità e concordare con l’agenzia gli aggiustamenti del caso (che potrebbero anche tramutarsi in una nuova iterazione)
  • Rifiutare il lavoro e non essere obbligato a pagare alcunché, essendo libero di rivolgersi ad altri (le eventuali iterazioni precedenti rimangono di sua proprietà)

Meglio di così…

Ti piace il nostro metodo di lavoro? Hai bisogno di sviluppare un progetto AgileContattaci!