Progetto ETROM/1

Con questo articolo si inaugura una nuova rubrica che speriamo possa incontrare i vostri favori. Sappiamo di non essere particolarmente originali, ma il termine Gola Profonda si è stampato in modo indelebile nel nostro immaginario collettivo per potervi sfuggire (a partire da film come Tutti gli uomini del presidente in avanti, che avevate capito!). E allora vi esortiamo, fate venire fuori il delatore che è in voi, spiate, denunciate, spargete fluido velenoso nascondendovi dietro allo pseudonimo Gola Profonda: noi vi garantiremo l’anonimato. Unica regola: nomi, aziende, luoghi… non ci interessano, non li vogliamo sapere, quello che vogliamo non è di certo diffamare nessuno, bensì stigmatizzare vizi profondi e superficiali virtù dell’IT di casa nostra.

Come al solito, mandate le vostre segnalazioni a info@stacktrace.it

ETROM

Questo diario di bordo è la storia di un team XP alle prese con un progetto in un contesto tradizionale. In qualche modo, è la storia di culture che a volte si confrontano e più spesso si scontrano. Oppure è più semplicemente la storia di ordinaria umanità alle prese con reciproche incomprensioni.
Il luogo del delitto è rappresentato da Sfiziosi Virgulti, software house di nicchia dal passato storico, in balia dei postumi della Gnù Economy, alla ricerca di un’identità che fa fatica a spiccare, in bilico tra moderne incertezze e antiche illusioni.

Era un giorno d’inverno, in piena era Berlusconi, cinque, dieci o forse cento anni fa. Il team sonnecchiava sugli allori felici di un progetto concluso con successo da troppo tempo ormai. Era giunto il tempo di fare qualcosa. Di cose interessanti all’orizzonte neanche a parlarne. La convivenza forzata tra noi e il resto dell’azienda mostrava tutti i segni di un disastro in attesa di manifestarsi. Era evidente che bisognava agire.

Dopo svariate confabulazioni con Mente Suprema, illuminato manager di Sfiziosi Virgulti, convengo in modo riluttante che è il caso di provare a sporcarsi le mani con un progetto cosiddetto “tradizionale”: un teorico “chiavi in mano” dove si cerca di farsi male il meno possibile, recitando a soggetto per il piacere della multinazionale di turno. Il progetto ETROM per il team XP nasce da queste premesse.

Data astrale 19873.4

Mi piazzo nella sala riunioni con il mio portatile, tanto so già che i miei compagni di merende arriveranno con almeno mezz’ora di ritardo:

  • er Magagna, impareggiabbbile account managgger formato alla scuola della Banda della Magliana, re del cinismo ed esperto in muri di gomma, è un acquisto relativamente recente, ma si distingue subito per la sua spiccata tendenza a sposare la vecchia guardia
  • Nitrito, un po’ project manager (in teoria), un po’ account manager (in teoria), un po’ di niente (in realtà), ha già avuto qualche esperienza con il team XP in passato, purtroppo andata bene per cui per il momento deve fare buon viso a cattivo gioco

