Jordi Coma i Marc Compta

Introducció.◦ Breu història.

◦ Concepte “àgil”.

◦ Aprofundiment.

Metodologies.◦ eXtreme Programming (XP).

◦ Scrum.

◦ Crystal.

◦ Dynamic System Development.

Conclusions.

Definició moderna com a part d’una reacciócontra les metodologies “pesades” el 1990, molt estructurades i estrictes.

Inicialment eren vistes com un “pas enrere”.

L’any 2001, membres de la comunitat es van reunir a Snowbird, Utah i van adoptar el nomde metodologies “àgils”.

Paradigma basat en processos àgils enfocat a la gent i als resultats.

Promou iteracions en el desenvolupament al llarg de tot el cicle de vida del projecte.

ITERACIÓ = PLANIFICACIÓ + ANÀLISI DE REQUERIMENTS + DISSENY + CODIFICACIÓ + REVISIÓ + DOCUMENTACIÓ

Simple oficina “oberta” també anomenada“plataforma de llançament” que inclouràrevisors, redactors de documentació i ajuda, dissenyadors d’iteració i directors de projecte.

Equips autoregulats.

CARA A CARA vs documentació.

Criticats per la falta de documentaciótècnica.

Recull els principis “àgils” bàsics.◦ Individus i interaccions per sobre de processos i

eines.

◦ Programari que funciona per sobre d’unadocumentació exhaustiva.

◦ Col·laboració del client per sobre de la negociaciódel contracte.

◦ Saber respondre al canvi per sobre de seguir un determinat pla.

Manifest disponible a http://agilemanifesto.org

De 2 a 8 persones per sala.

Comunicació i comunitat.

Usuaris experts junts amb l’equip de desenvolupament.

Cicles de feedback curts i continus.

Iteracions curtes.

Com a màxim 3 mesos per afavorir testing i depuracions ràpides.

Tests de regressió totalment automàtics.

Desenvolupadors experimentats.

eXtreme Programming (XP).

Scrum.

Crystal.

Dynamic System Development.

Extreme Programming Explained: EmbraceChange (1990). [Kent Beck]

ADAPTABILITAT vs previsibilitat.◦ “Els canvis són un aspecte natural i inevitable.”

Especialment favorable quan..◦ Projectes amb requeriments canviants.

◦ Risc del projecte molt elevat.

◦ Equips de desenvolupament petits (2 a 12 persones).

Desenvolupament iteratiu i incremental.

Proves unitàries contínues.◦ S’aconsella escriure el codi de la prova abans de la

pròpia codificació.

Programació per parelles.◦ Revisió i comentari “en calent” per davant de la

possible pèrdua de productividad immediata.

◦ Propietat col·lectiva del codi.

Freqüent integració de l’equip de programació amb el client.◦ Representant del client integrat en l’equip de

desenvolupament.

Correcció de tots els errors abans d’afegiruna nova funcionalitat.◦ + entregues freqüents.

Refractorització del codi.◦ Reescriure certes parts del codi per augmentar-ne

la lectura i manteniment. Les proves que haurempreparat garantiran la no introducció de nouserrors.

Simplicitat.◦ Un cop tot funcioni ho ampliarem funcionalment.

Setmana de 40 hores.

Comunicació: entre els desenvolupadors, ambel client…

Simplicitat: si una cosa es pot fer de forma senzilla, no la compliquem.

Feedback: incorporem totes les opinions al procés per a que aquest pugui millorar.

Coratge: a vegades s’ha de ser valent per adoptar la decisió més convenient.

Ensenyar a aprendre.◦ Canvis -> aprenentatge constant.

Inversió inicial petita.◦ Si sabem que al cap de poc temps haurem de

canviar perquè invertir tant de temps al principi en trobar “la solució”?

Adoptar actitud d’equip guanyador.

Experiments sobre parts concretes.

Comunicació oberta i honesta.

eXtreme Programming (XP).

Scrum.

Crystal.

Dynamic System Development.

Aconseguir dedicar el màxim de temps en la producció del programa en contes de dissenyar molt (moltes vegades difícil de justificar)

Seguir cicles de desenvolupament curs

Permet que tothom pugui veure el desenvolupament del projecte.

Permet dividir el projecte en diferents mini projectes, que poden ser portats per diferents grups auto-organitzats.

Suporta que el client vulgui canviar els requeriments a mig procés, anomenat “ requeriments churn” (pot ser implementat amb notes “post-it”, software, etc..).

Fàcil d'aprendre i implementar.

1986 Hirotaka Takeuchi i Ikujiro Nonaka fan una primera aproximació d'un sistema ràpid, eficaç amb treball amb equip com una sola persona.

