Retrospettiva Ubuntera 2004-2010: Agilità come vantaggio competitivo? Breve panoramica sulle metodologie Agili e analisi degli elementi di differenziazione di Ubuntu.

1. ubuntu & agile
Paolo Sammicheli <xdatap1@ubuntu.com>

4. Perché AGILE ?

5. Yahoo, 3 yyeeaarr ttrraannssiittiioonn:: 22000055 –– 22000088
RReessuullttss iinn 22000088::
220000 ssccrruumm tteeaammss wwoorrlldd wwiiddee,, ttoottaall aapppprrooxx.. 11550000++ eemmppllooyyeeeess
AAvveerraaggee TTeeaamm VVeelloocciittyy iinnccrreeaassee eessttiimmaatteedd aatt ++3355%% // yyeeaarr
DDeevveellooppmmeenntt ccoosstt rreedduuccttiioonn ooff oovveerr UUSSDD 11 mmiilllliioonn // yyeeaarr
RROOII oonn ttrraannssiittiioonn aanndd ttrraaiinniinnggss aabboouutt 110000%% iinn ffiirrsstt yyeeaarr
http://agilesoftwaredevelopment.com/blog/artem/lessons-yahoos-scrum-adoption

6. HCL EAI Services Inc.
Enterprise application integration
services: healthcare, retail,
telecommunication, wireless.
Source: http://www.slideshare.net/wasitova/agile-adoption-feb-2011

7. 100 Most Agile Companies Honored (2004)
http://www.cio.com/article/368313/100_Most_Agile_Companies_Honored
Technology Services
Pharmaceuticals Retail/Wholesale
Automotive Manufacturing
Aerospace
Banking/Investment
Business/Consumer Services
Communications
Computer Manufacturing
Transportation/Distribution
Education
Financial services
Government
Health Care/Health Insurance
Insurance
Manufacturing/Process Industries
Legal Services

8. COME OTTENERE QUESTI RISULTATI?

9. COESIONE

10. COMUNICAZIONE

11. CADENZA

12. PRODUTTIVITÀ

13. QUALITÀ

14. TRASPARENZA

15. SPRECHI

16. VALORE

17. VALIDATED LEARNING

18. ITERATIVO

19. INCREMENTALE

20. RISCHIO

21. Manifesto per lo Sviluppo Agile di Software
Stiamo scoprendo modi migliori di creare software,
sviluppandolo e aiutando gli altri a fare lo stesso.
Grazie a questa attività siamo arrivati a considerare importanti
Gli individui e le interazioni più che i processi e gli strumenti
Il software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei contratti
Rispondere al cambiamento più che seguire un piano
Ovvero, fermo restando il valore delle voci a destra,
consideriamo più importanti le voci a sinistra.

22. Modello di sviluppo WATERFALL
PLAN ANALYSIS DESIGN CODE TEST DEPLOY
ANALYSIS
DESIGN
CODE
TEST
PLAN
DEPLOY
ANALYSIS
DESIGN
CODE
TEST
PLAN
DEPLOY
ANALYSIS
DESIGN
CODE
TEST
PLAN
DEPLOY
Modello di sviluppo AGILE

23. Principles Methodologies Techniques
XP
LEAN STARTUP
MANAGEMENT 3.0
LEAN PRODUCTION
SCRUM
KANBAN
DSDM ATERN
FEATURE DRIVEN DEVELOPMENT
Planning
Game
Test Driven
Development
Behaviour Driven
Development
Continuous
Integration
Continuous
Pair Programming Refactoring Small Releases
Collective code
ownership Sustainable pace Coding standard System metaphor

26. 2004: GLI ELEMENTI DI NOVITÀ
CADENZA
Una release ogni sei mesi
UNA SOLA VERSIONE
Governance comunitaria per la versione a supporto commerciale
BRAND
Un brand molto inclusivo che ha generato una comunità
effervescente dal primo momento

27. 2004 – 2008: Le differenze software tra le
distribuzioni erano minime.

28. CADENZA, elemento di differenziazione
● Rilasci semestrali
● A partire dal 2006 versione LTS biennale supportata 5 anni.
● Numero di versione con lo schema AA.MM (es: 08.04 = Aprile 2008)
● Sistema di continuous integration e build / test automatizzati
● Transparency: tutto il processo di sviluppo su Launchpad

30. Codice di Condotta

