Teamwork in finale al Jolt Productivity Awards

Intervista a Pietro Polsinelli e Roberto Bicchierai di OpenLabdi

Teamwork: un software italiano per il project management tra i finalisti ai Jolt Productivity Awards! Scopriamone i segreti e i retroscena nella nostra intervista agli artefici di questo risultato.

Introduzione

Il primo incontro con gli amici di OpenLab risale alla JAOO conference dell‘anno scorso, in cui eravamo gli unici italiani presenti. Da quell‘incontro è nata l‘idea di uno o più articoli incentrati su Teamwork e sul modello di sviluppo adottato. Poi la nomination per i Jolt Awards ha un po‘ rimescolato le carte ed è nata l‘idea dell‘intervista.

Alberto Brandolini: Ciao. Innanzitutto complimenti per la nomination! Potete raccontarci come è andata?

Pietro Polsinelli: Noi ci siamo iscritti sostanzialmente per caso, su suggerimento di amici. Al Jolt Awards bisogna inviare materiale di presentazione abbastanza dettagliato e offrire una modalità  di fruizione dell‘applicazione. Questo per l‘accesso alla fase di selezione, che è quella più dura. A quel punto per motivi "misteriosi" siamo stati selezionati. Passata la selezione devi mandare materiale più approfondito ai 6 giudici del tuo "settore"... l‘abbiamo fatto e adesso aspettiamo la sentenza.

A.B.: A quando il verdetto finale?

P.P.: Il 21 marzo. A Santa Clara, presso S.Francisco. Ovviamente ci saremo anche noi.

A.B.: Beh, un bel viaggio a S.Francisco non si rifiuta. Parliamo della vostra applicazione, come nasce? Avevate individuato un vuoto nel mercato? Ã? un prodotto interno che è cresciuto?

P.P.: Allora, in realtà  entrambe le cose: l‘applicazione nasce constatando l‘esigenza diffusa e non soddisfatta dai prodotti esistenti, quindi abbiamo seguito un po‘ il principio dell‘"eat your own dogfood" e abbiamo iniziato utilizzandola internamente, ma anche molto rapidamente presentandola. Questo soprattutto per il primo Teamwork (siamo alla versione 3.0 n.d.r.). Da qui. il percorso per arrivare ad un prodotto maturo è stato lungo: parliamo di 5 anni di prove, esperimenti e cambiamenti di rotta. Il prodotto è giunto alla versione attuale con la maturazione della tecnologia utilizzata, che sostanzialmente è il framework web su Java e il motore di persistenza basato su Hibernate. La stabilità  dei framework di backend ci ha consentito di concentrarci sulle caratteristiche dell‘interfaccia utente; questo ci ha permesso di trasformare un‘applicazione J2EE in un componente di supporto a un prodotto a tutti gli effetti. In questo Teamwork è abbastanza particolare: ben pochi utilizzano le tecnologie J2EE per fare un prodotto generalista, come è Teamwork.

Roberto Bicchierai: considera fra l‘altro che l‘evoluzione dell‘applicazione è tutta basata sull‘evoluzione dell‘interfaccia utente: il modello a oggetti sottostante, anche se complesso, in realtà  è ormai stabile ormai da qualche anno. Il nuovo sviluppo viene effettuato principalmente lavorando sull‘usabilità , che è lo scoglio più grosso delle applicazioni web.

P.P.: Questo vale in particolare con applicazioni come queste, cioè di tipo collaborativo, che cercano di allargare il gruppo di lavoro; gruppo non limitato ai soli sviluppatori, ma esteso anche a chi si occupa di problemi di tipo organizzativo sia pure legati al mondo del software, anche con l‘obiettivo di avvicinare una platea non necessariamente tecnica a problematiche con un modello molto complesso. La sfida è quella di progettare interfacce semplici per l‘accesso a un modello complesso come quello del project management e del groupware, ed è infatti su quest‘area che si è concentrata la maggior parte del nostro sforzo.

A.B.: In effetti in questo settore, se c‘è una caratteristica dominante, è che ogni organizzazione ha il suo modo di vedere il project management, e richiede uno strumento che faccia esattamente le cose "come le vede l‘utente".

