agile manifesto understanding agile values
Introducció al Manifest Agile:
El nostre tutorial anterior sobre Metodologia Àgil ens va explicar tot sobre models i metodologies Agile en detall.
Però fins ara no ens expliquem per què hi havia una necessitat d’àgil en primer lloc i de com l’àgil va superar les deficiències de les metodologies de desenvolupament de programari existents, com el model de cascada.
En aquest tutorial, aprofundirem en els detalls de l'àgil i del manifest àgil. Veurem què diu el manifest i quins són els valors i principis que s’hi recullen.
quines màquines virtuals d'escriptori s'executen al sistema operatiu Windows
Què aprendreu:
Introducció
Com hem vist a la nostra tutorial anterior , les metodologies de desenvolupament anteriors trigaven massa temps i, quan el programari estava llest per al seu desplegament, els requisits empresarials haurien canviat i, per tant, no satisfan les necessitats actuals.
La velocitat de canvi que faltava en aquell moment causava molts problemes. Quan els líders de les diferents metodologies de desenvolupament es van reunir per decidir el camí a seguir, van poder acordar un mètode millor i també van poder finalitzar la redacció del manifest.
Es va capturar com a 4 valors i 12 principis per ajudar els professionals a entendre-la, referir-s'hi i posar-la en pràctica. I en aquell moment, cap d’ells no podia imaginar l’impacte que això tindria en el futur de la gestió de projectes.
Manifest Àgil
El manifest ha estat redactat amb molta cura per recollir l’essència de l’àgil en paraules mínimes i es llegeix com segueix:
“Estem descobrint millors maneres de desenvolupar un programari fent-ho i ajudant els altres a fer-ho. A través d’aquest treball hem arribat al valor següent:
- Individus i interaccions sobre processos i eines.
- Programari de treball sobre documentació completa.
- Col·laboració del client en la negociació de contractes.
- Respondre al canvi seguint un pla.
És a dir, si bé hi ha valor en els elements de la dreta, valorem més els elements de l’esquerra ”.
Com podem veure, són afirmacions bastant concises i senzilles i ho deixen molt clar com el que volien promoure els fundadors. Normalment, els plans de projectes tradicionals són rígids i emfatitzen els procediments i els terminis, però el manifest àgil propaga exactament les coses oposades.
Prefereix:
- Gent
- Producte
- Comunicació i
- Capacitat de resposta
Explorarem aquest nou paradigma que els fundadors volien promoure en detall amb una comprensió més profunda dels valors i principis àgils.
Els 4 valors àgils
Els quatre valors juntament amb els 12 principis guien el lliurament àgil del programari. Ara parlarem detalladament de cadascun dels valors.
# 1) Individus i interaccions sobre processos i eines
Es prefereixen les persones i les interaccions sobre els processos i les eines perquè fa que el procés sigui més sensible. Si les persones estan alineades i un cop s’entenen, l’equip pot resoldre qualsevol problema amb les eines o els processos.
Però si els equips insisteixen a seguir cegament els processos, pot provocar malentesos entre els individus i crear barreres inesperades que comportin retards en el projecte.
Per això, sempre és preferible tenir interaccions i comunicació entre els membres de l’equip en lloc de dependre cegament dels processos per guiar el camí a seguir. Una de les maneres d’aconseguir-ho és comptar amb un propietari de producte implicat que treballi i pugui prendre decisions en col·laboració amb l’equip de desenvolupament.
Permetre que les persones puguin contribuir per si mateixes també els permet mostrar lliurement el que poden aportar a la taula. Quan aquestes interaccions d’equip es dirigeixen cap a la resolució d’un problema comú, els resultats poden ser força potents.
# 2) Programari de treball sobre documentació completa
La gestió de projectes tradicionals implicava una documentació completa que comportava un retard de mesos. Això solia impactar negativament sobre la realització del projecte i els retards resultants eren inevitables.
El tipus de documentació creada per a aquests projectes era molt detallada i es van crear tants documents que ni tan sols es va fer referència a molts d’ells durant el progrés del projecte. Aquest va ser un mal innecessari amb què solien conviure els equips del projecte.
Però això també va agreujar els problemes de lliurament. El focus es va centrar en la documentació fins a tal punt perquè els equips volien acabar amb un producte acabat que era del 100% segons les especificacions. Per això, es va centrar en captar totes les especificacions en detalls.
Però, tot i així, el producte final solia ser força diferent de les expectatives o hauria perdut rellevància. És per això que Agile diu que un programari que funciona és una opció molt millor per avaluar les expectatives dels clients que un munt de documentació.
Això no implica que la documentació no sigui necessària. Només vol dir que un producte que funciona és un indicador millor d’alineació a les necessitats i expectatives del client que un document creat fa mesos. També implica que els equips responen i estan preparats per adaptar-se als canvis quan i quan es requereixi mentre mostren el programari de treball al client quan finalitza el sprint.
El fet de no provar el producte durant els sprints suposa un cost i un esforç múltiples al sprint següent. Un cop desplegada la funcionalitat, el cost d’aquests canvis augmenta encara més en un grau significatiu.
3. Col·laboració del client en la negociació del contracte
La negociació significa que els detalls encara s’estan capturant i no s’han finalitzat. Encara hi ha marge de renegociació. Però un cop acabada la negociació, no hi pot haver discussió. El que diu àgil és que, en lloc de negociar, aneu per la col·laboració.
La col·laboració implica que encara hi ha marge per debatre i la comunicació continua.
No és una cosa única. El que fa això és que proporciona un doble avantatge; tot i que ajuda l’equip a fer una correcció del curs si es requereix en una etapa anterior, també ajuda el client a refinar la seva visió i redefinir els seus requisits si es requereix durant el curs del curs. projecte.
L'altre aspecte és que, tot i que els models tradicionals de desenvolupament de programari impliquen al client abans que comenci el desenvolupament durant la fase de documentació i negociació, i no participen tan durant el desenvolupament del projecte.
Un cop congelats els requisits, només podran veure el producte, un cop el producte estigui llest. Agile també traspassa aquesta barrera en permetre la participació dels clients durant tot el cicle de vida.
Això ajuda els equips àgils a alinear-se millor amb les necessitats del client. Una de les maneres d’aconseguir-ho és mitjançant un propietari de producte dedicat i implicat que pugui ajudar l’equip en temps real per obtenir aclariments i alinear la feina amb les prioritats del client.
4. Respondre al canvi després d'un pla
El procés de pensament estàndard és que els canvis són una qüestió costosa i que hem d’evitar els canvis a tota costa. Això és el que se centra innecessàriament en la documentació i en els plans elaborats que cal complir seguint els terminis i les especificacions del producte.
Però, com també ens ensenya l’experiència, els canvis són inevitables en la seva majoria i, en lloc de fugir-ne, hem d’intentar adoptar-los i planificar-los.
Àgil ens permet fer aquesta transició. El que pensa àgil és que el canvi no suposa una despesa, sinó una retroalimentació benvinguda que ajuda a millorar el projecte. No s’ha d’evitar, sinó que afegeix valor.
Amb els sprints curts proposats per Agile, els equips poden obtenir una retroalimentació ràpida i canviar les prioritats en un termini breu. Es poden afegir noves funcions d’iteració a iteració.
Per què ho fem? Perquè la majoria de les funcions desenvolupades mitjançant l'enfocament de cascada no s'utilitzen mai. Això es deu al fet que el model de cascada segueix el pla, mentre que aquesta és la fase en què menys se sap.
Agile també planeja, però també segueix l’enfocament just in time en què la planificació es fa prou quan calgui. I els plans sempre estan oberts a canviar a mesura que avancin els sprints.
Els 12 principis àgils
Hi ha 12 principis àgils que es van afegir després de la creació del manifest per tal d’ajudar i guiar els equips a la transició cap a l’àgil i comprovar si les pràctiques que segueixen s’ajusten a la cultura àgil.
A continuació es mostra el text dels 12 principis originals, publicats el 2001 per l’Agile Alliance:
# 1) La nostra màxima prioritat és satisfer el client mitjançant l’enviament continu i precoç d’un valuós programari.
# 2) Benvingut a canviar els requisits, fins i tot tard en el desenvolupament. Els processos àgils aprofiten el canvi per obtenir l’avantatge competitiu del client.
# 3) Oferiu programari de treball amb freqüència, des d’un parell de setmanes fins a un parell de mesos, amb preferència a l’escala de temps més curta.
# 4) Els empresaris i els desenvolupadors han de treballar junts diàriament durant tot el projecte.
# 5) Construeix projectes al voltant d’individus motivats. Doneu-los l’entorn i el suport que necessiten i confieu en ells per fer la feina.
# 6) El mètode més eficaç i eficaç per transmetre informació a l’equip de desenvolupament i dins d’aquest és una conversa cara a cara.
quina és la millor eliminació de virus
# 7) El programari de treball és la mesura principal del progrés.
# 8) Els processos àgils afavoreixen el desenvolupament sostenible. Els patrocinadors, desenvolupadors i usuaris haurien de poder mantenir un ritme constant de manera indefinida.
# 9) L’atenció continuada a l’excel·lència tècnica i el bon disseny milloren l’agilitat.
# 10) Simplicitat: l’art de maximitzar la quantitat de treball no realitzat és molt essencial.
# 11) Les millors arquitectures, requisits i dissenys sorgeixen d’equips d’autoorganització.
# 12) A intervals regulars, l’equip reflexiona sobre com ser més eficaç i, a continuació, sintonitza i ajusta el seu comportament en conseqüència.
Aquests principis àgils proporcionen orientació pràctica per als equips de desenvolupament.
Una altra manera d’organitzar els 12 principis és considerar-los en els quatre grups diferents següents:
- La satisfacció del client
- Qualitat
- Treball en equip
- Gestió de projectes
# 1) La nostra màxima prioritat és satisfer el client mitjançant l’enviament continu i precoç d’un valuós programari: Custombviament, els clients estaran encantats de veure lliurar un programa de treball cada sprint en lloc d’haver de passar un període d’espera ambigu al final del qual només ells podran veure el producte.
Aquí es pot definir el client com el patrocinador del projecte o la persona que paga el desenvolupament. L’usuari final del producte també és client, però podem diferenciar-ne els dos ja que l’usuari final es coneix com a usuari.
# 2) Benvingut a canviar els requisits, fins i tot tard en el desenvolupament. Els processos àgils aprofiten el canvi per obtenir l'avantatge competitiu del client: Els canvis es poden incorporar sense massa retards en els terminis generals.
Atès que els equips àgils creuen en la qualitat per sobre de tot, prefereixen incorporar canvis i lliurar segons els requisits del client que evitar canvis i lliurar un producte que no serveixi a les necessitats del negoci.
# 3) Oferiu programari de treball amb freqüència, des d’un parell de setmanes fins a un parell de mesos, amb preferència a l’escala de temps més curta: Això s’encarrega dels equips que treballen en esprint. Atès que els sprints són iteracions temporitzades i ofereixen un programari de treball al final de cada sprint, els clients es fan regularment una idea del progrés
# 4) Els empresaris i els desenvolupadors han de treballar junts diàriament durant tot el projecte: Es prenen millors decisions quan tots dos treballen junts de manera col·laborativa i hi ha un bucle de retroalimentació constant entre els dos per a la correcció del recorregut i l’agilitat del canvi. La comunicació entre els grups d'interès és sempre la clau en l'àgil.
# 5) Construeix projectes al voltant d’individus motivats. Doneu-los l’entorn i el suport que necessiten i confieu en ells per fer la feina. Cal donar suport, confiar i motivar els equips. Un equip motivat és més probable que tingui èxit i lliurarà un producte superior que els equips infeliços que no estan disposats a donar el millor de si.
Una de les maneres de fer-ho és potenciar l’equip de desenvolupament perquè s’organitzi i prengui les seves pròpies decisions.
# 6) El mètode més eficaç i eficaç per transmetre informació a l’equip de desenvolupament i dins d’aquest és una conversa cara a cara: La comunicació és millor i té més impacte si els equips es troben al mateix lloc i es poden trobar cara a cara per debatre. Ajuda a generar confiança i aporta comprensió entre diversos grups d'interès.
# 7) El programari de treball és la mesura principal del progrés: Un programari de treball supera tots els altres KPIs i és el millor indicador de la feina feta.
# 8) Els processos àgils afavoreixen el desenvolupament sostenible. Els patrocinadors, desenvolupadors i usuaris haurien de ser capaços de mantenir un ritme constant indefinidament: Es subratlla la coherència del lliurament. L’equip hauria de ser capaç de mantenir el seu ritme durant la durada del projecte i no cremar-se després dels primers sprints.
# 9) L’atenció continuada a l’excel·lència tècnica i el bon disseny milloren l’agilitat: L’equip ha de tenir totes les habilitats i un bon disseny de producte per gestionar els canvis i produir un producte d’alta qualitat alhora que pot incorporar canvis.
# 10) Senzillesa - L’art de maximitzar la quantitat de treball no realitzat és essencial i és suficient per complir la definició de treball realitzat.
# 11) Les millors arquitectures, requisits i dissenys sorgeixen d’equips d’autoorganització - Els equips autoorganitzats estan apoderats i s’apropien del seu treball. Això condueix a una comunicació oberta i a l’intercanvi regular d’idees entre els membres de l’equip.
# 12) A intervals regulars, l’equip reflexiona sobre com ser més eficaç i, a continuació, sintonitza i ajusta el seu comportament en conseqüència. La superació personal condueix a resultats més ràpids i a una menor reelaboració.
Conclusió
La centricitat en el client i el focus en la comunicació han fet que l'èxit sigui àgil, que és visible avui en dia.
És una tècnica provada amb implicacions no només en el lliurament de programari, sinó també en altres indústries i avui s’ha convertit en una indústria en si mateixa.
El nostre proper tutorial d'aquesta sèrie explicarà més sobre l'equip Scrum juntament amb els seus papers.
Lectura recomanada
- Preguntes en línia sobre Agile Scrum: proveu els vostres coneixements sobre Agile Scrum
- El canvi mental d'un provador àgil: alinear-se amb el manifest àgil
- Kanban vs Scrum vs Agile: una comparació detallada per trobar diferències
- Com oferir funcions de programari d’alt valor en un període curt de temps mitjançant el procés Agile Scrum
- Tutorial SAFe Agile: què és Scaled Agile Framework
- 4 passos cap al desenvolupament de la mentalitat de proves àgils per a la transició amb èxit al procés àgil
- Tutorial JIRA Agile: Com utilitzar JIRA eficaçment per gestionar projectes Agile
- Pràctica de DevOps basada en el manifest Agile (part 2 - bloc 1)