o “Qué nos trajimos de la CAS de este año”
En nuestros equipos la CAS 2012 todavía resuena.
El año pasado, tras la CAS 2011 nos trajimos 5 SuperTips o MegaTrucazos que hicieron darle una vuelta entera a cómo trabajábamos: ideas puestas en común entre todos y que han dado grandes resultados. Tanto, que parece que las llevemos haciendo desde siempre. Os pego aquí abajo lo que presentamos internamente. (Nota mental: Hacer post con retro)
Este año volvimos a poner en común en un evento interno que llamamos “En busca del SuperTIP de la CAS 2012” las mejoras que queríamos meter en Kaleidos.
El resultado fue fantástico, hicimos los deberes y salieron propuestas de todo tipo: deuda técnica, prácticas ágiles, mejora continua comunicación, … Hay propuestas incluso muy parecidas porque la condición era que no se podían compartir antes del evento, ¡teníamos que ganar!
¡Veamos el resultado!
SUPERTIPS DE DEUDA TÉCNICA
Tolerancia CERO a bugs
Pablo Alba @_pabloalba_Cada bug detectado se tiene que solucionar, con la posible excepción de que se decida convivir con él (el clásico “bug reconocido”). Por lo tanto, si el bug se va a acabar solucionando, ¿por qué esperar? A más se tarde en solucionar, más código está escrito encima del bug, y más difícil y costoso de arreglar es. Por lo tanto, el objetivo debe ser cero bugs. Cada vez que se detecte un bug, debe convertirse en la tarea de máxima prioridad. Esto a la larga es muy beneficioso para la calidad del proyecto, y para los tiempos de desarrollo.
Backlog (lista) de deuda técnica
Iván López @ilopmarBasándonos en la regla de “cada vez que toques un trozo de código, déjalo mejor que como te lo encontraste” y en que ocasiones no hay tiempo para hacer esos refactors que son tan necesarios la idea es ir apuntando en un backlog, lista, wiki,… todo lo que sabemos que hay que mejorar en el futuro. Esa lista puede estar estimada y priorizada por el equipo de desarrollo y en cada sprint se puede ir abordando alguna tarea de refactor. Así, el código que vayamos construyendo “por encima” no irá acumulando toda la deuda técnica. Como sabemos que al final la deuda técnica hay que pagarla, lo mejor es tenerla localizada y pagarla cuanto antes.
“La mazmorra” o backlog de deuda técnica
Andrés Moya @amoyafossEn la CAS vi la definición de deuda técnica como “aquello que hace que los cambios cuesten más de lo que deberían”. La deuda ocurre normalmente cuando se cede a la presión de las fechas entregando algo antes de tiempo, a cambio de “pedir prestado” tiempo del futuro. Si tenemos un lugar donde apuntar estas carencias, ayudamos al principio scrum de detectar y visibilizar lo antes posible: llega el sprint, entregamos en fecha, todo funciona… pero ha aparecido “un bicho” en la mazmorra, que es subterránea, no se ve, pero está ahí, y debe ser eliminado cuanto antes. Al gestionar esta lista como un backlog, podemos priorizar las deudas según su impacto en el coste de desarrollos futuros. Esta forma de presentación ayuda a hacer entender al cliente de dónde ha salido esa deuda y por qué merece la pena dedicar tiempo a suprimirla.
SUPERTIPS DE PRÁCTICAS AGILES
Formar al PO
Teresa de la Torre @tdelatorrehSiempre nos estamos quejando del Product Owner… “que si tal no crea user stories”, “que si cual metió un bug que no es un bug”, etc… Es hora de eliminar el cuello de botella por nuestra parte, así que… ¡formemos al PO!. Dedicando un tiempo al PO al inicio del proyecto podremos explicarle bien qué es scrum, como utilizar redmine, como priorizar el backlog, que son las user stories, que son bugs, cómo perjudican los emails masivos con peticiones nuevas en el transcurso del sprint, y tantas otras cosas… Dedicar un tiempo a la formación del PO nos ahorrará muchos problemas a lo largo del proyecto.
Lucy
Pablo Ruiz @diacriticaLucy es un simulacro de paso a producción en una etapa muy temprana del desarrollo. Para el negocio proporciona visión temprana del producto, para desarrollo obliga a aplicar las mejores prácticas de calidad y para explotación, introducir documentación y control de releases pronto. Es muy compatible con enfoque Lean Startup y refuerza la promesa de Scrum.
Puedes ver esta idea desarrollada en el blog de Kaleidos.
90/50
Yamila Moreno @yamila_morenoA la hora de definir historias de usuario, deberíamos estar atentos y detectar aquellas que encajen en el patrón 90/50 que consiste en resolver el 90% de una funcionalidad definida en el 50% del tiempo estimado para el total. Son tareas cuyo ajuste fino final puede no aportar demasiado y obliga a los equipos a dedicar mucho esfuerzo en una parte del producto que puede no se crítico. Casos típicos son ciertas tareas administrativas que fácilmente se gestionan fuera de la aplicación, o páginas de pocas visitas en las que no hay que invertir tanto tiempo en hacer que sean muy dinámicas y configurables. Con esta información, podemos ofrecer al cliente la opción más ‘barata’ de forma que podamos añadir user stories. Junto a esta alerta, tenemos que ver rápidamente qué funcionalidades son core y necesitan varias iteraciones y mucho ajuste fino.
1/3
David Barragán @bamedaConsiste en ofrecer, una vez transcurrido el primer tercio del proyecto aproximadamente, un producto que pueda ser puesto en producción en modo beta privada/friends&family. Para ello se deberá focalizar el esfuerzo en definir US que no abarquen toda la funcionalidad pero que si garantice aquella que pueda resultar más deseables al usuario final, dejando para más adelante la “implementación fina” de las mismas. El equipo de desarrollo generará menos deuda técnica y más código de calidad abordando problemas más pequeños (“divide y vencerás”). El cliente obtendrá un producto usable que recoge gran parte de la funcionalidad deseada, del que podrá obtener feedback para dedicar el resto del trabajo en mejorar aquellas funcionalidades que resulten más útiles, añadir otras que no habían sido contempladas y evitar el gasto de innecesario de recursos en desarrollar aquellas que realmente no van a resultar atractivas ni útiles.
MEJORA CONTÍNUA
OpenSpace mensual sobre el estado de Kaleidos
Alejandro Alonso @_superalex_En Kaleidos la comunicación y la transparencia sobre el estado de la compañía es parte de nuestra filosofía, aún así es fácil perderse en el día a día y que se pueda perder un poco la visión general de la empresa. Desde management queremos dar un paso más adelante en esta linea y la idea es organizar los últimos viernes de cada mes un openspace en el que sean los propios miembros de Kaleidos qué temas tratar y cuánto tiempo dedicarles a cada uno. Queremos conseguir dar todavía más visibilidad a las inquietudes del equipo, a la labor de management y al funcionamiento/estado general de la compañía.
Comunicación y Asertividad
Daniel Herrero @dahgni Primitivo Cachero @primicacheroLa base de un buen equipo es la comunicación, y en el día a día se pueden dar situaciones que por no saber transmitir bien las ideas haga que se degrade el ambiente de equipo y de trabajo. Daniel propone una aproximación cercana y formal de cómo se han de comunicar los miembros del equipo utilizando herramientas y prácticas para que la información fluya, como levantar la mano cuando se eleva el volumen o nos salimos de contexto. Primitivo apoya además la realización de** talleres de comunicación y asertividad** específicos para mejorar el diálogo.
Be A Master
Antonio de la Torre @adelatorrefossPara disminuir el bus-factor, para hacer un equipo multidisciplinar, para avanzar en el camino de la maestría, es necesaria la formación, todos estamos de acuerdo. ¿Pero cómo se llega a ser un verdadero Master? Ese secreto solo está al alcance de los que van por delante en el camino. Be A Master consiste en recopilar información de las armas necesarias, empezando por los libros para iniciarse, siguiendo por los blogs para estar al día, los twitter a seguir, los congresos a los que no puedes faltar… Todos tenemos en nuestra empresa un experto en la tecnología, ¡que la comparta!
Conclusión
Usando nuestro infalible y calibrado aplausómetro, el ganador fue… Alejando Alonso con su_ “OpenSpace mensual sobre el estado de Kaleidos”_.
Alejandro se ha llevado el millón de euros, pero qué duda cabe que el trabajo ha merecido la pena. Hemos estado atentos en la CAS, hemos analizado lo que hacemos, le hemos dado al tarro y hemos compartido. Todas las ideas se implementarán qué duda cabe.
La duda es… ¿qué diremos de estos SuperTIPs dentro de una año?