Finalmente inizia la riunione. er Magagna ci spiega un po’ più in dettaglio il progetto, le esigenze da cui è nato ETROM (Esibisco Tanto Rumore Organizzato Malamente), a che serve, a grandi linee cosa deve fare: in pratica è una webapp per gli operatori di Gigantica Assurdità che serve a interfacciare il modulo di provisioning di FLOP attraverso un buffo protocollo testuale su socket. Gigantica Assurdità, mega-azienda presente in ogni luogo, caratterizzata da inefficienze organizzative leggendarie, ma ciò nondimeno dedita al machismo aziendale più spinto, ha acquistato da Sfiziosi Virgulti il mirabolante FLOP (Fantastico Luculliano Oscuro Prodotto), piattaforma di integrazione superlativa e ipertrofica, entrata negli annali del software engineering per avere dato una nuova dimensione al significato di “software legacy”.
Perché proprio una webapp? Perché ci sono operatori di Gigantica Assurdità di svariato tipo che devono creare un’associazione tra account ID del sistema di provisioning e ID nel gestionalone (noto anche come HAL -1): come dire, cercare di mettere assieme limone, olio e uova ==> l’unica possibilità è una maionese web con la speranza che non impazzisca. Di fatto per i poveri tapini un’idiotica interfaccia web è comunque il massimo a cui possano aspirare. Curiosità:

  • L’offerta è stata fatta dalla mattina alla sera per cui è priva dell’annesso tecnico. Ciò nonostante c’è un annesso tecnico “interno” che ha scritto Sguardo Vacuo, essere mononeuronale dalle limitate funzioni superiori e project manager di Sfiziosi Virgulti in pianta stabile presso Gigantica Assurdità. L’offerta comprende sia il lavoro di Smottamenti & Frane che quello di Sfiziosi Virgulti (per la cronaca, Smottamenti & Frane è una mini-azienda che collabora con Sfiziosi Virgulti per magnarsi più torta possibile al tavolo di Gigantica Assurdità – S&F ha sviluppato la prima versione di FLOP, chiaramente con l’intento di renderne il codice inintelleggibile)
  • Come er Magagna stesso ammette, il progetto è stato stimato “alla cazzo” (testuali parole): S&F ha stimato 40gg./uomo per la sua parte, con consegna 2 mesi dopo, e Sfiziosi Virgulti ha detto: “Mah, sembra una buona idea, anche noi!”
  • Sguardo Vacuo è il referente unico di progetto e colui che si occuperà del testing ==> nelle intenzioni di Nitrito lui dovrebbe trattarci alla stessa stregua di S&F (interessante come si passa da colleghi a fornitori dal giorno alla notte)
  • Se siamo in grado di rispettare gli economics di progetto e ci mettiamo sopra una coppia di sviluppatori è quasi matematico che finiremo con 1 mese di anticipo ==> consegnamo prima? Certo che no, intanto perché S&F consegnerà non prima della data promessa, e poi perché ciò potrebbe permettere a Gigantica Assurdità di vedere prima l’interfaccia e magari decidere di effettuare delle modifiche; meglio allora dargliela all’ultimo, anzi se possibile anche dopo, così è troppo tardi per effettuare qualunque cambiamento – non ho mai sentito niente di più rigido e immobile, ma non riesco a capire se è colpa nostra (come Sfiziosi Virgulti), di Gigantica Assurdità o di entrambe
  • Nel pacco completo stanno anche installazione, bug fixing, documenti architetturali, manuale di gestione in produzione e test spec ==> è Sfiziosi Virgulti che deve specificare i test, non il cliente, cioè Gigantica Assurdità, mentre è poi il Controllo Qualità di Gigantica Assurdità a eseguirli! Questo approccio è veramente curioso, perché io che pago non specifico i test, ma mi rifaccio a quelli definiti da te fornitore. er Magagna suggerisce di fare test più complicati possibile, in modo tale che il CQ non abbia il tempo reale per condurli e validi l’applicazione d’ufficio. Scherzava?

Giovedì parleremo con Sguardo Vacuo. Inizio a pensare che dovremo tagliare pesantemente sulla qualità per sperare di starci dentro. Ahi!

Parlo con Bovino Inconsapevole, giovane sviluppatore java di Sfiziosi Virgulti che fa della superficialità una ragion d’essere, indicatomi da er Magagna come referente per RicercheInutili, cioè un’applicazione che in passato si è già interfacciata con FLOP facendo cose simili a quelle che dovremmo fare noi. All’inizio è spiazzato e confuso, in fondo io gli sono cascato addosso come un fulmine a ciel sereno. Poi con calma mi dice le due cose meno importanti che volevo sapere, mentre per quella più difficile gli dico che mi va bene saperla per domani pomeriggio. In realtà dopo neanche due ore mi arriva un’email dettagliata, con snippet di codice ben ritagliati, in cui va ben oltre le mie aspettative. Non ho tutti gli elementi, ma va già bene così.

