Hacer SCRUM es como jugar a fútbol.

Todo el mundo sabe hacerlo pero sólo unas pocas personas lo hacen bien.

Euskaraz?

Hoy aprenderemos de la mano de Iván Salazar, responsable del desarrollo de nuestro nuevo producto Mairu, como aplicamos esta metodología ágil en el equipo de Mairu dentro de Hodeia y las dificultades, beneficios y experiencias vividas en el proceso.

Para una persona que nunca ha escuchado este concepto, ¿Cómo lo describirías?

Lo describiría como una forma de organizar el equipo de forma que el cliente pueda ir viendo el desarrollo de forma más iterada. Cada semana, cada dos semanas o cada mes eso según se vaya planificando. Y, bueno, al final mejora la productividad a la hora de desarrollar. 

Como responsable de este nuevo producto que estamos haciendo en Mairu, ¿Cómo se aterriza este concepto que has explicado teórico de la metodología scrum en el día a día? ¿Cómo os organizáis? ¿Cómo se hace este control de las iteraciones que has dicho?

Vale pues en nuestro caso en Mairu, organizamos sprints bisemanales y, bueno, es bastante estándar a lo que propone la misma metodología. Tenemos una planning, en la que definimos los PBIs que queremos hacer en ese sprint en función de la capacidad del equipo. Luego unas dailys diarias para, bueno, especificar que vamos a hacer durante el día y que hemos hecho en el día anterior y luego una retro y una demo en la que haya participado el product owner. Ve los resultados y luego, aparte sacamos propuestas de mejora para hacer más eficiente el trabajo del equipo.

Lo que estas planteando suena guay, pero... las primeras semanas o las primeras interacciones entiendo que serían un poco más complicadas. ¿Cómo fueron las primeras semanas de implementar esta metodología tan Silicon Valley, tan guay de desarrollo? 

Pues, bueno es acostumbrarse. En nuestro equipo, la peculiaridad es que ninguno de los integrantes del equipo, incluido yo, había trabajado con esta metodología, bueno la había llevado a la práctica. Lo habíamos trabajado, estudiado en la universidad… pero era la primera vez que lo estábamos llevando a la práctica. 

Entonces, tienes que adaptar la metodología a la forma de trabajar del equipo. No lo puedes aplicar de forma estricta porque al final es una teoría que esta impuesta, pero, al final, depende mucho del tamaño del equipo, de la forma de ser del equipo, de la gente que trabaja en remoto… de muchas variables que, al final hacen que lo tengas que adaptar si quieres que funcione bien. De hecho, llevamos un año desarrollando y aún vamos haciendo cambios en la forma de organizarnos. 

Y, por ejemplo, a groso modo a los cambios más significativos, ¿Podrías hacer un resumen de... cómo estaba el planning cuando se empezó scrum y que habéis cambiado ahora a mejor? Así, como dos, tres cambios.

Pues nosotros al principio, por ejemplo, lo aplicábamos de forma muy estricta. Me refiero, las plannings se llegaban a alargar mucho porque hacíamos la estimación tarea por tarea desvanándola bien, haciendo incluso el análisis en la propia planning que es algo que hemos externalizado, me refiero, ahora que lo hacemos antes de la planning para que, un pequeño equipo del desarrollo lo haga sin tener que participar todo el equipo.

Y te diría que se han agilizado mucho las reuniones dentro de la metodología scrum. Las planning igual al principio que tardaban cerca de tres horas… ahora ya suelen tardar entre media hora o una hora. Y bueno, las demos y las retros también, porque al final también es normal que haya más propuestas de mejora, pero cuando ya tiene más experiencia trabajando junto el equipo al final nos conocemos todos, ya hemos adaptado la metodología, entonces, se hace todo mucho más rápido. 

O sea que igual, en ese sentido, uno de los... no errores, pero cosas que no salían tan bien al principio era que estabais casi más tiempo planeando que casi trabajando o implementando. 

Si, te diría que como no teníamos mucha experiencia a la hora de estimar al final igual… intentábamos destinar demasiado tiempo a la estimación cuando luego llevado a la práctica no era tan importante. Ahora al final como todo, cuando el equipo tiene cierta experiencia estima de forma más exacta, entonces se coge más velocidad a la hora de hacer estas reuniones. 

¿Cuál dirías que es como el mayor beneficio? Por ejemplo, desde que empezamos con scrum ahora somos capaces de...

