calaix[À]gil


CAT | ESP | EN



Definition of Done, (DoD)

CAT, ESP

calaix[À]gil | Articles (CAT) | Conceptes Agile importants
Data publicació: 15/11/2022
Última modificació: 15/11/2022
Les Definition of Done ajuden a l’equip en la construcció d’un increment del producte que pugui afirmar-se que és de valor per al negoci i els usuaris

Les DoD (Definition of Done) ajuden a l’equip en la construcció d’un increment del producte, del que pugui afirmar-se que veritablement proporciona valor per al negoci i els usuaris


Podem imaginar les DoD com una llista d’accions, normes o bones pràctiques que cal complir, i que van més enllà de la simple construcció de l’increment, i que són igualment necessàries per poder donar per enllestida una tasca prevista en el Sprint. Sovint aquesta feina afegida es pot entendre com a treball ocult de les DoD, però és molt necessari ser conscient que tota aquesta feina és necessaria per assegurar la qualitat, la fiablitat, el rendiment o la seguretat del que estem creant.



Definir les DoD amb l’equip

Un cop hem imaginat les DoD com una llista; ara podem rumiar qui en l’organització és responsable de la definició i l’acompliment dels ítems d’aquesta llista. Les DoD plantegen pràctiques que orienten sobre el com construirem el producte. Acostumen a ser ítems tècnics que informen sobre el nivell de qualitat, fiabilitat o rendiment necessaris, així com la definició de l’univers d’artefactes i bones pràctiques necessaris per a poder acceptar el resultat obtingut amb garanties d’èxit. Per tant, sembla clar que els protagonistes de tot plegat són l’equip tècnic del projecte.

Així i tot, el Product Owner i l’organització tenen la misió de definir un conjunt de DoD que sigui d’aplicació en els projectes, i que marquin un mínim aplicable en l’organització. A partir d’aquest mínims, els equips s’adscriuen a aquesta definició, que poden completar si cal per fer-la més restrictiva, (tot i que mai per crear una DoD més laxa).


Les DoD han de ser el producte de la negociació i del consens entre membres de l’equip. Aquests, en aquest exercici, reconeixen, per una banda, els criteris de qualitat que l’organització i el negoci plantegen per aquest projecte. I, per altra banda, ha de ser l’espai on els tècnics proposen els seus propis criteris de qualitat, bones pràctiques o artefactes que facin possible l’obtenció del producte amb la qualitat desitjada.



Què hauríem d’incloure a les DoD?

Les DoD han d’incloure tot allò que es considera necessari, i que va molt més enllà de la simple construcció. Sovint, en la nostra feina, l’acció de construir ja és de per si tot un repte, que posa a prova la nostra resistència tant mental com física. És habitual llavors que, un cop finalitzem la construcció podem entrar en un procés de relaxació que fa que baixem la guàrdia davant altres accions igualment necessàries per a l’èxit d’allò que acabem de crear.

És tota una llàstima veure com un lliurament fracassa a causa de falta d’atenció en elements que proporcionen robustesa a allò que hem construït. En aquest sentit, cal ser curosos a l’hora de negociar amb l’equip quins elements a tenir presents a l’hora de crear la nostra DoD.


Podem classificar els ítems de la nostra DoD en les famílies següents:

  • Proves
  • Documentació
  • Bones pràctiques
  • Normes de l’organització o del negoci
  • Elements de qualitat sobre el producte i la seva tecnologia
  • Participació de 3rs i acceptacions específiques (UX, seguretat…)
  • Revisions entre companys d’equip (code review)
  • Algunes regles. Com per exemple: No arrencar res de nou sense acabar la feina actual

Les proves

Sovint, quan pensen en les DoD ràpidament la ment ens porta a pensar en les proves. Com si fos l’única missió de les DoD. No és cert. Hi ha més qüestions a tenir present a l’hora de construir les DoD. Però també és cert que les proves són un element d’especial importància.


Les proves són allò que rubrica la qualitat i la fiabilitat del que hem construit. Per molt esforç que dediquem a la construcció; si a la sessió de Review el producte dona problemes de fiabilitat, tota la nostra feina es posa en dubte. Per evitar això tenim les proves.

Hem de tenir presents algunes qüestions molt importants a l’hora de definir les proves:


La importància de les proves

Les proves són tant o més importants que la mateixa construcció. I requereix la participació activa de l’equip tècnic, tant en la definició, com en la posterior execució d’aquestes proves.


Proves a 360 graus

Les proves han de cobrir tots els aspectes tècnics i funcionals que permetin avaluar la nostra creació en un entorn de 360 graus. Així hem de planificar proves en els aspectes següents:

  • Proves unitàries i tècniques a nivell micro. Per cobrir aquest nivell de proves, no seria gens menyspreable que l’equip tingui presents les tendències actuals sobre la construcció centrades en proves.
  • Proves funcionals. Un cop tenim el producte; i aquest és tècnicament impecable gràcies a les proves unitàries i tècniques. L’equip ha de garantir que el producte creat respon de forma adequada davant escenaris funcionals concrets. D’una bona resposta del sistema davant escenaris d’error depèn en gran part l’èxit de la nostra creació.
  • Proves d’integració i regressives. És lògic pensar que la nostra creació no actuarà lliurement i aïlladament en el sistema tecnològic de l’empresa. Hi haurà interrelacions necessàries i, si mes no, en el normal escenari de construcció iterativa, hi haurà la necessitat d’assegurar-ne el correcte funcionament amb la porció ja existent del mateix producte. Si el nostre increment no té una bona relació amb terceres parts necessàries i/o amb els increments anteriors, no donarà el valor desitjat al negoci ni als usuaris.
  • Proves d’acceptació i criteris d’acceptació. Al Sprint Planning hem vist que, una part fonamental en la definició de què cal construir en el pròxim Sprint, consisteix en que els Stakeholders i/o el Product Owner ens indiquin els criteris d’acceptació en què basaran la seva inspecció al Sprint Review. L’equip llavors té informació molt valuosa que farà bé en explorar de cara a assegurar la qualitat del producte final. Per això, cal que s’asseguri, mitjançant proves d’acceptació, de què aquests criteris són efectivament reeixits.