P.P.: Questa è stata una delle nostre considerazioni dal punto di vista dell‘architettura. Noi ci siamo detti: è un prodotto generalista, ma è anche orientato alla piattaforma J2EE nel senso che si tratta di un‘applicazione con un‘infrastruttura aperta ed estremamente integrabile, sia verso strutture relazionali, sia tramite API rivolte verso l‘esterno per facilitare lo scambio di informazioni con Teamwork, sia in ingresso che in uscita. Tutto questo gestito compatibilmente con requisiti di sicurezza che tengano conto del fatto che viene coinvolto il core dell‘azienda, e che la gestione dei progetti è un‘area in cui non si può transigere dal punto di vista della riservatezza. Il modello deve essere quindi in grado di essere articolato, fine-grained, ma non impossibile da usare.

A.B.: Quindi, in uno scenario standard, possiamo o installarlo in modalità  standalone gestendo gli utenti al suo interno, oppure integrarci con un database di utenti aziendale, LDAP o altro?

P.P.: Esatto, ma il problema centrale non è tanto l‘accesso all‘archivio degli utenti, quanto la possibilità  di differenziare le esigenze di sicurezza, da progetto a progetto. Esigenza che hanno in realtà  quasi tutte le aziende e che è difficilissima da soddisfare. In questo credo che Teamwork sia notevole, se non unico.

A.B.: Quindi ogni progetto ha associato il suo contesto di sicurezza.

P.P.: Sà¬, perchà© in realtà  questo deriva direttamente dal contesto organizzativo del lavoro, ed è con questo che siamo riusciti a ottenere una certa usabilità  in quest‘area. Questa forse è la caratteristica più distintiva di Teamwork: quella di riuscire a supportare un modello articolato di sicurezza, pur non facendo impazzire l‘utente nel configurarlo, oltre ad essere un sistema pluggabile rispetto alla struttura dell‘azienda esistente. Per questo interessa soprattutto ad aziende che hanno già  una certa struttura e una certa complessità . Trattandosi inoltre di un prodotto open source, tutte queste caratteristiche insieme lo rendono appetibile per aziende che abbiano una realtà  IT complessa; riescono infatti a inserirlo fra i propri strumenti aziendali senza stravolgere i propri standard.

A.B.: Uno dei punti interessanti, rispetto ad altri strumenti di project management, è proprio il fatto che si ponga a un livello diverso rispetto all‘organizzazione, rispetto a strumenti più "piatti" rispetto al ruolo. Teamwork permette di evidenziare il ruolo rivestito dalla persona in uno specifico contesto e non la semplice associazione tra persona e task.

P.P.: Esattamente. In questo da parte nostra c‘è un approccio un po‘ particolare derivato dalla letteratura riguardante il teamware e dall‘analisi dei progetti (più che altro la letteratura è una collezione di insuccessi...): il nostro obiettivo era quello di coinvolgere sullo strumento tutto il team di sviluppo, non soltanto i tre o quattro core developers, ma anche chi si occupa di customer relationship, chi si occupa della vendita, i manager a tutti i livelli, in modo che le informazioni di valutazione siano complete ed aggiornate. Permettendo ad esempio di gestire situazioni, come quelle tipiche di SCRUM, in cui isoli il gruppo di sviluppo sulla base di un contratto. Ã? possibile definire una sicurezza fine grained per creare delle "isole" di utilizzo ed essere compatibili anche con questo scenario. Nota come in pochi minuti abbiamo delineato dei modelli di sicurezza radicalmente diversi ma che l‘utente di questo tipo di software ritiene naturali.

R.B.: Tornando al caso di SCRUM: la copertura rispetto a questo caso è stata ottenuta sulla base del modello iniziale, semplicemente definendo dei ruoli specifici in cui lo SCRUM master, lo SCRUM team e cosଠvia sono stati identificati. I permessi erano invece già  definiti: è stato sufficiente metterli in relazione con i ruoli specifici. La modellazione dello scenario SCRUM alla fine ci è venuta quasi gratis.

A.B.: Quindi un eventuale plugin RUP potrebbe nascere alla stessa maniera?

R.B.: Probabilmente, è per questo che Teamwork risulta cosଠinteressante per gli sviluppatori: perchà© è abbastanza facile utilizzarlo con una metodologia oppure con un‘altra.

