Exploración Ágil

[pic 1][pic 2][pic 3]

1. INTRODUCCIÓN

Bob estaba entusiasmado. El jefe había dicho: "Tenemos que volvernos ágiles" y a Bob le habían asignado la tarea de averiguar los primeros pasos. Había oído el rumor y estaba deseando descubrir qué es exactamente el desarrollo ágil y en qué consiste.

2. PROPUESTAS DE VALOR ÁGILES

2.1 Propuestas básicas

Comenzó con la "Declaración de Independencia" de Agile, el Manifiesto Agile [1] y sus principios de apoyo. En el Manifiesto, encontró las siguientes cuatro propuestas de valor con la afirmación de que los elementos de la izquierda se valoraban más que los de la derecha.

... hemos llegado a valorar:

1.  Colaboración del cliente sobre la negociación del contrato

2. Los individuos y las interacciones por encima de los procesos y las herramientas

3. Responder a los cambios en lugar de seguir un plan

4. Software de trabajo sobre documentación completa

Bob se mostró de acuerdo con las dos primeras propuestas y pensó que la mayoría de los profesionales experimentados aceptarían estas afirmaciones sobre las personas, independientemente de la metodología de desarrollo. Sin embargo, Bob tenía dudas sobre las otras propuestas, especialmente la última.

2.2 Respuesta al cambio

Bob entendió la tercera proposición como un llamamiento a ser conscientes de los cambios y a estar dispuestos a ajustar los planes en consecuencia. Supuso que no decía que Agilest prefería responder a esos cambios directamente causados por la falta de planificación en lugar de hacer la planificación correspondiente.

Bob pensó en una situación en la que un cliente tuviera un profundo conocimiento de los comportamientos necesarios del sistema y sus interacciones. La tendencia ágil hacia la "entrega temprana y continua" parecía implicar que el conocimiento del cliente se obtendría de forma incremental. Esto podría dar lugar a una refactorización innecesaria a medida que el desarrollador profundizara en su conocimiento. A Bob le pareció poco atractiva esta preferencia por la "ignorancia voluntaria", hasta que se dio cuenta de que podía haber encontrado una situación fuera del ámbito del desarrollo ágil. Tendría que averiguarlo.

Bob se preguntó si los agilistas aceptarían un cambio en su Manifiesto cuando éste no comunicara eficazmente.

2.3 Documentación exhaustiva

2.3.1 ¿Qué es la documentación exhaustiva?

Bob no entendió la cuarta proposición. El manifiesto decía "... hay valor en los elementos de la derecha ...". En un artículo sobre el manifiesto, Martin Fowler y Jim Highsmith [2] dicen: "... la documentación exhaustiva no es necesariamente mala ...".

Bob estaba confundido, así que buscó "exhaustiva" y encontró dos definiciones: (1) que incluye todo o todos (2) de amplio alcance. La primera hacía que la definición de "documentación exhaustiva" no fuera atractiva en ninguna situación, mientras que la segunda la dejaba imprecisa. La confusión de Bob se profundizó. ¿Qué es exactamente la "documentación exhaustiva" y cuándo es valiosa, si es que lo es? Cuando la documentación exhaustiva es valiosa, ¿tiene sentido preferir el software de trabajo? Cuando no es valiosa, preferir el software de trabajo tiene poco sentido, por ejemplo... hemos llegado a valorar el software de trabajo por encima de las monedas de madera. Bob se pregunta si el "software funcional" incluye pruebas ejecutables. Más preguntas.

2.3.2 Información económica

Para profundizar, Bob trató de pensar en una frase sustitutiva que nombrara algo que claramente tiene valor. Se decidió por "información económica" con la definición: información mínima necesaria para una comunicación rentable.

Un documento es un relato escrito o un archivo de texto que contiene información. Es una información que se comunica y que tiene valor. Un documento puede tener menos valor que la información que contiene si la información valiosa es difícil de reconocer, por ejemplo, debido a una mala selección (enterrada en información sin valor), una mala expresión o una mala organización. El valor de la información depende tanto de su forma como de su contenido. Una forma deficiente puede aumentar considerablemente el coste, disminuir la comprensión o desalentar el uso. Consideremos la especificación de una compleja expresión booleana en lenguaje natural. Bob sabía que el coste incluía tanto la creación y la gestión como el uso. Para que sea económica, el valor de la información debe ser (mucho) mayor que su coste.

2.3.3 Lo económico depende del contexto

Bob se centró en tres tipos de información económica: requisitos, diseño y uso. Se dio cuenta de que, en todos estos casos, la idea de "información mínima necesaria" es un concepto sensible al contexto que implica la comunicación con las partes interesadas, tanto presentes como futuras. A veces, las fuentes pueden tener información necesaria, pero inadecuada, es decir, por debajo del mínimo.

Decidir si la información es necesaria y mínima requiere conocer la experiencia, la comprensión, las necesidades de información, la disponibilidad de fuentes alternativas y las preferencias personales de las partes interesadas que reciben la información. Los "números mágicos" codificados no son mágicos para el codificador, al menos cuando se escriben. Cinco años después, un programador de mantenimiento puede opinar de forma diferente.

Bob recordó la siguiente ilustración de una presentación sobre la especificación de requisitos [4], en la que se muestra cómo la necesidad de detalles por escrito varía en función de la comprensión inicial de los proveedores y receptores de la información.

Tabla 1. La comprensión debe determinar la cantidad de detalles

PU - Proveedor Comprensión del dominio del problema y de las necesidades y deseos específicos de las capacidades de la solución

...