ubuntu & agile

Paolo Sammicheli <xdatap1@ubuntu.com>

Perché AGILE ?

Yahoo, 3 year transition: 2005 – 2008Yahoo, 3 year transition: 2005 – 2008Results in 2008:Results in 2008:200 scrum teams world wide, total approx. 1500+ employees200 scrum teams world wide, total approx. 1500+ employeesAverage Team Velocity increase estimated at +35% / yearAverage Team Velocity increase estimated at +35% / yearDevelopment cost reduction of over USD 1 million / yearDevelopment cost reduction of over USD 1 million / yearROI on transition and trainings about 100% in first yearROI on transition and trainings about 100% in first yearhttp://agilesoftwaredevelopment.com/blog/artem/lessons-yahoos-scrum-adoption

HCL EAI Services Inc. Enterprise application integration services: healthcare, retail, telecommunication, wireless.

Source: http://www.slideshare.net/wasitova/agile-adoption-feb-2011

http://www.cio.com/article/368313/100_Most_Agile_Companies_Honored

100 Most Agile Companies Honored (2004)

Aerospace

Automotive Manufacturing Banking/Investment

Business/Consumer Services

Communications Computer Manufacturing

EducationFinancial services

Government

Health Care/Health Insurance

Insurance

Legal Services Manufacturing/Process Industries

Pharmaceuticals Retail/Wholesale

Technology Services

Transportation/Distribution

COME OTTENERE QUESTI RISULTATI?

COESIONE

COMUNICAZIONE

CADENZA

PRODUTTIVITÀ

QUALITÀ

TRASPARENZA

SPRECHI

VALORE

VALIDATED LEARNING

ITERATIVO

INCREMENTALE

RISCHIO

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.

PLAN ANALYSIS DESIGN CODE TEST DEPLOY

ANALYSIS

DESIGN

CODETEST

PLA

N

DE

PLO

Y ANALYSIS

DESIGN

CODETEST

PLA

N

DE

PLO

Y ANALYSIS

DESIGN

CODETEST

PLA

N

DE

PLO

Y

Modello di sviluppo AGILE

Modello di sviluppo WATERFALL

Prin

cipl

es

Met

hodo

logi

es

Tech

niqu

es XP

KANBAN

SCRUM

DSDM ATERN

LEAN PRODUCTION

LEAN STARTUP

MANAGEMENT 3.0

Planning Game

Test DrivenDevelopment

Behaviour DrivenDevelopment

ContinuousIntegration

ContinuousRefactoring

Pair Programming Small Releases

Collective code ownership Sustainable pace Coding standard System metaphor

FEATURE DRIVEN DEVELOPMENT

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

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

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

Codice di Condotta

CODICE DI CONDOTTASiate 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.

CODICE DI CONDOTTASiate 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.

CODICE DI CONDOTTA

Siate premurosi. Siate

rispettosi.

Lasciate con considerazione.

consultate gli altri.

chiedete.

Siate collaborativi.

COLLECTIVE CODE OWNERSHIP

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)

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)

Aprile 2010 - Risultati

Wikimedia Visitor Log Analysis Report - Operating Systems

http://stats.wikimedia.org/archive/squid_reports/2010-04/SquidReportOperatingSystems.htm

Totali Linux DesktopUbuntu 26.345 74,42%Altri Linux 9.056 25,58%

Totale 35.401

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/

Qual'è il motivo di questo successo?Qual'è il motivo di questo successo?

Agile in Ubuntu

12 PRINCIPI AGILI1) 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

opensource

12 PRINCIPI AGILI5) 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

ubuntu

opensource

12 PRINCIPI AGILI9) 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.

✔

✔

✔

✔ubuntu

opensource

ubuntu

opensource

Tutti i principi Agili si mappano sul metodo di sviluppo di Ubuntu, alcuni anche su un

qualsiasi progetto Open Source

AGILE UBUNTUCadenza, Delivery Frequently CICLO SEMESTRALE

Continuous delivery DAILY e WEEKLY BUILDCICLO SEMESTRALE

Continuous Integration LAUNCHPAD

Automation LAUNCHPAD

Collective Code Ownership MOTU, SPONSORING

Early Feedback AUTOMAZIONE BUG

Pull BITE SIZEMERGE, SYNC & BUG FIX

Customer Collaboration DEVELOPER DA ALTRE AZIENDE(Dell, Google, System76, ecc)

Retrospettive e Face to Face UBUNTU DEVELOPERSUMMIT

Working Agreement CODE OF CONDUCT

Policy Visibili ROADMAP su WIKI, CoC,BLUEPRINTs

Conclusione

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.

Se invece ho ragione, allora Ubuntu costituisce un interessante Success

Story di applicazione delle metodologie Agili e potremmo continuare ad

approfondire l'argomento.

GRAZIE

Paolo Sammicheli <xdatap1@ubuntu.com>