archivo

Archivos Mensuales: enero 2014

La reducción de costes no va en dirección opuesta a la generación de valor.

Tal vez el problema podría estar inicialmente en una mala gestión de los recursos económicos disponibles, si bien, si no se cambian comportamientos, enfoques y estrategias a todos los niveles, muy difícilmente se conseguirá que la reducción de costes vayan de la mano de una mayor capacidad de generar valor.

Y eso ha pasado una y otra vez en este período de crisis, en el cual, se ha optado por lo fácil que es recortar, sin que exista un plan alternativo que tenga como objetivo hacer las cosas mejor y siempre es posible, si se tiene una mínima capacidad de autocrítica, de hacer las cosas mejor.

Para Michael Bolton (traducción libre): “Si estás implacablemente centrado en la reducción de costes,rápidamente te convertirás en alguien ajeno a las oportunidades que permitan aumentar el valor”.

Esta reflexión va en la línea de lo comentado anteriormente, es decir, si tu objetivo único es recortar, sin centrarte en el crecimiento, enfocarás tu atención en eso y no en los cambios necesarios para invertir la tendencia de la organización porque la misma tendrá, tal vez, menos costes pero seguirá sin crecer y, lo más probable, es que como sigue sin hacerse nada para adaptarse al nuevo contexto, la situación no hará más que empeorar, lo que llevará inexorablemente a la realización de nuevos recortes. Hasta que ya no quede más que recortar.

En el campo de los proyectos de desarrollo de software, muchas organizaciones están optando por recortar la inversión. De entrada no es ni bueno ni malo, racionalizar la inversión, habría que analizar cada situación en particular.

El problema nos lo encontramos en el momento en que a proyectos concretos se les mete la tijeras, sin que vaya de la mano de una recorte proporcional en las expectativas. Ese desequilibrio solo puede moderarse a costa del esfuerzo de los que participan en el proyecto, que incluso haciéndolo muy bien, no podrán, en todos los casos, hacer un producto satisfactorio porque precisamente los recortes han obligado a hacer un sobreesfuerzo y a renunciar a ciertos patrones de calidad que han impactado en la capacidad de generar valor en cada iteración del producto.

Me parece muy interesante la siguiente cita de David Gilbert: “La cantidad de formato y nivel de detalle aplicado a un plan de pruebas es inversamente proporcional a la cantidad de buenas pruebas reales representadas por dicho plan”.

Esta reflexión es aplicable al resto de documentación generada en un proyecto de desarrollo de software.

La calidad no se mide al peso ni por lo bonito que sea su envase. Es cierto que en ciertos ámbitos esto vende pero en el ámbito de un proyecto su valor no es relevante si no se ha hecho pensando en que sea práctico, útil y acorde a las necesidades.

Un plan de pruebas farragoso no se ejecutará de manera adecuada, en la mayoría de los casos, en muchos de ellos por simple agotamiento o aburrimiento de la persona que debe realizar las tareas de testing y en otros muchos porque entre tanto forraje se perderá lo realmente relevante.

Veamos una posible implementación Scrum-dominante. Dentro del flujo de trabajo que se defina en un tablero Scrum, supongamos que se definen un conjunto de fases tan simple como: Sin iniciar, en construcción, testing y finalizada, y para una o más de ellas se establece un límite de tareas abiertas de manera que si se alcanza el límite ninguna tarea más puede entrar en esa fase, lo que hace que los esfuerzos se deban enfocar en eliminar ese cuello de botella: deben salir tareas para que puedan entrar otras. De esa manera se pretende detectar problemas lo más próximo posible a su origen para tratar de resolverlos lo antes posible (filosofía lean).

Veamos ahora una posible implementación Kanban-dominante. En este caso, el sprint está abierto, pueden ir entrando nuevas tareas siempre y cuando no se sobrepase el WIP definido.

Llegado un punto (se puede denominar punto de ajuste) tendremos que ir cerrando la iteración, lo que obligará a centrarnos en aquellas tareas en ejecución que se consideren más prioritarias, lo que implicará que determinadas tareas ya iniciadas pasen a ser trabajadas en futuros sprints. Ese punto de ajuste deberá realizarse con suficiente antelación porque de lo contrario puede haber un mayor número de tareas que queden abiertas y/o que dentro de las que ya se ha comenzado a trabajar haya algunas prioritarias que queden sin ser atendidas.

Hemos visto dos posibles implementaciones, en función de que se pretenda que predomine Scrum o Kanban. También existen otras en las que pueden convivir ambas estrategias, una de ellas puede consistir en que el sprint se realice según las prácticas de Scrum y por otro lado, tener reservada cierta capacidad del equipo de trabajo para resolver incidencias u otro tipo de peticiones que tengan que ser atendidas con urgencia sin alterar los compromisos adquiridos en la iteración (pila de sprint).

Esta capacidad se regiría por prioridades y limitando el WIP.

