archivo

Archivos diarios: mayo 13, 2011

En el artículo anterior, se analizaron algunos de los principios que surgen de los cuatro valores o principios fundamentales que se especifican en el manifiesto ágil, en este se va a proceder a analizar los que restan:

– La atención continua a la excelencia técnica enaltece la agilidad.

No se pueden realizar desarrollos ágiles con software desarrollado con mala calidad. La deuda técnica impedirá avanzar en los desarrollos de manera eficiente y productiva ya que se necesitará más tiempo para comprender el funcionamiento de un módulo o de una clase y existirán más riesgos de efectos colaterales en el mantenimiento del software o en su desarrollo mediante iteraciones.

Si se quiere minimizar la documentación, incluso la que se realiza en el código mediante los comentarios es necesario que la claridad del código sea la mejor posible, así como su ejecución técnica. De esta forma los fuentes estarán autodocumentados y no será necesario realizar ajustes en los comentarios conforme la aplicación vaya evolucionando porque la comprensión del código está implícita en él.

– La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.

Una de las virtudes y también, si no se maneja adecuadamente, uno de los grandes defectos de los que nos dedicamos al desarrollo de software lo tenemos en nuestra creatividad. Tenemos por costumbre aportar nuestro granito de arena en los proyectos y en muchos casos lo que hacemos nos es otra cosa que complicar lo que los usuarios (cliente) nos ha solicitado.

Funcionalidades, las justas y necesarias. Complejidad, la justa y la necesaria. Todo lo que vaya más allá de esto es trabajo de más, cuya recompensa será inferior en la mayor parte de los casos al esfuerzo realizado. No debemos olvidar que todo esfuerzo de más que invirtamos en una tarea, es esfuerzo de menos que dedicamos a otras tareas que necesita de ello (en cierto modo es uno de los ejes en los que se sustentan los métodos de producción mediante kanban).

– Las mejores arquitecturas, requisitos y diseños emergen de equipos que se autoorganizan.

La interacción entre personas, la comunicación entre las mismas, la unicidad de los equipos de trabajo favorecen la toma de decisiones. Nadie es tan listo o bueno como para que sus ideas sean mejores que las que proporcionan el resto de personas que participan en el proyecto, donde no llega la perspectiva de uno, llegará la de otro y si no llega la de ninguno seguro que una decisión tomada entre varios tendrá más posibilidades de acercarse más a la realidad (o alejarse menos de ella) que la que toma uno de manera individual.

La integración del equipo de trabajo permite que cada cual pueda aportar más en el área donde sea más fuerte. Esta forma de trabajar favorece el reparto de tareas en función de las habilidades de cada uno, de sus circunstancias personales.

Para ser ágil, es necesario además que los equipos tengan la oportunidad de tomar decisiones. Hay aspectos relativos a la ejecución del proyecto que perfectamente pueden ser tratados y tenidos en cuenta por quienes participan en él. Se podrá estar equivocado o acertado, pero existirá un menor margen del error si las decisiones se toman desde el interior del proyecto que desde fuera, ya que quienes trabajan en el mismo conocen de primera mano la problemática que se está produciendo.

Esto es compatible con la existencia de un marco de trabajo o de una metodología porque todas ellas son o deben ser lo suficientemente abiertas como para dar la oportunidad de realizar ajustes que favorezcan la realización de los trabajos.

– En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

El fracaso es la antesala del éxito. Los errores son un medio para continuar aprendiendo. Todo es susceptible de mejorar, pero para ello es necesario realizar un análisis de lo que se está haciendo lo más objetivo posible, basado siempre que se pueda en métricas que sean evaluables y repetibles.

Las mejoras en los procesos, metodologías, técnicas, decisiones, etc… no llegan de una sola vez, son el resultado de diferentes iteraciones, igual que los desarrollos. Los proyectos son adaptativos, las organizaciones cambian, la tecnología evoluciona, nosotros también.

Nunca se es lo suficientemente experto, nunca se es lo suficientemente bueno, incluso los mayores expertos en ingeniería del software del mundo se equivocan y pueden fallar en proyectos donde nosotros podemos tener éxito y tener dudas en los mismos aspectos en que podamos tenerla nosotros.

El objetivo no es saberlo todo sino en intentar ser cada vez mejor, esto requiere de analizar nuestros resultados, de ser autocríticos y a partir de ahí sacar conclusiones y crecer.

Continuemos con el análisis del manifiesto ágil.