P.P.: Nota che non ha l‘ambizione di rimpiazzare i tool specialistici quando questi servono. In questo caso, la cosa migliore è limitare l‘uso di Teamwork alla gestione del gruppo e del progetto, e magari delegare alcune funzioni ad esempio linkando uno specifico tool per l‘issue tracking integrato nell‘IDE, tipo quello presentato da Erich Gamma alla OOP conference in Germania (JAZZ n.d.r.). Una cosa che caratterizza Teamwork è il fatto che si possa fare un po‘ tutto: gestire la condivisione delle informazioni, il diario del progetto, l‘assegnazione dei task, ma niente impedisce di gestire una parte degli aspetti di coordinamento delegandoli a strumenti già  esistenti.

R.B.: I vantaggi maggiori li hai quando riesci a gestire tutto all‘interno di Teamwork, però nessuno ti vieta di agganciarti all‘esterno. La struttura del DB è comunque aperta e intelligibile, e corredata da tutte le API che ti servono per la lettura e per agganciarti agli oggetti di sistema. Viene quindi naturale pensare a delle verticalizzazioni fatte in casa che ti permettano di agganciarti all‘esistente.

A.B.: Avete già  definito dei punti di contatto con l‘esterno?

P.P.: Una cosa che abbiamo implementato recentemente è l‘esposizione delle classi di Teamwork come web service tramite Axis. Inoltre è già  presente l‘import/export con Microsoft Project, e stiamo lavorando sull‘integrazione delle API di Lucene basandosi sull‘implementazione di Hibernate nella versione 3.x e anche con MSOutlook ed MSExchange Server, Google Calendar, e l‘integrazione mediante il formato iCal. Abbiamo infine integrato JBPM, il motore di workflow di JBoss nella nostra applicazione, che è in grado di girare nella stessa sessione Hibernate in cui stiamo facendo girare Teamwork. Inoltre abbiamo anche una componente server side per la gestione dei flussi JBPM, che è integrabile con Teamwork.

A.B.: In effetti anche le nostre esperienze con JBPM sono state positive. Ha fatto il suo dovere con onore. MS Project è normalmente il punto di partenza "standard" per le attività  di project management, quindi voi state facilitando la strada per chi voglia abbandonare Project o semplicemente provare il vostro tool.

R.B.: La critica maggiore che noi muoviamo a Project, e a strumenti di questo tipo, è che sono pensati per il project management o comunque "dall‘alto verso il basso"; poi però sono carenti nella gestione del progetto in corso di avanzamento. Questo principalmente per carenze a livello di interfaccia: solo presentando un‘interfaccia gradevole ed utilizzabile puoi pensare di poter coinvolgere anche i livelli più bassi della tua gerarchia all‘utilizzo dello strumento.

P.P.: Noi abbiamo avuto un feedback molto articolato dai nostri amici di Java Black Belt ([5]) in cui alcuni degli utenti hanno reagito male alla prima adozione di Teamwork, perchà© lo hanno visto come un modo per essere "controllati", mentre in genere non è mai cosà¬: il controllo in azienda avviene con altri mezzi, mentre questo è uno strumento che aiuta a monitorare la qualità  del lavoro, abbassando il livello di disorganizzazione che tende a minare la qualità  del lavoro. L‘obiettivo in effetti è quello del miglioramento della qualità  del lavoro, non del controllo in senso stretto.

A.B.: Spesso però la situazione è capovolta: è il Project Manager che richiede l‘interfaccia carina per le proprie operazioni, mentre non tiene conto dell‘usabilità  per le altre fasce di utenti.

R.B.: Una cosa buffa che abbiamo verificato è che quelli che sono incontentabili sono proprio i Project Manager: alcuni sembrano più interessati alla definizione del progetto a monte che alla sua gestione nel quotidiano.

A.B.: La maggior libertà  nella definizione dell‘interfaccia utente, permessa da strumenti come Ajax, permette di superare la distanza legata all‘usabilità . Ricordo che mi avete accennato ad un modello di programmazione particolare sull‘interfaccia utente.

P.P.: Abbiamo lavorato principalmente per abbassare la soglia di adozione. L‘utilità  di questi strumenti è proprorzionale al numero di persone che li adottano. Per aumentare l‘usabilità  abbiamo adottato un modello misto tra stato HTTP e un modello ad eventi che si appoggia ad Ajax. Questo perchà© un modello misto dà  vantaggi a tutti: permette feedback immediato per l‘utente, ma per le parti più legate a form submission continuiamo a usare il classico submit della richiesta dell‘intera pagina.

