Els artefactes per governar, planificar i coordinar el desenvolupament Agile
Artefactes de governança de TI
Artefactes de coordinació i informes
Com es relacionen les tres categories?
La relació entre valor de negoci i treball tècnic
Els artefactes de PM²-Agile són els elements que permeten documentar, planificar, comunicar, coordinar i governar el projecte. La seva funció és donar visibilitat sobre el treball que es realitza dins de la capa Agile i facilitar la coordinació amb la resta de l’organització del projecte.
La guia PM²-Agile agrupa els artefactes en tres categories oficials:
- IT Governance artefacts: proporcionen el marc de governança IT.
- Agile-specific artefacts: permeten planificar i gestionar el treball Agile.
- Coordination & Reporting artefacts: faciliten la coordinació entre les activitats Agile i el projecte global, així com el seguiment i la comunicació del progrés.
IT Governance artefacts / Artefactes de governança de TI
Els IT Governance artefacts proporcionen la informació requerida per la governança IT de l’organització. Són artefactes comuns als projectes IT, independentment de l’enfocament de gestió que s’utilitzi.
En PM²-Agile inclouen:
- Business Case / Cas de negoci
- Project Charter / Carta del projecte
- Architecture Overview / Visió general de l’arquitectura
- Operational Model / Model operatiu
Aquests artefactes estableixen el context dins del qual es desenvolupa la solució Agile.
1. Business Case / Cas de negoci
El Business Case justifica el projecte i explica per què l’organització hauria d’invertir-hi. Recull els beneficis esperats i permet valorar aspectes com:
- la necessitat o oportunitat que origina el projecte;
- els beneficis esperats;
- els costos;
- els riscos;
- la viabilitat econòmica;
- l’alineació amb els objectius estratègics.
Per tant, el Business Case permet respondre una pregunta fonamental: Per què hem de fer aquest projecte i quin valor esperem obteni-ne? És el punt de partida per entendre la justificació empresarial i estratègica de la iniciativa.
2. Project Charter / Carta del projecte
El Project Charter defineix formalment el projecte i estableix les seves principals condicions de governança. Entre altres aspectes, defineix:
- els objectius;
- l’abast;
- els principals resultats esperats;
- els rols;
- les responsabilitats;
- les parts interessades;
- les principals condicions de governança;
- les restriccions i dependències més rellevants.
En un projecte PM²-Agile, el Project Charter proporciona el marc estable dins del qual es desenvoluparà el treball Agile. L’Agile permet adaptar i evolucionar la solució, però aquesta flexibilitat no elimina la necessitat de tenir clars els objectius, l’abast i les responsabilitats del projecte.
3. Architecture Overview / Visió general de l’arquitectura
L’Architecture Overview ofereix una visió general de l’arquitectura de la solució. Descriu els principals:
- components;
- sistemes;
- integracions;
- decisions tècniques;
- principis arquitectònics;
- relacions entre els diferents elements de la solució.
El seu objectiu és proporcionar una visió compartida de l’arquitectura, especialment important quan el desenvolupament evoluciona de manera iterativa. No cal que documenti tots els detalls tècnics de cada implementació. Ha de permetre entendre com s’estructura la solució i quines decisions arquitectòniques orienten el desenvolupament.
4. Operational Model
L’Operational Model descriu com funcionarà operacionalment la solució. Inclou aspectes relacionats amb:
- infraestructura;
- sistemes;
- aplicacions;
- usuaris;
- entorns;
- desplegament;
- operació.
La seva funció és assegurar que el projecte no es limita a construir una solució, sinó que també considera com aquesta solució serà desplegada, utilitzada i operada.
Agile-specific artefacts / Artefactes específics d’àgil
Els Agile-specific artefacts capturen la informació necessària per planificar els processos, les activitats, les Releases (entregables), les Iterations i altres fites específiques del desenvolupament Agile.
Dins d’aquesta categoria trobem els principals artefactes que utilitza l’equip per organitzar i executar el desenvolupament:
- Development Handbook / Manual de desenvolupament
- Development Work Plan / Pla de treball de desenvolupament
- Work Items List (WIL) / Llista d’elements de treball (WIL)
- Release Plan / Pla de llançament
- Iteration Plan / Pla d’iteració
- Test Plan / Pla de proves
- Deployment Plan / Pla de desplegament
1. Development Handbook / Manual de desenvolupament
El Development Handbook defineix les normes, pràctiques, processos i convencions que utilitzarà l’equip durant el desenvolupament Agile. Pot establir aspectes relacionats amb:
- processos de desenvolupament;
- eines;
- estàndards;
- control de versions;
- pràctiques de qualitat;
- revisió de codi;
- gestió dels Work Items;
- formes de col·laboració.
El seu objectiu és establir una manera de treballar compartida per tot l’equip. En el model PM², el Development Handbook es relaciona amb el Project Handbook global. La guia PM²-Agile indica que aquest artefacte passa a formar part del Project Handbook general.
2. Development Work Plan / Pla de treball de desenvolupament
El Development Work Plan organitza el treball de desenvolupament. Permet definir:
- activitats;
- responsabilitats;
- prioritats;
- dependències;
- planificació prevista.
És la peça que ajuda a convertir els objectius i les necessitats del producte en una planificació concreta del treball de desenvolupament. Igual que el Development Handbook, el Development Work Plan s’integra amb els artefactes globals de PM²: passa a formar part del Project Work Plan.
3. Work Items List (WIL) / Llista d’elements de treball (WIL)
La Work Items List (WIL) proporciona una visió única del treball que s’ha de realitzar. És especialment important perquè permet mantenir conjuntament diferents tipus de treball:
- User Stories;
- Enabler Stories;
- Bugs;
- altres Work Items.
Això evita considerar únicament les funcionalitats visibles per a l’usuari i permet fer visible també el treball tècnic necessari per construir, mantenir i evolucionar el producte.
- Una User Story descriu una necessitat concreta d’un usuari que aporta valor i que pot implementar-se durant una iteració. El seu focus és funcional: representa una necessitat que l’usuari o el negoci necessita resoldre.
- Una Enabler Story representa treball tècnic necessari per permetre, facilitar o garantir futures funcionalitats del producte. Pot estar relacionada, per exemple, amb arquitectura, infraestructura, integracions, seguretat, rendiment o altres capacitats tècniques. Encara que el seu resultat no sigui necessàriament visible per a l’usuari, forma part del treball necessari per construir el producte.
- Un Bug identifica un error o comportament incorrecte que necessita ser corregit. Els bugs formen part del treball real del producte i, per tant, han de poder ser gestionats i prioritzats juntament amb les noves funcionalitats i el treball tècnic.
- Altres Work Items: La WIL també pot contenir altres elements de treball que no encaixin directament com a User Story, Enabler Story o Bug. D’aquesta manera, la WIL proporciona una visió completa del treball necessari.
Features i Stories / Característiques i històries
Per entendre com s’organitza el treball dins de la WIL, és important diferenciar entre Features i Stories.
- Una Feature representa una capacitat funcional significativa que aporta valor al negoci, als usuaris o al producte. Una Feature pot ser massa gran per implementar-la directament en una única iteració. Per això es divideix en unitats de treball més petites.
- Una Story divideix una Feature en una unitat de treball més petita, comprensible, estimable i implementable dins d’una iteració.
La relació habitual es pot representar així: Feature → Stories → Tasks → Increment
Aquesta relació permet passar d’una capacitat de producte a un conjunt concret d’activitats de desenvolupament i, finalment, a un increment funcional.
Business & Enabler / Negoci i facilitador
Una distinció fonamental dins del treball Agile és la que existeix entre Business (negoci) i Enabler (facilitar). No tot el treball necessari per construir un producte és visible per a l’usuari. Una part important correspon a capacitats tècniques que permeten construir, desplegar, protegir, escalar o mantenir les funcionalitats de negoci. Per això, el treball tècnic també forma part del producte i s’ha de planificar, prioritzar i controlar.
- Una Business Feature (Característica empresarial) representa una capacitat del producte orientada directament a generar valor per al negoci o per als usuaris. És la capacitat funcional que respon a una necessitat de negoci.
- Una Business/User Story (Història d’empresa/usuari) concreta una necessitat funcional que l’usuari necessita i que l’equip pot implementar. És una unitat de treball prou concreta per ser entesa, estimada i desenvolupada.
- Una Enabler Feature (Funció habilitadora) representa una capacitat tècnica necessària per fer possible o sostenir una determinada funcionalitat. Pot estar relacionada amb:
- arquitectura;
- infraestructura;
- integracions;
- seguretat;
- rendiment;
- escalabilitat;
- altres capacitats tècniques.
La seva importància és que fa visible un tipus de treball que, tot i no ser necessàriament percebut directament per l’usuari, és imprescindible per al producte.
Coordination & Reporting artefacts / Artefactes de coordinació i informes
La tercera categoria oficial són els Coordination & Reporting artefacts. Aquests artefactes tenen una funció diferent dels dos grups anteriors: permeten coordinar les activitats del projecte global amb les activitats realitzades per l’Agile Project Core Team (A-PCT) i proporcionar al Project Manager visibilitat sobre les activitats específiques del domini Agile, les incidències, les fites i el progrés.
Aquesta categoria és especialment important perquè PM²-Agile no funciona com un entorn Agile aïllat. L’equip Agile forma part d’un projecte PM² més ampli i, per tant, necessita mecanismes que connectin els dos nivells. Entre aquests artefactes trobem principalment:
- Els PM²-Agile Logs permeten registrar i fer seguiment de diferents aspectes del treball Agile. Poden incloure informació relacionada amb:
- proves;
- retrospectives;
- incidències;
- decisions;
- altres elements que necessiten seguiment i coordinació.
La guia mostra, dins del paisatge d’artefactes PM² i PM²-Agile, exemples com el Testing Log i el Retrospectives Log. Aquests logs aporten una memòria del que ha passat i faciliten el seguiment continu del desenvolupament.
- El Development Status Report proporciona informació sobre l’estat del desenvolupament Agile. Permet donar visibilitat sobre aspectes com:
- progrés;
- activitats realitzades;
- fites;
- incidències;
- situació del desenvolupament;
- aspectes que poden requerir atenció.
És especialment important des de la perspectiva del Project Manager, perquè permet integrar la informació procedent de l’equip Agile amb la visió general del projecte. En el model PM², el Development Status Report s’integra amb els Project Status Reports generals.
Com es relacionen les tres categories?
Les tres categories d’artefactes tenen funcions complementàries. Els IT Governance artefacts estableixen el marc i els objectius del projecte; els Agile-specific artefacts permeten planificar i executar el desenvolupament Agile; i els Coordination & Reporting artefacts connecten el treball Agile amb el projecte global i en faciliten el seguiment i la comunicació.
En conjunt, formen una cadena coherent: Governança → Desenvolupament → Coordinació i reporting.
La relació entre valor de negoci i treball tècnic
Un dels aspectes clau de PM²-Agile és que la planificació ha de considerar tant el Business work, orientat directament al valor per a l’usuari o el negoci, com l’Enabler work, necessari per fer possible i sostenir les funcionalitats del producte. Així, una mateixa necessitat pot donar lloc a Business Features i Business/User Stories, però també a Enabler Features i Enabler Stories que donen suport al desenvolupament. Ambdues línies de treball contribueixen al mateix resultat final i, per això, la Work Items List (WIL) és especialment rellevant, ja que proporciona una visió conjunta del treball funcional, tècnic, correctiu i d’altres tipus, fent que el treball tècnic no visible per a l’usuari formi part explícita de la planificació i gestió del producte.
Vídeos i recursos complementaris
Per ampliar i reforçar els continguts explicats en aquest apartat, pots consultar la següent llista de vídeos de YouTube, que ofereix recursos complementaris i exemples pràctics relacionats amb els conceptes tractats:
Veure la llista de vídeos a YouTube
Aquests vídeos poden ser útils per aprofundir en els conceptes i facilitar-ne la comprensió mitjançant explicacions i exemples visuals.