1991 Peter DeGrace i Lesle Stahl fan el llibre “Wicked Problems, Righterous Solutions”, i defineixen el nom de scrum, sinònim de melé fet servir en el rugbi.

1990- primera posada en funcionament, companyia “Advanced developmentmethods”.

1995 Sutherland i Schward fan una sèrie d'articles i presenten el mètode scrum.

2001 Schwaber i Mike Beedle descriuen la metadologia en un llibre “Agile Software Development with scrum”.

Partició del projecte en diferents “mini projectes” “sprints”.

Abans de començar es decideix que s'ha de fer en una reunió, “Sprint Planig”.

Cada un d'aquests són entregables en un temps definit curt.

Cada sprint representa una funcionalitat que ha de tenir la aplicació final.

Sprint Planning.

Daily scrum Meeting.

Sprint Review.

Sprint Retrospective.

Hi ha 2 grups de rols:◦ “pigs” els desenvolupadors

◦ “chikens” clients, venedors...

ScrumMaster.

Team (equip de desenvolupadors).

Product Owner (representa el client).

Treure els impediments de desenvolupament per tal de poder arribar a complir la data de sprint.

Serveix per aïllar de les influencies externes l'equip (només informar de les coses importants).

S'assegura que es segueix la metodologia.

S'encarrega de portar el projecte.

Petit equip de treball, normalment de 5-10 persones.

Composta per gent amb diverses habilitats, dissenyadors, programadors, testers, comunicacions, etc...

S'encarrega que l'equip complexi els requisits.

S'encarrega de prendre els requeriments i els posa al “backlog”.

Pot pertanyer al grup de treball, però no pot ser scrum master.

Prioritzar els requeriments segons la utilitat, marcat, etc...

Definir data final, preu.

Diaria: programada sempre a la mateixa hora, parlen els desenvolupadors i només dura 15 minuts. Explicació del que s'ha fet, problemes i el que es farà durant el dia.

Scrum d'scrums: igual que la diària, però amb un representant de cada grup de treball, discutint com integrar-ho.

Reunió de planificació: al començament de cada cicle. Preparar el backlog, durada màxima de 8 hores.

Revisió sprint: Revisó de la feina que s'ha acabat i la que no s'ha acabat.

Preparació de la “demo”. Limit 4 hores.

Retrospectiva: Cada membre de l'equip dóna les impressions sobre l'sprint acabat.

Product backlog: Descripció del produdcte a gran nivell, incorpora els requeriments, etc...

És la guia que fa servir el “product owner” per decidir què és el que es fa primer i quan hauria d'estar acabat.

Sprint backlog:Document que conté la informació de com s'implementarà. Cada requeriment es separa amb tasques que cada unes 4-16 h. Cada tasca s'assigna segons les habilitats dels membres de l'equip.

Scrum-ban. És un model basat amb Scrum i Kaban, especialment preparat per el manteniment de projectes amb molts canvis o errors.

La principal diferència és que els sprints són continus.

eXtreme Programming (XP).

Scrum.

Crystal.

Dynamic System Development.

Impulsada per Alistair Cockburn.

Dona una importància fonamental a les persones que formen l’equip d’un projecte.◦ Aspecte humà de l’equip.

◦ Mida de l’equip.

◦ Comunicació entre els components.

◦ Polítiques a seguir.

◦ Espai físic de treball.

Equips reduïts per a una millor comunicació.

Solucions per a una amplia diversitat de projectes.◦ Diferents polítiques.

Crystal Clear y Crystal Orange.◦ Desenvolupament incremental amb “releases”

habituals, implicació de l’usuari i testos de regressió.

eXtreme Programming (XP).

Scrum.

Crystal.

Dynamic System Development.

IDEA: En comptes de fixar la quantitat de funcionalitats d’un producte i aleshores ajustar el temps i els recursos necessaris per aconseguir aquesta funcionalitat és millor primer fixar el temps i els recursos i després ajustar la funcionalitat.

5 fases: estudi de viabilitat, estudi de negocis, iteració del model funcional, iteració de disseny i construcció i implementació.

Principis:◦ Implicació de l’usuari.◦ L’equip ha de prendre decisions.◦ Entregar sovint.◦ Les entregues han de tenir valor de negoci.◦ Desenvolupament iteratiu i incremental.◦ Tots els canvis són reversibles.◦ Els requeriments només s’especifiquen a alt nivell.◦ El testeig s’ha d’integrar al llarg de tot el cicle de

vida.◦ El procés ha de ser col·laboratiu i compartit per

tots els interessats.

Les metodologies àgils surgeixen com a resposta a problemes reals.

Es basen en aplicar el sentit comú trencant amb diverses creences arraigades.

Però la metodologia perfecte no existeix.

Cada vegada més aplicades.

Jordi Coma i Marc Compta