R.B.: Abbiamo trovato più benefici nell‘aggiungere comportamenti Ajax-based alla struttura esistente, che non passare tutto a un‘interfaccia completamente ridisegnata sul nuovo modello, anche solo per il costo in termine di tempo per ridefinire integralmente l‘interfaccia.

P.P.: A ben guardare tutte le applicazioni completamente Ajax-based di nuova generazione sono in genere nuove, e molto semplici, per poter partire da zero. Non è detto che la tecnologia sia completamente matura per la gestione di un‘applicazione complessa delle dimensioni di Teamwork, per potersi appoggiare unicamente sul modello a eventi. Anche sul mercato sono presenti modelli molto alternativi: manca ancora il modello di riferimento della nuova generazione. Sarebbe troppo rischioso per noi e per i nostri clienti buttarci a pesce su una sola di queste opzioni in questo momento.ù

R.B.: Tra l‘altro, in alcune parti di Teamwork i vantaggi sarebbero minimi. Ci siamo concentrati sulle parti che offrivano vantaggi significativi.

A.B.: In effetti la logica del tutto in una pagina fa a pugni con la modularizzazione di applicazioni complesse. L‘architettura della vostra applicazione si può riassumere in questo modo: una parte server side più o meno tradizionale, con la presentation basata su un framework MVC. Ã? una soluzione standard o sviluppata in casa?

P.P.: Ã? una componente sviluppata in casa: un MVC molto light, con un Front Controller, mentre "dietro" ci basiamo su Hibernate 3. Questo è rilevante perchà© abbiamo cominciato a introdurre tutta la gestione appoggiandoci sulle annotations. Sul lato client, invece, HTML e Javascript + Ajax per migliorare la responsività  delle pagine.

A.B.: Il tutto gira sotto jBoss?

P.P.: No, è sufficiente uno standard web container, Tomcat ad esempio. Ã? necessaria però la compliance agli standard Java 5. Siamo anche compatibili JDK 6, che non è molto difficile... basta non fare niente...

A.B.: Per quanto riguarda l‘interfaccia utente, come avete affrontato la parte non tecnologica del miglioramento dell‘usabilità  dell‘applicazione? Come studiate il comportamento degli utenti?

P.P.: C‘è un grande apporto di feedback da parte della nostra community, oltre alla letteratura specifica ([1], [2]) ma oltre allo studio, abbiamo un gruppo dedicato al design, e una grande fonte di informazioni che è Roberto stesso... se è approvato da lui, in genere il cliente è già  soddisfatto.

A.B.: Visivamente sono due le parti maggiormente in evenienza: a parte il plugin per SCRUM di cui abbiamo già  parlato, una è la dashboard iniziale customizzabile che aiuta a entrare nel contesto dello specifico progetto, nell‘ottica del "vediamo cosa c‘è di nuovo oggi".

P.P.: Nota che è completamente customizzabile via drag & drop, cosa che ha comportato dei dolori atroci in sviluppo, anche perchà© l‘applicazione gira sia su Explorer che su Firefox. Però ora funziona, e la stiamo espandendo con nuove funzionalità , ad esempio un componente ad albero Ajax-based su cui ridisegneremo le parti di gestione dell‘albero dei progetti.

A.B.: L‘altra caratteristica carina era la presenza delle sticky notes, stile post-it, che effettivamente rendono più familiare l‘ambiente di lavoro. Assomigliano a ciò che trovi sulla scrivania se stai un paio di giorni in ferie.

R.B.: Infatti è proprio questo lo spirito di quegli oggetti. Si chiamano semplicemente sticky notes perchà© non potevamo utilizzare il nome ufficiale per problemi di copyright.

P.P.: Questo è proprio un esempio della filosofia che abbiamo cercato di implementare. Per noi è più importante cercare di fare qualche cosa che è già  familiare all‘utente, intuitivo, piuttosto che creare una funzionalità  di Earned Value Analysis, che piace molto a una categoria di utenti, ma che nella gestione quotidiana non mi serve a granchà©. Per noi l‘utente è l‘intero team e non solamente il Project Manager che lo coordina.