Pues yo te diría que… saber las prioridades del sprint y trabajar de manera más organizada. Al final si no te organizas para saber las prioridades el problema que tienes es que pasados tres, cuatro días, te va a surgir otra cosa que vas a querer hacer y vas a dejar todo a medias. En cambio, de esta forma vas a definir los tres, cuatro, cinco PBIs que hay que realizar de forma prioritaria en el sprint y hasta que no lo termines no lo vas a modificar. 

Si tuvieses que volverte un año atrás y vieses a ese little Iván sin experiencia en scrum, ¿Qué le dirías? En plan... pues céntrate en o cuidado con. Así una o dos ideas/consejos clave. 

Yo igual le diría que… dedicase más tiempo a describir las especificaciones de los PBIs y hacer el análisis previo porque es el principal fallo que cometimos. Pecábamos de ir directamente a programar sin definir esas especificaciones antes y al final muchas veces acabábamos improvisando. Entonces a veces es mejor no ir tanto a la programación y trabajar más inteligente porque luego se hace más productivo el tiempo que estás programando.  

¿Igual delimitar el marco de actuación cuando la metodología es nueva, no? En plan, delimitar las acciones de cada uno de los integrantes para que ya en el futuro cuando tengamos esa inercia así poder no centrar tanto tiempo el planning. 

Si, yo te diría un poco saber exactamente qué funciones o que especificaciones tiene que tener, los criterios de aceptación e incluso el diseño. El diseño muchas veces al desarrollador le decimos que funcionalidad tiene que tener, pero no como se tiene que ver y al final eso a él le genera muchas dudas de cómo llevarlo a cabo.

Entonces… algo que hicimos pasado dos, tres meses fue empezar a hacer mockups en Adobe XD. Algo así muy básico que hacía yo, pero eso, quieras que no, aunque no fuese exacto a lo que se tiene que llevar a la práctica, ayuda mucho al desarrollador porque ya tenía una primera idea de lo que los product owner tenían en mente. Y aparte, a la hora de definir las especificaciones con los product owner, vean visualmente lo que quieren hacer y entonces se concretan mejor las especificaciones. 


SCRUM EGITEA FUTBOLEAN JOLASTEA DA.

Denek dakite hori egiten, baina gutxi batzuek bakarrik egiten dute ondo.

Gaur, Mairu produktu berriaren garapenaren arduradun den Iván Salazarren eskutik, metodologia arin hori Hodeiko Mairu taldean nola aplikatzen dugun ikasiko dugu, baita prozesuan bizi izan diren zailtasunak, onurak eta esperientziak ere.

Kontzeptu hori inoiz entzun ez duen pertsona batentzat, nola deskribatuko zenuke?

Taldea antolatzeko modu gisa deskribatuko luke, bezeroak garapena modu zorrotzagoan ikus dezan. Astero, bi astean behin edo hilero, planifikatzen den heinean. Eta, beno, azkenean produktibitatea hobetzen du garatzeko orduan.

Mairun egiten ari garen produktu berri honen arduraduna zaren aldetik, nola lurreratzen da eguneroko lanean scrum metodologiaren kontzeptu teoriko hau? Nola antolatzen zarete? Nola kontrolatzen dira aipatu dituzun iterazioak?

Beraz, gure kasuan, Mairun, bi asteko esprintak antolatzen ditugu, eta, beno, nahiko estandarra da metodologia berak proposatzen duenerako. Plangintza bat dugu, esprint horretan egin nahi ditugun PBIak taldearen ahalmenaren arabera definitzen dituena. Gero, eguneko daily batzuk, egunean zehar egingo duguna eta aurreko egunean egin duguna zehazteko, eta, ondoren, produktu ownerrak parte hartu duen retro eta demo bat. Emaitzak ikusi, eta, gero, hobekuntza-proposamenak egin, taldearen lana eraginkorragoa izan dadin.

Planteatzen ari zarenak guay dirudi, baina... lehenengo asteak edo lehenengo elkarreraginak, nire ustez, konplexuagoak izango lirateke. Nolakoak izan ziren hain garapen gidoia den Silicon Valley metodologiaren lehen asteak?

Ba, beno ohitura hartzea da. Gure taldean, taldekide bakar batek ere, ni barne, ez zuen metodologia horrekin lan egin, beno, praktikan jarri zuen. Lan egin genuen, unibertsitatean ikasi genuen… baina lehen aldiz ari ginen lanean.

Orduan, metodologia taldearen lan egiteko erara egokitu behar duzu. Ezin duzu hertsiki aplikatu, azkenean inposatuta dagoen teoria delako, baina, azkenean, taldearen tamainaren, taldearen izateko moduaren, urrunetik lan egiten duen jendearen eta abarren mende dago, eta aldagai horien ondorioz, egokitu egin behar duzu ondo funtzionatzea nahi baduzu. Izan ere, urtebete daramagu antolatzeko moduan aldaketak egiten eta egiten.