Esta última implementación me parece muy interesante y es bastante efectiva. Puedes empezar a practicarla sin definir WIP (aunque ya no estaríamos aplicando Kanban) y más adelante empezar a ajustar límites en determinadas tareas del flujo.

Scrumban es el resultado de combinar prácticas de Scrum con Kanban. Sería más ortodoxo decir que es la combinación de Scrum (puro) con Kanban pero la realidad es que no son muchos casos en los que organizaciones o equipos aplican Scrum al pie de la letra y no es porque no exista voluntad de hacerlo, sino porque la realidad de muchos proyectos lo impide.

Es cierto que la Scrum Guide dice que si solo se implementan partes concretas de Scrum no se puede considerar Scrum, y lo respeto, por ese motivo prefiero hablar generalmente de prácticas de Scrum en lugar de utilizar de manera rotunda la palabra Scrum.

No obstante, en este artículo cuando la utilice, me gustaría que lo entendieráis como su conjunto de prácticas (roles, eventos, etc…), independientemente de que las utilice todas o no o haya alguna sobre la cual se aplique un enfoque diferente, ya que resulta más interesante entrar a analizar cómo se puede combinar con Kanban.

Realmente y como os he insistido en muchas ocasiones, no podemos considerar una herramienta, una metodología o una estrategia por muy interesante y práctica que ésta sea como para que todo nuestro trabajo gire alrededor de ella. Le damos el valor que se merece pero nunca por encima de las necesidades de un proyecto, sin hiciéramos lo contrario no estaríamos siendo ágiles.

Hay muchas implementaciones posibles de Scrumban porque se trata, como dice, Henrik Kniberg de obtener lo mejor de ambas. Os recomiendo la lectura de su libro: “Kanban y Scrum, obteniendo lo mejor de ambos”.

Simplificando, podríamos decir que se trataría de añadir el concepto de gestión visual del flujo de trabajo (si bien esta práctica se aplica prácticamente de serie en muchos equipos que utilizan Scrum) y el WIP (Work in Progress) a Scrum, con el objeto de detectar cuellos de botella dentro de cada sprint. Sin embargo, depende mucho de la implementación que se vaya a realizar, ya que si un equipo está habituado a trabajar con Kanban, podría decirse que Scrumban se trataría de añadir el concepto de sprint a Kanban.

También existen estrategias que combinan en flujos de trabajo diferentes ambos enfoques.

En el siguiente artículo veremos algunos ejemplos de implementaciones de Scrumban.

En su día escribí un artículo sobre esta práctica de testing. Hace poco leí una cita de Bob Martin que resume perfectamente los objetivos que se persiguen con el testing exploratorio (traducción libre): “El testing exploratorio es un esfuerzo creativo en el que los testers exploran el comportamiento del sistema en un intento de caracterizar sus comportamientos; tanto documentados como no documentados”.

El testing unitario (y en extensión otras prácticas de testing automatizadas) no es suficiente como tampoco lo es el que se basa en planes de pruebas porque ambos dejan o pueden dejar espacios del sistema sin cubrir y que pueden ser importantes.

Es lo que tienen los defectos, cuando menos oportunos son, antes aparecen. De ahí que me parezca muy acertada la siguiente cita de Michael Stahl: “Los bugs irreproducibles se vuelven altamente reproducibles justo después de la entrega al cliente”.

Siempre es posible invertir más esfuerzo en la detección de defectos pero es necesario calibrar (todas las partes) qué impacto tiene la ocurrencia de determinados defectos en el software y la disponibilidad económica para hacer ese trabajo.

Es preferible siempre menos pero con más calidad y más garantías, sin embargo, muchos no lo ven así, prefiere llegar a lo que tenían pensado que debería ser el producto sin ponerse a analizar que completo no es lo mismo que correcto.

Cuanto más crítico sea el sistema más exhaustivo se tiene que ser con la localización de defectos y más se debe invertir en su detección lo más próxima posible a su origen (tanto de manera automática como manual), eso es muy importante y se debe tener en cuenta a la hora de hacer estimaciones ya sea como parte de cada historia de usuario o como parte de personas ajenas al equipo que desarrolla el sprint.

Trabajar en planes de pruebas que traten de recoger todas las posibles acciones del usuario requeriría tanto esfuerzo que perfectamente podría consumir todo el presupuesto del proyecto.

El esfuerzo en testing (en general y no centrándome en los planes de prueba que tienen una utilidad parcial y concreta y en los cuales no creo mucho) debe ser siempre proporcional a la criticidad del software y siempre deben existir unos mínimos.

Se deben detectar y corregir los defectos lo antes posible y evitar que lleguen a producción, sin embargo, es tal la casuística que puede provocar un usuario que resulta muy complicado que ninguno traspase esa frontera, de hecho, Elisabeth Hendrickson lo resume perfectamente en la siguiente cita: “Las acciones de los usuarios son siempre variables”, no obstante y con independencia de eso, se debe intentar que el número de defectos críticos que lleguen a producción tiendan a cero y para ello es fundamental darle al testing la importancia que se merece.