Les Tools and Techniques (eines i tècniques) són una part fonamental de PM²-Agile perquè proporcionen recursos pràctics per millorar la qualitat, facilitar la col·laboració, gestionar el treball i augmentar l’agilitat en el desenvolupament de solucions. PM²-Agile no imposa una única manera de treballar, sinó que ofereix un conjunt de pràctiques que els equips poden utilitzar i adaptar segons les característiques del projecte.
Aquestes tècniques ajuden a transformar els principis Agile en pràctiques concretes: des de la manera com es construeix i s’organitza l’equip fins a la definició dels requisits, l’estimació del treball, la visualització del progrés i la incorporació de la qualitat durant el desenvolupament. La guia PM²-Agile presenta aquestes tècniques des d’una perspectiva introductòria i d’alt nivell.
1. Assessing Teamwork (avaluació del treball en equip)
Un projecte Agile depèn en gran mesura de la capacitat de l’equip per treballar de manera cohesionada i efectiva. Assessing Teamwork (avaluació del treball en equip) és una tècnica que permet analitzar la maduresa i l’eficàcia d’un equip i identificar aspectes que poden estar limitant-ne el rendiment.
PM²-Agile relaciona aquesta avaluació amb el model de les Five Dysfunctions of a Team (cinc disfuncions d’un equip) de Patrick Lencioni. L’objectiu és ajudar l’equip a identificar les seves fortaleses i les àrees que necessita millorar.
L’avaluació se centra en cinc aspectes fonamentals:
- Trust (confiança): els membres de l’equip han de poder confiar els uns en els altres.
- Conflict (conflicte): els desacords s’han de poder abordar de manera constructiva.
- Commitment (compromís): l’equip ha d’assumir conjuntament les decisions i objectius.
- Accountability (responsabilitat): els membres han de poder demanar-se responsabilitats mútuament.
- Results (resultats): l’equip ha d’estar orientat a assolir els resultats del projecte.
Aquesta tècnica permet detectar problemes que no són necessàriament tècnics però que poden afectar directament la productivitat i la qualitat del treball.
2. Self-Organising Teams (equips autoorganitzats)
Els Self-Organising Teams (equips autoorganitzats) són equips que disposen de la capacitat i l’autoritat necessàries per prendre decisions sobre la seva manera de treballar i adaptar-se als canvis.
En lloc de rebre instruccions detallades sobre cada decisió, l’equip disposa d’un determinat grau d’autonomia per decidir com assolir els objectius que té assignats.
L’autoorganització no significa absència de lideratge ni de responsabilitat. Significa crear les condicions perquè les persones puguin prendre decisions, col·laborar i adaptar-se a nous reptes.
A més, PM²-Agile considera que Self-Organising és un procés continu i no una situació que s’assoleix una vegada i queda establerta definitivament. L’organització i els responsables del projecte han de proporcionar l’entorn, la confiança i el suport necessaris perquè l’equip pugui evolucionar cap a nivells més elevats de maduresa i rendiment.
3. Design Blocks (blocs de disseny)
Els Design Blocks (blocs de disseny) són sessions de treball basades en tècniques de Design Thinking (pensament de disseny) que tenen com a objectiu concretar i qüestionar les assumpcions relacionades amb una Feature o amb els Work Items que es volen desenvolupar durant una iteració.
A la pràctica, un Design Block consisteix en un conjunt de tallers on participen l’Agile Project Core Team (A-PCT) i altres stakeholders. Durant aquestes sessions, els participants comparteixen les seves interpretacions, identifiquen assumpcions i treballen conjuntament sobre el que s’ha de construir.
Un element especialment important és la creació d’un low-fidelity prototype (prototip de baixa fidelitat). Aquest prototip permet representar de manera senzilla la futura funcionalitat abans de començar-ne la implementació.
Quan l’equip ha arribat a un nivell suficient d’acord i comprensió, els dissenyadors d’interfície poden desenvolupar un high-fidelity prototype (prototip d’alta fidelitat) aplicant els estàndards visuals i les biblioteques de disseny existents.
Això permet discutir abans de programar aspectes com el disseny, la interacció, el comportament, els requisits i les qüestions tècniques, reduint així la incertesa durant el desenvolupament.
4. Features and Stories (funcionalitats i històries)
Les Features and Stories (funcionalitats i històries) permeten expressar els requisits que ha d’abordar una solució.
Una Feature (funcionalitat o capacitat) representa una funcionalitat o servei significatiu que la solució proporciona per respondre a les necessitats dels stakeholders.
Una Story (història) representa una part més petita de la funcionalitat, concebuda com una porció vertical de la funcionalitat del sistema que pot ser implementada i lliurada en un període relativament curt.
Per tant, una Feature acostuma a tenir un abast més gran i pot incloure diferents escenaris, mentre que les Stories permeten dividir aquesta funcionalitat en peces més petites i manejables.
Aquesta descomposició és especialment important en PM²-Agile perquè el desenvolupament és iteratiu i incremental. Les Features es divideixen en Stories que es poden incorporar a la Work Items List (WIL) i implementar progressivament.
El benefici és doble: l’equip pot construir la solució «peça a peça» i, al mateix temps, obtenir feedback dels stakeholders durant les iteracions.
5. Definition of Done (definició de completat)
La Definition of Done (DoD) (definició de completat) estableix les condicions que s’han de complir perquè un Work Item es pugui considerar realment complet.
En un entorn iteratiu i incremental, dir que una funcionalitat està «desenvolupada» no significa necessàriament que estigui acabada. Pot faltar, per exemple, completar proves, revisar la qualitat o complir determinats criteris establerts per l’equip.
La DoD proporciona una referència comuna perquè tots els membres de l’equip entenguin què significa Done (complet).
Pot incloure criteris com:
- el codi està implementat;
- les proves necessàries s’han executat;
- els defectes identificats estan resolts;
- la funcionalitat compleix els criteris de qualitat;
- la documentació necessària està actualitzada.
La Definition of Done ha de ser acordada per l’equip i reflectir els estàndards de qualitat del projecte. La seva utilització ajuda a incorporar la qualitat dins del mateix cicle de desenvolupament i redueix el risc que apareguin problemes en fases posteriors.
6. User Stories Breakdown (descomposició de User Stories)
Una User Story (història d’usuari) pot tenir diferents dimensions durant el cicle de vida del projecte. Quan arriba el moment d’implementar-la, és important que tingui una mida adequada per poder ser estimada, prioritzada i desenvolupada dins d’un període raonable, habitualment una iteració.
Dividir una User Story massa gran en Stories més petites aporta diversos beneficis:
- facilita la implementació modular;
- millora el disseny i la mantenibilitat;
- facilita l’adaptació als canvis;
- redueix la incertesa i el risc;
- disminueix la variabilitat del treball;
- facilita que les funcionalitats avancin pel procés de desenvolupament.
L’objectiu no és dividir les Stories de manera arbitrària, sinó trobar una mida que permeti a l’equip entendre, estimar, implementar i validar el treball amb facilitat.
7. Planning Poker (estimació mitjançant cartes)
Planning Poker (estimació mitjançant cartes) és una tècnica basada en el consens que s’utilitza per estimar de manera relativa la mida dels Work Items.
Cada membre de l’equip realitza una estimació de manera independent i, posteriorment, es comparen les estimacions. Quan existeixen diferències significatives, els participants expliquen els seus arguments i es torna a estimar fins que s’arriba a una visió compartida.
La principal característica del Planning Poker és que permet incorporar les opinions, coneixements i preocupacions dels diferents membres de l’equip sense convertir l’estimació en una decisió imposada per una sola persona.
PM²-Agile recomana especialment aquesta tècnica en tallers de refinament i estimació dels Work Items de major prioritat.
8. Kanban Method (mètode Kanban)
El Kanban Method (mètode Kanban) és una tècnica de gestió visual del treball basada en els principis Lean.
El terme Kanban prové del japonès i està associat al concepte de senyal o targeta visual. El mètode va ser desenvolupat en el context del sistema de producció de Toyota i es basa en una lògica de tipus pull (arrossegament): el treball nou entra en el procés quan la capacitat del pas següent ho permet.
En un equip Agile, aquesta idea es pot representar mitjançant un Kanban board (tauler Kanban) que mostra visualment l’estat dels Work Items.
Per exemple:
To Do → In Progress → Testing → Done
Cada Work Item es representa com una targeta que avança pel tauler.
Aquesta visualització permet identificar fàcilment:
- què està pendent;
- què s’està desenvolupant;
- quins elements estan bloquejats;
- quina feina està acabada;
- on es produeixen colls d’ampolla.
El Kanban ajuda així a millorar la visibilitat, la transparència i el control del Work in Progress (WIP), és a dir, del treball que està en curs.
9. Burndown Charts (gràfics de treball pendent)
Els Burndown Charts (gràfics de treball pendent) són eines visuals que permeten representar l’evolució del treball restant al llarg del temps.
La idea és senzilla: partint d’una quantitat inicial de treball, el gràfic mostra com aquesta quantitat va disminuint fins arribar a zero o al nivell esperat de treball restant.
PM²-Agile utilitza els Burndown Charts per analitzar tant el progrés d’una Iteration (iteració) com el d’una Release (lliurament).
En una iteració, el gràfic pot representar el treball restant en hores d’esforç o Story Points al llarg dels dies.
En una Release, el gràfic pot mostrar la funcionalitat restant en Story Points al llarg de les diferents iteracions.
Aquests gràfics permeten identificar desviacions, obstacles i possibles problemes de velocitat. També faciliten la previsió sobre si l’equip podrà assolir l’objectiu previst dins del temps disponible.
Un aspecte important és que el Burndown Chart és dinàmic: el treball planificat pot canviar a partir del feedback i de l’aprenentatge obtingut durant el desenvolupament.
10. Test-Driven Development (desenvolupament orientat a proves)
Test-Driven Development (TDD) (desenvolupament orientat a proves) és una pràctica de desenvolupament en què les proves i el codi d’implementació es construeixen conjuntament en passos molt petits.
El cicle bàsic del TDD és:
Test → Fail → Code → Pass → Repeat
Primer, el desenvolupador escriu una petita prova que descriu el comportament que vol aconseguir. La prova inicialment ha de fallar, ja que la funcionalitat encara no està implementada.
A continuació, escriu només el codi necessari perquè la prova passi correctament. Una vegada superada, es passa al següent comportament que cal implementar.
Aquest procés genera cicles molt curts i incrementals. L’avantatge és que el desenvolupador avança en passos petits i controlats, reduint el risc de construir grans quantitats de codi abans de verificar que funcionen correctament.
PM²-Agile destaca també que TDD contribueix a integrar la qualitat dins del desenvolupament, en lloc de deixar la detecció d’errors únicament per a una fase posterior.
11. Pairing (treball en parelles)
Pairing (treball en parelles) és una tècnica en què dos membres de l’equip Agile treballen conjuntament en una mateixa activitat.
No es limita necessàriament a programar. El Pairing es pot aplicar a activitats com:
- dissenyar una part de la solució;
- desenvolupar una funcionalitat;
- revisar una implementació;
- executar proves;
- resoldre un problema tècnic.
Quan aquesta tècnica s’aplica específicament a la programació, rep el nom de Pair Programming (programació en parelles).
En aquest cas, dos desenvolupadors treballen conjuntament sobre el mateix codi. Tots dos participen en les decisions i analitzen com implementar la funcionalitat.
Un dels principals beneficis del Pairing és la revisió instantània i contínua del treball. En lloc d’esperar que una altra persona revisi el resultat més endavant, dues persones analitzen conjuntament les decisions mentre el treball s’està realitzant.
Això pot contribuir a millorar la qualitat, compartir coneixement i detectar problemes abans que avancin cap a fases posteriors.
Com es complementen aquestes tècniques?
Les Tools and Techniques de PM²-Agile no s’han d’entendre com un conjunt de pràctiques independents. El seu valor principal apareix quan es combinen per donar suport a diferents moments del desenvolupament.
Per exemple, un equip pot començar avaluant la seva capacitat de col·laboració mitjançant Assessing Teamwork, crear les condicions perquè funcioni com a Self-Organising Team i utilitzar Design Blocks per concretar una Feature amb els stakeholders.
Posteriorment, la Feature es pot dividir en Stories, aquestes Stories es poden refinar mitjançant User Stories Breakdown i estimar amb Planning Poker. Durant el desenvolupament, el Kanban Method permet visualitzar el flux de treball, mentre que els Burndown Charts proporcionen informació sobre el progrés.
Al mateix temps, la Definition of Done estableix què significa que un Work Item està realment complet, mentre que Test-Driven Development i Pairing contribueixen a incorporar la qualitat durant la pròpia construcció de la solució.
El resultat és un conjunt de tècniques que cobreixen diferents dimensions:
Equip → Disseny → Requisits → Estimació → Flux de treball → Progrés → Qualitat → Desenvolupament
Aquesta combinació encaixa amb la filosofia general de PM²-Agile: proporcionar als equips eines que els ajudin a treballar de manera col·laborativa, iterativa, transparent i orientada a la generació contínua de valor. La guia també destaca que PM²-Agile amplia PM² amb mètodes, eines i tècniques específiques per incorporar principis Agile i Lean dins dels projectes PM².
Les Tools and Techniques (eines i tècniques) de PM²-Agile proporcionen un conjunt de pràctiques concretes per convertir els principis Agile en una manera de treballar aplicable al projecte.
Assessing Teamwork ajuda a comprendre i millorar la dinàmica de l’equip; Self-Organising Teams fomenta l’autonomia i l’adaptabilitat; Design Blocks faciliten la concreció col·laborativa de les solucions; i Features and Stories permeten dividir les necessitats en unitats de treball manejables.
La Definition of Done estableix els criteris que determinen quan un treball està realment complet, mentre que Planning Poker ajuda a obtenir estimacions consensuades. El Kanban Method fa visible el flux de treball i els Burndown Charts permeten seguir-ne el progrés.
Finalment, Test-Driven Development i Pairing contribueixen a incorporar la qualitat durant el mateix procés de desenvolupament.
En conjunt, aquestes tècniques permeten que l’equip no només planifiqui què ha de fer, sinó que també pugui col·laborar millor, visualitzar el treball, adaptar-se als canvis, controlar el progrés i construir qualitat des del principi. Aquest és precisament un dels objectius de PM²-Agile: combinar l’estructura i la governança de PM² amb pràctiques Agile que facilitin el desenvolupament iteratiu, incremental i orientat al valor.