NEXUS24 UPC

Jaume Moral, membre de l’equip MailToTicket

El dilluns dia 18 de gener he assistit a la píndola formativa sobre com millorar l’eficiència del nostre equip impartida pel Sylvain Loubradou (@SylvainPAM18) i l’Òscar Poncelas (ex membre de VIACOM i facilitador de l’equip Banc del Temps UPC) i organitzada pel Programa Nexus24. El Sylvain ens ha ofert la seva expertesa en metodologies àgils de forma totalment desinteressada. Així que abans de res, és de justícia agrair-li el seu esforç.

Definint els temes

La píndola no ha començat amb un temari definit, sinó que cada equip ha hagut d’apuntar en Post-Its quins eren els problemes amb que s’havien trobat a l’hora de treballar col·laborativament i també quins eren els aspectes positius que havien trobat.

Un cop penjats els Post-Its en un panell i intentar agrupar-los en temes, hem vist que d’una forma o altre, tots topàvem amb les mateixes pedres al camí. Bàsicament, els problemes més importants han estat:

• Dispersió d’eines i llocs on col·locar la informació.
• Diferències de coneixements entre diferents perfils de l’equip.
• Bons usos del Trello.
• Comunicació amb l’exterior.

Tot i la falta de temps hem atacat alguns d’ells i també hem profunditzat una mica més en Scrum.

Dispersió d’eines

Quan hem començat a parlar d’eines, hem vist que tothom feia servir una gran varietat: Trello, Slack, WhatsApp, Google Groups, Google Drive, Dropbox, Blogger, GitHub, correu…

M’ha agradat molt la norma del 4: no fer servir més de 4 eines per evitar la dispersió i en tot cas si es fan servir, que estigui plenament justificat.

També he trobat molt correcte el consell de tenir una eina com a vertebradora de les altres. Per exemple, posar en un Trello els enllaços a la resta d’eines perquè així no estigui perdut. Crec que és una cosa que tots hem fet de forma més o menys inconscient i hem vist que no érem els únics.

I no menys important: tenir unes regles clares de per a que utilitzar cada eina i que aquestes regles estiguin consensuades, escrites i consultables per tothom. Si es decideix com a equip que els documents estaran al Drive, no pot ser que algú vagi per lliure i els posi com a adjunt al Trello. Amb unes normes clares, tot és més clar.

Scrum

Ha estat especialment important la part dedicada a Scrum o com s’ha encarregat de recalcar, el «més o menys Scrum» que cada equip ha convertit en la seva forma de treball. Especialment clar ha estat la definició clara i concisa dels rols per aquells que tenen problemes amb el vocabulari de Scrum:

• Scrum Master: és el pilot. No decideix el rumb, però si es el responsable que l’avió arribi on s’ha decidit. Procura per que l’equip pugui fer la feina.
• Product Owner: decideix, priorita i valida la feina a fer. És un rol normalment reservat al client o algú que faci d’enllaç amb el client. Com als equips Nexus 24 no hi ha un usuari clar, una possibilitat és que l’equip sigui el propi Product Owner, però això requereix disciplina, ja que el Product Owner pensa en el què es farà i perquè, no en el com es farà.
• Històries d’usuari vs. tasques. Una historia d’usuari és una funcionalitat del producte (què volem fer) i es divideix en tasques (com ho farem). Són les tasques, que de fet és la feina concreta, les que es planifiquen en un sprint.
• Les retrospectives. És la primera cosa que es deixa de fer i realment és la més important. És on podem solucionar els problemes utilitzant una sèrie de tècniques per evitar una confrontació directa.
• Les sessions de demo. S’han de convertir en una forma de recompensa de la feina feta, obertes a tothom qui sigui possible. Una oportunitat de sortir de la rutina i de no caure a l’efecte «roda de hàmster» que provoca que l’equip es cremi i ens convertim després en zombis desmotivats.

A destacar que hem vist una visió de Scrum molt «humana» que no oblida que som persones. Scrum ens ajuda a la disciplina i a fer unes interaccions entre els membres el més fluïdes possible.

Organitzant bé el Trello

Una bona forma de treballar és tenir dos taulers actius per projecte. El primer tauler conté històries d’usuari. Potser diferents columnes per temes o per prioritats. També com a tauler principal del projecte podem afegir una columna amb enllaços a altres eines del projecte.

D’aquest tauler, quan planifiquem un sprint en podem extreure les històries triades cap a un altre tauler. De fet, podem moure les històries al nou sprint per tenir clar quines són les que estem fent i d’aquestes, planificar i prioritzar les tasques en les que es descomposen. En aquest tauler de sprint, són les tasques les que mourem cap a la dreta, no les històries en sí. Això ho podrem fer (si ho creiem convenient) al tauler principal.

Conclusions

Com a conclusió crec que aquesta píndola ha estat tremendament interessant. Molt orientada a la pràctica, 100% aplicable i amb un formador que realment ens ha fet arribar els conceptes. Així que només ens resta dir, gràcies Sylvain. Espero que ens tornem a veure!