En estos últimos años, se ha ido extendiendo el modelo de desarrollo software llamado Metodología Agile o desarrollo ágil de software, en sus distintas variantes y enfoques: Kanban , Scrum o XP entre otros. Aunque muchos principios son antiguos, y algunos como la Programación Extrema (XP) se pusieron de moda hace años, ha sido últimamente cuando se ha desatado el “furor” por este modo de trabajo.
En el Manifiesto por el Desarrollo Ágil se resaltaron una serie de criterios y ponderaciones
- Individuos e interacciones sobre procesos y herramientas
- Software funcionando sobre documentación extensiva
- Colaboración con el cliente sobre negociación contractual
- Respuesta ante el cambio sobre seguir un plan
- Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
- Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
- Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
- Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
- Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
- El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
- El software funcionando es la medida principal de progreso.
- Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
- La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
- La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
- Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
- A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
 |
| By Dr ian mitchell (Own work) [CC BY-SA 3.0] |
De forma muy simplificada, ¿qué se pretende conseguir?
Pues que en lugar de acordar con un cliente (interno o externo) un proyecto totalmente cerrado, que el cliente no ve hasta que han pasado muchos meses, descubriendo (con horror en algunos casos) en el momento de la entrega que no tiene nada que ver con lo que pensaba, se utiliza una aproximación gradual que el cliente/usuario puede ir siguiendo y orientando.
En lugar de un modelo jerárquico donde un jefe de proyecto o un analista transmite unas decisiones (que en algunos casos pueden ser erróneas), se utiliza un modelo cooperativo de trabajo en equipo, donde todo el mundo (incluido el usuario) aporta y se siente integrado, consiguiendo más calidad y productividad.
Y en lugar de perder demasiado tiempo documentando y actualizando documentación en algunos casos innecesaria, debe emplearse en hacer un código fuente claro y autodocumentado.
Personalmente pienso que el trabajo en equipo y la implicación de todos integrantes de un proyecto es un principio indiscutible, se use la metodología que se use. El tener en cuenta las opiniones de profesionales con distintos enfoques (programador, arquitecto, experto en base de datos, administrador,..) enriquece y permite detectar problemas y orientar mejor el proyecto, teniendo en cuenta la experiencia de cada perfil.
Igualmente la participación del cliente/usuario, evita un efecto “teléfono estropeado” donde el usuario cuenta lo que quiere a un técnico, que lo traduce para otro que lo transmite a otro, hasta que al final el programador implementa algo totalmente distinto.
También parece indiscutible, se use la metodología que se use, la efectividad de revisar el trabajo y el modo de desarrollo, buscando y aplicando mejoras al mismo (tanto a las soluciones como al modo de trabajo), lo que lleva años aplicándose en cadenas de montaje industriales de Japón con el nombre de Kaizen.
Sin embargo hay otros principios que aunque inicialmente parecen muy razonables, sin embargo pueden provocar problemas. Como en cualquier herramienta, disciplina o metodología, los problemas provienen de dos fuentes: mal uso de la metodología y problemas intrínsecos a la metodología, que en algunos casos se entremezclan.
Algunos problemas potenciales
Quizá el primero que surge es el de coste y plazos. Antes de empezar un proyecto debe conocerse su viabilidad y fechas de disponibilidad. Si el alcance (requisitos) y la solución no están muy cerrados no es posible conocer si el proyecto es viable ni si podrá entrar en producción en plazos. Por tanto, o se conocen (casi) todos los requisitos inicialmente (lo que choca con la “alegría” en “recibir requisitos en épocas tardías”), o son requisitos menores o se corre el riesgo de irse en plazos y costes tanto o más que en desarrollo “tradicional”.
Hay otro riesgo relacionado con el suministro gradual de requisitos. Como se citaba en el párrafo anterior, hay requisitos que pueden implicar más trabajo, pero hay requisitos que pueden implicar cambios sustanciales en la solución o herramientas usadas. Hace años las aplicaciones se desarrollaban en un lenguaje de programación u otro, almacenaban los datos en una base de datos y el grueso del trabajo era “programación” sin más. Pero los proyectos son cada vez más complejos, se exigen más funcionalidades, y los volúmenes son mayores. Esto ha provocado que raramente se desarrolle absolutamente todo desde cero. Lo habitual es que se utilicen framework de desarrollo, que se utilicen muchas librerías o bibliotecas y que se integre múltiples productos y servidores en un solo proyecto. Los requisitos de “última hora” pueden provocar que se descubra que alguno de los lenguajes/productos/librerías/tecnologías elegidos no sirven porque no cubren esa función o no ofrecen el rendimiento esperado, lo que puede provocar:
- el rehacer gran parte del desarrollo para integrar otro producto/librería,
- el tener que comprar licencias de otro producto,
- el requerir infraestructura y servidores que no estaban previstos,
Otro punto potencialmente peligroso es el de las “entregas periódicas”. Un proyecto medianamente complejo requiere normalmente la construcción (o selección) de marcos de trabajo, librerías, clases, etc. comunes a todo el proyecto y que luego facilitan el desarrollo y su calidad. Pero esos elementos iniciales en la mayoría de los casos son componentes muy “técnicos”, no son entregas “funcionales” por lo que puede ocurrir que los Sprint iniciales, o bien se hacen mucho más largos que el resto o bien la “revisión del proyecto” puede ser ver un fichero jar de java, que “no muestra nada” inteligible.
Quiero con ello resaltar la importancia de estas primeras fases en que se pone los cimientos y estructura del proyecto, y durante los cuales no hay nada que mostrar a un usuario no técnico. El forzar un desarrollo que muestre periódicamente “algo funcionando” puede llevar a desarrollos mal estructurados y mal enfocados, provocando el clásico desarrollo “espagueti” de Visual Basic que aunque muestra rápidamente pantallas, se hace imposible de mantener y propenso a errores al tener “todo conectado con todo”.
Finalmente, respecto la documentación, hay dos elementos “peligrosos”:
- se debe dar prioridad a “software funcionando frente a documentación”.
- “El método más eficiente y efectivo de comunicar información es la conversación…”,
Desde luego documentar lo que un método o función hacen, puede documentarse en el Javadoc del mismo, no tiene sentido elaborar una documentación redundante y con riesgo de incoherencias o desactualización.
Pero muchas veces la documentación más importante NO está en el código fuente (entre otras cosas porque puede afectar a varios fuentes, a la forma de instalar un producto o de usar una librería o a otros elementos que no son el código fuente en sí). La documentación debe hacer referencia a la arquitectura general, la forma recomendada de uso, documentar porqué se optó por un producto o implementación. Sin esa información documentada adecuadamente, una segunda fase del proyecto (o la corrección de errores), que además podría incorporar un equipo nuevo, puede tomar decisiones incorrectas.
Respecto a la transmisión de información oral, evidentemente ayuda a explicar algunos aspectos y a debatir propuestas en modo “tormenta de ideas”, pero el escribirlas ayuda a formalizar y sistematizar las ideas y propuestas y formaliza el análisis y debate de los puntos, generando reuniones más eficaces. “Las palabras se las lleva el viendo”, y adicionalmente el texto escrito y formal permite evitar interpretaciones diferentes por distintos integrantes de un equipo.
En función de las reflexiones anteriores, podría deducirse que para proyectos donde el grueso está decidido (o incluso implementado) y queda pendiente el interfaz de usuario, o se trabaja sobre una nueva iteración, parece especialmente adecuado, mientras que para proyectos totalmente nuevos, con mucha indefinición funcional y tecnológica, el riesgo con una metodología ágil es mayor, especialmente si no se utiliza adecuadamente.
Como en cualquier herramienta (física o intelectual) debe utilizarse con criterio y analizando en cada caso los riesgos y necesidades. Al final, entre el blanco y el negro hay toda una gama de grises, y se debe elegir cual es el “color” adecuado, aplicando la metodología y los criterios de la forma adecuada y sin “fundamentalismos”.
 |
| No Brain | by Pierre-Olivier |
Como indicaba un letrero sobre una maquinaria pesada “CAUTION: This machine has no brain, use your own” (“Precaución: esta máquina no tiene cerebro, use el suyo propio”)
No hay comentarios:
Publicar un comentario