Después de años de experiencia, puedo decir que he participado en muchos proyectos y en cada uno de ellos hemos usado metodologías diferentes. Mi opinión y mi experiencia es que se debe buscar un punto de equilibrio entre diferentes metodologías. No se debe estar ni en una metodología en Cascada ni en Code and fix ni en un Scrum riguroso. En mi opinión una metodología Scrum es un punto intermedio, pero no debemos ser rigurosos, y tener la capacidad de adaptarnos al cliente, y ser cuidadosos en utilizar Scrum en proyectos Fix Price.
Al final el cliente es la parte más importante de nuestros proyectos. Debemos tener la capacidad de adaptarnos al entorno del Proyecto. No debemos perder el tiempo en una Documentación Extensa e innecesaria, y tampoco podemos desarrollar sin Análisis, Requisitos, Prioridades… La documentación debe ser útil, pertinente y necesaria.
Con respecto a la metodología de trabajo, mi consejo y mi “Gran Lucha”, es la aplicación de El Principio KISS (Keep It Simple, Stupid!), «Manténlo sencillo, ¡Estúpido!». Es una recomendación de uso de instrucciones sencillas y comprensibles: arquitectura de la solución, herencia, código… en todos los ámbitos de un proyecto y rechazar lo complejo e innecesario. En muchas ocasiones por seguir un modelo, una arquitectura o una estructura de capas concreta, se complican los desarrollos, nos podemos perder en la estructura creada. Mi principal motivo para adoptar este principio es el “Mantenimiento” de la solución y el “Trabajo en Equipo”. Por otro lado, en el proceso de desarrollo de una aplicación, existen muchos factores por los que pueden entrar y salir personas en el equipo, si se ha creado una estructura compleja e inmanejable será un problema de tiempo de aprendizaje para las personas que se incorporen.
En muchas ocasiones me he encontrado con Directores de Proyectos Profesionales, que consideran que reemplazar a una o varias personas en un proyecto no implica costes de aprendizaje y que las nuevas incorporaciones son capaces de desarrollar desde el principio. Como he escuchado personalmente: “…hacemos un cambio de Cromos y seguimos avanzando…”.
A continuación se describen algunos métodos de Ingeniería del Software. Existen muchos más, pero por ahora nos vamos a centrar en los siguientes:
Desarrollo Ágil:
Es una metodología que engloba a otros metódos de Desarrollo de Software. Están basadas en evitar el exceso de documentación innecesaria y obtener antes un producto terminado. La mayor prioridad es que el cliente esté satisfecho y obtener un software que funcione. Estos métodos se basan en el contacto más directo con el cliente para tener una visión más real de sus necesidades. Para ello la toma de requisitos no es rígida sino que puede ir cambiando con las necesidades del cliente. Algunas metodologías que se incluyen en el Desarrollo Ágil:
- Scrum.
- Kanban.
- Open Unified Process (OpenUP).
- Programación Extrema (XP).
- Método de desarrollo de sistemas dinámicos (DSDM).
Scrum:
Pertenece al entorno del Desarrollo Ágil. Uno de los objetivos principales es la mejora de trabajo en equipo y la capacidad de adaptación a las necesidades y cambios que solicite el cliente.
Se realizan unas entregas parciales de partes del producto cada cierto tiempo. Estas entregas parciales son módulos funcionales que forman parte del producto final. Básicamente se definen unos Roles (ScrumMaster, ProductOwner, Team), y se planifican unas reuniones (Sprint) periódicas. Para cada una de las reuniones se debe poder entregar una parte del código utilizable. El cliente puede cambiar requisitos y pedir modificaciones en cada presentación (Sprint). Esto es la base de todas las metodologías Ágiles.
Existe una primera reunión Sprint Planning donde se definen que avances se deben entregar en las reuniones. Para ello Se definen los Requisitos y las prioridades de cada uno de ellos. Las reuniones (Sprints) tienen definidos unos puntos básicos y estructura que deben abordarse.
Roles:
- Scrum Master = Director de Proyecto o Jefe de Equipo de Desarrollo.
- Product Owner = Representa a las partes interesadas (StakeHolders), o propietario del producto. Es un intermediario entre el cliente final y el resto del equipo Scrum. Se encarga de transmitir las necesidades del cliente. Por este motivo en muchas ocasiones el Product Owner termina siendo el propio cliente.
- Team = Equipo de desarrollado.
Actividades:
- Planificación de la iteración (Sprint Planning)
- Ejecución de la iteración (Sprint)
- Reunión diaria de sincronización del equipo (Scrum Daily Meeting)
- Demostración de los requisitos completados (Sprint Review)
- Retrospectiva (Sprint Retrospective)Refinamiento de la lista de requisitos y cambios en el proyecto
Herramientas
- Lista de requisitos priorizada (Product Backlog)
- Lista de tareas de la iteración (Sprint Backlog)
- Gráficos de trabajo pendiente (Burndown Chart)
Beneficios obtenidos en la metodología Scrum: Gestión de las expectativas del cliente, reducción de riesgo, productividad y motivación del equipo, resultados anticipados, alineamiento entre cliente y equipo, flexibilidad y adaptación, retorno de inversión.
Cascada:
Es el método clásico. Define unos pasos rigurosos y estrictos que deben cumplirse. Por ejemplo:Análisis de requisitos.Diseño.Codificación / Desarrollo.Pruebas.Implantación.Mantenimiento.No se puede pasar a una fase del proceso sin haber terminado la anterior. Es mucho más rígida, y un error en una de las Fases supone el re-diseño del sistema. Esto supone unos costes más elevados.
Code and Fix:
Codificación y Corrección, más que una metodología es el resultado de falta de planificación y se trata más de improvisar o de presiones sobre los plazos de entrega. No se realiza ningún diseño y el equipo de desarrollo empieza de forma inmediata codificar. No se realizan pruebas muy a fondo y se van entregando partes del desarrollo al cliente. Según se detectan errores se van corrigiendo.
Lo triste de esta metodología es que se usa más de lo aconsejado.