Parlo con Labbroni Epossidici, capace javaista tanto masochista da spendere i migliori anni della sua vita su FLOP, anche lui un po’ spiazzato per la mancanza di preavviso, ma molto efficace e collaborativo. Con lui scopro che mi manca un documento, che l’installazione di FLOP garantitami da er Magagna in Sfiziosi Virgulti per esigenze di testing, in realtà non è così banale da tenere in piedi, non è alla versione corrente (necessita di un upgrade che prima o poi verrà fatto, anche se non credo impatterà molto il nostro progetto) e soprattutto ci sono un paio requisiti che er Magagna non aveva tirato fuori. Mi sembra che i tempi siano sempre più tirati, ma aspettiamo a vedere che dice Sguardo Vacuo tra un paio di giorni. Il colloquio via telnet con FLOP è abbastanza semplice, ma Labbroni Epossidici stesso evidenzia come ci siano alcune varianti cui bisogna stare attenti nella predisposizione dell’ambiente di test.

Tra l’incontro con Bovino Inconsapevole e quello con Labbroni Epossidici parlo con il team. Siamo tutti d’accordo che sul progetto può lavorare al più una coppia. Forse è meglio portare avanti due progetti e basta tra quelli in corso d’opera per evitare un contest switch troppo elevato. Ci ripromettiamo di fare una settimana e vedere come va.
I ragazzi sono contenti che ci sia un progetto, anche se a condizioni pietose, e tutti quanti concordiamo che dobbiamo fare ogni cosa che è in nostro potere per tentare di stare nei numeri menzionati sopra. C’è una piacevole sensazione di sfida, voglia di dimostrare il proprio valore, ma contemporaneamente un senso di inutilità e la percezione di essere relegati su cose marginali. Rintuzzo più che posso, dipingo il futuro in tinte pastello (anche il marrone può essere pastello) e consolido il loro commitment.

Alla fin fine, di chiacchera in chiacchera, oggi ho dedicato suppergiù 3 ore a tentare di capire cosa bisogna fare. Immagino che queste ore vadano decurtate dal monte complessivo di 40 gg./uomo, magari moltiplicandole per 2 o per 10 data la seniority del sottoscritto. Paradossalmente, meno mi occupo del progetto e meglio è, ma come si fa?

Ripenso alla stima che è stata formulata: 40 gg./uomo, ovvero:

  1. 2 mesi di 1 persona,
  2. oppure 1 mese di 2 persone,
  3. oppure 2 settimane di 4 persone,
  4. oppure 1 settimana di 8 persone.

La “quantità” economica in gioco è sempre quella, ma la percezione cambia completamente: 1) sembra molto abbondante, 4) sembra stretto stretto. È il solito problema con i “gg./uomo”: le entità sono confrontabili solo da un punto di vista economico, mentre da un punto di vista di progetto cambiano completamente.

Cerco di non pensarci, provo a fare l’XPer. A naso mi sembra ci siano in gioco almeno 10 user stories, forse di più, dipende molto dall’interpretazione dei requisiti più reconditi e ignorati. Mi rendo conto che questi nascondono almeno 2 o 3 user story che sono state sottovalutate/ignorate. Se in tutto fossero una decina (il che include naturalmente la compilazione dei documenti, preparazione dei test, installazione, ecc.), nell’ipotesi ottimistica che viaggino su un 2-3 gg. ciascuna, parliamo di suppergiù 30 gg./coppia, cioè 60 gg./uomo ==> non ci siamo, ed è già tutto estremamente ottimistico. Dobbiamo inventarci qualcosa, ma aspetto giovedì per vedere che dice Sguardo Vacuo. L’applicazione in sé è semplice, bisogna riuscire a mantenerla tale anche in una formulazione più dettagliata e attenta.

Data astrale 3246.8

