SCRUM una eina clau

 

Lectura 1: “Reuniones de planificación de Sprint que duran, y duran …”

Existeix el dubte de què fer quan veiem que una reunió necessita allargar-se: acabar-la a mitges o allargar-la. La metodologia Scrum opta per acabar-la, tenint com a conseqüència un Sprint més complicat. És per aquest sofriment que l’equip aprendrà que les reunions s’han de complir i, per tant, la planificació de la propera reunió serà més eficient. També els semblarà bé allargar el temps de reunió; sense la mala experiència es queixarien més.

Aquest mètode té molt sentit en el món Agile, ja que sempre es busca la millora contínua i el fet d’escollir complir el temps de reunió reforça aquesta idea. Es forma un equip més unit que entèn el que fa i es millora la manera de treballar a llarg termini.

Lectura 2: “estimación de tiempos usando planning poker”

L'estimació del temps és important perquè ajuda en la planificació de projectes i l’assignació de recursos, i és una tasca d'equip perquè els membres tenen diferents àrees d'experiència i participen en diferents parts del projecte. La tècnica de planning poker consisteix en que cada membre de l'equip té una baralla de cartes amb números que representen la seva estimació de temps (en punts d'història) i les col·loca boca avall sobre la taula. Després, es donen la volta al mateix temps per evitar que un membre de l'equip influeixi en les estimacions dels altres. Si hi ha molta discrepància entre dues estimacions, l'equip discuteix les diferències i intenta construir una imatge comuna del treball necessari per a la història. Aquest procés es repeteix fins que l'estimació de temps convergeix i tots els membres de l'equip estimen aproximadament el mateix per a aquella història. A més, també existeixen algunes cartes especials de la baralla, com la "0" que indica que la història ja està feta o la "Tassa de cafè" que significa que es necessita un descans.

Pel que fa a la meva reflexió, crec que la tècnica de planning poker és una excel·lent manera d'estimar el temps en equip. Sovint, els membres poden tenir diferents punts de vista per a la realització d’una tasca, i la tècnica de planning poker garanteix que totes les perspectives es considerin i es discuteixin abans que s'arribi a una estimació final. També evita que una persona influeixi en les estimacions dels altres, el que pot ser útil per evitar prejudicis. En general, crec que la tècnica de planning poker pot ajudar a millorar la comunicació i la col·laboració en l'equip i, a més, millorar la qualitat del projecte.

Lectura 3: “històries tècniques”

Les històries tècniques són aquelles tasques o requisits que són necessaries per a un correcte entorn de desenvolupament, però que no aporten valor immediat al Cap de Producte.

Alguns exemples d'aquestes històries poden ser: instal·lar un servidor de compilació continua per estalvi i optimització del temps; crear documentació respecte procediments complexos o escriure una definició del disseny general; netejar codi; actualitzar versions del programari de seguiment d'errors…

És important encabir aquestes tasques en els "sprints", a fi de millorar processos. Per fer-ho, cal intentar arribar a un acord amb el Cap de Producte, perquè tot i ser una persona sense una visió tècnica pugui donar valor a aquestes tasques. A través del diàleg es poden considerar els següents punts:

1. Transformar/redefinir aquests requisits en històries normals amb un valor de negoci mesurable.
2. Fer d'aquesta tasca una subtasca d'una altra història que hi pugui estar relacionada.
3. Tenir una llista d'històries tècniques independents de la pila general de tasques, i negociar amb el Cap de Producte la realització d'aquestes progressivament.

Lectura 4: “Tratando con tardones”

Tenir una guardiola que s’omple amb multes per arribar tard és un bon mètode per tractar amb els impuntuals. S’intenta fomentar la responsabilitat i el compromís emb els horaris. Aquests diners es poden emprar en sortides de grup. Tot i així, no es vol arribar al punt de multar en situacions extraordinàries com una boda o una cita amb el metge.

Hi ha gent, però, que poden sentir angoixa amb aquesta tècnica i els pot fastidiar la productivitat. La cultura té impacte en aquest aspecte. És per això que s’ha de conèixer la gent de l’equip i en quina situació es troba. També és veritat que un grup on la gent és puntual no necessita d’una política de multes.

Una alternativa podria ser considerar incentius positius en lloc de negatius. És a dir, enlloc d’una multa, reconèixer el fet d’arribar d’hora o fins i tot tenir petits premis per a aquests. Hem de teni present que l’objectiu final és afectar positivament la moral de l’equip i a la vegada fer que aquest sigui eficient.

Lectura 5: “Tratando con 'no sé qué hacer hoy'”

A vegades, membres del grup de treball es poden trobar en la situació de no saber què fer, de no saber en què contribuir. En tal cas, el Scrum Master pot ajudar-los suggerint-los idees, com per exemple que es juntin en una feina ja existent o, com a últim recurs, donar-ho tot per enllestit, cosa que farà saltar les alarmes i les diferents persones es preguntaran realment si ja està tot fet.

Personalment, considero que aquest enfocament és molt efectiu, ja que l'Scrum Master ajuda els membres de l'equip a sortir del bloqueig d'una manera no invasiva, fomentant la col·laboració i la creativitat per trobar solucions i continuar avançant a l'esprint. També em sembla important que l'Scrum Master tingui en compte el nivell d'importància i habilitats de cada membre de l'equip en assignar tasques o emparellar-los amb altres membres, per assegurar-se que la feina es faci de manera eficient i efectiva. En general, considero que l'enfocament de Scrum és molt útil per millorar la productivitat de l'equip i garantir que s'assoleixin els objectius de l'esprint en temps i forma

Lectura 6: “Por qué insistimos en que todos los Sprints acaben con una demo”

En general, una demostració exitosa d'un projecte té múltiples beneficis, com ara obtenir reconeixement per a l'equip, obtenir feedback dels interessats, fomentar la interacció entre diferents equips, i obligar a l'equip a acabar les tasques que tenen pendents. A més, si un equip es veu obligat a fer una demostració, encara que no tinguin gaire cosa per mostrar, això pot ser una mena de "medicina amarga" que els impulsarà a treballar més dur per al següent sprint.

Personalment, crec que la demo és una part crucial de la metodologia àgil i pot ser una eina valiosa per al desenvolupament d'un projecte. La demo permet que l'equip mostri la seva feina i rebre feedback, el que pot ajudar a identificar problemes aviat en el procés i fer ajustaments necessaris. A més, la demo pot ser una font de motivació per a l'equip, ja que els permet veure el progrés que han aconseguit i obtenir reconeixement pel seu treball. En general, crec que la demo pot ser una forma efectiva de garantir que l'equip estigui en el camí correcte i estigui treballant de manera eficient cap a la finalització del projecte.

Lectura 7: “Descansos entre Sprints”

Molts de nosaltres som addictes a ser productius. Cal dir que es tracta d'una addició estranya, però real. Per aquest motiu alguns de nosaltres ens deixem el terme descans pel camí. Si sempre et trobes amb necessitat de produir, la realitat és que al final la qualitat de la producció empitjorarà.

No tal sols pel benestar del desenvolupador de software, sinó que el Cap de producte i la resta de components de l'equip també es trobaran digerint moltíssima informació que necessitaran reposar. Per aquest motiu resulta innecessari i ineficient el solapament de Sprints.

Per això resulta interessant introduir descansos abans de començar un nou Sprint. El temps de descans el poden invertir els desenvolupadors de múltiples maneres com investigant sobre API o noves tecnologies o programar un projecte personal com a hobby. Aquest temps de descans se li anomena 'dies de laboratori'. En la lectura aquest descans de Sprint era el primer divendres de cada mes. És important que tot l'equip descansi a l'uníson de forma que el descans rebi la importància que necessita.