archivo

Archivos Mensuales: abril 2013

La sobreproducción se entiende como la realización de trabajo de más que no resulta necesario en estos momentos. Tiene las siguientes implicaciones:

– Esfuerzo realizado que tal vez no sirva para nada, ya que una vez que el cliente evalúe lo que realmente necesita puede modificar total o parcialmente todo el conjunto de funcionalidades de más que se han realizado.

– División de la atención entre lo realmente importante y lo que no lo es. Ese esfuerzo que se dedica a lo que no es prioritario puede afectar a la calidad, al grado de terminación y a la tasa de errores de lo que sí lo es.

– El usuario, cuando se le presenta la solución en su conjunto (en su versión actual), también pierde el enfoque pudiéndose perderse en detalles que están lejos del objetivo principal de la versión.

– Incremento de la complejidad del sistema tanto a nivel técnico (deuda técnica) como de la usabilidad.

Trabajo de más es resistencia de más para poder adaptarnos al cambio, ya que nos resta flexibilidad. A lo anterior hay que sumarle el coste que se ha invertido en desarrollar funcionalidades que lo mismo nunca se llegan a utilizar o deben ser sensiblemente reajustadas, por lo que disminuye la proporción entre valor y esfuerzo.

¿Qué se necesita?, ¿esto?, es lo que desarrollamos. Cualquier elemento de más es sobreproducción y corremos diferentes riesgos: que no podamos recuperar su inversión, que nos genere costes adicionales: en el caso de la producción de elementos físicos tenemos un ejemplo en los costes de almacenamiento y en el de los elementos lógicos lo tenemos en una mayor deuda técnica, complejidad funcional, etc… (además de haber desviado la atención de otras funcionalidades o tareas más prioritarias).

El concepto es sencillo, ¿lo es su implementación?. Vamos a centrarnos en el mundo de los proyectos de desarrollo de software:

– Requiere que el cliente o área usuaria estén implicados, de manera que se centren en priorizar de manera adecuada lo que necesitan, ajustándose a la capacidad de producción que tiene en cada momento el equipo de desarrollo.

– Requiere que el equipo de desarrollo respete el compromiso al que se ha llegado con el cliente, realizándose ajustes siempre por consenso entre las partes.

¿Cuáles son los riesgos?

– Que no exista una previsión sobre valles de producción, lo que puede dar lugar a que se desarrollen funcionalidades de más (algunas de ellas no prioritarias, otras no necesarias y otras que podrían cambiar por su dependencia con funcionalidades todavía no maduras), con tal de no tener a parte del equipo parado. Si se prevén, es posible hacer una gestión adecuada del equipo, de manera que se pueden dedicar a realizar actividades en otros proyectos (o incluso otras actividades en el mismo proyecto que seleccionadas sin la improvisación de tener que dar trabajo pueden ser beneficiosas: refactorización, mejoras de rendimiento, en la infraestructura de desarrollo, etc…).

– Que no exista una previsión sobre cimas de producción, lo que puede provocar que no se pueda atender a la demanda del cliente.

– Que el alcance de los trabajos sea de gran magnitud, ya que la probabilidad de que se hayan desarrollado funcionalidades que no se necesitan (o que incluso no deban aparecer en la versión del producto que se entrega) es mayor, además es muy posible que sea necesario perfeccionar muchas de ellas a través del feedback y la dependencia que puede existir entre ellas puede provocar el mantenimiento en cadena de varias de ellas.

Esto hace que una estrategia interesante sea reducir los tiempos entre versiones o lo que es lo mismo, las iteraciones no deben ser de gran duración. Esto permite, además, que los problemas que puedan producirse durante el desarrollo del sprint sean más sencillos (por regla general) de tratar.

– El cliente puede tener nuevas necesidades y la cadena de producción (sprint) está ocupada con otras tareas. Tendrá que esperar a que termine la iteración o aplicarse otras medidas en el caso de que no se pueda esperar. El hecho de no alterar los trabajos ya iniciados tiene su ventaja en el hecho de que el equipo está centrado en una serie de actividades, lo que le permite ser más productivo.

En el caso de que el desarrollo quede bloqueado, la aplicación de esta estrategia de trabajo, una vez que está interiorizada por el equipo y por la organización, hará que se centren los esfuerzos en desbaratar ese bloqueo, ya que de lo contrario no se podrá atender a nuevas demandas, ya que la capacidad de trabajo está comprometida en una serie de tareas que todavía no se han completado.

Es importante diferenciar entre reconocer la necesidad y crearla. Lo primero es positivo, lo segundo solo es interesante si tu misión es vender productos o servicios.

En el desarrollo de software menos suele significar más e incrementar la complejidad de un sistema por incorporarle necesidades que no son reales no da buenos resultados.

Reconocer la necesidad es tener la capacidad de interpretar las expectativas del usuario. Es muy complicado conseguirlo a la primera, requiere su tiempo, se necesita conocer al usuario, a su negocio, realizar varias iteraciones y a partir de ahí empezar a crecer.

Una conocida cita de Charles Eames dice lo siguiente: “El reconocimiento de la necesidad es la primera condición para el diseño”.

La clave, por tanto, es la intención. Una cosa es que el universo de expectativas tarde en conocerse (e interpretarse) y otra es que desde un primer momento no intentemos hacerlo lo mejor posible con la información que tengamos. Si no se tiene suficiente información para acometer un desarrollo, aunque sea una primera iteración, lo mejor es esperar a adquirir algo más de conocimiento para empezar a reconocer cuáles son esas necesidades.

