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).

El cono de incertidumbre de Steve McConnell viene a expresar algo que ya sabemos y es que efectivamente se acierta más cuanto más conocimiento tenemos del proyecto, su contexto, sus problemas, de las personas que participan, etc…

Ese conocimiento se adquiere conforme se va desarrollando el proyecto, con el proceso de definición de las historias de usuario, su construcción, el feedback y las retrospectivas. Cualquier otra actividad de carácter teórico puede producir mejores estimaciones, de base no lo niego, pero siempre limitada y siempre menor que la que se adquiere con la experiencia.

Entonces, ¿de qué valen las estimaciones que se realizan en la definición del proyecto y que tienen como objeto asignarle un presupuesto? Para definir un punto de partida e interesa que el mismo no esté muy equivocado, si bien lo realmente importante es la actitud que cliente (sobre todo el cliente) y el proveedor tienen sobre esas condiciones de partida. Si la orientación es al contrato, a su lectura literal, procura acertar (al cliente porque la satisfacción de sus expectativas respecto al producto final dependerá del acierto y al proveedor porque tendrá que prepararse a sufrir y perder mucho dinero).

En cualquier caso es conveniente dedicar tiempo a hacer la mejor estimación posible con la materia prima disponible, teniendo en cuenta que hay que saber cuándo parar porque si se pretende llegar a un conocimiento muy detallado, además del tiempo que se requiere para ello, se estará suponiendo que después la línea de desarrollo va a ir en esa dirección y lo mismo (lo más probable) se van produciendo cambios conforme el usuario vaya teniendo más claro qué es lo que quiere.

Las estimaciones iniciales no van a ser buenas, las finales estarán más ajustadas y no solo es cuestión de conocimiento técnico y funcional, sino que nos habremos dado cuenta de varios errores que se cometen sistemáticamente con las estimaciones (y que no sería de extrañar que los volvamos a repetir en el siguiente proyecto): considerar condiciones ideales, dejarse llevar por el optimismo, ser demasiado permeable a las presiones externas para admitir más capacidad o para producir estimaciones sin un conocimiento más en detalle de la historia de usuario o del requisito, exceso de ambición, etc…

Volviendo al cono de incertidumbre, hay que tener en cuenta que Steve McConnell lo planteó sobre una secuencia de fases que bien podrían ajustarse a un ciclo de vida clásico o en cascada, si bien podría ser extrapolable, al menos conceptualmente a otros enfoques de desarrollo de software.

McConnell señala que las estimaciones iniciales con un conocimiento insuficiente sobre la visión del producto (visión abstracta del sistema a desarrollar) se suelen desviar hasta cuatro veces por encima o por debajo de lo que viene a ser el esfuerzo real. En el momento en que se avanza más en la definición de la visión del producto, la desviación se ajusta hasta dos veces por encima o por debajo. Vuelve a bajar en la definición de requisitos (un 50%) y así sucesivamente hasta la entrega.

Me parece muy interesante la siguiente reflexión de Mike Beedle (traducción libre): “El coraje en Scrum no es algo visible o tangible. Tampoco es una especie de heroísmo romántico. En su lugar, consiste en tener el coraje y la determinación de hacerlo lo mejor que puedas. Es la obstinación de no darse por vencido y cumplir los compromisos. Este tipo de coraje es valiente, no glorioso”.

Beedle lo asocia a Scrum, sin embargo su cita me parece interesante porque refleja una actitud que va más allá de la utilización de una determinada estrategia de desarrollo de software y que desde mi punto de vista es absolutamente acertada: la actitud por intentar cumplir unos compromisos, por hacerlo lo mejor posible, de dar lo mejor de nosotros para conseguir esos objetivos.

Esto supone en primer lugar un compromiso con nuestro, con nuestro equipo y con nosotros mismos de lo contrario como mucho llegaremos a ser cumplidores (incluso con una cierta eficiencia) pero falta el empuje necesario para vencer determinadas resistencias que nos encontraremos en el proyecto y que requieren lo mejor de nosotros mismos, así como la capacidad de levantarse y recuperarse ante las dificultades que vayan surgiendo.

Como comenta Beedle no se trata de sacar la varita mágica y convertir en sencillo lo difícil sino de saber que nos encontramos ante un reto que exigirá lo mejor de nosotros mismos y que para superarlo requerirá mucho esfuerzo. ¿Qué después no es para tanto? Mejor, pero eso no quita que en el siguiente proyecto nos encontremos con mayores dificultades.

No es malo, antes al contrario, es muy positivo tener buenos deseos, ya que supone una declaración de intenciones. El problema lo tenemos cuando las intenciones se quedan solo en palabras, algo que todos sabemos se produce con demasiada frecuencia.

Es fácil hablar y escribir, mucho más difícil actuar.

Para Mary Poppendieck: “Un enfoque disciplinado para la resolución de problemas hace que un equipo pase de los buenos deseos a los nuevos conocimientos a las contramedidas específicas y los resultados permanentes”.

Y es cierto que la actuación requiere disciplina pero también determinación, mucha determinación.

Muchos proyectos fracasan por la falta de determinación y disciplina, perdidos en un sinfín de reuniones, en papeles mareados entre las partes u olvidados como adjuntos en correos electrónicos y en discursos teóricos que pretenden conquistar el mundo pero que tienen menos fondo que una caja de cerillas.