Durante la formación para ser profesionales del mundo de la informática se enseñan metodologías de ingeniería del software para lo cual, normalmente se, enseñan con cierta profundidad procesos pesados (en contraposición a los ágiles) como métrica o UP. Las metodologías ágiles se suelen nombrar, pero no se profundiza mucho en ellas.
Nunca me han gustado las metodologías pesadas ya que considero que en la mayoría de los casos es más costoso seguir la metodología y escribir la documentación que desarrollar el proyecto.
En contraposición con todo esto existen las metodologías ágiles, que permiten utilizar un esquema de desarrollo mucho más natural.
Utilizando una metodología pesada el ciclo de desarrollo puede ser algo como:
- Entrevista con el cliente para obtener requisitos
- Convertir los datos obtenidos del cliente en una especificación de requisitos (doc1)
- Hacer diagramas de casos de uso que contemplen todas las funcionalidades (doc2)
- Hacer un montón de documentos más (Plan de pruebas,…)
- Presentarle los documentos anteriores al cliente (que en muchas ocasiones no es técnico y no los entiende bien)
- Desarrollar el proyecto
- Desplegar el proyecto
En las metodologías ágiles se busca aligerar la carga que conlleva la documentación, pero también se consigue hablar de manera natural el lenguaje del cliente. El ciclo anterior podría ser:
- Entrevista con el cliente para obtener requisitos en forma de ejemplos (se utiliza un lenguaje cercano al la lógica de negocio del cliente)
- Convertir los ejemplos en tests (esto es código)
- Desarrollar el proyecto verificando que pase los tests
- Desplegar el proyecto
En el primer caso era necesario convertir en explícito los datos entregados por el cliente mediante multitud de documentos. Esto hace que, si los requisitos del proyecto cambian, sea necesario modificar todos los documentos generados con nuevas versiones que reflejen los cambios, con lo cual el coste del cambio va aumentando con el transcurso de los distintos ciclos. En este tipo de metodologías el contrato son los documentos.
En el segundo caso se evita generar documentos para explicitar los acuerdos, requisitos, etc, presentados por el cliente. Acuerdos, requisitos, etc. se reflejan en los ejemplos, que, una vez convertido en tests, son el contrato. Además el contrato es en sí mismo el plan de pruebas (o al menos una parte muy importante de este).
