Archivio 2007
Agile Estimation
Stavo cercando qualche informazione in più su come pianificare, in un progetto agile, le iterazioni e le user story per ogni iterazione e su come stimare i tempi. Ho trovato su YouTube il talk completo di Mike Cohn su “Agile Estimation” fatto a Marzo del 2007. Vale la pena ascoltarlo anche se è lungo 90 minuti.
Parte I
http://www.youtube.com/watch?v=fb9Rzyi8b90
Parte II
http://www.youtube.com/watch?v=jeT0pOVg0EI
Da qui potete scaricare le slide del talk.
Inoltre, molto interessante è anche questo post di Mike Cohn sugli Story Points. Lui ritiene che non dovrebbero essere usati come misura di produttività:
Using story points or ideal days to measure productivity is a bad idea because it will lead the team to gradually inflate the meaning of a point when trying to decide between calling something “two points” or “three points” [...]
My view is that points can be used as the best way to estimate and assess progress that we’ve ever had or they can be used as another weapon with which to hit the team [...]
E ci sono tanti altri post interessanti sul suo blog, come questo:
A common source of confusion on agile teams occurs when the sprint (“iteration”) backlog and the product backlog are both estimated in hours. To avoid this confusion I strongly recommend estimating these backlogs in different units.
In sprint planning the team should always talk of tasks and hours. Sprint planning covers the horizon of typically two to four weeks out.
In release planning the team can choose between “ideal days” and “story points”. Regardless of which they choose, they still do sprint planning in hours [...]
[...] I don’t use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term [...]
REST
Mi scrive uno studente della laurea specialistica (sarà lui, se vorrà, a rivelare la propria identità nei commenti).
voglio segnalarvi un link molto interessante sull’architettura REST e in particolare sul progetto che IBM ha lanciato prima che qualche altro Rest-incubator prende piede (Restlet ad esempio) integrandolo come al solito in
Eclipse: Project Zero. Visto che ultimamente sto lavorando su questo stile architetturale per WS ho trovato tutto molto interessante.
http://www.infoq.com/articles/rest-introduction
http://www.projectzero.org/wiki/bin/view/Main/WebHome
La segnalazione è molto interessante e meritava la segnalazione. L’autore meriterebbe di poter postare senza filtri sul collablog.
The Semantic Web and Social Web are essentially compatible
E’ il microscopico abstract di un ottimo articolo introduttivo appena pubblicato su Computer da Alexander Mikroyannidis, dell’università di Leeds. Vale la pena leggerlo.
L’inventore del termine Folksonomy ha qualcosa da ridire…
Con mio grande stupore ho letto questo breve post di Thomas Vander Wal, in cui colui che ha coniato questo termine (spesso criticato) in qualche modo si ribella (molto pacatamente) all’accostamento del termine folksonomy con il termine collaborative tagging. A suo giudizio non c’è alcuna collaborazione perchè manca un obiettivo comune ma solo un aggregazione collettiva… da qui lui preferisce il termine “collective”. A mio parere sta dimenticando che in questi sistemi sebbene manchi l’obiettivo comune e sia più forte un interesse personale esiste comunque un feedback costante che si riceve dagli altri e il meccanismo di collegamento tra utenti risorse e tag spinge inevitabilmente a scoprire come si comportano gli altri, vedere quali tag usano quali risorse e tutto ciò favorisce la cosìdetta serendipity. Inoltre riflettevo anche su una piccola considerazione nata dalla lettura del post di Vander Wal: è vero che spesso non si parte da un obiettivo comune e che senza un beneficio evidente personale questi sistemi stentano a decollare però nonostante molti sistemi di tagging consentano di mantenere privati i propri tag come le proprie risorse, sono in netta minoranza coloro che decidono di non condividere con gli altri la propria organizazzione personale.
IMHO il signo Vander Wal dovrebbe riflettere anche sul fatto che il termine folksonomy nato dall’unione di folk & taxonomy non ha nulla a che fare con una tassonomia…
gli avrei volentieri lasciato un commento ma non sono ammessi :S
Breve aggiornamento: qui commentano lo stesso post di Vender Wal in particolare riporto un pezzetto interessante:
Collaboration should not so narrowly be defined and applied only to a single artifact within joint work (e.g., a wiki page). Collaboration has multiple levels and can involve coordination across co-dependent artifacts with varying degrees of symmetric “joint work” on group and individual artifacts within that project.
You say (party) We say (die) ;)
Prendendo spunto (secondo me) da un gruppo indie canadese (appunto gli You Say Party! We Say Die!)
un laureando (credo tedesco) ha realizzato (contentrandosi molto sull’aspetto interfaccia utente) un tool che consente a un utente di un collaborative tagging system di verificare se i tag che lui ha assegnato a una risorsa sono in qualche modo accettati o no dall’intera comunità… in ogni caso lo strumento ha lo scopo di mostrare quali tag sono anche usati dalla comunità e quali invece sono più personali.
Il tool l’ha chiamato “You say… We say…” per il momento non è disponibile sul web ma scaricabile e soprattutto da testare…
Lo stesso studente poi ha fatto una tesi chiamata “Visual tools for the socio–semantic web” scaricabile in pdf sempre dal suo blog in cui (se non sbaglio) analizza il suo e altri tool che dovrebbero proporsi come nuove forme di visualizzazione delle informazioni reperibili da una folksonomia… alternative insomma alle famose tag clouds
Stiamo reinventando la ruota?
Nei miei peregrinaggi notturni ho trovato questo post. A qualcuno dovrebbero rizzarsi le orecchie (evitate battute scontate nei commenti, grazie):
Combining tagspaces di Jon Udell
Is there a service that will deliver a feed containing the union of tagged items for one tag across a set of various services?
Android – An Open Handset Alliance Project
Google ha lanciato un concorso, mettendo in palio 10 milioni di dollari (quasi 7 milioni di euro), per gli sviluppatori che creeranno le migliori applicazioni per cellulari sulla nuova piattaforma Android utilizzando il kit di sviluppo legato alla piattaforma.
Purtroppo però l’Italia non rientra tra i paesi che possono partecipare al progetto :-(
The Android Developer Challenge is open to individuals, teams of individuals, and business entities. While we seek to make the Challenge open worldwide, we cannot open the Challenge to residents of Cuba, Iran, Syria, North Korea, Sudan, and Myanmar (Burma) because of U.S. laws. In addition, the Challenge is not open to residents of Italy or Quebec because of local restrictions
per motivi burocratici:
Ma quali sono i limiti burocratici opposti dall’Italia al concorso? La necessità di depositare in anticipo la somma complessiva del monte premi in garanzia; l’obbligo di attribuire i premi in presenza di un notaio e di un rappresentante di un’associazione consumatori legalmente riconosciuta; il vincolo della registrazione del concorso in due ministeri e agli atti dei monopoli di Stato. Lungaggini eccessive a cui Google non intende sottostare.
Frederick Brooks, Jr. at OOPSLA 2007
Ultimo reportage da OOSPLA, con un po’ di ritardo per non pesare troppo sui lettori.
Collaboration and Telecollaboration in Design
Frederick P. Brooks, Jr. (University of North Carolina at Chapel Hill)
Qualcuno osa chìedere chi è Fred Brooks? Questa volta vi accontento.
Brooks distilled the successes and failures of the development of Operating System/360 in The Mythical Man-Month: Essays in Software Engineering, (1975, 20th Anniversary Edition, 1995). He further examined software engineering in a 1986 paper, No Silver Bullet. He is a member of the National Academy of Engineering, the National Academy of Science, and the American Academy of Arts and Sciences. He has received the ACM A.M. Turing Award, the IEEE John von Neumann Medal, the IEEE Computer Society’s McDowell and Computer Pioneer Awards, the ACM Allen Newell and Distinguished Service Awards, the AFIPS Harry Goode Award, and an honorary Doctor of Technical Science from the Swiss Federal Institute of Technology
Il design engineering, a differenza dell’arte, è un lavoro di team. Perché? Ci sono aspetti sempre più sofisticati anche nei prodotti più semplici. Tuttavia i grandi progetti di ingegneria sono ancora oggi il lavoro di una, al più due menti. Si ha così l’integrità concettuale.
Brooks mostra una tabella con a sinistra linguaggi e sistemi disegnati da una sola persona e a destra quelli disegnati da un processo di gruppo. Solo i primi hanno il loro fan club.
Il problema è: come ottenere integrità concettuale con il team design. Il design non può essere il prodotto di una negoziazione. Ci vuole un chief designer e per grandi sistemi un chief architect. Anche l’interfaccia utente richiede un solo user-interface designer (es. Google). Per preservare l’integrità concettuale le assunzioni devono essere documentate:
“better to be wrong than silent or vague”
Brooks cita The Cathedral and the Bazaar con Unix costruito da gruppi diversi e l’early bug detection come risultato dell’enorme scala del testing. La posizione di Brooks è che il modello del bazaar è basato sul gift e funziona quando gli sviluppatori sono i clienti stessi: conoscono così i requisiti in base alla loro esperienza personale. Costruireste mai un sistema di controllo del traffico aereo? Attenzione alle generalizzazioni errate, quindi.
Ma quando la collaborazione aiuta? Aiuta nel caso dell’esplorazione concettuale (alternative radicali, brainstorming) ma non nel conceptual design né nel detailed design. E il pair programming? E nei design review? I review sono collettivi, il design no. Il design è un processo prevalentemente per il singolo individiuo mentre il review è un processo di gruppo condotto in modo iterativo.
Il messaggio che Brooks vuole trasmettere è:
Low tech often suffice
I documenti condivisi sono il fattore più importante. Poi la voce. Quando unsare la videoconference?
- When issues vital to one or more players
- When people are insecure
- When interviewing strangers
- When organization or national cultures are very different
Freb Brooks conclude dicendo che cI sono pochi studi di telecollaboration in design.