31. CODICE DI CONDOTTA
Siate premurosi. Il vostro lavoro sarà usato da altre persone, e voi a vostra volta dipenderete dal lavoro degli altri. Ogni decisione presa
coinvolgerà utenti e colleghi, e ci aspettiamo che prendiate in considerazione le conseguenze di ogni decisione. Ad esempio, quando siamo in
uno stato di "freeze", non fate drammatici upload di nuove versioni di software per sistemi critici, in quanto altre persone sono in fase di test
dei sistemi "congelati" e non sono in grado di assorbire grandi variazioni.
Siate rispettosi. La comunità Ubuntu ed i suoi membri si rivolgono l'un l'altro con grande rispetto. Ciascuno può realizzare un valido contributo
ad Ubuntu. Non possiamo sempre essere d'accordo, ma il disaccordo non è una scusa per un comportamento e per modi scorretti. Potremmo
tutti vivere qualche frustrazione talvolta, ma non potremmo mai permettere che tale frustrazione si trasformi in un attacco personale. E'
importante ricordare che una comunità dove le persone si sentono a disagio non è una comunità produttiva. Ci aspettiamo che i membri della
comunità Ubuntu siano rispettosi sia quando hanno a che fare con altri collaboratori, sia con persone al di fuori del progetto Ubuntu, sia con
gli utenti.
Siate collaborativi. Ubuntu e Free Software collaborano e lavorano insieme. La collaborazione riduce la ridondanza del lavoro compiuto del
mondo Free Software e migliora la qualità del software prodotto. Dovreste tendere a collaborare con altri maintainers Ubuntu, così come con
la comunità a monte che è interessata al vostro lavoro. Il vostro lavoro dovrà essere eseguito con trasparenza e le patch per Ubuntu devono
essere consegnate alla comunità quando si rendono disponibili, non al rilascio dell'edizione. Se volete lavorare a nuovo codice per progetti
esistenti, almeno mantenete informati delle vostre idee e progressi i responsabili di quei progetti. Potrebbe non essere possibile ottenere il
consenso circa la corretta implementazione di un'idea, così non sentitevi obbligati ad ottenere un accordo prima di iniziare, ma almeno
mantenete informato del vostro lavoro il mondo esterno, e pubblicatelo in modo tale da consentire altri di svolgere prove, discussioni e
contribuire ai vostri sforzi.
Quando non siete d'accordo, consultate gli altri. Disaccordi, sia politici che tecnici, avvengono ogni giorno e la comunità Ubuntu non ne è
esente. L'obiettivo importante non è evitare i disaccordi o le diverse vedute, ma di risolverli costruttivamente. Dovreste sempre tornare alla
comunità ed ai suoi processi per cercare consigli e risolvere disaccordi. Ci sono sia il Technical Board che il Community Council che vi
aiuteranno a decidere il giusto corso di Ubuntu. Ci sono inoltre diversi Project Teams e Team Leaders, che vi aiuteranno a capire quale
direzione potrebbe essere la più accettabile. Se alla fine volete comunque prendere una strada diversa, vi invitiamo a fornire una diversa
distribuzione o un set di pacchetti alternativo usando la struttura dell'Ubuntu Package Management, affinchè la comunità possa comunque
provare i vostri cambiamenti e le vostre idee, e contribuire alla discussione.
Quando non siete sicuri, chiedete. Nessuno sa tutto, e nessuno si aspetta che l'altro sia perfetto nella comunità Ubuntu. Rivolgere domande
evita molti problemi lungo il percorso, e quindi le domande sono incoraggiate. Coloro che devono rispondere, dovranno essere reattivi e di
grande aiuto. Comunque, nel porre una domanda, occorre avere cura nel rivolgersi al forum appropriato. Domande fuori-tema, come ad
esempio una richiesta di supporto in una mailing list di sviluppo distoglie da una discussione produttiva.
Lasciate con considerazione. Gli sviluppatori di ogni progetto vanno e vengono, e per Ubuntu non è diverso. Quando lasciate un progetto, del
tutto o in parte, fatelo cercando di minimizzare le ripercussioni sul progetto stesso. Ciò significa che dovreste avvisare prima di lasciare e
intraprendere le opportune azioni per assicurare che gli altri possano riprendere dal punto da voi lasciato.

