Chess - antoniomartel.com

Archivos de Autor: Antonio Martel

Deadline Driven Development

I have recently read the article «Deadline Driven Development» from Simón Muñoz. Quite a captivating one.
As in TDD, we create tests before developing the solution, he suggests setting a deadline before estimating, and then doing only what can be done until that deadline.
There are multiple perks to that approach: product managers avoid scope creep, and adding unnecessary features to the product being built. Other than that, developers will reduce the overengineering or creating too complex solutions, far beyond what is needed.
We will be reducing waste by building applications or services with just the two or three most important uses cases . Then, we can release our service, and see what was useful, what our clients require now, when they can use the product. From that point we can make more informed decisions on investing more, and better (or to cancel the product).


See the link to the original blog post (in Spanish): Deadline Driven Development by Simón Muñoz.

Mi experiencia con SAFe

En muchas empresas de tamaño grande han estado teniendo problemas con la adopción de Scrum. Tienen múltiples equipos trabajando en diversos productos interconectados y cada vez que tienen que acometer un desarrollo en el que hay dependencias distribuidas entre esos equipos, los tiempos de entrega se alargan indefinidamente.

Es por eso que un porcentaje alto de esas empresas han decidido adoptar SAFe (Scaled Agile Framework Enterprise) buscando escalar la agilidad al tamaño de sus proyectos. Cuando me enfrenté a esta forma de trabajar por primera vez, lo hice algo preocupado porque fuera un monstruo demasiado grande de digerir y se tragara la posible agilidad que pudiéramos tener.

Lo cierto es que tiene algunas cosas buenas: el Product Owner debe aprobar cada desarrollo (lo que suele implicar que todo el mundo revise bien su trabajo para evitar un rechazo) y los Planning Interval cada tres meses te fuerzan a tener en mente los objetivos a largo plazo que tiene la empresa.

Por otro lado, esa planificación tan a «largo» plazo puede hacer que se pierda algo de flexibilidad. Además de que las reuniones de coordinación entre todos esos equipos de trabajo hacen que el tiempo empleado en reuniones (y la multidud que asiste) se multiplique por varios órdenes de magnitud.

Desde luego, no ha estado mal la experiencia. Quizás, cuando la vea dentro de unos meses, valore haber ganado, o perdido, otras cosas de las que ahora no me doy cuenta.

¿Sprints de solo una semana?

Hace algún tiempo me preguntaron por la duración de los sprints en los equipos en los que trabajaba, y les contesté que eran habitualmente de dos semanas. Habíamos hecho alguno de solo una semana, pero nos parecía demasiado overhead de reuniones y eventos de Scrum. También alargábamos a tres semanas durante las vacaciones de verano y Navidad, pero teníamos la sensación de perder de vista en qué semana del desarrollo estábamos.

Ya no veo tan mal los sprints de una semana. Con los de dos vemos siempre que la gráfica de burndown se mantiene plana durante todo el sprint, y baja solo durante los dos últimos días de la iteración (ya conocemos la Ley Parkinson: el trabajo se expande hasta que ocupa por completo el tiempo destinado para su realización).

Con solo una semana por sprint, la gráfica sufre el mismo problema, pero en la mitad de tiempo. Además es más fácil acertar en la velocidad del equipo y lo que puede comprometerse: tienes una mejor idea de lo que puedes hacer en solo cinco días (y reaccionar si surge algo imprevisto). Cuestión de seguir probando.

Features versus bugs

Cuando ponemos una nueva features en producción o liberamos nueva release, aparecerán inevitablemente algunos errores de cuando en cuando. Si no los solucionamos sino que seguimos desarrollando nuevas features, seguirán habiendo un porcentaje nuevo de bugs. Llegará un momento en el que dedicaremos más tiempo a poner parches y solucionar errores urgentes en producción que a desarrollar nuevas features o historias de usuario, que es lo que mantiene a nuestro producto en el mercado.

Si llegamos a una nueva empresa, revirtamos esa tendencia. Enfoquémonos en solucionar deuda técnica eligiendo una lista de los principales dolores de cabeza y dediquemos un par de historias de usuario cada sprint a solucionarlas. Una vez solucionado, ataquemos el siguiente problema según el tormento que nos cause.

Cuando haya pasado un tiempo veremos que ya no hay tantas llamadas urgentes, que los desarrolladores no están todo el día apagando fuegos y tienen disponibilidad (además de concentración, foco, y menos interrupciones) para desarrollar nuevas funcionalidades, que ahora sí, aportarán valor al producto.

Pasado un tiempo, confiemos en que no mucho, deberíamos ver una gráfica como esta (si no la tienes, deberías creártela, te podría sorprender lo mucho que estás dedicando a waste, en lugar de a nuevo valor).

Si tu trabajo es comerte una rana

Mark Twain dijo una vez: si tu trabajo es comerte una rana, es mejor hacerlo a primera hora de la mañana. Y si tu trabajo es comerte dos ranas, es mejor comerse la más grande primero. Si quieres ser productivo y no dejarte las cosas esenciales detrás, haz las cosas más importantes o difíciles primero. Verás si eres capas, si el proyecto es viable. Luego tienes el resto del día (o del proyecto) libre para mejorar y con la tranquilidad de haber resuelto los principales problemas primero.

Al principio de la mañana, el proyecto o de la tarea, estás más despierto, más animado, más concentrado. Todavía tienes recursos por delante para reaccionar si es más difícil de lo esperado o se requieren otras acciones. Al final el mismo, estarás comprometido con las fechas de entrega, más estresado y con más prisas. No harás las cosas importantes bien o las dejarás a medio cerrar. Puede sucederte como en ese clásico meme de las redes sociales en las que se ven los cuartos traseros de un caballo dibujados con gran exactitud y precisión, pero a medida que el dibujante avanza hacia la parte delantera, debido a la presión por entregar, va eliminando trazos y simplificando los detalles hasta entregar solo una caricatura de la cabeza del caballo.

Siempre hay cosas en el trabajo que nos resistimos a hacer. Son más difíciles, requieren de más dedicación, o tenemos miedo de hacerlas mal y que seamos criticados por ello. Asegúrate de que en el equipo de trabajo hay «coraje» para enfrentarse a ellas y acometerlas de una vez. Coraje, entendido como en Extreme Programming, surge donde se ha creado un ambiente en el que no hay miedo a ser castigado o criticado por cometer un error.

A todos nos cuesta comernos las «ranas» de nuestro trabajo. Es algo completamente normal. ¿No has visto alguna vez, que cuando en el backlog hay diversas tareas y una de ellas es un trago más amargo que las demás, todas las historias de usuario se terminan excepto la más compleja? Pasará una y otra vez al siguiente sprint casi sin tocar donde volverá a suceder lo mismo con las nuevas tareas añadidas. Hasta que no eliminas las «distracciones» y los hitos fáciles de conseguir del sprint backlog, no conseguirás que se decidan a atajar el problema.

Una vez has acabado con sapos y culebras, todas las nuevas tareas en tu To-Do list te parecerán un plato mucho más fácil de digerir.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad