Els principis, rols, temes, cerimònies, artefactes i eines
PM²-Rols i responsabilitats àgils
PM²-Agile combina la governança i l’estructura de la metodologia PM² amb les pràctiques de desenvolupament Agile. L’objectiu no és substituir PM² per Agile, sinó crear un marc que permeti treballar de manera iterativa i adaptable sense perdre el control sobre la planificació, els riscos, la qualitat, l’arquitectura, el reporting i el compliment normatiu.
Aquesta combinació és especialment útil en projectes europeus, on l’equip de desenvolupament ha de conviure amb estructures de governança, múltiples stakeholders, requisits de seguretat, protecció de dades i obligacions de documentació i traçabilitat.
Què és Agile?
Agile és una manera de desenvolupar productes i gestionar projectes basada en la col·laboració, la iteració, el feedback i l’adaptació al canvi.
El punt de partida és assumir que, especialment en projectes complexos, no sempre podem saber al principi exactament què necessitarà l’usuari ni quina serà la millor solució.
Per això Agile proposa treballar en cicles curts:
Planificar → Construir → Revisar → Aprendre → Adaptar
En lloc d’esperar fins al final del projecte per descobrir si la solució funciona, l’equip busca obtenir feedback contínuament.
Què és PM²-Agile?
PM²-Agile és una extensió de PM² que incorpora pràctiques Agile al model de gestió de projectes de la Comissió Europea. La idea central es pot resumir que PM² proporciona governança; Agile proporciona adaptabilitat.
Les fases generals: PM² manté les fases generals del projecte: Initiating → Planning → Executing → Closing i el Monitor & Control transversal.
Els tres nivells de cicle interactius: PM²-Agile introdueix dins d’aquest marc cicles iteratius de desenvolupament.
- Daily Cycle: És el cicle de coordinació diària. El principal instrument és el Daily Stand-up.
- Iteration: És el cicle de desenvolupament. L’equip planifica un conjunt de treball, implementa, prova, revisa el resultat i reflexiona sobre la manera de treballar.
- Release: Agrupa diferents iteracions i permet lliurar una versió significativa del producte.
Per tant: Daily → Iteration → Release → Project
El cicle CIR
CIR = Coordinate → Implement → Review
- Coordinate: L’equip decideix què farà i com s’organitzarà.
- Implement: Es desenvolupa i prova la solució.
- Review: Es revisa tant el producte com el procés.
Aquesta estructura crea un ritme constant de planificació, desenvolupament, feedback i millora.
Els quatre valors d’Agile
El Manifesto for Agile Software Development estableix quatre preferències fonamentals:
Individuals and interactions (Individuals and interactions) per sobre de processos i eines.
Working software (Programari funcional) per sobre de documentació exhaustiva.
Customer collaboration (Col·laboració amb clients) per sobre de negociació contractual.
Responding to change (Resposta al canvi) per sobre de seguir un pla de manera rígida.
Agile no és Scrum
És important no confondre els conceptes. Agile és una filosofia i un conjunt de principis. Scrum, Kanban, XP o Lean UX són aproximacions i pràctiques que poden aplicar aquests principis. PM²-Agile adopta principis Agile però els integra dins d’un marc de governança més ampli.
PM²-Agile Roles & Responsibilities / Rols i responsabilitats
Un dels punts més importants de PM²-Agile és que Agile no elimina els rols de governança de PM². Els adapta.
Project Manager — PM
El Project Manager continua sent responsable de la gestió global del projecte. En PM²-Agile, però, el PM no ha de controlar cada tasca de l’equip.
L’equip Agile és més autònom i el PM facilita les condicions perquè pugui treballar correctament.
- governança;
- planificació global;
- gestió de riscos;
- coordinació;
- reporting;
- stakeholders;
- dependències;
- impediments;
- alineament amb els objectius del projecte.
Business Manager — BM
El Business Manager representa la perspectiva del negoci.
És responsable d’assegurar que el projecte continua alineat amb:
- les necessitats del negoci;
- els objectius de l’organització;
- els usuaris;
- els beneficis esperats.
Product Owner — PrOw
El Product Owner és la connexió operativa entre el negoci i l’equip Agile.
El BM proporciona la direcció de negoci, mentre que el Product Owner pot prendre decisions més properes al dia a dia del producte.
Gestiona i prioritza el valor del producte i ajuda l’equip a entendre què s’ha de construir i per què.
Team Coordinator — TeCo
El Team Coordinator facilita el funcionament de l’equip Agile.
- facilita les cerimònies;
- ajuda en la coordinació;
- facilita la comunicació;
- ajuda a eliminar impediments;
- promou la millora contínua.
- Agile Team
Agile Team
L’equip Agile és cross-functional i self-organising. Això significa que disposa de les competències necessàries per construir la solució i té autonomia per organitzar el seu treball. La gran diferència respecte d’un model més tradicional és que l’equip no espera que el PM li assigni constantment cada tasca.
PM²-Agile Themes / Temes
Els Themes són àrees transversals que ajuden a gestionar aspectes importants del projecte Agile. No són fases. Són perspectives que s’han de tenir presents durant el projecte.
Coordination & Reporting
- Planning: L’Agile Core Team prepara els lliurables i plans necessaris per organitzar el treball, definir prioritats i mantenir l’alineació amb els objectius del projecte.
- Reporting: L’equip proporciona informació actualitzada sobre el progrés, els resultats, els impediments i els riscos, facilitant la presa de decisions dels responsables i stakeholders.
- Architecture: Defineix i manté una arquitectura coherent amb les necessitats del projecte. L’Architecture Overview evoluciona progressivament segons el coneixement obtingut durant les iteracions.
- Deployment and Transition: Garanteix que la solució desenvolupada pugui desplegar-se correctament i passar a l’entorn operacional, considerant infraestructura, documentació, formació i suport.
- Risk: Identifica i gestiona els riscos de manera contínua. Les iteracions curtes, la simplicitat, la comunicació entre equips i la reflexió regular permeten detectar problemes aviat i reduir la incertesa.
Cal connectar: Agile Team → PM → BM → Governance → Stakeholders
L’objectiu no és generar més informes, sinó proporcionar la informació adequada a cada nivell de decisió.
Architecture
L’arquitectura proporciona la coherència tècnica del sistema. PM²-Agile utilitza especialment 2 artefactes clau:
- L’Architecture Overview mostra la visió arquitectònica de la solució.
- L’Operational Model explica com aquesta solució funcionarà operacionalment.
L’arquitectura és evolutiva: es defineix prou al principi per prendre bones decisions, però es refina a mesura que el projecte obté coneixement.
Planning
L’exit dels projectes Agile depen de com d’efectiva i eficiente es fa la programació:
- Els cicles de la planificació (i l’abast)
- Tothom participa en la planificació
- La planificació és més important que els plans
En PM²-Agile, l’estimació i la priorització permeten determinar què és més important i quin esforç requereix cada element. La Relative Estimate (Estimació relativa) compara la complexitat entre Stories, habitualment mitjançant punts, sense calcular hores exactes. Les Velocity Measures (Mesures de velocitat) indiquen quant treball pot completar l’equip en una iteració i ajuden a planificar les següents. Finalment, l’Absolute Estimate (Estimació absoluta) intenta calcular l’esforç real necessari, per exemple en hores o dies. Aquestes tècniques faciliten una planificació més realista i adaptable.
Deployment & Transition
El producte no està acabat simplement perquè el codi funcioni.
Cal preparar: desplegament; infraestructura; operacions; formació; documentació; suport; transició al negoci.
Aquesta perspectiva evita el problema de construir una aplicació que després no pot ser operada correctament.
El control de canvis
El control de canvis és essencial en projectes PM²-Agile, especialment quan es treballa amb múltiples artefactes que evolucionen al llarg del projecte. Requisits, User Stories, plans, documents d’arquitectura o configuracions poden canviar durant les iteracions, i cal garantir que aquests canvis siguin controlats, traçables i coherents.
En aquest context, el Software Configuration Management (SCM) permet gestionar de manera sistemàtica els elements que formen part de la configuració del projecte. Els seus principals passos són:
- Identificació: determinar quins elements formen part de la configuració i com s’han d’identificar.
- Control de canvis: analitzar, aprovar i registrar els canvis abans d’incorporar-los.
- Control de versions: mantenir l’historial de les diferents versions dels artefactes i del software.
- Auditoria de configuració: comprovar que els elements compleixen els requisits i que els canvis han estat correctament aplicats.
- Informes: proporcionar informació sobre l’estat, les versions i els canvis realitzats.
Així, el SCM garanteix traçabilitat, consistència i control durant tot el cicle de vida del projecte.
Risk
En PM²-Agile, el risc es gestiona contínuament. Els cicles curts permeten detectar riscos abans. Tres principis són especialment importants:
- Collocated Teams: La proximitat física o virtual facilita la comunicació.
- Simplicity: Eliminar complexitat i treball que no aporta valor.
- Regular Reflection: Reflexionar regularment sobre què funciona, què no i què s’ha de canviar redueix els riscos.
Gestió del risc en PM²-Agile: En PM²-Agile, el risc es gestiona com un procés continu format per quatre pasos:
- Primer, Identify risk (identifiquem el risc), detectant qualsevol situació que pugui afectar els objectius del projecte.
- Després, fem una Risk assessment (avaluació del risc), analitzant-ne la probabilitat i l’impacte.
- En tercer lloc, definim una Risk response strategy (estratègia de resposta), decidint com prevenir-lo, reduir-lo o afrontar-lo.
- Finalment, Control risk response (controlem la resposta al risc), comprovant si les mesures adoptades funcionen i ajustant-les quan sigui necessari.
Stakeholders
Els stakeholders no haurien d’aparèixer només al principi i al final del projecte.
Han de participar en el feedback.
Això permet validar: requisits; prototips; increments; prioritats; qualitat; valor de negoci.
Lean UX
Lean UX parteix de la idea que moltes decisions de producte són hipòtesis. Per exemple: «Els usuaris necessiten un dashboard únic.» En lloc de construir directament el dashboard, podem crear un prototip i validar-lo.
En un projecte europeu, un prototip pot actuar com a llenguatge comú entre usuaris, negoci, equip tècnic i stakeholders institucionals.
El cicle és: Inici i recerca → Creació d’un prototip validat → Desplegament d’un prototip → Avaluació i aprenentatge → Tornar a començar
PM²-Agile Ceremonies / Cerimònies
1. Release Planning
Serveix per determinar què es vol aconseguir en una Release, és a dir una versió acabada i provada que inclou noves funcions o correccions. Es prioritzen les funcionalitats i es defineixen objectius.
La pregunta principal és: Quin valor volem entregar en aquesta Release?
2. Iteration Planning
L’equip selecciona els Work Items (unitats de traball) que intentarà completar durant la iteració.
Es defineix: objectiu de la iteració; Stories; tasques; capacitat; dependències.
3. Daily Stand-up
És una reunió curta de coordinació. L’objectiu no és fer reporting al PM, sinó permetre que l’equip coordini el seu treball.
Serveix per detectar: bloquejos; dependències; problemes; canvis necessaris.
4. Iteration Review
Al final de la iteració, l’equip mostra el que ha construït. Els stakeholders poden donar feedback.
Aquesta cerimònia respon: Hem construït el que necessitàvem?
5. Iteration Retrospective
La retrospectiva no se centra en el producte sinó en el procés.
Preguntes típiques: Què ha funcionat? Què no ha funcionat? Què hem après? Què podem millorar?
La pregunta final és: Què farem diferent en la pròxima iteració? Això és el principi de Regular Reflection.
PM²-Agile Artefacts / Artefactes
Els artefactes són els elements que permeten documentar, planificar, comunicar i governar el projecte.
Artefactes de governança
- Business Case: Justifica el projecte, explica els seus beneficis esperats i permet valorar-ne la viabilitat econòmica i estratègica.
- Project Charter: Defineix formalment el projecte, els seus objectius, abast, rols, responsabilitats i principals condicions de governança.
- Architecture Overview: Ofereix una visió general de l’arquitectura, components, decisions tècniques, integracions i principis que guien la solució.
- Operational Model: Descriu com funcionarà operacionalment la solució, incloent infraestructura, sistemes, aplicacions, usuaris i desplegament.
Artefactes Agile
- Development Handbook: Defineix les normes, pràctiques, processos i convencions que utilitzarà l’equip durant el desenvolupament Agile.
- Development Work Plan: Organitza el treball de desenvolupament, indicant activitats, responsabilitats, prioritats, dependències i planificació prevista.
- Work Items List (WIL): Conté tot el treball pendent o planificat, incloent Stories, Enabler Stories, bugs i altres elements.
- Release Plan: Defineix què es vol lliurar en una Release, les funcionalitats prioritzades i els objectius corresponents.
- Iteration Plan: Detalla l’objectiu d’una iteració i els Work Items que l’equip preveu completar durant aquest període.
- Test Plan: Defineix l’estratègia, activitats i criteris necessaris per verificar que la solució compleix els requisits.
- Deployment Plan: Explica com es desplegarà la solució, incloent activitats, responsables, dependències, entorns i requisits operacionals.
Work Items List
La Work Items List (WIL) és especialment important perquè proporciona una visió única del treball que s’ha de realitzar.
Pot contenir diferents tipus d’elements:
- User Story: Descriu una necessitat concreta d’un usuari que aporta valor i pot implementar-se durant una iteració.
- Enabler Story: Representa treball tècnic necessari per permetre, facilitar o garantir futures funcionalitats del producte.
- Bug: Identifica un error o comportament incorrecte que necessita ser corregit per garantir la qualitat del producte.
- Altres Work Items: Representen altres activitats necessàries que no encaixen directament com User Stories, Enabler Stories o bugs.
Features i Stories
- Feature: Representa una capacitat funcional significativa que aporta valor al negoci, als usuaris o al producte.
- Story: Divideix una Feature en una unitat de treball més petita, comprensible, estimable i implementable dins d’una iteració.
La relació habitual és: Feature → Stories → Tasks → Increment
Business i Enabler
Aquesta distinció és fonamental perquè el treball tècnic no visible per l’usuari també forma part del producte i s’ha de planificar, prioritzar i controlar. PM²-Agile diferencia també dues perspectives de treball:
- Business Feature: Representa una capacitat del producte orientada directament a generar valor per negoci o usuaris.
- Business/User Story: Concreta una necessitat funcional que l’usuari necessita i que l’equip pot implementar.
- Enabler Feature: Representa una capacitat tècnica necessària per fer possible o sostenir una funció.
PM²-Agile Tools & Techniques / Eines i tècniques
Les eines i tècniques Agile tenen com a objectiu facilitar que l’equip pugui organitzar el treball, prendre decisions, fer visible el progrés i aprendre durant el desenvolupament. No són simplement eines de gestió: ajuden a crear transparència i a detectar problemes abans que es converteixin en riscos importants.
Backlog / Work Items List
El Backlog, que en PM²-Agile es relaciona amb la Work Items List (WIL), és l’espai on es recull i s’organitza el treball que encara s’ha de realitzar. No és una llista estàtica, sinó que evoluciona a mesura que el projecte obté informació nova.
La seva funció principal és ajudar a decidir què s’ha de fer, en quin ordre i per què. Per prioritzar els Work Items es poden considerar factors com el valor que aporten al negoci o als usuaris, el risc que redueixen, les dependències amb altres elements, l’esforç necessari i el coneixement que permeten obtenir. D’aquesta manera, l’equip intenta treballar primer en allò que proporciona més valor o que permet reduir més incertesa.
Estimació relativa
En Agile, l’equip no necessita predir amb exactitud quantes hores trigarà cada Story. En lloc d’això, pot utilitzar una estimació relativa, comparant la complexitat d’una Story amb la d’altres.
Una escala habitual és 1, 2, 3, 5, 8, 13. Per exemple, si una Story té un valor 8 i una altra un 3, significa que la primera es considera considerablement més complexa, no necessàriament que trigarà exactament 8 hores i l’altra 3. Aquesta tècnica evita una falsa sensació de precisió i ajuda l’equip a parlar sobre complexitat, esforç i incertesa.
Kanban Board
El Kanban Board és una representació visual del flux de treball. Les tasques es mouen entre diferents estats, per exemple: To Do → In Progress → Review → Done
La seva utilitat és fer visible què està passant realment dins de l’equip. Si moltes tasques s’acumulen a Review, per exemple, pot indicar que existeix un coll d’ampolla en la revisió o en les proves.
Per tant, el Kanban Board no només serveix per saber «què falta fer», sinó també per entendre com flueix el treball i on apareixen els problemes.
Burndown Chart
El Burndown Chart mostra visualment com disminueix la quantitat de treball pendent al llarg d’una iteració.
Permet comparar el treball que queda amb el temps disponible. Si, a mesura que avança la iteració, el treball pendent no disminueix com s’esperava, l’equip pot detectar-ho aviat i analitzar-ne les causes.
És, per tant, una eina senzilla per tenir una visió ràpida del progrés, però no hauria d’utilitzar-se com una mesura absoluta de productivitat.
Definition of Done
La Definition of Done (DoD) estableix què significa realment que un Work Item està «acabat». És important perquè en un projecte de software hi ha una gran diferència entre haver escrit el codi i haver completat una funcionalitat preparada per formar part del producte.
Per exemple, una Story podria considerar-se Done quan ha estat desenvolupada, provada, revisada i compleix els criteris d’acceptació. També pot requerir que la documentació estigui actualitzada i que s’hagin complert els requisits de seguretat corresponents.
Així, la Definition of Done crea una definició compartida de qualitat i finalització per a tot l’equip.
Prototyping
El Prototyping és especialment important quan s’utilitza Lean UX. Consisteix a crear una representació simplificada d’una possible solució abans de desenvolupar-la completament.
Un prototip permet ensenyar una idea als usuaris i stakeholders i comprovar si realment respon a les seves necessitats. Pot ser tan senzill com un esquema de pantalles o arribar a ser un prototip interactiu.
El seu valor principal és aprendre abans de gastar massa recursos. Si els usuaris detecten que una funcionalitat no és útil, és molt més fàcil modificar un prototip que una aplicació ja desenvolupada.
Workshops
Els Workshops són sessions de treball col·laboratives en què diferents perfils participen en la definició o resolució d’un problema. En PM²-Agile poden reunir usuaris, Product Owner, experts de negoci, arquitectes, desenvolupadors i altres stakeholders.
La seva importància està en crear una comprensió comuna. En lloc que cada persona interpreti els requisits des de la seva perspectiva, el grup pot discutir-los, qüestionar-los i construir una solució conjuntament.
Per això són especialment útils en projectes complexos, on la comunicació i l’alineament són tan importants com la tecnologia.
Retrospectives
La Retrospective és una tècnica de millora contínua que es realitza després d’una iteració. L’equip analitza com ha treballat i identifica què ha funcionat bé, què ha generat problemes i què podria fer-se millor.
El més important és que la retrospectiva no hauria de quedar-se en una simple conversa. L’equip hauria d’identificar accions concretes de millora i intentar aplicar-les en la iteració següent.
Això connecta directament amb un dels principis importants de PM²-Agile: Regular Reflection → Learning → Improvement
En definitiva, les eines i tècniques Agile no són l’objectiu del projecte. Són instruments que permeten que l’equip tingui visibilitat, feedback i capacitat d’adaptació, reduint la incertesa i millorant progressivament tant el producte com la manera de treballar.
PM²-Agile combina la governança i el control necessaris en els projectes europeus —planificació, reporting, riscos, qualitat, seguretat i compliance— amb la flexibilitat i adaptabilitat que necessita un equip Agile, basades en iteracions curtes, feedback i experimentació.
En definitiva, PM²-Agile busca aportar més adaptabilitat sense perdre el control. L’èxit no depèn d’aplicar moltes eines o cerimònies Agile, sinó d’aconseguir que negoci, governança i equip tècnic treballin de manera coordinada, aprenent contínuament i lliurant valor de forma progressiva, segura i verificable.