Aquesta primera fase es duen a terme les accions prèvies necessàries per a una bona planificació i visió inicial del projecte, així com revisar i corroborar aspectes contractuals. Trobareu preguntes sobre els rols que duran a terme el projecte, tràmits sobre els entorns de treball, usuaris, materials i accessos necessaris perquè un equip sigui completament operatiu el dia del Kick-Off.
Un equip autogestionat és aquell que decideix per si mateix com fer les feines, quines persones estan a l'equip per fer aquesta feina, i fins i tot el producte en què aquest equip està treballant. L'autogestió es beneficia de límits explícits, per evitar el caos organitzacional. Per exemple, aquí en el CTTI, en un equip de desenvolupament de programari tenim diferents rols com desenvolupadors de programari, testers, arquitectes, analistes, consultors, etc. on tots els membres tenen totes les capacitats necessàries per ser autosuficients i per fer totes les tasques necessàries en un desenvolupament. Això és el que s'anomena equip scrum.
Els equips àgils no treballen sols, sovint hi ha dependències entre tasques desenvolupades entre equips diferents o productes diferents, i aquesta situació la podem gestionar treballant de forma escalada. Hi ha diversos marcs que es basen en Scrum per resoldre desafiaments específics que poden trobar els equips, com ara Nexus, Scrum-at-Scale, LeSS o SAFe®.
La reunió de Kick-Off de projecte és una trobada que es realitza al començament d'un projecte àgil per definir els objectius i les expectatives del projecte i establir la base per a una comunicació i col·laboració efectives entre els membres de l'equip, els interessats, promotors i clients. Aquesta reunió és útil per establir una base sòlida, és a dir, assegurar una bona marxa del projecte amb governança, seguiment, acords de treball, rols i persones responsables. També és un camí a seguir planificant amb un roadmap que inclogui fites i lliurables per a una bona execució. Establir objectius clars i definir amb precisió l'abast del projecte i identificar les parts interessades i definir rols i responsabilitats.
Per saber sobre quines serien les funcions que realitzaria qualsevol rol del model de treball <Scrum/CTTI>, podeu trobar tota la informació des de la infografia interactiva que es troba a la web de Qualitat fent clic al rol que voleu consultar, i també en el Playbook que podeu descarregar des de la mateixa infografia.
Aquesta fase d'Esprint 0 és el primer esprint d'un projecte que segueix el model <Scrum/CTTI> i es considera un esprint especial de preparació de l'equip. Aquí trobareu preguntes sobre totes les cerimònies habituals, la planificació que es fa amb un conjunt de tasques específiques, orientades a construir una primera versió de la Pila de producte (Product Backlog) que serà deixar llestes (Ready) les Històries d'Usuari (HU) més prioritàries, i eliminar impediments de cara a l'esprint 1 i successius. S'ha de centrar en fer una prova de concepte del desenvolupament, que garanteixi que el codi està al SIC i es desplega a l'entorn de preproducció. També convé que es facin les proves adients d'integració amb altres sistemes, càrrega, regressives, acceptació de l'usuari, etc.
A l'inici del projecte, l'equip haurà d'executar una primera iteració que consistirà a executar un conjunt de tasques o Històries d'Usuari (HU) per assegurar el correcte encaix de l'equip a l'inici del desenvolupament. Algunes d'aquestes tasques són d'obligada realització per a tots els casos. Altres dependran de cada projecte. A continuació, es detallen aquestes tasques:
Comunicar el Kick-Off: Com a part interessada, implicada o afectada pel projecte, vull que se'm comuniqui les característiques del Kick-Off (dia, hora, lloc…) per poder-hi assistir, si fos oportú.
Realització del Kick-Off: Com a responsable del projecte vull donar a conèixer el mateix a totes les parts interessades, implicades o afectades. També vull alinear les diferents expectatives i necessitats.
Planificació de lliurables: Com a equip volem tenir una planificació inicial a alt nivell dels lliurables que s'han de dur a terme.
Acordar DoR (Definició de Llest) i DoD (Definició de Fet): Com a part de l'equip vull una definició clara de quan una HU està llesta per poder-la treballar i quan compleix tots els requisits per poder-la implementar.
Pla mestre de proves: Com a usuari vull garanties que l'aplicació compleix amb tots els estàndards de qualitat (seguretat, funcionalitat, rendiment...).
Prototip: Com a propietari de l'aplicació vull poder tenir una primera versió per validar l'enfocament adoptat.
Integració amb Gicar: Com a CTTI vull que les aplicacions que es desenvolupen s'integrin dins de Gicar per al registre d'usuaris.
Procediments de desenvolupament: Com a CTTI vull que totes les persones que treballen en desenvolupament i manteniment d'aplicacions, coneguin els procediments, protocols, estàndards, artefactes... propis.
Document d'arquitectura: Com a CTTI necessito que totes les aplicacions que es desenvolupen, respectin i s'integrin a l'arquitectura corresponent, seguint les indicacions establertes.
Hello Wolrd App: Com a desenvolupador i com a CTTI vull estar segur que l'equip disposa de les eines i coneixements per poder desplegar una aplicació a l'entorn productiu.
Revisar requisits: Com a CTTI i com a proveïdor volem tenir clars els requisits de l'oferta.
Aspectes contractuals: Com a CTTI i com a proveïdor volem tenir clars i corroborar els aspectes contractuals que hem de complir.
Assegurar capacitat de l'equip: Com a equip volem assegurar que tenim tots els rols necessaris amb el coneixement corresponent per poder tirar endavant el projecte i assolir els objectius marcats.
Assegurar recursos: Com a equip hem de disposar dels recursos necessaris, tant físics com digitals, per tirar endavant el projecte.
Acords d'equip: Com a equip volem acordar els nostres objectius i la manera en la qual treballarem.
Mapa de “Interessats”: Com a equip volem conèixer totes les parts interessades amb qui ens haurem de relacionar i comunicar.
Scrum és un model de referència que defineix un conjunt de pràctiques, on cada persona participant assumeix un rol (Scrum Master, Product Owner, Equip de desenvolupament, etc), fet que permet adaptar-se a les necessitats i preferències de cada equip o organització. En el CTTI, tenim el model de treball <Scrum/CTTI> on es basa en Dual Track que és un model organitzatiu àgil que separa l'esforç per descobrir i definir una Història d'Usuari, de l'esforç per entregar i construir producte. Consta de dues pistes (tracks) d'activitat: descobriment (Discovery) i lliurament (Delivery).
Amb el model de treball <Scrum/CTTI> un esprint s'executa amb “Dual Track”, és a dir en dos fluxos de treball (Discovery Track i Delivery Track). El “Dual Track”, separa la definició i la descoberta d'Històries d'Usuari de la part de la construcció, és a dir, conviuen en paral·lel.
En el track “Discovery” es treballen i s'analitzen les necessitats i requisits fins que les Històries d'Usuari (HU) estan en estat “Ready” que voldrà dir que la Història d'Usuari és a punt per a que l'equip de desenvolupament la realitzi.
En canvi, en el track “Delivery” es desenvolupen les funcionalitats i requisits que estan “Ready” fins que les Històries d'Usuari estan en estat “Done”. Voldrà dir que l'increment de producte és a punt per passar a producció.
Les eines més importants per a un Scrum Màster són els pilars d'Scrum: Transparència, Inspecció i Adaptació. Amb el temps, la majoria d'Scrum Màsters recopila una gran quantitat d'eines, tècniques i pràctiques al seu kit d'eines per impulsar l'empirisme, com a eines per donar suport a la col·laboració, la gestió de la Pila de producte i comunicació.
En la infografia es pot trobar informació sobre els rols, artefactes, compromisos, fases del projecte i cerimònies a seguir en el model <Scrum/CTTI>. També, des d'allà, teniu el Playbook que és una guia de consulta per a qualsevol persona implicada en desenvolupaments amb metodologies àgils.
Aquestes tasques les realitza el Propietari del producte (PO). És el responsable de maximitzar el valor del producte resultant del treball de l'equip Scrum. La forma principal d'aconseguir aquest objectiu és gestionar la Pila de producte (Product Backlog) de manera eficaç. Aquesta tasca inclou:
Perquè els POs tinguin èxit, tota l'organització ha de respectar les seves decisions. Aquestes decisions són visibles en el contingut i l'ordre de la Pila de producte.
En l'apartat "Recomanació d'estructuració d'una Pila de producte" del Playbook que podeu descarregar des de la infografia podeu trobar explicat detalladament com estructurar la Pila de producte (Product Backlog) en un projecte <Scrum/CTTI> de dalt a baix.
Totes les Històries d'Usuari (HU) han de ser creades complint la Definició de Llest (DoR) definida per l'equip. Una HU ha de tenir un títol curt que expressi valor de negoci i ha de ser concreta i verificable. Les HUs han d'estar explicades detalladament de forma objectiva i inequívoca, tenir definits els criteris d'acceptació i el context i l'entorn d'aplicació i tenir correctament identificat i escrit l'abast. També han d'estar estimades en punts d'història (Story Points) o el format triat, i prioritzades amb el valor de negoci (Business Value). Si hi ha dependències d'altres HUs, aquestes estan identificades a la HU i han d'estar resoltes abans d'iniciar-les. Les HU han de ser prou petites per a abastar-les en un sol esprint. En cas d'HU de negoci cal identificar l'èpica mare.
L'especificació dels requisits funcionals d'un sistema ha de ser completa, és a dir, que tots els serveis sol·licitats per l'usuari o un altre sistema estan definits i també ha de ser coherent, en el sentit de què els requisits no tenen una definició contradictòria. Per una altra banda, els requisits no funcionals (NFR), no parlen del que fa el sistema, sinó de com ho fa. Defineixen restriccions del sistema que afecten a les èpiques i Històries d'Usuari. Una Història d'Usuari no es pot considerar feta si no compleix amb els requisits no funcionals associats. Per al compliment dels NFR se solen reflectir les restriccions als criteris d'acceptació de les Històries d'Usuari; si es tracta de restriccions persistents (apliquen sempre, com per exemple temps de resposta d'una pàgina) se solen afegir com a elements nous en la Definició de Fet (DoD). En la Pila de producte, s'ha de tenir en compte els dos tipus de requisits (FR i NFR) per exemple, veure en quins casos són Històries d'Usuari no funcionals on algunes seran puntuals (upgrade de versió de base de dades), i d'altres requeriran d'una acció per posar-se "al dia" i després es consolidaran com a criteri de la DoD (temps de resposta de les pàgines), si són criteris d'acceptació d'una Història d'Usuari , o si són condicions de DoD (sobre un producte ja existent, reduir el temps de resposta a un segon).
En l'apartat "Requisits no funcionals" del Playbook que podeu descarregar des de la infografia podeu trobar més infomació sobre els requisits no funcionals.
Per decidir prioritats en les Històries d'Usuari, hi ha diferents tècniques per utilitzar. Una d'elles és la MoSCoW per identificar les èpiques més prioritàries. La tècnica MoSCoW ve de les sigles Must, Should, Could i Won't en anglès, que podríem traduir com a «obligació», «hi hauria», «podria» i «no»: hem d'encaixar cada èpica dins d'una d'aquestes quatre categories. I les més prioritàries, evidentment, seran les "obligatòries", les Must. Després les Should «deuria», les Could, «podria» i finalment les Won't, tasques que potser ens agraden, però que no són essencials i no les podem incloure de moment. Una altra tècnica pot ser SMART goals que serveix per obligar-nos a redactar certes tasques de manera que encaixin bé en un projecte. SMART són unes sigles que solen significar tasques específiques, mesurables, viables, rellevants i limitades en el temps. També podeu trobar altres tècniques com: piràmide de priorització, mètode RICE, model Kano, valor de negoci vs. complexitat, principi de Pareto, etc.
No només es pot, sinó que pot ser una bona pràctica revisar els criteris si durant l'execució del projecte es veu que sistemàticament no es poden tancar Històries d’Usuari (HUs) perquè hi ha dependències amb algun dels criteris que fa que no es pugui assumir. Per exemple, pel cas de quan encara no tenim aprovisionats els entorns de preproducció o producció, el que podem fer és relaxar la DoD (Definició de Fet). És a dir, sobre el fet de fer les proves per poder validar que tot està bé i no hi ha errors o problemes a l'hora de desplegar una nova versió del producte en els entorns de treballs. Aquesta part de fer les proves, com encara no tenim els entorns disponibles, podem crear una nova Història d'Usuari per posar-la a la Pila (Backlog). Així ho deixem anotat a la Pila per a quan tinguem els entorns disponibles i poder fer les proves i desplegar en els entorns de treball. Amb això només estaríem fent una part de la DoD i la part pendent que no podem fer per la falta dels entorns, com hem comentat, l'afegiríem com una Història d'Usuari nova a la Pila.
Quan parlem de pràctiques àgils sovint ens ve al cap Scrum, però pot no ser sempre viable o adequat. Per això, trobem altres tècniques que es poden utilitzar per a diferents projectes, com per exemple, Kanban, Lean Thinking, Design Thinking, etc. Per exemple, Kanban seria recomanable quan estem treballant en un projecte on l'objectiu és tenir un flux de treball constant, és a dir, lliurar constantment valor sense cap planificació prèvia com es fa en Scrum. Kanban és un sistema d'extracció, no planificat. Per altra banda, si el projecte es troba en una fase inicial o té un desenvolupament en curs que tingui un problema identificat o necessitat identificada, la tècnica de Design Thinking pot ser recomanable per gestionar la creativitat a l'hora de generar idees, la creació de prototips i l'experimentació. Aquesta tècnica pot ajudar a aplicar aquest enfocament innovador al problema o necessitat detectada.
Un cop transcorregudes les dues fases anteriors (Embarcament i Esprint 0), l'equip es troba en situació d'iniciar els esprints o iteracions ordinàries del projecte. En aquesta part, trobareu preguntes sobre les cerimònies de Planificació, Revisió i Retrospectiva que es realitzen en cada esprint. També en trobareu sobre els dos camins o tracks que transcorren en paral·lel dins l'esprint (Discovery Track i Delivery Track).
Pels equips que no s'ajusten al timebox, des del rol d'Scrum Màster (SM), hauria de revisar què és el que està passant, i poder reconduir aquest problema. El que es pot fer és crear una agenda clara per a la reunió amb els temes que es voldrà tractar, i aconseguir que la reunió sigui eficient. Així, es podrà mantenir el focus, passar al tema següent quan sigui necessari i assegurar-se d'abordar tots els punts de l'agenda. Cal recordar que a les Revisions, només es mira el treball acabat i no el que no està acabat, és a dir, l'equip de desenvolupament només mostra durant la cerimònia, les Històries d’Usuari o tasques acabades i que compleixen amb la DoD que s'han realitzat durant l'esprint.
Durant la Revisió és un moment perfecte per comentar tots els canvis que hi ha respecte als requisits, amb totes les parts interessades juntes i l'equip. És important fer una actualització dels requisits durant la revisió per poder procedir a adaptar la Pila de producte a la vista de tothom amb la informació que té el Propietari del producte (PO). Algunes organitzacions no actualitzen els requisits, o ho fan en reunions puntuals amb alguns implicats. Això no és recomanable, ja que no s'estaria aplicant transparència en l'equip i l'organització.
Per evitar aquests problemes, és important que la Revisió es prepari uns dies abans de fer-la per poder-la fer correctament, de manera efectiva i enfocats amb el que volem mostrar i explicar. En aquesta preparació prèvia, també és important, fer moltes proves sobre elements que es vulguin mostrar per verificar el seu correcte funcionament, fins inclús uns minuts abans de la Revisió. També, seria necessari tenir un altre entorn preparat, en el cas que hi hagués algun problema a l'hora d'ensenyar-ho.
El Propietari del producte (PO) ha d'anar inspeccionat i acceptant ítems durant tot l'esprint i, per tant, conèixer de primera mà com és l'increment. El fet que el PO no revisi els elements acabats durant l'esprint, és un problema que pot indicar una manca de col·laboració entre l'equip i el PO està absent, o que l'equip treballi en totes les tasques de la Pila d'esprint (Sprint Backlog) alhora, amb el qual es crea un Burndown pla amb una caiguda el darrer dia de l'esprint. Quan passa això, probablement l'equip té problemes de col·laboració i comunicació entre ells. Un altre fet que pot generar aquest problema és que l'entorn no estigui disponible, és a dir, que no està preparat o aprovisionat per començar a treballar. Com a resultat, el que podem fer, és relaxar la DoD (Definició de Fet).
Aquesta cerimònia és la més important del model de treball <Scrum/CTTI>, i si no es realitza, no es pot dur a terme de manera efectiva aquest model de treball. Amb la Revisió, l'equip de desenvolupament pot mostrar el seu treball fet durant l'esprint (HUs o tasques acabades i complint amb la DoD), i així obtenir feedback per part de client o dels interessats (Stakeholders).
És necessari que es realitzin les cerimònies de Retrospectives, ja que ens hem d'inspeccionar nosaltres mateixos com estem fent la nostra feina, què podem fer per millorar, què hem de deixar fer i quins problemes estem tenint i hem de posar solució. La Retrospectiva és l'esdeveniment per millorar la nostra manera de treballar pel que fa a equip, i s'han de fer perquè ens aporti valor com a equip.
Tot l'equip Scrum ha de ser present a la Retrospectiva; això inclou el Product Owner (PO), Scrum Màster (SM) i la totalitat de l'equip de desenvolupament. La Retrospectiva és un esdeveniment exclusivament per a l'equip, on s'inspeccionen ells mateixos pel que fa a la manera en què treballen. Quan no assisteix un membre de l'equip scrum, s'està perdent transparència quant a la manera com es treballa junts. Moltes vegades el membre de l'equip que no sol assistir, és el Product Owner (PO). El PO és un membre de l'equip Scrum, i també ha d'aportar la seva opinió sobre la manera en què treballa, que s'ha de deixar de fer, quins problemes han sorgit i com solucionar-ho.
Per una banda, quan els equips utilitzen sempre la mateixa dinàmica, tenen tendència a sentir que les Retrospectives han arribat a un punt d'estancament i s'avorreixen. Per això, és recomanable incorporar jocs i altres tàctiques variades a les Retrospectives de tant en tant, ja que dona a l'equip alguna cosa per esperar i pot fer que aquestes reunions siguin més emocionants per als participants. Aquest fet fa que s'abstregui les coses una mica i generi algunes converses productives i creatives. Des de l'Àrea de Qualitat, recomanem realitzar el servei de "Facilitació Retrospectiva" que hi podeu trobar al Catàleg de serveis, ja que en aquest servei s'explica què és una Retrospectiva, per a què serveix, es realitza una part pràctica de com fer una Retrospectiva, i es donen exemples de diferents dinàmiques. Per altra banda, amb tot el que s'ha parlat en una Retrospectiva, és important que es defineixin accions o tasques a fer pel pròxim esprint i que estiguin assignades a un responsable. Definir accions concretes és la millor manera de posar en pràctica els comentaris i complir el propòsit de la retrospectiva per millorar contínuament el procés de l'esprint. Una bona pràctica és mantenir una llista visible perquè tots la vegin i cal assegurar-se d'establir expectatives i terminis. Les accions pendents eficaces inclouen un encarregat clar, una data límit i una descripció que comença amb un verb perquè no hi hagi ambigüitat sobre el que cal fer.
Quan un projecte consisteix en desenvolupar un MVP (Minimum Viable Product), aquest MVP serveix per diverses coses:
No tenim un abast clar de fins on volem arribar amb un producte, i desenvolupem el mínim necessari per tal d'avaluar-ne l'acceptació i continuar, modificar o descartar segons feedback usuaris.
Tenim (o no ) clar l'abast i només tenim X recursos per a desenvolupar. Els invertirem en allò que més valor aporti.
No tenim clara la viabilitat tècnica d'una solució, avaluem si el ritme de desenvolupament és suficient per mantenir el projecte dins de pressupost i descartem si és insuficient.
En qualsevol cas, un cop seleccionades les èpiques o 'grans històries' que formen el nostre MVP, pot ser que en el track de Discovery aquestes històries creixin. No totes les històries refinades a partir de la selecció inicial són MVP i és important tenir-ho en compte, altrament no s'acabarà mai. Per tant és important tornar a prioritzar amb Pareto, o Moscow o el que convingui el fruit del refinament de la Pila (Backlog). A continuació, s'indica un exemple perquè quedi més clar:
HU no refinada que forma part de l'MVP.
Com a administrador del sistema vull que compti amb un mestre de municipis de Catalunya.
HU refinada, es converteix en 3 HU:
Com a administrador del sistema vull que compti amb una taula mestra de base de dades amb els municipis de Catalunya (MUST --> MVP)
Com a administrador del sistema vull que compti amb pantalla de manteniment del mestre de municipis de Catalunya (SHOULD --> Backlog)
Com a administrador del sistema vull que s'actualitzi automàticament obtenint les dades de l'IDESCAT (COULD --> Backlog)
Per estimar el treball que em costarà realitzar una Història d'Usuari puc utilitzar tècniques d'estimació com per exemple "Planning Poker". Aquesta tècnica és un mètode d'estimació que ajuda l'equip a calcular la quantitat d'esforç que es necessita per completar una Història d'Usuari (HU). Consisteix que el Propietari del producte, llegeix una HU i els membres de l'equip de desenvolupament votaran (amb unes cartes o amb un sistema de votació des de Miro) amb un dels valors de la seqüència de Fibonacci (1,2,3,5,8,13,21,34, etc.) que correspon a la quantitat d'esforç o punts d'història (SP) per fer la HU. El valor més votat serà l'estimació d'aquesta HU. Si els membres de l'equip tenen opinions diferents sobre les seves estimacions inicials, els membres que hagin votat valors dispars es prendran un temps per debatre sobre ells i es tornarà a fer una votació fins a arribar a un consens. De fet el debat és una part esencial de l'estimació, per ajudar a que surtin tots els aspectes a tenir en compte. Altres tècniques d'estimació són: T-shirt (talla de samarreta), estimació per afinitat, etc.
Això depèn de si l'equip ja coneix la seva velocitat, és a dir, quants punts d'història solen completar per esprint. Aquesta mitjana ens dirà quantes de les històries prioritàries hi caben, una vegada estimades. De totes maneres farem servir l'empirisme, inicialment agafarem una quantitat de tasques que ens sembli realitzable, i en funció de com acabem l'esprint ens servirà d'informació pel següent, ja sigui perquè ens hem passat o perquè ens hem quedat curts. En qualsevol cas si a mig esprint ens quedem sense feina s'ha de recórrer a la Pila (Backlog) per agafar les següents tasques prioritzades pel Propietari del producte (PO).
Aquesta Història d'Usuari s'ha de passar al següent esprint. Si hi ha alguna part feta, es pot fer un split de la Història d'Usuari amb la feina pendent.
Quan tenim Històries d'Usuari que no s'acaben d'entendre, és recomanable fer sessions de refinament. Les Històries d'Usuari s'han de revisar contínuament i refinar-les en el cas que no siguin clares. Es recomana fer un cop en cada esprint una sessió de refinament amb l'equip de desenvolupament i el Propietari del producte.
La visió del producte s'aconsegueix mitjançant el lliurament dels objectius del producte (Product goals) i els objectius del producte s'assoleixen mitjançant objectius d'esprint (Sprint goals). Els objectius d'esprint alhora s'assoleixen lliurant increments que compleixin amb la Definició de Fet (DoD).
El propòsit de la Revisió és inspeccionar el resultat de l'esprint i determinar futures adaptacions i ajustaments. Doncs l'equip presenta els resultats del seu treball a les parts interessades clau i el progrés cap a l'Objectiu del producte (Product Goal) es discuteix. Sense l'assistència de les parts interessades, no podem obtenir feedback sobre el nostre producte, i per tant no podem realitzar els ajustaments o adaptacions perquè s'ajusti millor el producte a les necessitats del client o usuaris. Si les parts interessades (Stakeholders) no venen a la Revisió, se'ls hi ha d'explicar per què la Revisió hi és i per què és important. Això és una tasca que ha de fer l'Scrum Màster.
Tota documentació s'ha d'enllaçar en algun lloc. Quan implementen una Història d'Usuari, tota la documentació relacionada amb ella, és recomanable adjuntar-la a la mateixa Història d'Usuari. Així qualsevol membre de l'equip que necessiti informació sobre això, ho té accessible per revisar-ho. Tanmateix és important que existeixi un repositori on es pugui trobar tota la documentació endreçada. Actualment el més comú és fer servir eines al núvol que permetin la consulta i edició en equip.
Durant la cerimònia Planificació d'esprint, s'ha d'escollir les Històries d'Usuari amb prioritat alta i agafar un nombre d'històries segons la velocitat de l'equip. D'aquesta cerimònia, cal haver-hi planificat tot el treball a fer durant l'esprint i haver definit l'Objectiu d'esprint (Sprint Goal). L'Objectiu d'esprint (Sprint Goal) és l'únic objectiu de l'esprint. Com hem comentat, es determina durant la cerimònia Planificació d'esprint i respon a la pregunta: Per què hem seleccionat aquests articles de la Pila de producte? L'Objectiu d'esprint ha de proporcionar flexibilitat, coherència i enfocament, i animar l'equip a fer-ho treballar junts en comptes d'iniciatives separades. Un objectiu d'esprint no és una llista d'activitats, però sí que és una declaració de com contribuirà aquest esprint a l'objectiu general del producte en termes de valor.
En la web de Qualitat podeu trobar informació sobre les diferents eines que s'utilitzen en el CTTI.
Aquesta primera fase es duen a terme les accions prèvies necessàries per a una bona planificació i visió inicial del projecte, així com revisar i corroborar aspectes contractuals. Trobareu preguntes sobre els rols que duran a terme el projecte, tràmits sobre els entorns de treball, usuaris, materials i accessos necessaris perquè un equip sigui completament operatiu el dia del Kick-Off. En aquesta última fase del model, trobareu preguntes sobre un Increment de producte que és tot allò que es construeix i finalitza completament dins d'un esprint i que té valor per ser lliurat a client. Tots els Increments de producte contribueixen a formar una nova versió del Producte, que s'alliberarà al client final amb la freqüència que consideri adequada el Propietari del producte.
Totes les Històries d'Usuari fetes han de complir amb la Definició de Fet (DoD) que s'ha pactat amb l'equip. Si una Història d'Usuari (HU) no compleix amb la DoD, no es pot considerar un increment.
Quan fem seguiment de contractes àgils, hem d'utilitzar mètriques de seguiment que s'adiguin més amb l'entrega de valor primerenc que és el que volem mesurar. Les mètriques poden ser de resultats i de comportament. Totes dues es complementen, si l'equip millora el seu comportament a través de les pràctiques, això es veu reflectit en el rendiment final positivament. El més important és definir les mètriques que s'utilitzaran en l'esprint. De res serveix implementar un munt d'indicadors, si al final no aporten dades valuoses que es puguin convertir en una font d'informació per prendre decisions de qualitat. A continuació, es mostren algunes d'elles:
Mètriques de resultats:
Els percentatges d'eficiència
Els lliuraments en dates específiques
La qualificació de l'usuari final o client
Mètriques de comportament:
Burndown Chart
Gràfica de Velocitat (Velocity Chart)
Aquesta primera fase es duen a terme les accions prèvies necessàries per a una bona planificació i visió inicial del projecte, així com revisar i corroborar aspectes contractuals. Trobareu preguntes sobre els rols que duran a terme el projecte, tràmits sobre els entorns de treball, usuaris, materials i accessos necessaris perquè un equip sigui completament operatiu el dia del Kick-Off.
Un equip autogestionat és aquell que decideix per si mateix com fer les feines, quines persones estan a l'equip per fer aquesta feina, i fins i tot el producte en què aquest equip està treballant. L'autogestió es beneficia de límits explícits, per evitar el caos organitzacional. Per exemple, aquí en el CTTI, en un equip de desenvolupament de programari tenim diferents rols com desenvolupadors de programari, testers, arquitectes, analistes, consultors, etc. on tots els membres tenen totes les capacitats necessàries per ser autosuficients i per fer totes les tasques necessàries en un desenvolupament. Això és el que s' anomena equip scrum.
Els equips àgils no treballen sols, sovint hi ha dependències entre tasques desenvolupades entre equips diferents o productes diferents, i aquesta situació la podem gestionar treballant de forma escalada. Hi ha diversos marcs que es basen en Scrum per resoldre desafiaments específics que poden trobar els equips, com ara Nexus, Scrum-at-Scale, LeSS o SAFe®.
La reunió de Kick-Off de projecte és una trobada que es realitza al començament d'un projecte àgil per definir els objectius i les expectatives del projecte i establir la base per a una comunicació i col·laboració efectives entre els membres de l'equip, els interessats, promotors i clients. Aquesta reunió és útil per establir una base sòlida, és a dir, assegurar una bona marxa del projecte amb governança, seguiment, acords de treball, rols i persones responsables. També és un camí a seguir planificant amb un roadmap que inclogui fites i lliurables per a una bona execució. Establir objectius clars i definir amb precisió l'abast del projecte i identificar les parts interessades i definir rols i responsabilitats.
Per saber sobre quines serien les funcions que realitzaria qualsevol rol del model de treball <Scrum/CTTI>, podeu trobar tota la informació des de la infografia interactiva que es troba a la web de Qualitat fent clic al rol que voleu consultar, i també en el Playbook que podeu descarregar des de la mateixa infografia.
Aquesta fase d'Esprint 0 és el primer esprint d'un projecte que segueix el model <Scrum/CTTI> i es considera un esprint especial de preparació de l'equip. Aquí trobareu preguntes sobre totes les cerimònies habituals, la planificació que es fa amb un conjunt de tasques específiques, orientades a construir una primera versió de la Pila de producte (Product Backlog) que serà deixar llestes (Ready) les Històries d'Usuari (HU) més prioritàries, i eliminar impediments de cara a l'esprint 1 i successius. S'ha de centrar en fer una prova de concepte del desenvolupament, que garanteixi que el codi està al SIC i es desplega a l'entorn de preproducció. També convé que es facin les proves adients d'integració amb altres sistemes, càrrega, regressives, acceptació de l'usuari, etc.
A l'inici del projecte, l'equip haurà d'executar una primera iteració que consistirà a executar un conjunt de tasques o Històries d'Usuari (HU) per assegurar el correcte encaix de l'equip a l'inici del desenvolupament. Algunes d'aquestes tasques són d'obligada realització per a tots els casos. Altres dependran de cada projecte. A continuació, es detallen aquestes tasques:
Comunicar el Kick-Off: Com a part interessada, implicada o afectada pel projecte, vull que se'm comuniqui les característiques del Kick-Off (dia, hora, lloc…) per poder-hi assistir, si fos oportú.
Realització del Kick-Off: Com a responsable del projecte vull donar a conèixer el mateix a totes les parts interessades, implicades o afectades. També vull alinear les diferents expectatives i necessitats.
Planificació de lliurables: Com a equip volem tenir una planificació inicial a alt nivell dels lliurables que s'han de dur a terme.
Acordar DoR (Definició de Llest) i DoD (Definició de Fet): Com a part de l'equip vull una definició clara de quan una HU està llesta per poder-la treballar i quan compleix tots els requisits per poder-la implementar.
Pla mestre de proves: Com a usuari vull garanties que l'aplicació compleix amb tots els estàndards de qualitat (seguretat, funcionalitat, rendiment...).
Prototip: Com a propietari de l'aplicació vull poder tenir una primera versió per validar l'enfocament adoptat.
Integració amb Gicar: Com a CTTI vull que les aplicacions que es desenvolupen s'integrin dins de Gicar per al registre d'usuaris.
Procediments de desenvolupament: Com a CTTI vull que totes les persones que treballen en desenvolupament i manteniment d'aplicacions, coneguin els procediments, protocols, estàndards, artefactes... propis.
Document d'arquitectura: Com a CTTI necessito que totes les aplicacions que es desenvolupen, respectin i s'integrin a l'arquitectura corresponent, seguint les indicacions establertes.
Hello Wolrd App: Com a desenvolupador i com a CTTI vull estar segur que l'equip disposa de les eines i coneixements per poder desplegar una aplicació a l'entorn productiu.
Revisar requisits: Com a CTTI i com a proveïdor volem tenir clars els requisits de l'oferta.
Aspectes contractuals: Com a CTTI i com a proveïdor volem tenir clars i corroborar els aspectes contractuals que hem de complir.
Assegurar capacitat de l'equip: Com a equip volem assegurar que tenim tots els rols necessaris amb el coneixement corresponent per poder tirar endavant el projecte i assolir els objectius marcats.
Assegurar recursos: Com a equip hem de disposar dels recursos necessaris, tant físics com digitals, per tirar endavant el projecte.
Acords d'equip: Com a equip volem acordar els nostres objectius i la manera en la qual treballarem.
Mapa de “Interessats”: Com a equip volem conèixer totes les parts interessades amb qui ens haurem de relacionar i comunicar.
Scrum és un model de referència que defineix un conjunt de pràctiques, on cada persona participant assumeix un rol (Scrum Master, Product Owner, Equip de desenvolupament, etc), fet que permet adaptar-se a les necessitats i preferències de cada equip o organització. En el CTTI, tenim el model de treball <Scrum/CTTI> on es basa en Dual Track que és un model organitzatiu àgil que separa l'esforç per descobrir i definir una Història d'Usuari, de l'esforç per entregar i construir producte. Consta de dues pistes (tracks) d'activitat: descobriment (Discovery) i lliurament (Delivery).
Amb el model de treball <Scrum/CTTI> un esprint s'executa amb “Dual Track”, és a dir en dos fluxos de treball (Discovery Track i Delivery Track). El “Dual Track”, separa la definició i la descoberta d'Històries d'Usuari de la part de la construcció, és a dir, conviuen en paral·lel.
En el track “Discovery” es treballen i s'analitzen les necessitats i requisits fins que les Històries d'Usuari (HU) estan en estat “Ready” que voldrà dir que la Història d'Usuari és a punt per a que l'equip de desenvolupament la realitzi.
En canvi, en el track “Delivery” es desenvolupen les funcionalitats i requisits que estan “Ready” fins que les Històries d'Usuari estan en estat “Done”. Voldrà dir que l'increment de producte és a punt per passar a producció.
Les eines més importants per a un Scrum Màster són els pilars d'Scrum: Transparència, Inspecció i Adaptació. Amb el temps, la majoria d'Scrum Màsters recopila una gran quantitat d'eines, tècniques i pràctiques al seu kit d'eines per impulsar l'empirisme, com a eines per donar suport a la col·laboració, la gestió de la Pila de producte i comunicació.
En la infografia es pot trobar informació sobre els rols, artefactes, compromisos, fases del projecte i cerimònies a seguir en el model <Scrum/CTTI>. També, des d'allà, teniu el Playbook que és una guia de consulta per a qualsevol persona implicada en desenvolupaments amb metodologies àgils.
Aquestes tasques les realitza el Propietari del producte (PO). És el responsable de maximitzar el valor del producte resultant del treball de l'equip Scrum. La forma principal d'aconseguir aquest objectiu és gestionar la Pila de producte (Product Backlog) de manera eficaç. Aquesta tasca inclou:
Perquè els POs tinguin èxit, tota l'organització ha de respectar les seves decisions. Aquestes decisions són visibles en el contingut i l'ordre de la Pila de producte.
En l'apartat "Recomanació d'estructuració d'una Pila de producte" del Playbook que podeu descarregar des de la infografia podeu trobar explicat detalladament com estructurar la Pila de producte (Product Backlog) en un projecte <Scrum/CTTI> de dalt a baix.
Totes les Històries d'Usuari (HU) han de ser creades complint la Definició de Llest (DoR) definida per l'equip. Una HU ha de tenir un títol curt que expressi valor de negoci i ha de ser concreta i verificable. Les HUs han d'estar explicades detalladament de forma objectiva i inequívoca, tenir definits els criteris d'acceptació i el context i l'entorn d'aplicació i tenir correctament identificat i escrit l'abast. També han d'estar estimades en punts d'història (Story Points) o el format triat, i prioritzades amb el valor de negoci (Business Value). Si hi ha dependències d'altres HUs, aquestes estan identificades a la HU i han d'estar resoltes abans d'iniciar-les. Les HU han de ser prou petites per a abastar-les en un sol esprint. En cas d'HU de negoci cal identificar l'èpica mare.
L'especificació dels requisits funcionals d'un sistema ha de ser completa, és a dir, que tots els serveis sol·licitats per l'usuari o un altre sistema estan definits i també ha de ser coherent, en el sentit de què els requisits no tenen una definició contradictòria. Per una altra banda, els requisits no funcionals (NFR), no parlen del que fa el sistema, sinó de com ho fa. Defineixen restriccions del sistema que afecten a les èpiques i Històries d'Usuari. Una Història d'Usuari no es pot considerar feta si no compleix amb els requisits no funcionals associats. Per al compliment dels NFR se solen reflectir les restriccions als criteris d'acceptació de les Històries d'Usuari; si es tracta de restriccions persistents (apliquen sempre, com per exemple temps de resposta d'una pàgina) se solen afegir com a elements nous en la Definició de Fet (DoD). En la Pila de producte, s'ha de tenir en compte els dos tipus de requisits (FR i NFR) per exemple, veure en quins casos són Històries d'Usuari no funcionals on algunes seran puntuals (upgrade de versió de base de dades), i d'altres requeriran d'una acció per posar-se "al dia" i després es consolidaran com a criteri de la DoD (temps de resposta de les pàgines), si són criteris d'acceptació d'una Història d'Usuari , o si són condicions de DoD (sobre un producte ja existent, reduir el temps de resposta a un segon).
En l'apartat "Requisits no funcionals" del Playbook que podeu descarregar des de la infografia podeu trobar més infomació sobre els requisits no funcionals.
Per decidir prioritats en les Històries d'Usuari, hi ha diferents tècniques per utilitzar. Una d'elles és la MoSCoW per identificar les èpiques més prioritàries. La tècnica MoSCoW ve de les sigles Must, Should, Could i Won't en anglès, que podríem traduir com a «obligació», «hi hauria», «podria» i «no»: hem d'encaixar cada èpica dins d'una d'aquestes quatre categories. I les més prioritàries, evidentment, seran les "obligatòries", les Must. Després les Should «deuria», les Could, «podria» i finalment les Won't, tasques que potser ens agraden, però que no són essencials i no les podem incloure de moment. Una altra tècnica pot ser SMART goals que serveix per obligar-nos a redactar certes tasques de manera que encaixin bé en un projecte. SMART són unes sigles que solen significar tasques específiques, mesurables, viables, rellevants i limitades en el temps. També podeu trobar altres tècniques com: piràmide de priorització, mètode RICE, model Kano, valor de negoci vs. complexitat, principi de Pareto, etc.
No només es pot, sinó que pot ser una bona pràctica revisar els criteris si durant l'execució del projecte es veu que sistemàticament no es poden tancar Històries d’Usuari (HUs) perquè hi ha dependències amb algun dels criteris que fa que no es pugui assumir. Per exemple, pel cas de quan encara no tenim aprovisionats els entorns de preproducció o producció, el que podem fer és relaxar la DoD (Definició de Fet). És a dir, sobre el fet de fer les proves per poder validar que tot està bé i no hi ha errors o problemes a l'hora de desplegar una nova versió del producte en els entorns de treballs. Aquesta part de fer les proves, com encara no tenim els entorns disponibles, podem crear una nova Història d'Usuari per posar-la a la Pila (Backlog). Així ho deixem anotat a la Pila per a quan tinguem els entorns disponibles i poder fer les proves i desplegar en els entorns de treball. Amb això només estaríem fent una part de la DoD i la part pendent que no podem fer per la falta dels entorns, com hem comentat, l'afegiríem com una Història d'Usuari nova a la Pila.
Quan parlem de pràctiques àgils sovint ens ve al cap Scrum, però pot no ser sempre viable o adequat. Per això, trobem altres tècniques que es poden utilitzar per a diferents projectes, com per exemple, Kanban, Lean Thinking, Design Thinking, etc. Per exemple, Kanban seria recomanable quan estem treballant en un projecte on l'objectiu és tenir un flux de treball constant, és a dir, lliurar constantment valor sense cap planificació prèvia com es fa en Scrum. Kanban és un sistema d'extracció, no planificat. Per altra banda, si el projecte es troba en una fase inicial o té un desenvolupament en curs que tingui un problema identificat o necessitat identificada, la tècnica de Design Thinking pot ser recomanable per gestionar la creativitat a l'hora de generar idees, la creació de prototips i l'experimentació. Aquesta tècnica pot ajudar a aplicar aquest enfocament innovador al problema o necessitat detectada.
Un cop transcorregudes les dues fases anteriors (Embarcament i Esprint 0), l'equip es troba en situació d'iniciar els esprints o iteracions ordinàries del projecte. En aquesta part, trobareu preguntes sobre les cerimònies de Planificació, Revisió i Retrospectiva que es realitzen en cada esprint. També en trobareu sobre els dos camins o tracks que transcorren en paral·lel dins l'esprint (Discovery Track i Delivery Track).
Pels equips que no s'ajusten al timebox, des del rol d'Scrum Màster (SM), hauria de revisar què és el que està passant, i poder reconduir aquest problema. El que es pot fer és crear una agenda clara per a la reunió amb els temes que es voldrà tractar, i aconseguir que la reunió sigui eficient. Així, es podrà mantenir el focus, passar al tema següent quan sigui necessari i assegurar-se d'abordar tots els punts de l'agenda. Cal recordar que a les Revisions, només es mira el treball acabat i no el que no està acabat, és a dir, l'equip de desenvolupament només mostra durant la cerimònia, les Històries d’Usuari o tasques acabades i que compleixen amb la DoD que s'han realitzat durant l'esprint.
Durant la Revisió és un moment perfecte per comentar tots els canvis que hi ha respecte als requisits, amb totes les parts interessades juntes i l'equip. És important fer una actualització dels requisits durant la revisió per poder procedir a adaptar la Pila de producte a la vista de tothom amb la informació que té el Propietari del producte (PO). Algunes organitzacions no actualitzen els requisits, o ho fan en reunions puntuals amb alguns implicats. Això no és recomanable, ja que no s'estaria aplicant transparència en l'equip i l'organització.
Per evitar aquests problemes, és important que la Revisió es prepari uns dies abans de fer-la per poder-la fer correctament, de manera efectiva i enfocats amb el que volem mostrar i explicar. En aquesta preparació prèvia, també és important, fer moltes proves sobre elements que es vulguin mostrar per verificar el seu correcte funcionament, fins inclús uns minuts abans de la Revisió. També, seria necessari tenir un altre entorn preparat, en el cas que hi hagués algun problema a l'hora d'ensenyar-ho.
El Propietari del producte (PO) ha d'anar inspeccionat i acceptant ítems durant tot l'esprint i, per tant, conèixer de primera mà com és l'increment. El fet que el PO no revisi els elements acabats durant l'esprint, és un problema que pot indicar una manca de col·laboració entre l'equip i el PO està absent, o que l'equip treballi en totes les tasques de la Pila d'esprint (Sprint Backlog) alhora, amb el qual es crea un Burndown pla amb una caiguda el darrer dia de l'esprint. Quan passa això, probablement l'equip té problemes de col·laboració i comunicació entre ells. Un altre fet que pot generar aquest problema és que l'entorn no estigui disponible, és a dir, que no està preparat o aprovisionat per començar a treballar. Com a resultat, el que podem fer, és relaxar la DoD (Definició de Fet).
Aquesta cerimònia és la més important del model de treball <Scrum/CTTI>, i si no es realitza, no es pot dur a terme de manera efectiva aquest model de treball. Amb la Revisió, l'equip de desenvolupament pot mostrar el seu treball fet durant l'esprint (HUs o tasques acabades i complint amb la DoD), i així obtenir feedback per part de client o dels interessats (Stakeholders).
És necessari que es realitzin les cerimònies de Retrospectives, ja que ens hem d'inspeccionar nosaltres mateixos com estem fent la nostra feina, què podem fer per millorar, què hem de deixar fer i quins problemes estem tenint i hem de posar solució. La Retrospectiva és l'esdeveniment per millorar la nostra manera de treballar pel que fa a equip, i s'han de fer perquè ens aporti valor com a equip.
Tot l'equip Scrum ha de ser present a la Retrospectiva; això inclou el Product Owner (PO), Scrum Màster (SM) i la totalitat de l'equip de desenvolupament. La Retrospectiva és un esdeveniment exclusivament per a l'equip, on s'inspeccionen ells mateixos pel que fa a la manera en què treballen. Quan no assisteix un membre de l'equip scrum, s'està perdent transparència quant a la manera com es treballa junts. Moltes vegades el membre de l'equip que no sol assistir, és el Product Owner (PO). El PO és un membre de l'equip Scrum, i també ha d'aportar la seva opinió sobre la manera en què treballa, que s'ha de deixar de fer, quins problemes han sorgit i com solucionar-ho.
Per una banda, quan els equips utilitzen sempre la mateixa dinàmica, tenen tendència a sentir que les Retrospectives han arribat a un punt d'estancament i s'avorreixen. Per això, és recomanable incorporar jocs i altres tàctiques variades a les Retrospectives de tant en tant, ja que dona a l'equip alguna cosa per esperar i pot fer que aquestes reunions siguin més emocionants per als participants. Aquest fet fa que s'abstregui les coses una mica i generi algunes converses productives i creatives. Des de l'Àrea de Qualitat, recomanem realitzar el servei de "Facilitació Retrospectiva" que hi podeu trobar al Catàleg de serveis, ja que en aquest servei s'explica què és una Retrospectiva, per a què serveix, es realitza una part pràctica de com fer una Retrospectiva, i es donen exemples de diferents dinàmiques. Per altra banda, amb tot el que s'ha parlat en una Retrospectiva, és important que es defineixin accions o tasques a fer pel pròxim esprint i que estiguin assignades a un responsable. Definir accions concretes és la millor manera de posar en pràctica els comentaris i complir el propòsit de la retrospectiva per millorar contínuament el procés de l'esprint. Una bona pràctica és mantenir una llista visible perquè tots la vegin i cal assegurar-se d'establir expectatives i terminis. Les accions pendents eficaces inclouen un encarregat clar, una data límit i una descripció que comença amb un verb perquè no hi hagi ambigüitat sobre el que cal fer.
Quan un projecte consisteix en desenvolupar un MVP (Minimum Viable Product), aquest MVP serveix per diverses coses:
No tenim un abast clar de fins on volem arribar amb un producte, i desenvolupem el mínim necessari per tal d'avaluar-ne l'acceptació i continuar, modificar o descartar segons feedback usuaris.
Tenim (o no ) clar l'abast i només tenim X recursos per a desenvolupar. Els invertirem en allò que més valor aporti.
No tenim clara la viabilitat tècnica d'una solució, avaluem si el ritme de desenvolupament és suficient per mantenir el projecte dins de pressupost i descartem si és insuficient.
En qualsevol cas, un cop seleccionades les èpiques o 'grans històries' que formen el nostre MVP, pot ser que en el track de Discovery aquestes històries creixin. No totes les històries refinades a partir de la selecció inicial són MVP i és important tenir-ho en compte, altrament no s'acabarà mai. Per tant és important tornar a prioritzar amb Pareto, o Moscow o el que convingui el fruit del refinament de la Pila (Backlog). A continuació, s'indica un exemple perquè quedi més clar:
HU no refinada que forma part de l'MVP.
Com a administrador del sistema vull que compti amb un mestre de municipis de Catalunya.
HU refinada, es converteix en 3 HU:
Com a administrador del sistema vull que compti amb una taula mestra de base de dades amb els municipis de Catalunya (MUST --> MVP)
Com a administrador del sistema vull que compti amb pantalla de manteniment del mestre de municipis de Catalunya (SHOULD --> Backlog)
Com a administrador del sistema vull que s'actualitzi automàticament obtenint les dades de l'IDESCAT (COULD --> Backlog)
Per estimar el treball que em costarà realitzar una Història d'Usuari puc utilitzar tècniques d'estimació com per exemple "Planning Poker". Aquesta tècnica és un mètode d'estimació que ajuda l'equip a calcular la quantitat d'esforç que es necessita per completar una Història d'Usuari (HU). Consisteix que el Propietari del producte, llegeix una HU i els membres de l'equip de desenvolupament votaran (amb unes cartes o amb un sistema de votació des de Miro) amb un dels valors de la seqüència de Fibonacci (1,2,3,5,8,13,21,34, etc.) que correspon a la quantitat d'esforç o punts d'història (SP) per fer la HU. El valor més votat serà l'estimació d'aquesta HU. Si els membres de l'equip tenen opinions diferents sobre les seves estimacions inicials, els membres que hagin votat valors dispars es prendran un temps per debatre sobre ells i es tornarà a fer una votació fins a arribar a un consens. De fet el debat és una part esencial de l'estimació, per ajudar a que surtin tots els aspectes a tenir en compte. Altres tècniques d'estimació són: T-shirt (talla de samarreta), estimació per afinitat, etc.
Això depèn de si l'equip ja coneix la seva velocitat, és a dir, quants punts d'història solen completar per esprint. Aquesta mitjana ens dirà quantes de les històries prioritàries hi caben, una vegada estimades. De totes maneres farem servir l'empirisme, inicialment agafarem una quantitat de tasques que ens sembli realitzable, i en funció de com acabem l'esprint ens servirà d'informació pel següent, ja sigui perquè ens hem passat o perquè ens hem quedat curts. En qualsevol cas si a mig esprint ens quedem sense feina s'ha de recórrer a la Pila (Backlog) per agafar les següents tasques prioritzades pel Propietari del producte (PO).
Aquesta Història d'Usuari s'ha de passar al següent esprint. Si hi ha alguna part feta, es pot fer un split de la Història d'Usuari amb la feina pendent.
Quan tenim Històries d'Usuari que no s'acaben d'entendre, és recomanable fer sessions de refinament. Les Històries d'Usuari s'han de revisar contínuament i refinar-les en el cas que no siguin clares. Es recomana fer un cop en cada esprint una sessió de refinament amb l'equip de desenvolupament i el Propietari del producte.
La visió del producte s'aconsegueix mitjançant el lliurament dels objectius del producte (Product goals) i els objectius del producte s'assoleixen mitjançant objectius d'esprint (Sprint goals). Els objectius d'esprint alhora s'assoleixen lliurant increments que compleixin amb la Definició de Fet (DoD).
El propòsit de la Revisió és inspeccionar el resultat de l'esprint i determinar futures adaptacions i ajustaments. Doncs l'equip presenta els resultats del seu treball a les parts interessades clau i el progrés cap a l'Objectiu del producte (Product Goal) es discuteix. Sense l'assistència de les parts interessades, no podem obtenir feedback sobre el nostre producte, i per tant no podem realitzar els ajustaments o adaptacions perquè s'ajusti millor el producte a les necessitats del client o usuaris. Si les parts interessades (Stakeholders) no venen a la Revisió, se'ls hi ha d'explicar per què la Revisió hi és i per què és important. Això és una tasca que ha de fer l'Scrum Màster.
Tota documentació s'ha d'enllaçar en algun lloc. Quan implementen una Història d'Usuari, tota la documentació relacionada amb ella, és recomanable adjuntar-la a la mateixa Història d'Usuari. Així qualsevol membre de l'equip que necessiti informació sobre això, ho té accessible per revisar-ho. Tanmateix és important que existeixi un repositori on es pugui trobar tota la documentació endreçada. Actualment el més comú és fer servir eines al núvol que permetin la consulta i edició en equip.
Durant la cerimònia Planificació d'esprint, s'ha d'escollir les Històries d'Usuari amb prioritat alta i agafar un nombre d'històries segons la velocitat de l'equip. D'aquesta cerimònia, cal haver-hi planificat tot el treball a fer durant l'esprint i haver definit l'Objectiu d'esprint (Sprint Goal). L'Objectiu d'esprint (Sprint Goal) és l'únic objectiu de l'esprint. Com hem comentat, es determina durant la cerimònia Planificació d'esprint i respon a la pregunta: Per què hem seleccionat aquests articles de la Pila de producte? L'Objectiu d'esprint ha de proporcionar flexibilitat, coherència i enfocament, i animar l'equip a fer-ho treballar junts en comptes d'iniciatives separades. Un objectiu d'esprint no és una llista d'activitats, però sí que és una declaració de com contribuirà aquest esprint a l'objectiu general del producte en termes de valor.
En la web de Qualitat podeu trobar informació sobre les diferents eines que s'utilitzen en el CTTI.
Aquesta primera fase es duen a terme les accions prèvies necessàries per a una bona planificació i visió inicial del projecte, així com revisar i corroborar aspectes contractuals. Trobareu preguntes sobre els rols que duran a terme el projecte, tràmits sobre els entorns de treball, usuaris, materials i accessos necessaris perquè un equip sigui completament operatiu el dia del Kick-Off. En aquesta última fase del model, trobareu preguntes sobre un Increment de producte que és tot allò que es construeix i finalitza completament dins d'un esprint i que té valor per ser lliurat a client. Tots els Increments de producte contribueixen a formar una nova versió del Producte, que s'alliberarà al client final amb la freqüència que consideri adequada el Propietari del producte.
Totes les Històries d'Usuari fetes han de complir amb la Definició de Fet (DoD) que s'ha pactat amb l'equip. Si una Història d'Usuari (HU) no compleix amb la DoD, no es pot considerar un increment.
Quan fem seguiment de contractes àgils, hem d'utilitzar mètriques de seguiment que s'adiguin més amb l'entrega de valor primerenc que és el que volem mesurar. Les mètriques poden ser de resultats i de comportament. Totes dues es complementen, si l'equip millora el seu comportament a través de les pràctiques, això es veu reflectit en el rendiment final positivament. El més important és definir les mètriques que s'utilitzaran en l'esprint. De res serveix implementar un munt d'indicadors, si al final no aporten dades valuoses que es puguin convertir en una font d'informació per prendre decisions de qualitat. A continuació, es mostren algunes d'elles:
Mètriques de resultats:
Els percentatges d'eficiència
Els lliuraments en dates específiques
La qualificació de l'usuari final o client
Mètriques de comportament:
Burndown Chart
Gràfica de Velocitat (Velocity Chart)