Eta, adibidez, aldaketa esanguratsuenei groka, laburpenik egin dezakezu... nola zegoen plangintza scrum hasi zenean eta orain hobeto aldatu dituzuenean? Horrela, bi, hiru aldaketa.

Bada, guk hasieran, adibidez, oso zorrotz aplikatzen genuen. Esan nahi dut planning-ak asko luzatzen zirela ataza bidezko ataza kalkulatzen genuelako eta ondo desegiten genuelako. Azterketa ere egin genuen planningean bertan, eta hori kanporatu egin dugu. Orain, plangintza egin aurretik egiten dugu, garapen-talde txiki batek egin dezan, talde osoak parte hartu gabe.

Eta esango nizuke asko bizkortu direla bilerak scrum metodologiaren barruan. Hasierako plangintzak hiru ordu inguru behar izaten zituen… orain ordu erdi edo ordubete behar izaten dute. Eta beno, demoak eta atzerapenak ere bai; izan ere, azken finean, normala da hobetzeko proposamen gehiago egotea, baina taldean esperientzia handiagoa duenean denok elkar ezagutzen dugu azkenean, metodologia egokitu dugu, orduan dena askoz azkarrago egiten da.

Beraz, agian, alde horretatik,... ez erroreetako bat, baina hasieran hain ondo ateratzen ez ziren gauza bat zen ia lanean edo inplementatzen baino denbora gehiago ari zinetela planeatzen.

Bai, esango nizuke azkenean berdin zenbatesteko orduan esperientzia handirik ez genuenez… saiatu ginen denbora gehiegi ematen zenbatespenerako, gero praktikan jarri ez genuenean. Orain, azkenean, dena den, taldeak esperientzia jakin bat duenean, zehaztasun handiagoz pentsatzen du, orduan abiadura handiagoa hartzen du bilerak egiteko orduan.

Zein da onura handiena? Adibidez, scrum-arekin hasi ginenetik, orain gai gara...

Ba nik esango nizuke… esprintaren lehentasunak zein diren jakitea eta modu antolatuagoan lan egitea. Azkenean, lehentasunak zein diren jakiteko antolatzen ez bazara, hiruzpalau egun igaro ondoren, egin nahi duzun beste zerbait sortuko zaizu, eta dena erdi bana utziko duzu. Hala ere, esprintean lehentasunez egin behar diren hiru, lau, bost PBIak definituko dituzu, eta amaitu arte ez duzu aldatuko.

Urtebete lehenago itzuli beharko bazenu eta scrum-ean esperientziarik ez duen little Ivan horretara bazoaz, zer esango zenioke? Planean..., bada, ekin edo kontuz. Hala, funtsezko ideia/aholku bat edo bi.

Nik esango nioke… denbora gehiago eman beharko lukeela PBIen zehaztapenak deskribatzen eta aurretiazko azterketa egiten, hori baita egiten dugun akats nagusia. Zehaztapen horiek aurrez zehaztu gabe programatzera joatekotan geunden, eta, azkenean, askotan inprobisatzen genuen. Orduan, batzuetan hobe da programaziora ez joatea eta adimentsuago lan egitea, programatzen ari zaren denbora gero eta emankorrago bihurtzen baita.

Nola mugatu jarduera-esparrua metodologia berria denean, ezta? Planean, kide bakoitzaren ekintzak mugatzea, etorkizunean inertzia hori dugunean planning-a hainbeste denboran ez zentratzeko.

Bai, nik esango nizuke zehatz-mehatz zer funtzio edo zehaztapen izan behar dituen, onartzeko irizpideak eta are diseinua ere. Diseinuak, askotan, funtzionaltasuna izan behar duela esaten diogu garatzaileari, baina ez ikusi behar den bezala, eta, azkenean, horrek zalantza asko sortzen dizkio garatzaileari hori nola egin behar den jakiteko.

Orduan… bi, hiru hilabete igaro ondoren, Adobe XDn zipriztinak egiten hasi ginen. Nik egiten nuen horrelako zerbait oso oinarrizkoa, baina horrek, nahi ez, praktikan jarri behar denera zehatza ez bada ere, asko laguntzen dio garatzaileari, lehen ideia bat baitzuen produktu ownerrek zer zuten buruan. Eta, horrez gain, produktu-ownerrekin zehazpenak definitzean, ikusi zer egin nahi duten, eta orduan hobeto zehazten dira zehaztapenak.