Metodologia SCRUM (PDF)

Tema 6 Metodologia SCRUM: cicle de vida d'un projecte TIC, desenvolupament de projectes TUC en scrum, principals rols i les seves funcions, descripció de les reunions principals de treball. 1 Introducció DEFINICIÓ D'SCRUM És un marc de treball per al desenv...

Tema 6 Metodologia SCRUM: cicle de vida d'un projecte TIC, desenvolupament de projectes TUC en scrum, principals rols i les seves funcions, descripció de les reunions principals de treball. 1 Introducció DEFINICIÓ D'SCRUM És un marc de treball per al desenvolupament de producte, especialment útil per a contextos complexos com és el desenvolupament i manteniment de programari. Alineat amb el moviment de desenvolupament de software àgil. Scrum fa un plantejament iteratiu del desenvolupament, en el que s’anomena Sprint a cadascuna de les iteracions. El marc de treball Scrum es compon per:  Els Equips Scrum (Scrum Team - ST) i els seus Rols: o Propietari del Producte (Product Owner - PO): responsable de maximitzar el valor del producte, a través de l’expressió incremental dels requeriments d’un producte al DT. o Equip de desenvolupament (Development Team - DT): responsables de gestionar, organitzar i executar el treball de desenvolupament per satisfer els requeriments del PO. o Scrum Master (SM): responsable de guiar, acompanyar, ensenyar i ajudar al conjunt de l’Equip Scrum i el seu entorn en una adequada comprensió i utilització de Scrum.  Els Artefactes, entesos com objectes fabricats amb tècnica per desenvolupar una funció específica: o Pila de Producte (Product Backlog): llista ordenada del treball a realitzar per desenvolupar o mantenir un producte, gestionada pel PO. o Pila del Sprint (Sprint Backlog): vista general del treball de desenvolupament a realitzar per assolir l’objectiu del Sprint. o Increment: una peça de nou programari potencialment utilitzable, que afegida als increments creats prèviament, conformen el producte.  Els Esdeveniments o reunions estàndard: o Planificació del Sprint (Sprint Planning): reunió per tal que l'ST inspeccioni el treball del Product Backlog que aporta més valor realitzar a continuació, i el desglossi en el Sprint Backlog. o Scrum diari (Daily Scrum): reunió diària de màxim 15 min en la que el DT replanifica la feina de desenvolupament del següent dia del Sprint en curs. Els canvis es reflecteixen en el Sprint Backlog. o Revisió del Sprint (Sprint Review): reunió que conclou el treball de desenvolupament d’un Sprint. Serveix a l’ST i als diferents interessats (Stakeholders) per inspeccionar l’increment de producte resultant del Sprint, avaluar l’impacte de la feina feta en el progrés global i actualitzar el Product Backlog, per maximitzar el valor del període següent. o Retrospectiva del Sprint (Sprint Retrospective): reunió que permet a l'ST valorar el Sprint que finalitza i planificar millores pel següent Sprint.  Les Regles de Scrum, que relacionen els rols, esdeveniments i artefactes, governant les relacions i interaccions entre ells. 2 TEORIA D'SCRUM Scrum es basa en l’empirisme (el coneixement procedeix de l’experiència), i en poder prendre decisions basant-se en allò conegut. Utilitza un enfocament iteratiu i incremental per optimitzar la predictibilitat i el control del risc. La implementació del control de processos empírics es basa en tres pilars:  Transparència: els aspectes significatius han de ser visibles per tots els responsables del resultat.  Inspecció: els usuaris han d’inspeccionar sovint els artefactes de Scrum i el progrés cap a un objectiu prefixat per detectar variacions indesitjades.  Adaptació: Si un o més aspectes es desvien dels límits acceptables, i el producte resultant serà inacceptable, el procés o material s’haurà d’ajustar quant abans, per evitar que les desviacions creixin. Scrum preveu 4 esdeveniments formals, dintre del sprint, per la inspecció i adaptació. ELS VALORS D'SCRUM Els 3 pilars Scrum es materialitzen i fomenten la confiança quan els següents valors són incorporats i viscuts per l'ST: COMPROMÍS, CORATGE, FOCALITZACIÓ, RESPECTE i OBERTURA. Scrum treballa fent visibles les disfuncions i impediments que estan impactant al PO i a la productivitat del DT, de forma que puguin ser gestionades. Scrum no soluciona els problemes de desenvolupament, els fa visibles, i proporciona un marc de treball perquè l’equip explori vies per resoldre'ls en cicles curts i amb petits experiments de millora. 3 Cicle de vida d'un projecte TIC El cicle de vida d’un projecte TIC normalment consta de les següents fases seqüencials: 1) Presa de requeriments 2) Disseny 3) Construcció 4) Proves 5) Integració 6) Pas a Producció (PAP) En els projectes àgils passem del cicle complet al cicle iteratiu, en el qual aquestes fases es produeixen per cadascuna de les iteracions. En Scrum anomenem Sprint a cadascuna d’aquestes iteracions. El Sprint és el cicle on es dóna tot el treball de l'Equip. La seva durada es decideix a l’inici per l’equip i es manté relativament fixa durant tot el projecte, essent com a màxim de 30 dies (o 4 setmanes). Genera un increment del producte potencialment lliurable (utilitzable). Entre Sprint i Sprint no hi ha cap esdeveniment ni treball de l'equip: quan acaba un Sprint, immediatament comença el següent. El Sprint conté 4 esdeveniments o reunions estàndard, que permeten la inspecció i adaptació. L’Objetiu del Sprint (Sprint Goal) és una meta establerta per al Sprint que proporciona una guia al DT sobre el per què està construint l’increment. Es crea, obligatòriament, per l’ST durant la Planificació de cada Sprint (Sprint Planning). A mesura que el DT treballa, manté l’objectiu del Sprint en ment, i implementa la funcionalitat i la tecnologia per satisfer-lo. Com a instrument per reduir els riscos, existeix la premissa de què durant un Sprint NO es pot variar el seu abast, el seu objectiu ni l’equip que el desenvolupa (la constància permet la concentració i millora la productivitat del DT). => Cancel·lació del Sprint Un Sprint pot cancel·lar-se abans d’arribar al seu final. Només el PO té l’autoritat per cancel·lar el Sprint, tot i que pot fer-ho sota la influència dels interessats, del DT o del SM. Un Sprint es cancel·laria si l’objectiu del Sprint es queda obsolet (p.ex. perquè canviïn les circumstàncies de la companyia). La cancel·lació d’un Sprint és possible però molt poc freqüent donada la seva curta durada. Executarem tants sprints com faci falta fins que: 1. El projecte finalitza perquè: a. Hem acabat tot el que hi ha al Product Backlog. b. El client no vol res més. L’última iteració ha estat suficient i ja no hi ha justificació per invertir més esforç amb noves funcionalitats. 2. El projecte és cancel·lat per alguna raó 4 Gestionar versions (Releases): En els projectes Scrum, l’increment de producte produït per cada Sprint és potencialment lliurable, però no necessàriament tots els Sprints es passaran a l’entorn de Producció. A l’inici del projecte es definirà un Pla de versions o releases que passaran a Producció, incloent cada versió o release l’increment de producte generat per un conjunt de Sprints. En ocasions les Releases estan dirigides per les dates. En aquests casos l’equip executa tants Sprints com sigui possible en el temps disponible. Altres productes requereixen un mínim de funcionalitats desenvolupades per ser llançats, i no es posaran en marxa fins que aquestes estiguin satisfetes. Desenvolupament de projectes TIC en SCRUM ELS REQUISITS FUNCIONALS EN SCRUM En Scrum s’utilitzen les històries d’usuari per descriure els requeriments del producte a desenvolupar: són peticions concretes i petites i potencien la participació de l’equip en la presa de decisions. Són uns requeriments centrats en l'usuari (User Experience - UX), més que els típics requeriments funcionals. Les històries d’usuari incorporen els requeriments del producte a desenvolupar, i s’incorporen de forma ordenada en el Product Backlog, que és un dels artefactes Scrum que veurem a continuació. Expliquen el QUI, el QUÈ i el PER QUÈ. No expliquen el COM, que seria tasca del DT. També inclouen quins seran els criteris d’acceptació que permetran donar com a bo el comportament del programari que implementi la història. Exemple d’història d’usuari: QUI: com usuari corporatiu QUÈ: vull protegir el meu compte amb verificació de dos passos PER QUÈ: per estar segur de què no em roben la paraula de pas Criteris d’acceptació: Usuari [correcte, incorrecte...] Interfície [diferents browsers] Completitud [usuari sense mòbil] Rendiment [proves de càrrega] (...) Per desenvolupar un projecte Scrum amb èxit, és important que les històries d’usuari compleixin els principis INVEST, que són les inicials de: - Independent: la història hauria de ser auto-continguda, sense dependències amb altres històries. - Negotiable: les històries poden ser renegociades, reescrites i modificades, fins el moment en què entren en un Sprint. - Valuable: una història ha d’entregar valor als interessats (el negoci, els usuaris...). - Estimable: hauríem de ser capaços d’estimar l’esforç associat a desenvolupar la història. - Small: les històries haurien de ser el suficientment petites com per què les poguem estimar, planificar i prioritzar amb poca incertesa. - Testable: La història ha de contenir suficient informació com per què puguem desenvolupar els casos de prova. 5  Una èpica és un nivell d’agrupació per sobre de les històries d’usuari que permet classificar-les per funcionalitats, mòduls, subsistemes, etc… És a dir, es té en ment una imatge abstracta del que es vol obtenir amb l’èpica (que es desenvoluparà probablement en diversos Sprints), però són les històries d’usuari, la seva implementació en els Sprints i el feedback els que acaben donant-li finalment la forma. ELS ARTEFACTES EN SCRUM Scrum té tres artefactes bàsics que ajuden a planificar i gestionar la feina de l'equip, i a lliurar-la a l'usuari: 1. Pila de Producte (Product Backlog) És la llista prioritzada d’elements o "ítems" que farà l'Equip per satisfer les necessitats de l'usuari. El PO n’és el responsable, incloent el seu contingut, disponibilitat i ordenació (tot i que el podria modificar el PPO o el DT, si és a criteri del PO). Els "ítems" (o PBI, de Product Backlog Item) són paquets de treball que aporten un valor concret a l'usuari i que es poden desplegar de manera independent. Els ítems més habituals són:  Requisits (normalment en forma d’històries d’usuari)  Defectes (correccions)  Millores tècniques transversals El Product Backlog evoluciona quan cal en base a la interlocució amb els usuaris i a l'aprenentatge obtingut de contrastar els increments resultants del Sprint amb les necessitats de l'usuari. => Seguiment del Progrés cap als Objectius del projecte El PO fa seguiment del treball restant per assolir els objectius del projecte, almenys en cada Revisió de Sprint (Sprint Review), i el compara amb el treball que restava pendent en Revisions de Sprint prèvies per avaluar el progrés cap a la finalització del projecte en el temps desitjat. 2. Pila del Sprint (Sprint Backlog) El Backlog del Sprint conté els ítems del Product Backlog que el PO i el DT acorden fer al Sprint com a més prioritaris tant des del punt de vista de negoci (pel valor que aporten) com des del punt de vista tècnic. El Sprint Backlog es pot desglossar en tasques si el DT ho considera necessari durant l'esdeveniment de Planificació del Sprint (Sprint Planning). Al Product Backlog no cal que les ítems tinguin estimació, però sí cal que la tinguin quan entren al Sprint Backlog (les estimacions s'ha de fer en sprints anteriors, durant els refinaments, o en la reunió de planificació de l'spring). El DT podria proposar canvis al Sprint Backlog per optimitzar la meta del Sprint (Sprint Goal), però el PO no pot proposar canvis al Sprint Backlog durant el sprint. =>Seguiment del Progrés del Sprint El DT fa seguiment del treball restant en el Sprint, almenys en cada Scrum Diari (Daily Scrum) per projectar la possibilitat d’aconseguir l’objectiu del Sprint. 3. Increment És el producte resultat del Sprint, construït sobre els increments previs. Conté tots els subproductes (codi, documentació, proves, scripts de pujada a producció, etc). Al final del Sprint l’increment ha d’estar “Fet”(“Done”), el que vol dir que compleix la Definició de Fet (Definition of Done - DoD) de l’Equip Scrum. És vital que aquest increment sigui potencialment lliurable (utilitzable) després de qualsevol Sprint per garantir la flexibilitat al PO de decidir si l’allibera o no. El DT és el responsable final de la qualitat de l’increment. 6 ALTRES ELEMENTS D'SCRUM Existeixen altres elements en Scrum importants, però que no formen part dels rols, esdeveniments i artefactes principals. Els més importants: o Definició de Preparat (Definition of Ready – DoR-): Ajuda a establir si un determinat element del Product Backlog conté tota la informació necessària per poder començar a treballar-hi dins un sprint. Els elements de la pila de producte que compleixen la DoR són candidats a entrar en un Sprint i podran ser seleccionats durant la propera reunió de Planificació del Sprint (Sprint Planning). La millor manera de tenir elements de la pila de producte que compleixen la DoR és mitjançant l'activitat periòdica de refinament, que s’explica més endavant en aquest punt. o Definició de Fet (Definition of Done – DoD-): D'acord amb la guia oficial de Scrum, quan es diu que un element del Product Backlog o un increment es troben fets, tothom ha de poder entendre el mateix sobre el que significa ‘Fet’ (de nou anem a parar al pilar de la Transparència). El DoD respon a un acord del DT apropiat per al producte en qüestió (llevat que vingui fixat pels estàndards de l’organització), que podrà ser revisat a mesura que el projecte avança i es disposa de les evidències empíriques de les bondats o mancances del DoD acordat. També pot variar d’un equip Scrum a un altre però si hi ha múltiples equips Scrum treballant en l’entrega d’un mateix sistema o producte, els equips de desenvolupament en tots els equips Scrum hauran de definir conjuntament i compartir la DoD. Aquesta mateixa definició guia el DT a l'hora de decidir quants i quins elements de la pila de producte poden seleccionar durant la reunió de Planificació del Sprint (Sprint Planning) donat que el propòsit de cada Sprint és entregar increments de funcionalitat que s'ajustin a la DoD de l'Equip Scrum, i que siguin potencialment desplegables en producció. o Refinament del Product Backlog (Product Backlog Grooming): És una activitat periòdica mitjançant la qual s'afegeix informació (detalls, estimacions, ordre, etc.) als elements del Product Backlog. El refinament es comença pels ítems de la part superior del Product Backlog, que en ser els més prioritaris, són els primers pels que caldrà complir la DoR per tal que puguin entrar en un Sprint. El PO és responsable d’ordenar (prioritzar) els ítems del Product Backlog i el DT és responsable de les estimacions d’aquests ítems. La freqüència amb què es fa aquesta activitat de refinament, en la qual participen el PO i el DT, dependrà del context específic (producte, equip, mercat, etc.). Per exemple, pot ser que un Equip Scrum no gaire madur hagi de refinar sovint els elements de la pila de producte perquè són massa grans i complexos. Un cop hagin après a tenir elements el més petits i senzills possible, la freqüència i la durada d'aquest tipus d'activitat anirà disminuint; al mateix temps, l'efectivitat de l'equip anirà augmentat. D'altra banda, unes reunions de refinament força freqüents també podrien ser degudes a la volatilitat del mercat i a la necessitat d'adaptar-s'hi constantment. Així doncs, de cara a la millora contínua, tant la freqüència i la durada com l'efectivitat de les activitats de refinament podran ser objecte de les reunions de Retrospectiva del Sprint (Sprint Retrospective) de l'Equip Scrum. La principal diferència entre aquesta activitat i els esdeveniments Scrum és que aquests darrers tots tenen una durada màxima prefixada, però el refinament és una activitat contínua que té lloc durant tot el Sprint. o Deute tècnic: Cost i interessos a pagar per haver fet les coses malament o per haver deixat de fer el que s'hauria hagut de fer. Acostuma a produir-se sobretot quan la data d'entrega d'un producte/servei s'aproxima i la pressió per acabar la feina pendent augmenta de manera considerable. 7  =>Algunes consideracions sobre el deute tècnic:  El deute tècnic pot ser involuntari (p.ex. feina de baixa qualitat per falta d'experiència) o intencional (p.ex. feina de baixa qualitat per assegurar-se encàrrecs de manteniment posteriors).  Tot i que no es veu, el deute tècnic treu valor al producte/servei en qüestió.  Normalment les persones que generen deute tècnic no són les mateixes que en paguen els interessos.  Poden ser els proveïdors, els clients, o els usuaris, però al final sempre hi haurà algú que pagarà el deute tècnic. o Eines de seguiment del desenvolupament: d'ús habitual als equips Scrum. Les proporcionen les eines web o en paper:  Eines per projectar tendències i predir el progrés en base a la velocitat del DT fins al moment actual:  Gràfiques Burndown (diagrama de treball pendent) del Sprint i de la versió o Release  Gràfica Burnup (treball completat) de la versió o Release  Cumulative Flow (flux acumulat)  Altres eines:  Tauler Kanban Pel que fa a la gestió integral dels projectes Scrum, són molt adequades les eines col laboratives, perquè s’alineen amb el pilar Scrum de la transparència i faciliten la inspecció. Qualsevol membre de l’equip pot saber en qualsevol moment i de forma autònoma l’estat del Product Backlog i dels Sprints. En el cas de l’Ajuntament de Barcelona s’utilitzen les eines col laboratives següents: 8   JIRA: per la gestió dels projectes Scrum. Permet mantenir el Product Backlog i gestionar el cicle de vida dels Sprints. També permet generar diferents reports com per exemple la gràfica Burndown del Sprint.  Confluence per gestionar la documentació associada als projectes Scrum. o Pràctiques d’enginyeria i automatització Fan més efectiu el desenvolupament amb Scrum:  Proves unitàries automatitzades del codi (TDD))  Integració Contínua (CI)  Proves funcionals automatitzades del sistema (ATDD i BDD)  Desplegament Continu (CD)  Infraestructura com a codi  DevOps: és un conjunt de tecnologies i bones pràctiques de desenvolupament de programari estretament lligades amb les metodologies àgils tals com Scrum perquè permet als equips de desenvolupament lliurar els increments de software de forma iterativa i continuada assegurant la qualitat del codi, la transparència i comunicació a llarg del desenvolupament del producte. Principals rols i les seves funcions L’ST està format per 3 rols: 1. El Propietari del Producte (Product Owner - PO) És el “guardià del valor del producte” (una persona): té com a objectiu maximitzar el valor lliurat als usuaris amb els recursos disponibles. Ho aconsegueix gestionant la demanda (prioritzada en el Product Backlog) i verificant quan està preparat el producte per ser lliurat a l'usuari. El PO no és un analista, sinó un gestor que té en compte els objectius i necessitats de l'usuari i que interactua amb el DT per aconseguir-los. Requereix comunicació i col·laboració constant amb el client. 2. L’equip de desenvolupament (Development Team - DT) Conjunt de persones que desenvolupa la solució completa, incloent activitats com: anàlisi funcional, disseny tècnic, programació, proves tècniques i funcionals i posada en producció. El DT no són únicament programadors: és un equip sense dependències d'altres persones ni equips per lliurar totes les necessitats de l'usuari. El DT s'autogestiona en la realització de les necessitats prioritzades pel PO. Això vol dir que:  Planifiquen com fer la feina dins del Sprint.  Segueixen l'estat del Sprint i com repartir-se la feina.  Interactuen amb el PO i amb rols de fora de l'equip segons es necessiti.  Identifiquen millores al seu funcionament. El DT s’encarrega de crear l’increment de producte que s’entrega en estat de “Fet”(“Done”) segons la DoD al final del Sprint. És un equip horitzontal (sense jerarquies), multidisciplinari, auto-organitzat i responsable en la seva totalitat sobre el treball realitzat. => Mida del DT: suficientment petit per ser àgil i no requerir massa coordinació i suficientment gran per poder completar una quantitat de treball significativa contemplant totes les habilitats 9  necessàries. La recomanació de la Guia oficial de Scrum.org és que tingui un mínim de 3 membres i un màxim de 9. 3. El Scrum Master (SM) És el “guardià de la metodologia”(una persona): és un entrenador de tota l'organització per augmentar la seva efectivitat i agilitat. No es el líder del DT (perquè ells s’auto-organitzen), sinó que actua com una protecció entre el DT i qualsevol influència que el distregui. El seu objectiu és liderar i ajudar a les persones (és un facilitador de l’aplicació de Scrum), no intervenir els desenvolupaments. Ajuda les persones externes a l'ST a entendre quines interaccions amb l'ST poden ser útils i quines no, ajudant a modificar aquestes interaccions per maximitzar el valor creat per l'ST. S’encarrega d’eliminar els obstacles que impedeixen que l’equip assoleixi l’objectiu del Sprint. Resumint, les principals funcions del SM són:  Formar i ajudar a treballar en Scrum a les persones de l'organització.  Fer un seguiment del PO i del DT, guiar-los en l’exercici dels seus rols i millorar el seu rendiment.  Ajudar a tota l'organització a la transformació àgil i eliminar els impediments per a l'agilitat. Addicionalment existeix un quart rol (opcional): el Proxy Product Owner (PPO): De vegades el PO no té la capacitat d'estar tant a prop dels usuaris com del DT, normalment per excés de càrrega de treball. Tot i que la millor opció és alliberar-lo d'activitats no essencials per la seva missió, una altra opció consisteix en habilitar un rol auxiliar com el PPO per centrar-se en aspectes com la gestió detallada del Product Backlog. És un rol que en el cas concret de l’Ajuntament de Barcelona s’ha implantat, però no és exclusiu d’aquest entorn, sinó que al sector privat també existeix en molts casos. Descripció de les reunions principals de treball Scrum té una sèrie d’esdeveniments o reunions estàndard. Tots ells tenen un time-box (temps màxim) que es pot dedicar a l’esdeveniment per garantir que l’equip no es dispersa. En tot cas, un Sprint més curt exigeix esdeveniments més curts. El 4 esdeveniments estàndard, i els seus Time-box associats són els següents: 1. Planificació del Sprint (Sprint Planning) Reunió inicial de cada Sprint on el PO i el DT determinen quins ítems del Product Backlog es faran durant la iteració que comença. Aquesta reunió té 2 objectius principals: 1. Determinar què es farà: se seleccionen els ítems més prioritaris des del punt de vista de negoci i tècnic, de manera col·laborativa entre el PO i el DT. El PO discuteix l’objectiu que el següent Sprint hauria d’assolir i s’acorden els ítems del Product Backlog que s’abordaran per assolir aquest objectiu, que no poden excedir la quantitat de treball que el DT pot comprometre’s a completar durant el Sprint. En aquesta reunió l'ST defineix l’objectiu del Sprint (Sprint Goal). 2. Determinar com es farà: el DT analitza tècnicament com es faran els ítems, p.e. fent un disseny d'alt nivell i desglossant les tasques tècniques. És molt important que els ítems estiguin prèviament analitzats (en estat “Preparat” (“Ready”) segons el DoR) per tal que aquesta reunió sigui efectiva i es generin pocs dubtes que puguin provocar problemes durant el Sprint. 10  Els ítems del Product Backlog seleccionats per a aquest Sprint, més el pla per finalitzar-los, rep el nom de Pila de Sprint (Sprint Backlog). Planning pocker és una possible forma d’estimar els ítems del backlog que són candidats a entrar en el següent sprint. L’estimació es pot fer en hores o en punts i és decisió de l’equip, al igual que el valor dels punts. Segons la capacitat de l’equip, i la durada del proper sprint, podran entrar més o menys ítems en el següent Sprint. No obstant, la guia Scrum no entra en les tècniques concretes d’estimació. Aspectes bàsics: o Assistents: ST (PO, DT i SM), tot i que a l'Espai Agile de l'IMI la participació de l'SM és opcional. o Time-box (Durada màxima): 8 hores per un Sprint d'1 mes. Per Sprints més curt, l’esdeveniment és usualment més curt. o Entrades: Product Backlog i metes de negoci del PO, darrer increment de producte, capacitat projectada del DT per al Sprint. o Sortides: Sprint Backlog i meta del Sprint (Sprint Goal). 2. Scrum diari (Daily Scrum) És una reunió que es fa tots els dies per tal que el DT faci seguiment del Sprint, es coordini i decideixi accions correctives en cas que sigui necessari. Optimitza les possibilitats de què el DT compleixi l’objectiu o meta del Sprint (Sprint Goal). Els membres del DT utilitzen aquestes preguntes per coordinar-se i prendre decisions: o Què he fet en les darreres 24 hores per ajudar al DT a assolir la meta del Sprint? o Què faré en les properes 24 hores per ajudar al DT a assolir la meta del Sprint? o Quins riscos o problemes veig per què el DT o jo assolim la meta del Sprint? Per reduir complexitat el Scrum diari (Daily Scrum) es realitza a la mateixa hora i lloc tots els dies. El DT és l’encarregat d’establir l’estructura de la reunió. El DT o els seus membres sovint es tornen a reunir després del Scrum Diari (Daily Scrum) per discutir detalladament algun dels temes sorgits. Els Scrum Diaris (Daily Scrum) milloren la comunicació, redueixen la necessitat de realitzar altres reunions, identifiquen impediments a gestionar, promouen la presa ràpida de decisions i milloren el nivell de coneixement del DT. És una reunió clau d’inspecció i adaptació. Aspectes bàsics o Assistents: DT i SM, tot i que a l'Espai Agile de l'IMI la participació de l'SM és opcional o Time-box (Durada màxima): 15 minuts. o Entrades: Sprint Backlog i meta del Sprint (Sprint Goal). o Sortides: Sprint Backlog i decisions preses. 3. Revisió del Sprint (Sprint Review): És una reunió de gestió on el PO i el DT revisen què s'ha aconseguit lliurar a l'increment i pensen què queda per fer als futurs sprints (es pot adaptar el Product Backlog si és necessari). A aquesta reunió pot assistir qualsevol altre rol de l'organització que el PO consideri convenient convidar per tal que conegui l'estat del desenvolupament. Durant aquesta reunió es pot fer una demo general per identificar millores per propers Sprints, però aquesta demo no serveix per validar les funcionalitats lliurades. La validació dels ítems lliurats ha de fer- se durant el Sprint, ítem a ítem per part del PO, i ha de formar part de la Definició de Fet (DoD). 11  Aspectes bàsics o Assistents: ST i els interessats clau invitats pel PO (DT, PO, SM i altres rols de l'organització), tot i que a l'Espai Agile de l'IMI la participació de l'SM és opcional. o Time-box (Durada màxima): 4 hores per Sprints d’un mes. Per Sprints més curts, es reserva un temps usualment més curt. o Entrades: Product Backlog i meta del sprint (Sprint Goal). o Sortides: Product Backlog revisat. 4. Retrospectiva del Sprint (Sprint Retrospective): És la darrera reunió del Sprint, on el DT, el PO i el SM identifiquen millores al funcionament de l'Equip Scrum (Scrum Team) per a propers Sprints (el propòsit d’aquesta reunió és realitzar una millora contínua del procés). És on cada membre de l'Equip valora el darrer Sprint i fa propostes pel següent, responent a les preguntes: o Què ha anat bé en aquest Sprint? o Què ha anat malament en aquest Sprint? o Quines accions concretes de millora podríem fer als propers Sprints? És convenient que el SM faci també propostes de millora i un seguiment de les millores proposades durant els Sprints previs. Aquesta reunió té lloc després de la Revisió de Sprint (Sprint Review) i abans de la següent Planificació de Sprint (Sprint Planning). Les millores funcionals detectades les ha d'aprovar el PO. En cas de ser millores d'organització/gestió, les ha d'aprovar l'ST. Aspectes bàsics o Assistents: ST (DT, PO i SM). o Time-box (Durada màxima): 3 hores per Sprints d’un mes. Per Sprints més curts, es reserva un temps usualment més curt. o Entrades: Millores identificades en anteriors Retrospectives (Sprint Retrospective), evolució del darrer Sprint completat, en quant a persones, relacions, processos i eines. o Sortides: noves millores identificades per al proper Sprint. 12  Cicle de desenvolupament Revisar i validar resultat Sprint: tot l’equip és corresponsable. El PO n’és Coordinació i planificació de la l’aprovador Què i com es farà al sprint?: tot jornada: tot l’equip (DT) és l’equip (ST) és corresponsable corresponsable. SM condueix reunió Product de la seva execució. El PO n’és Owner (PO) prioritzador Proxy Product Owner (PPO) Development Sprint Team (DT) 3 setmanes Scrum Master (SM) Identificar què BACKLOG REFINEMENT es pot millorar Scrum Team (ST) pel proper Sprint: tot l’equip és corresponsable. SM n’és l’aprovador Actor interessat 3 He afegit els dubtes d'Scrum resolts per l'Eva Terrer a l'explicació anterior. És recomanable llegir la informació de l'annex, especialment la de Scrum@IMI i la industrialització de l'spring 0 de l'SCRUM@IMI (publicat a l'agost del 2021). També seria convenient mirar-se la informació de la carpeta SCRUM@IMI (per saber qui fa i aprova cada ítem del procés). De totes formes, reconec que NO HE ESTAT CAPAÇ DE VEURE ON ESTÀ LA INFORMACIÓ DE LA PREGUNTA DE SCRUM QUE VAN INCLOURE AL TEST DE L'OPO2019. Només es pot respondre utilitzant la lògica, perquè m'he mirat tots els documents de la documentació addicional i en cap d'elles s'indica que al finalitzar la reunió de planificació és l'SM l'encarregat de comunicar a l'ST: l'informació de l'sprint, objectiu, velocitat estimada, capacitat i longitud de l'sprint acordat en la reunió. TEST 6. La metodologia SCRUM descriu que a l’inici d’un sprint, després de la seva planificació, és convenient realitzar un seguit de tasques com ara:  Crear una pàgina d’informació de l’sprint  Enviar un correu a tot l’equip scrum informant que es dona per iniciat el nou sprint incloent- hi l’objectiu i l’enllaç a la pàgina  Actualitzar el document d’estadístiques de l’sprint, afegint la velocitat estimada, la capacitat de l’equip i la longitud de l’sprint. La realització d’aquestes tasques correspon a les funcions del rol de: A. Product owner. B. Equip scrum. C. Scrum master. D. Equip de desenvolupament. 23. L’organització TI ha identificat que els requisits del nou producte no són coneguts d’una manera clara i ha recomanat que l’equip de desenvolupament de software treballi seguint la metodologia àgil SCRUM, tot i que hi ha moltes parts amb diferents necessitats i interessos, la mateixa àrea central, els districtes i els casals de barri. El projecte és 13 complex i després de les converses a tres bandes, l’àrea central d’acord amb TI ha assignat el rol de “Product Owner” a una persona del districte de Sant Martí, en concret a la directora del Servei a les Persones i Territori, com a professional experimentada en la introducció de canvis a l’organització. Quines de les següents funcions haurà d’exercir aquesta directora com a “Product Owner”, en el marc del projecte de desenvolupament del nou producte: A. Estimar l’esforç de cada tasca de cada sprint. B. Proporcionar suport a l’equip de desenvolupament. C. Mantenir la pila de producte (en anglès “product backlog”). D. Proposar i promoure millores sobre el funcionament de l’equip. 24. Continuant amb l’assignació de rols de la metodologia SCRUM per al desenvolupament de software, l’àrea central i TI han acordat que el rol de “Scrum Master” recaigui en una persona del departament de desenvolupament de TI. Assenyala quina de les següents opcions correspon a les funcions d’aquest rol: A. Prioritzar les històries que entren a cada sprint. B. Proposar, promoure i potenciar millores sobre la forma de treball i sobre l’equip. C. Estimar l’esforç de cada història a cada sprint. D. Gestionar el pressupost. 12. Per al sistema de manteniment evolutiu del gestor d’expedients de contractació del Lot 1 s’ha decidit que s’aplicarà un mètode àgil de desenvolupament de programari. Des d’una perspectiva SCRUM, les següents definicions: 1. requeriments prioritzats a acomplir de tot el projecte 2. reunió valorativa del funcionament de l’equip de treball i entorn del projecte i millores possibles a aplicar 3. coordinador i supervisor del funcionament i aplicació del mètode Corresponen ordenadament als següents elements: A. 1.Product backlog – 2.Reunió de Sprint – 3.Equip de desenvolupament. B. 1.Product backlog – 2.Reunió de retrospectiva – 3.Scrum master. C. 1.Sprint backlog – 2.Reunió diària d’Scrum – 3.Cap de l’Equip de desenvolupament. D. 1.Definition of done – 2.Sprint backlog – 3.Product owner. BIBLIOGRAFIA ESPAI AGILE IMI http://llocs.ajuntament.bcn/llocs/ComInterna/GovernSeguretat/Qualitat/Pagines/Metodologia/Espai%20Agi le/Espai-Agile.aspx SCRUM IMI http://llocs.ajuntament.bcn/llocs/ComInterna/GovernSeguretat/Qualitat/Pagines/Metodologia/Espai%20Agi le/[email protected] SCRUM IMI https://es.wikipedia.org/wiki/Scrum_(desarrollo_de_software) Altres fonts consultades (s’adjunten com a documentació de suport per qui desitgi ampliar continguts):  Glossari Scrum (Scrum Glossary.pdf) 14   Guia oficial Scrum.org (2017-Scrum-Guide-Spanish-European.pdf)  The Scrum PRIMER, a Lightweight Guide to the Theory and Practice of Scrum (scrumprimer20.pdf)  The Scrum Master Training Manual (The Scrum Master Training Manual - Management Plaza ( PDFDrive.com ).pdf)  Metodologies AGILE a l’Ajuntament de Barcelona (guia_adt_3_metodologies_agile_cat_2017_af_3.pdf) ANNEX Beneficis de Scrum  Entrega periòdica de resultats (els requeriments més prioritaris en aquell moment, ja completats), el que proporciona els següents avantatges: o Gestió regular de les expectatives del client i basades en resultats tangibles: el client comprova de manera regular si es van complint les seves expectatives, dóna feedback, ja des de l'inici del projecte pot prendre decisions informades a partir de resultats objectius i dirigeix aquests resultats del projecte, iteració a iteració, cap a la seva meta. S'estalvia esforç i temps pel fet que s’eviten hipòtesis. o Reducció del Time to Market: el client pot començar a utilitzar les característiques més importants del projecte abans de què estigui completament acabat (d’aquí la importància de què el Product Backlog es prioritzi maximitzant el valor). Focus en el valor i la satisfacció del client. o Flexibilitat i adaptació davant dels canvis: de manera regular el client redirigeix el projecte en funció de les seves noves prioritats, dels canvis en el mercat, dels requisits completats que li permeten entendre millor el producte, de la velocitat real de desenvolupament, etc. Al final de cada iteració el client pot aprofitar la part de producte completada fins a aquest moment per fer proves de concepte amb usuaris o consumidors i prendre decisions en funció del resultat obtingut o Gestió sistemàtica del Retorn de la Inversió (ROI): de manera regular, el client maximitza el ROI del projecte. Quan el benefici pendent d'obtenir és menor que el cost de desenvolupament, el client pot finalitzar el projecte. o Mitigació sistemàtica dels riscos del projecte: des de la primera iteració l'equip ha de gestionar els problemes que poden aparèixer en un lliurament del projecte. En fer patents aquests riscos, és possible iniciar la seva mitigació de manera anticipada. "Si cal equivocar-se o fallar, millor fer- ho el més aviat possible". El feedback primerenc permet estalviar esforç i temps en errors tècnics. La quantitat de risc a què s'enfronta l'equip està limitada als requisits que es poden desenvolupar en una iteració. La complexitat i riscos del projecte es divideixen de manera natural en iteracions.  Major productivitat i qualitat: De manera regular l'equip va millorant i simplificant la seva forma de treballar. Els membres de l'equip sincronitzen el seu treball diàriament i s’ajuden a resoldre els problemes que poden impedir aconseguir l'objectiu de la iteració. Les persones treballen més enfocades i de manera més eficient quan hi ha una data límit a curt termini per lliurar un resultat al qual s'han compromès. La consciència d'aquesta limitació temporal afavoreix la priorització de les tasques i força la presa de decisions. El fet que la durada dels Sprints sigui regular facilita la sincronització sistemàtica amb 15  altres equips, amb la resta de l'empresa i amb el client. Així mateix, amb iteracions curtes la precisió de les estimacions augmenta. Les persones treballen de manera més eficient i amb més qualitat quan elles mateixes decideixen com fer-ho (auto-organització), que quan se'ls ha assignat una tasca i indicat el temps necessari per realitzar-la. L’equip està més motivat (no només per aquesta auto-organització, sinó també perquè pot usar la seva creativitat per resoldre problemes), el que també redunda en una major productivitat. L’equip s'evita caminar molt de temps per un camí equivocat que l'obligui a realitzar un gran esforç per arribar a l'objectiu esperat. S'assegura la qualitat del producte de manera sistemàtica i objectiva, a nivell de satisfacció del client, requisits llestos per ser utilitzats i qualitat interna del producte.  Alineament entre el client i el DT: els resultats i esforços del projecte es mesuren en forma d'objectius i requisits lliurats al negoci. Tots els participants en el projecte coneixen quin és l'objectiu a aconseguir. El producte s'enriqueix amb les aportacions de tots.  Compromís dels Stakeholders (grups d’interès): Scrum requereix una cooperació propera i diària amb les persones usuàries, tant per obtenir correctament els requisits del projecte com per verificar l’increment de valor del producte en cada Sprint.  Costos i planificació previsibles: a través d’aquest marc de treball es coneix la velocitat mitjana de l’equip per Sprint, amb el que és més fàcil estimar quan es podrà lliurar determinada funcionalitat que encara està en el Product Backlog. 16 Scrum@IMI Per abordar projectes Scrum a l’IMI, s’ha fet una adaptació de Scrum al nostre entorn que s’ha anomenat Scrum@IMI. En els epígrafs d’aquest tema es parla del Scrum genèric. L’Equip Scrum a l’IMI La implementació dels rols de Scrum a l'IMI es fa respectant al màxim els objectius i les responsabilitats estàndard dels rols, a la vegada que s'adapten al context de l'IMI, que proveeix serveis complexes de gestió TIC per l'Ajuntament de Barcelona. o Product Owner (Ajuntament) Donat que és el rol que té com a objectiu maximitzar el valor lliurat als usuaris, les millors implementacions del rol són aquelles on el PO està a prop d'on es prenen les decisions "de negoci", motiu pel qual s'empodera amb aquest rol a alguna persona clau dels sectors i gerències de l'Ajuntament. El PO a l'Ajuntament típicament té una alta càrrega de feina i molts interlocutors amb els que interactuar. Això fa que puguin tenir poca dedicació a les activitats habituals del PO, per aquests motius, serà freqüent que els PO tinguin un rol assistent a l'IMI anomenat Proxy Product Owner. Això en cap cas li ha de restar transparència envers les activitats de l'equip ni capacitat de decisió. o Proxy Product Owner (IMI) Tal com s’ha comentat, en el context de l'Ajuntament i de l'IMI, serà freqüent que l'IMI aporti aquest rol, les funcions més habituals del qual seran:  Donar suport al PO amb la definició de la part tècnica de l'Avantprojecte o Plec.  Coordinar l'estimació de l'esforç del Product Backlog inicial per part del DT.  Desglossar el Product Backlog durant el refinament.  Planificar els lliuraments conjuntament amb l'Equip.  Definir els criteris d'acceptació dels ítems.  Aclarir dubtes funcionals durant el refinament o el Sprint.  Coordinar i supervisar el Pla de gestió del canvi (des del punt de vista tècnic).  Analitzar i prioritzar els incidents de Producció derivats a l'Equip. o Equip de Desenvolupament (Proveïdor) El DT realitza totes les activitats necessàries de desenvolupament. El PO i PPO seran els principals interlocutors respecte la feina a fer, i el SM els servirà de guia metodològic i també d'orientació organitzativa dins de l'IMI. o Scrum Master (IMI) En el context de l'IMI, el SM té alguns objectius addicionals als habituals del rol:  Ajudar al DT a integrar-se a l'entorn de l'IMI i Ajuntament, especialment amb els departaments transversals.  Proporcionar al DT la guia sobre els aspectes metodològics i de qualitat en l’entorn de l’IMI.  Facilitar els esdeveniments Scrum i fer suggeriments de millora.  Fer el seguiment del Backlog de millores de l'Equip.  Realitzar un seguiment i control del rendiment del DT, amb l'objectiu d'ajudar-los a millorar. Només en el cas de desviacions greus del rendiment i la incapacitat de solucionar-les, les hauria d'escalar al PO/PPO i al Responsable de contracte. 17   Ajudar a desenvolupar-se als membres de l'Equip (entrenament individual). Respecte la vessant organitzativa del SM, els seus objectius principals inclouen:  Desenvolupar l'Espai Agile.  Desenvolupar les eines ALM conjuntament amb el grup d'Arquitectura.  Coordinar l'Equip Scrum amb els departaments transversals.  Coordinar-se amb els altres SM en una Comunitat de Pràctica (CoP). o A banda d’aquests rols, s’afegeixen els següents: - Responsable del contracte (IMI): El Responsable del Contracte (RC) és un rol de Scrum@IMI que té com a objectiu principal portar a terme el seguiment del contracte i el model de relació contractual amb el proveïdor. És el màxim responsable del resultat positiu del servei i del compliment de les condicions descrites al plec i al contracte. Les seves principals tasques són: o Gestió del Contracte → Aspectes de facturació, penalitzacions, aspectes administratius. o Seguiment dels canvis, lliurables, substitució d'uns lliurables per altres i assegurament dels canvis formals. o Avaluació econòmica del Sprint Backlog. o Execució de les reunions de seguiment econòmic del contracte. o Reporting a les eines de control pressupostari de l'IMI. - Enllaços : L'equip es complementa amb enllaços de totes les àrees de l'IMI que tinguin participació en el projecte. Aquests enllaços faciliten la interacció, la transmissió d'informació, aporten la seva visió dins de la seva especialitat/àrea i els requisits no funcionals al projecte. Model de Governança amb Scrum La governança en Scrum està basada en la transparència, i en la freqüent inspecció i adaptació dels Sprints, dins de l'Equip Scrum. L'IMI té tres rols (PO, PPO i SM) sincronitzats amb els resultats (i el funcionament) dels 18 sprints. Tot i així, tant la complexitat de l'estructura de l'Ajuntament i de l'IMI, com la dels projectes, pot requerir algunes activitats de coordinació amb la resta de rols. Aquestes activitats respecten totalment la independència de l'Equip Scrum: o Comitè de Direcció: El Comitè de Direcció permet corregir eventuals desviacions de l'execució del projecte, o d'alineament amb els departaments de l'IMI. Donada l'autonomia i l'empoderament dels rols de l'IMI a l'Equip Scrum, així com les inspeccions freqüents dels Sprints, aquesta necessitat queda bastant reduïda. Tot i així, la coordinació amb els directors de l'IMI i els gerents de l'Ajuntament segueix essent convenient, malgrat els comitès probablement seran, en general, més curts i rutinaris. Aquestes reunions estaran sincronitzades amb els sprints, recomanant que no entre elles com a mínim transcorrin 2 Sprints o un mes. L'assistència habitual a aquesta reunió hauria d'incloure:  Director de desenvolupament de l'IMI.  Gerent del sector pel que es desenvolupa el projecte.  Product Owner.  Proxy Product Owner.  Scrum Master (opcional).  Responsables del contracte. o L’equip Scrum i els departaments transversals: L'Equip Scrum és en principi autogestionat i autosuficient, però en organitzacions complexes com IMI requerirà del cert coordinació almenys amb els departaments transversals com Arquitectura, Seguretat o Operacions. L'enfocament serà per part d'aquests més de mentorització i capacitació per reduir la intervenció habitual i el control. Cal destacar el paper del Scrum Master, i dels enllaços en aquesta coordinació. Alguns moments on pot ser habitual la col·laboració entre aquests departaments i l'Equip Scrum són:  La fase d'avantprojecte, on poden donar suport al PO i PPO en la redacció del plec.  L'activitat de refinament, on poden donar suport al PPO i al DT en l'anàlisi funcional i tècnic  La reunió de Scrum Diari (Daily Scrum), si els membres dels departaments transversals s'involucren temporalment al Sprint per donar suport a la realització dels ítems. En molts projectes Scrum de l’IMI, s’ha optat per convidar els enllaços a una reunió de Scrum Diari setmanalment (una de les cinc setmanals).  La reunió de Revisió del Sprint (Sprint Review), on poden aportar idees a l'Equip Scrum i sincronitzar-se amb aquests per als següents Sprints. Model de qualitat Scrum a l’IMI: A banda dels mecanismes estàndard de Scrum ja explicats que incideixen en la qualitat del producte (la Definició de FET (DoD), l’acompanyament del SM, l’anàlisi del procés a les Retrospectives...), afegir dos instruments addicionals: o L’anàlisi estàtic del codi: La plataforma SIDECAR incorpora la possibilitat de fer anàlisi estàtica del codi amb l’eina Sonar a l’etapa d’integració contínua. o Les enquestes a l’usuari: Les enquestes freqüents (p.e. mensuals) haurien d’ajudar a tenir un coneixement quantitatiu i freqüent de la satisfacció amb el producte i el procés tant de l’Equip Scrum directament implicat, com de la Direcció de l’IMI. 19 La “industrialització” de l’sprint 0 Com a novetat, s’incorpora la “industrialització” de l’Sprint 0. En els projectes Scrum@IMI, l’sprint 0 (podem consultar-ne la descripció a l’Espai Agile) té per objectiu crear la infraestructura de la nova aplicació i generar una primera pàgina de prova (Hello IMI) a l’entorn de preproducció. Donat que el conjunt de tasques i peticions a dur a terme són semblants d’un projecte a un altre, i amb l’objectiu de millorar l’eficiència de l’sprint 0, s’ha elaborat un quadern de bitàcola, conformat per un conjunt predefinit de tasques i del rol responsable d’abordar cada una d’elles. La identificació de les tasques d’aquesta guia, que s’anirà depurant i millorant amb la implementació dels cicles de millora contínua que permet el marc de treball SCRUM@IMI, és fruit d’unes sessions de treball i col·laboració entre les diferents àrees tècniques de l’IMI. La valoració d’aquesta iniciativa per part dels dos projectes ha estat molt positiva, amb apreciació d’un estalvi significatiu en el temps i les gestions necessàries per completar el primer desplegament a l’entorn de preproducció. FAQ’s - Per què s’està implementant Agile a l’IMI? La implantació de les metodologies àgils neix com a part del pla de Transformació Digital impulsat des de l'IMI que pretén la millora en l'entrega dels projectes estratègics així com de la necessitat interna de transformació, que està basada en els principis del Manifest Àgil. Aquests principis es focalitzen en la maximització del lliurament de valor a l'usuari: - Fomentant una estreta col·laboració amb l'equip que desenvolupa el producte o servei. - Creant equips de desenvolupament multidisciplinaris, auto-organitzats i autosuficients. - Escurçant el temps de desenvolupament per oferir increments de producte de manera freqüent, que l'usuari pugui validar millorant així la qualitat de l'entrega. - Vistos els rols Scrum...Qui és el Cap de Projecte? No existeix aquest rol en Scrum. Les responsabilitats del cap de projecte estan distribuïdes entre els tres rols de Scrum, i no hi ha una gestió centralitzada del projecte. - Com es poden contractar projectes Scrum en l’Administració pública, on els contractes requereixen concretar a priori l’abast, els recursos i les fites de facturació? Efectivament la contractació de projectes Scrum en l’Administració pública és un repte. La solució passa per buscar un punt d’equilibri en el nivell de concreció de l’abast del producte a desenvolupar i les seves fites de planificació i facturació, que permeti d’una banda acotar el projecte i establir un marc de treball, i de l’altra garantir el marge de flexibilitat que tot projecte Scrum requereix per adaptar el producte que es va desenvolupant a les necessitats que es van identificant conforme el projecte avança. Aquest punt d’equilibri pot venir donat per uns requeriments funcionals a molt alt nivell (per exemple a nivell d’èpiques) i una definició de versions o Releases. Tot plegat fixarà un marc de treball dintre del qual existirà flexibilitat en la definició de les històries d’usuari de cada èpica, i del sprints de cada Release. D’altra banda, durant l’execució del contracte, cal anar deixant constància del que es desenvolupa i el que no, de cara a les certificacions que es duguin a terme posteriorment. 20