32. CODICE DI CONDOTTA
Siate premurosi. Il vostro lavoro sarà usato da altre persone, e voi a vostra volta dipenderete dal lavoro degli altri. Ogni decisione presa
coinvolgerà utenti e colleghi, e ci aspettiamo che prendiate in considerazione le conseguenze di ogni decisione. Ad esempio, quando siamo in
uno stato di "freeze", non fate drammatici upload di nuove versioni di software per sistemi critici, in quanto altre persone sono in fase di test
dei sistemi "congelati" e non sono in grado di assorbire grandi variazioni.
Siate rispettosi. La comunità Ubuntu ed i suoi membri si rivolgono l'un l'altro con grande rispetto. Ciascuno può realizzare un valido
contributo ad Ubuntu. Non possiamo sempre essere d'accordo, ma il disaccordo non è una scusa per un comportamento e per modi scorretti.
Potremmo tutti vivere qualche frustrazione talvolta, ma non potremmo mai permettere che tale frustrazione si trasformi in un attacco
personale. E' importante ricordare che una comunità dove le persone si sentono a disagio non è una comunità produttiva. Ci aspettiamo che i
membri della comunità Ubuntu siano rispettosi sia quando hanno a che fare con altri collaboratori, sia con persone al di fuori del progetto
Ubuntu, sia con gli utenti.
Siate collaborativi. Ubuntu e Free Software collaborano e lavorano insieme. La collaborazione riduce la ridondanza del lavoro compiuto del
mondo Free Software e migliora la qualità del software prodotto. Dovreste tendere a collaborare con altri maintainers Ubuntu, così come con
la comunità a monte che è interessata al vostro lavoro. Il vostro lavoro dovrà essere eseguito con trasparenza e le patch per Ubuntu devono
essere consegnate alla comunità quando si rendono disponibili, non al rilascio dell'edizione. Se volete lavorare a nuovo codice per progetti
esistenti, almeno mantenete informati delle vostre idee e progressi i responsabili di quei progetti. Potrebbe non essere possibile ottenere il
consenso circa la corretta implementazione di un'idea, così non sentitevi obbligati ad ottenere un accordo prima di iniziare, ma almeno
mantenete informato del vostro lavoro il mondo esterno, e pubblicatelo in modo tale da consentire altri di svolgere prove, discussioni e
contribuire ai vostri sforzi.
Quando non siete d'accordo, consultate gli altri. Disaccordi, sia politici che tecnici, avvengono ogni giorno e la comunità Ubuntu non ne è
esente. L'obiettivo importante non è evitare i disaccordi o le diverse vedute, ma di risolverli costruttivamente. Dovreste sempre tornare alla
comunità ed ai suoi processi per cercare consigli e risolvere disaccordi. Ci sono sia il Technical Board che il Community Council che vi
aiuteranno a decidere il giusto corso di Ubuntu. Ci sono inoltre diversi Project Teams e Team Leaders, che vi aiuteranno a capire quale
direzione potrebbe essere la più accettabile. Se alla fine volete comunque prendere una strada diversa, vi invitiamo a fornire una diversa
distribuzione o un set di pacchetti alternativo usando la struttura dell'Ubuntu Package Management, affinchè la comunità possa comunque
provare i vostri cambiamenti e le vostre idee, e contribuire alla discussione.
Quando non siete sicuri, chiedete. Nessuno sa tutto, e nessuno si aspetta che l'altro sia perfetto nella comunità Ubuntu. Rivolgere domande
evita molti problemi lungo il percorso, e quindi le domande sono incoraggiate. Coloro che devono rispondere, dovranno essere reattivi e di
grande aiuto. Comunque, nel porre una domanda, occorre avere cura nel rivolgersi al forum appropriato. Domande fuori-tema, come ad
esempio una richiesta di supporto in una mailing list di sviluppo distoglie da una discussione produttiva.
Lasciate con considerazione. Gli sviluppatori di ogni progetto vanno e vengono, e per Ubuntu non è diverso. Quando lasciate un progetto,
del tutto o in parte, fatelo cercando di minimizzare le ripercussioni sul progetto stesso. Ciò significa che dovreste avvisare prima di lasciare e
intraprendere le opportune azioni per assicurare che gli altri possano riprendere dal punto da voi lasciato.

33. CODICE DI CONDOTTA
Siate premurosi. Siate
rispettosi.
Siate collaborativi.
consultate gli altri. chiedete.
Lasciate con considerazione.

34. COLLECTIVE CODE OWNERSHIP