Os recomiendo la lectura del artículo: “Preparando el primer sprint“.

El método MoSCoW es una técnica de priorización de requisitos basada en el hecho de que aunque todos los requisitos se consideren importantes es fundamental destacar aquellos que permiten darle un mayor valor al sistema, lo que permite enfocar los trabajos de manera más eficiente.

Lo que la diferencia de otras técnicas tradicionales como por ejemplo calificar los requisitos como de prioridad alta, media o baja es que en este caso la escala utilizada tiene un significado intrínseco, de manera que el usuario responsable de asignar la prioridad conoce el efecto real que producirá su elección.

M (Must): Requisito que tiene que estar implementado en la versión final del producto para que la misma pueda ser considerada un éxito.

S (Should): Requisito de alta prioridad que en la medida de lo posible debería ser incluido en la solución final, pero que llegado el momento y si fuera necesario, podría ser prescindible si hubiera alguna causa que lo justificara.

C (Could): Requisito deseable pero no necesario, se implementaría si hubiera posibilidades presupuestarias y temporales.

W (Won’t): Hace referencia a requisitos que están descartados de momento pero que en un futuro podrían ser tenidos de nuevo en cuenta y ser reclasificados en una de las categorías anteriores.

Esta clasificación puede ser modificada durante el proceso de desarrollo y definirse, en el caso de desarrollos iterativos incrementales, prioridades a nivel de iteración.

No sabemos de todo, no tenemos las respuestas a todas las preguntas, no somos infalibles, no dominamos todos los contextos. Cuanto antes asumamos esto menos errores evitables cometeremos por nuestro exceso de suficiencia.

La confianza en uno mismo no consiste en considerarte por encima de todo y de todos sino por saber que no eres ni mejor ni peor por buscar las respuestas donde podrías encontrarlas.

Escucha lo que te tengan que decir, aunque no estés de acuerdo. Después es posible que sigas sin estar de acuerdo pero por el simple hecho de escuchar has tenido que poner en contraste tus ideas con otras diferentes y eso aporta valor.

El desarrollo de software es un trabajo colectivo en el que todos tienen la capacidad (y deben aportar). Más percepciones de la realidad amplía el abanico de posibilidades y el número y calidad de las respuestas. Lo importante es sacar el proyecto adelante no que la idea decisiva la hayas dado tu.

Por último os dejo la siguiente reflexión de Jerry Weinberg que puede resumir el contenido de este artículo: “Cuando no eres terriblemente inteligente, te ayuda ser un buen oyente”.

Incluso siéndolo debes ser siempre un buen oyente.

Entregar rápido permite que tanto usuarios como desarrolladores aprendan antes, que los problemas salgan a relucir pronto, que el valor del producto se acelere, que la visión del producto cobre forma y que nuestra respuesta al cambio sea adecuada.

Ahora bien, entregar rápido debe modularse a las características del proyecto en el que nos encontremos, del equipo de personas que trabaja en él, la capacidad de trabajo que se puede absorber, su contexto y el estado actual del desarrollo.

Hay proyectos donde se puede considerar entregar rápido definiendo sprints de 2 semanas y otros que pueden ser igual de rápidos con sprints de 6. Depende. Lo mejor es adaptar la solución al proyecto y no el proyecto a la solución.

Entregar rápido funcionalidades incompletas no presenta ventajas. Entregar rápido funcionalidades con errores críticos es incluso peor. Entregar rápido con baja calidad en el código a la larga es devastador. Entregar rápido funcionalidades que aportan poco valor produce poco beneficio a esta estrategia e incluso puede ser perjudicial si tenemos que llevar de lastre funcionalidades no decisivas mientras se desarrollan las que verdaderamente importan.

Una buena práctica o estrategia ejecutada a ciegas probablemente produzca resultandos opuestos a los esperados.

La versatilidad y la polivalencia son características muy apreciadas en los integrantes de equipos de trabajo ágiles. Si además, se promueve la rotación de tareas, se entiende que cualquiera está preparado para cualquier actividad que se presente en el proyecto, dotando al equipo de una mayor eficiencia y de una gran flexibilidad que resulta muy útil a la hora de afrontar las diferentes contingencias que, seguro, vamos a encontrar.

Sin embargo, no se debe menospreciar la especialización. No es ágil prescindir a priori de la idea de tener determinados especialistas en el proyecto (en general no es ágil crear restricciones sin analizar la situación).

Un analista es un especialista. Su misión es interpretar las expectativas del usuario, trasladarlas al equipo de proyecto, recoger el feedback y vuelta a empezar. No es un intermediario, sino un facilitador tanto para usuarios como para desarrolladores, no es alguien que está en el medio, sino alguien que está con ellos. Esa es la visión de este perfil en un proyecto ágil.

En un enfoque clásico, la división en procesos hace que los analistas sí que tengan una mayor separación con respecto a los programadores, aunque dependerá mucho de cómo se haya organizado el proyecto, ya que es frecuente también que presten soporte en el proceso de construcción.

Pero incluso en estos casos, la diferencia con un proyecto ágil se encuentra en la intensidad. En el enfoque clásico los analistas dedican un mayor esfuerzo en la fase de captura de requisitos y análisis, en los enfoques ágiles su esfuerzo se mantiene constante, ya que mientras se ejecuta una iteración, preparan la materia prima para la siguiente (interviniendo en ambas tareas con la dedicación que se precise en ese momento en el proyecto).