Giornata dedicata per lo più ad altro (un po’ di allenamento per Boiatta Poetica, giovane tesista di belle speranze, discussioni varie, progetti interni), tranne un’oretta di riflessione e di chiacchere con er Magagna. Gli faccio un po’ di domande per preparare l’incontro di domani con Sguardo Vacuo. Entro una settimana dovremmo avere in piedi un FLOP 78.24.51.bis-12 (versione di riferimento per questo lavoro): così facendo potremmo iniziare a giochicchiare e fare almeno lo strato di colloquio di più basso livello.

Faccio notare a er Magagna una serie di problemi nella pletora di pseudo-documenti che ho in mano, annesso tecnico compreso. Ad esempio, non si capisce se user/password sono propri della webapp (e quindi da manutenere a parte, a carico dell’applicazione), oppure sono quelli del modulo di provisioning di FLOP (perché pure lui ce li ha). La differenza è notevole, perché nel primo caso a sua volta bisogna capire se l’autenticazione è proprietaria sulla webapp (e quindi bisogna gestirsi ad esempio un proprio schema di database, annessi e connessi), oppure deve essere integrata su un qualche sistema esterno delirante (a detta di er Magagna stesso) con tutte le sue problematiche (magari si trattasse di un LDAP!). Insomma, non lo sappiamo ancora.
Un’altra cosa pessima è che nell’annesso tecnico manca totalmente qualunque menzione della gestione degli errori. Diciamo che è stato fatto supponendo che vada sempre tutto bene, il che è quantomeno naive, avendo a che fare con dei sistemi che si interfacciano su un protocollo di rete. Non abbiamo nemmeno la più pallida idea di come presentare a schermo i messaggi di errore ritornati dal modulo di provisioning e soprattutto come gestire le situazioni di errore stesse.
Così a naso mi sembra un annesso tecnico fatto molto alla carlona, ma spero in considerazioni illuminanti da parte di Sguardo Vacuo.

Non ho ancora messo a fuoco come avviene, in termini di socket programming, il colloquio via telnet, ma mi aspetto che sia di una banalità assoluta. Mi piacerebbe riutilizzare le classi che ha usato Bovino Inconsapevole (scritte da lui? da altri? ereditate da Smottamenti & Frane? per il momento non mi è dato saperlo), ma ho la sgradevole sensazione di avere a che fare con il solito monolito di design immobile, cioè difficilmente estraibile senza portarsi dietro l’universo intero, a tal punto da rendere più conveniente una riscrittura da zero ==> questo è uno dei problemi principali che ha l’anima tecnica di Sfiziosi Virgulti omologa alla vecchia guardia, generato unicamente da imperizia e scarsa consapevolezza dei temi di design; in questo caso, avere una bella mini-libreria da usare come “black-box” per colloquiare con FLOP sarebbe proprio l’ideale e consentirebbe di farci risparmiare un poco di tempo. Mi basterebbe che il tutto sia facilmente rifattorizzabile, ma per il momento ancora non lo so. Devo riparlare con Bovino Inconsapevole.

L’architettura è comunque abbastanza chiara e banale: servlet in Tomcat, pagine web generate dinamicamente attraverso l’uso di un template engine (magari Velocity, come stiamo già facendo in altri progetti), possibilmente una sessione telnet per ogni invocazione (sicuramente inefficiente, ma non meno efficace e molto meno costoso in termini di tempo rispetto a un pool di sessioni telnet cui si acceda in modo condiviso – teoricamente fattibile visto che ogni conversazione con il server sembra stateless), informazioni rese persistenti su db Oracle (sigh) o direttamente su filesystem (magari attraverso Prevayler?). er Magagna stesso non mi sembra un fanatico di db e non gli dispiace l’idea che gestiamo la persistenza senza dover scomodare il DBA di turno, prevedere schemi di creazione, ecc., però non sappiamo se invece questo sia un preciso requisito da parte di Gigantica Assurdità: anche per questo attendiamo delucidazioni da Sguardo Vacuo.