R.B.: Se l‘obiettivo è questo tipo di analisi, è pensabile che questo sia definito con Project e sincronizzato con Teamwork. Lasciando a Teamwork la gestione delle interazioni e lo scambio di informazioni tra i differenti membri del gruppo di progetto, tramite messaggi, SMS ed e-mail, RSS feed e cosଠvia. La gestione del feed RSS tiene comunque conto delle problematiche di autorizzazione, permettendo all‘utente di vedere il feed delle informazioni a lui concesse.

A.B.: Cambiamo argomento, in che cosa è diverso per una software house italiana affrontare il mercato estero?

P.P.: Se si vuole fare un prodotto per il mercato internazionale, bisogna fin dall‘inizio creare un‘immagine del proprio prodotto legata alla qualità ; non investendo più sul mercato diretto, ma curando soprattutto il sito e la percezione dell‘immagine. Ovviamente, dal punto di vista applicativo, va tenuto conto di tutte le problematiche legate all‘internazionalizzazione, utilizzando supporto multilingue, codifica UTF-8. Poi però le cose si semplificano: società  con una cultura informatica più strutturata della nostra sono più rapide ad adottare questo tipo di strumenti. Hanno bisogno di molta meno interazione: sui mercati tedesco, inglese, americano, ma anche dell‘Europa dell‘est, questo tipo di prodotto viene capito immediatamente. Per noi è un‘esperienza interessantissima; per certi aspetti siamo una delle pochissime software house italiane che cerca di muoversi in questo modo. Chiaro che arrivare al break-even economico non è banale, perchà© si tratta di "sfondare", con un prodotto che è a bassissimo costo e con un investimento sull‘estero non indifferente.

A.B.: In effetti il prezzo della vostra soluzione è decisamente interessante (si parla più o meno di 30 â?¬ per client n.d.r.), specialmente se raffrontato con prodotti concorrenti.

P.P.: Abbiamo avuto modo di confrontarci con soluzioni "di marca" che costavano decisamente di più.

A.B.: Come gestite il feedback degli utenti sparsi per il mondo?

R.B.: Attualmente abbiamo due categorie di clienti: quelli che hanno sottoscritto un contratto di supporto che ci contattano direttamente. Altrimenti si usa il canale pubblico, che è il forum. Stiamo abbastanza attenti a controllare il forum e a garantire risposte rapide, e a integrare le modifiche in rilasci piuttosto frequenti. A breve rilasceremo la versione 3.2.0. Chiaramente all‘interno utilizziamo Teamwork per coordinare il tutto nel gruppo di sviluppo spostandolo sui vari sottoprogetti collegati alle differenti release pianificate.

P.P.: In alternativa i clienti hanno a disposizione un meccanismo di submission automatizzato dei bug verso di noi. Teamwork poi ci permette di spostare le segnalazioni e le feature da una versione pianificata all‘altra in maniera molto semplice. Quello che ci ha fatto conquistare tanti clienti è stata anche l‘estrema reattività  sia sul bug fixing che sull‘implementazione di nuove feature. Su questo abbiamo dei tempi invidiabili, caratteristica legata al fatto di essere un team molto piccolo, che è il nostro problema, ma anche la nostra qualità .

A.B.: Hmmm, direi che dal mio punto di vista ho poco altro da chiedervi. C‘è qualcosa che vorreste aggiungere?

P.P.: Il nostro software è ridicolmente facile da installare, cosa che per un‘applicazione J2EE non è sempre detta. Abbiamo creato un installer veramente semplice per facilitare anche l‘installazione di prova.

Riferimenti

[1] Alan Cooper, " The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity", SAMS, 1999.

[2] Joel Spolsky, "User Interface Design for Programmers", Apress, 2000.

[3] Il sito ufficiale di Teamwork

http://www.twproject.com

[4] L‘elenco dei finalisti ai Jolt Productivity Awards del 2007

http://www.joltawards.com/2007/

[5] Il riferimento a Teamwork sul sito di Java Black Belt

http://www.javablackbelt.com/NewsView.wwa?newsId=3518389

Condividi

Pubblicato nel numero
115 febbraio 2007
Ti potrebbe interessare anche