La definició documentada de les proves

L’equip participa activament en la definició de les proves de l’increment (i de les seves peces unitàries) de forma prèvia a la construcció del producte. Fer-ho així situa a l’equip en l’entorn de treball adequat on, les proves són l’element que aglutina la construcció. Per assolir això cal crear algun tipus d’element documental on queden reflectides l’univers de proves que es durà a terme, la infraestructura necessària i els resultats que s’esperen.


Les evidències en l’execució de les proves

Les proves són un element seriós que requereix l’aportació d’evidències que demostren la correcta definició i execució d’aquestes. Les evidències són elements imprescindibles a l’hora de mostrar el nivell de qualitat i fiabilitat assolit en la nostra creació.


La documentació

Qui ha dit que en agilitat no es documenta?


No pot plantejar-se una construcció seriosa ni amb garanties sense un corpus documental adequat. Així, en les nostres DoD ha d’haver espai per la definició d’aquests elements documentals. Com es construiran, qui els construirà, i quin nivell de qualitat s’espera d’aquests elements.

Alguns elements documentals necessaris:

  • Documentació tant de la necessitat a la qual dona cobertura l’increment i cada una de les històries d’usuari incorporades, com de la solució tècnica o tecnològica aplicada.
  • Plans documentats que siguin necessaris tant per al desplegament o lliurament al negoci i als usuaris, com per al posterior manteniment i evolució

Les bonespràctiques

Sovint, a causa del tipus de projecte, a les característiques del producte que vol construir-se o a la tecnologia aplicable, existeixen una sèrie de normes estàndards que poden o han de ser d’aplicació en el nostre projecte.


Així tenim bones pràctiques de programació, normes sobre usabilitat i accessibilitat , bones pràctiques sobre disseny UX, DevOps, CI/CD , bones pràctiques en la documentació, etc.


Normes de l’organització o del negoci

Sovint l’empresa no és agnòstica sobre alguns criteris de qualitat dels productes que s’exploten en ella. Per exemple podem trobar criteris de qualitat a nivell de marca, estils, normes jurídiques aplicables, normes de seguretat que afecten el producte o al seu ús.

Sovint aquestes normes de qualitat estan regides per un departament d’oficina tècnica (PMO) que intervé en els projectes per tal d’assegurar el seu acompliment. L’equip tècnic del projecte han de tenir presents aquestes normes per tal de poder aplicar-les i, sobretot, detectar i gestionar possibles interferències o punts foscos en l’assoliment dels objectius de qualitat.


Elements de qualitat sobre el producte i la seva tecnologia

A causa de la tecnologia utilitzada per la creació del producte, poden ser d’aplicació algunes normes de caràcter tecnològic i arquitectònic. Com per exemple:

  • API First
  • Nivells de qualitat pel que fa al rendiment. Com per exemple temps d’accés a característiques del mateix producte o a integracions amb productes externs.
  • Nivells de fiabilitat en diferents escenaris com per exemple: situacions d’error d’elements tecnològics o de suport, situacions de càrrega o caigudes totals o parcials del servei.
  • Nivells de seguretat. Com per exemple certificats d’accés, seguretat passiva i activa, segon factor, còpies de seguretat i recuperació, etc.



Les DoD cobreixen tots els nivells de construcció

Quan l’equip defineix els ítems de la DoD no està pensant només en l’increment com a element indivisible. Fer-ho així seria un error. Les DoD són elements que poden explorar la qualitat a tots els nivells de la construcció:


Així doncs, l’equip consensua elements de la DoD que poden ser aplicats a un o més d’aquests nivells, i que han d’incloure tant elements tècnics, com documentals o d’evidències.



Les DoD s’avaluen al Sprint Review

La Sprint Review, a banda de ser l’espai on es fa lliurament de l’increment; també ha de ser l’espai on s’aporten les evidències que demostren que aquest increment és fiable i té el nivell de qualitat necessari. Les DoD són un element crucial en aquesta demostració de la qualitat. Les DoD han de formar part, juntament amb el mateix increment, en la il·lustració del seu funcionament.



Les DoD es revisen de forma constant a la Sprint Retrospective

Les DoD són un element viu, que evoluciona de la mateixa manera que evoluciona el propi projecte. I que milloren i es perfeccionen de forma constant, de la mateixa manera que també evolucionen i milloren les persones i els equips que hi participen. Constantment apareixen noves formes de fer. I constantment avaluem si podem fer-ho millor. En aquest procés constant es pot sotmetre la DoD a revisió. Afegir, treure i modificar aspectes de la DoD per adaptar de forma constant aquestes polítiques a les necessitats canviants.

La Retrospectiva és el millor espai possible per dur a terme aquesta revisió. La revisió de les DoD no pot ser una excusa per minimitzar normes que la organització considera importants. Tot i que si pot ser un espai per dialogar sobre com disposar de les DoD més adequades. El millor indicatiu de maduresa de l’equip (i de l’organització) és que en el procés de cerca de millora que tracta de promoure la retrospectiva, les DoD hi són presents com a un element més sobre el que l’equip posa el focus per perfeccionar-lo.