Provo a immaginare quante user stories ci sono.
Innanzitutto 3 user stories per doc architetturale, manuale di operations e test list. Spero che la test list si possa ridurre in una banale estrazione dal repository dei test di accettazione (presumibilmente Fitnesse, ma vedremo). Questi doc saranno sicuramente molto più sacrificati rispetto a quelli fatti per altri clienti. Penso che consegneremo solo lo stretto indispensabile, non un carattere in più, di informazioni dense ed estremamente sintetiche.
Poi ci sono sicuramente 2 pagine web dinamiche, entrambe in 2 varianti diverse: sono almeno 4 user stories, ma probabilmente di più, perché la pagina di amministrazione è un po’ più complessa. Comunque teniamo 4 come numero di riferimento.
Poi abbiamo un meccanismo di doppia conferma da mettere in piedi nel caso dell’operatore semplice e uno scheduler a orari ben precisi nel caso dell’amministratore: 2 user stories, di cui la seconda è veramente una gran rottura di scatole.
L’interfaccia dell’amministratore deve prevedere una logica di accesso mutuamente esclusivo, ovvero una sessione unica con timeout ==> 1 altra user story.
L’impostazione di un flag sfruttabile dal solo amministratore, con una certa logica di verifica e impostazione, potrebbe generare ancora 1 user story. (NB: ancora non sappiamo esattamente che comportamento deve essere implementato).
Mancano ancora autenticazione e gestione degli errori, che in un’ipotesi molto ottimistica potrebbero generare almeno altre 2 + 2 user stories.
Per finire ci sono le installazioni, 1 per il CQ e 1 per Ops: 2 user stories.

Totale: 17

Ahia! Qualche user story sarà anche piccolina, ma allo stato attuale la situazione mi sembra peggiorata rispetto a ieri. Continuo a sperare nell’incontro di domani, ma mi chiedo se il mio è un atteggiamento razionale o inizio a diventare mistico?!?

Comments

  1. Questa divertente storia mi ricorda in maniera molto efficace il mio tirocinio universitario in azienda…. 😀

  2. Ho riconosciuto l’azienda e il progetto MORTE. Complimenti, tutto vero.

  3. badpazzword says:

    TheDailyWTF.com, versione italiana? Non vedo l’ora 😀

  4. Eiopago says:

    Forse l’autore ha dimenticato che Sfiziosi Virgulti gli ha permesso per anni di restarsene tranquillo a contare pomodori, scegliendosi solo progetti alla moda, protetto da Mente Suprema mentre qualcun altro si sporcava le mani con progetti FLOP e clienti come Gigantica Assurdità.

  5. Chissà perché certe storie mi suonano familiari 😉

    Bella l’idea, un po’ contorto il primo racconto, ma mi rendo conto che più chiari non si poteva essere!

  6. L’autore dimentica che il progetto FLOP (che putroppo ha consentito di pagargli lo stipendio per un solo mese…) con gente diversa da lui sarebbe durato meno di quanto lui ha probabilmente impiegato a scrivere questo post

  7. Forse Santone imbronciato non vuole ricordare da quali progetti arrivavano le risorse che permettevano il verificarsi del miracolo mensile dello stipendio, evento che trasferiva una bella polpetta nella sua dispensa. Infatti, i bilanci del suo team erano più rossi dei pomodori che contavano ogni giorno …

  8. NonCiPossoCredere says:

    IIlluminante visione di come un ordinario progetto di una “idiotica interfaccia web” da 40 giorni/uomo (ma facciamo anche 60 visto che era “stimato alla cazzo”) sia rappresentato in una mente cosiddetta agile (almeno questo è l’agile che abbiamo conosciuto noi).

  9. VecchiaGuardia says:

    Non è curioso che nessuno in Sfiziosi Virgulti si ricordi di un solo progetto concluso con successo dall’autore?. Molti ricordano invece le sostanziose perdite accumulate per permettere al suddetto, sempre ben pagato, di perseverare a oltranza nei suoi riti da sciamano del software.

  10. le storie saranno anche magari in direzione thedailywtf-alike. ma sui commenti c’è da lavorare di brutto… se avete cose da dirvi fatelo di persona, o almeno aprite una mailinglist 🙂

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.