35. COLLECTIVE CODE OWNERSHIP
● Le altre distribuzioni avevano il ruolo di maintainer. Ogni pacchetto
era mantenuti da uno o più maintainer (nel caso di pacchetti
complessi)
● Ubuntu divide la gestione tra MAIN (i pacchetti code base, mantenuti
dai core-dev) e UNIVERSE (mantenuti dai MOTU)
● Si incentiva la collaborazione di nuovi contributori con la
classificazione dei lavori per dimensione (iniziativa bite-size)
● I pacchetti vengono scelti dai volontari su liste automatiche (PULL)

38. 2004 – 2010: Risultati
● Prima distribuzione Linux per diffusione sul desktop
● Stimati almeno 12 Milioni di Utenti
● Prima distribuzione a stipulare accordi OEM per pre-installazione sui
pc (DELL, Lenovo, ecc)

39. Aprile 2010 - Risultati
Wikimedia Visitor Log Analysis Report - Operating Systems
http://stats.wikimedia.org/archive/squid_reports/2010-04/SquidReportOperatingSystems.htm
Totali Linux Desktop
Ubuntu 26.345 74,42%
Altri Linux 9.056 25,58%
Totale 35.401

40. Aprile 2010 - Risultati
Popularity of Open source Operating systems over time
http://shape-of-code.coding-guidelines.com/2013/01/27/popularity-of-open-source-operating-systems-over-time/

41. QQuuaall''èè iill mmoottiivvoo ddii qquueessttoo ssuucccceessssoo??

42. Agile in Ubuntu

43. 12 PRINCIPI AGILI
1) La nostra massima priorità è soddisfare il cliente
rilasciando software di valore, fin da subito e in maniera
continua.
2) Accogliamo i cambiamenti nei requisiti, anche a stadi
avanzati dello sviluppo. I processi agili sfruttano il
cambiamento a favore del vantaggio competitivo del
cliente.
3) Consegniamo frequentemente software funzionante,
con cadenza variabile da un paio di settimane a un paio
di mesi,preferendo i periodi brevi.
4) Committenti e sviluppatori devono lavorare insieme
quotidianamente per tutta la durata del progetto.
✔
✔
✔
✔
ubuntu
ubuntu
ubuntu
open
source

44. 12 PRINCIPI AGILI
5) 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.
6) Una conversazione faccia a faccia è il modo più
efficiente e più efficace per comunicare con il team ed
all'interno del team.
7) Il software funzionante è il principale metro di misura di
progresso.
8) I processi agili promuovono uno sviluppo sostenibile.
Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere
in grado di mantenere indefinitamente un ritmo costante.
✔
ubuntu
✔
ubuntu
✔
open
source
✔ubuntu

45. 12 PRINCIPI AGILI
9) La continua attenzione all'eccellenza tecnica e alla
buona progettazione esaltano l'agilità.
10) La semplicità - l'arte di massimizzare la quantità di
lavoro non svolto - è essenziale.
11) Le architetture, i requisiti e la progettazione migliori
emergono da team che si auto-organizzano.
12) A intervalli regolari il team riflette su come diventare
più efficace, dopodiché regola e adatta il proprio
comportamento di conseguenza.
✔
open
source
✔
ubuntu
✔
open
source
✔ubuntu

46. Tutti i principi Agili si mappano sul metodo
di sviluppo di Ubuntu, alcuni anche su un
qualsiasi progetto Open Source

47. AGILE UBUNTU
Cadenza, Delivery Frequently CICLO SEMESTRALE
Continuous delivery DAILY e WEEKLY BUILD
CICLO SEMESTRALE
Continuous Integration LAUNCHPAD
Automation LAUNCHPAD
Collective Code Ownership MOTU, SPONSORING
Early Feedback AUTOMAZIONE BUG
Pull BITE SIZE
MERGE, SYNC & BUG FIX
Customer Collaboration DEVELOPER DA ALTRE AZIENDE
(Dell, Google, System76, ecc)
Retrospettive e Face to Face UBUNTU DEVELOPER
SUMMIT
Working Agreement CODE OF
CONDUCT
Policy Visibili ROADMAP su WIKI, CoC,
BLUEPRINTs

48. Conclusione

50. Se ho torto ed Agile non è il motivo del
successo di Ubuntu, pazienza.
Potrebbe essere comunque
interessante analizzare alcune pratiche
Agili che possono essere utili per i
Leader della Community.

52. Se invece ho ragione, allora Ubuntu
costituisce un interessante Success
Story di applicazione delle metodologie
Agili e potremmo continuare ad
approfondire l'argomento.

53. GRAZIE
Paolo Sammicheli <xdatap1@ubuntu.com>