Metodologías de desarrollo de software.

Hola. En las dos últimas entrevistas me preguntaron sobre metodologías. Ésta no es la pregunta más importante ni la más difícil, pero sería bueno tener una hoja de referencia para la respuesta. En este artículo intentaré dar una idea de qué es una metodología de desarrollo y comparar aquellas que he conocido personalmente o sobre las que me han preguntado. La metodología de desarrollo de software es un proceso de descripción de cómo se desarrollará un producto específico, es decir, una de las formas de organizar el desarrollo del equipo. Hay muchos modelos diferentes de tal proceso, cada uno de los cuales describe su propio enfoque, y no se puede decir que entre ellos haya uno que deba usarse en cada proyecto, todo es puramente situacional. Propongo considerar tres de ellos con más detalle.

Cascada

Cascada (cascada, cascada) es una de las metodologías más antiguas e implica la implementación secuencial estricta de todas las etapas, cada una de las cuales debe completarse antes de que comience la siguiente. Es decir, la transición a la siguiente etapa significa la finalización completa del trabajo de la anterior. La imagen muestra que primero analizamos la tarea (documentamos las tareas, discutimos las dificultades), luego ocurre el diseño (en esta etapa se forma la estructura del proyecto), luego codificamos y probamos. No hay reembolsos para etapas posteriores. Se recomienda utilizar un sistema de este tipo en proyectos pequeños donde los requisitos se conocen de antemano y hay pocas probabilidades de que cambien. Ventajas:

• Documentación completa y consistente en cada etapa;
• Facilidad de uso;
• Requisitos estables.
• El presupuesto y los plazos están predeterminados.

Defectos:

• Una gran cantidad de documentación;
• No es un sistema muy flexible;
• El cliente no puede ver la versión demo del producto;
• No hay manera de retroceder un paso.

Melé

Scrum es un sistema de desarrollo de software que se basa en dividir todo el proceso en iteraciones, donde al final de cada una de ellas el equipo está listo para brindar una versión demo del producto. La imagen muestra que el equipo pasa por todas las etapas de desarrollo en paralelo, lo que nos permite tener una parte terminada del proyecto al final de cada iteración. Intentaré explicar brevemente en palabras sencillas la esencia de la metodología, pero aquí hay muchos términos. Creo que lo más importante es comprender la esencia y los términos se recordarán con la experiencia. Todo el desarrollo se divide en sprints (a menudo de 2 a 3 semanas). Hay un trabajo pendiente (lista de tareas) para todo el período de desarrollo y para cada sprint por separado. Cada tarea tiene su propio punto de historia (grado de dificultad). Cada participante en el proceso tiene un rol:

• Un equipo Scrum es un equipo que trabaja en un proyecto (desarrolladores, probadores, diseñadores).
• Un Scrum Master es una persona que garantiza que se sigan los principios de Scrum.
• Propietario del producto – cliente.

Dado que en este sistema el énfasis está en la comunicación, existen una gran cantidad de manifestaciones:

• El stand-up es una reunión breve que se realiza todos los días, en la que participan todos los miembros del equipo y cada participante responde 3 preguntas: ¿qué hiciste? ¿Qué hará? ¿Y cuáles son los bloqueadores?
• Planificación: se lleva a cabo al comienzo del sprint y en esta reunión se determina qué tareas deben completarse en el próximo sprint.
• La retrospectiva se realiza al final del sprint y su esencia es descubrir qué se hizo bien y qué se podría mejorar.

Ventajas:

• El cliente puede observar el resultado durante el proceso de desarrollo.
• Control diario sobre el proceso de desarrollo.
• Capacidad para realizar ajustes durante el desarrollo.
• Comunicaciones bien establecidas con todos los miembros del equipo.
• Pequeña cantidad de documentación.

Defectos:

• Es difícil estimar la mano de obra y los costos necesarios para el desarrollo.
• Es difícil determinar los mayores obstáculos antes de que comience el desarrollo.
• La necesidad de involucrar a todos en el desarrollo de los demás miembros del equipo.

Kanban

Kanban es un sistema basado en la visualización del proceso de realización de tareas en equipo. La idea principal de este sistema es reducir la cantidad de tareas que se están realizando actualmente (en la columna “en progreso”). En Scrum, el equipo se enfoca en completar con éxito los sprints, en Kanban, las tareas son lo primero. Bueno para proyectos que se encuentran en la etapa de soporte, donde la funcionalidad principal ya se ha desarrollado y quedan mejoras mínimas y corrección de errores. En Kanban, las tareas se envían individualmente. La tarea, independientemente de otras tareas, pasa por todas las etapas del tablero y tan pronto como se completa se puede mostrar al cliente. Un tablero Kanban consta de columnas, cada una de las cuales representa un proceso de desarrollo independiente. Algunas columnas (por ejemplo, en progreso) imponen restricciones sobre la cantidad de tareas que pueden estar allí. Esto ayuda a encontrar fácil y rápidamente áreas problemáticas en la distribución de tareas. La imagen muestra un ejemplo de un tablero tan simple. El número de columnas y nombres puede variar, pero nombraré los más comunes:

• Por hacer: una lista de tareas que deben realizarse
• En progreso: tareas en las que se está trabajando actualmente
• Revisión de código: tareas que se han completado y enviado para revisión
• En pruebas: tareas listas para probar
• Listo: tareas completadas.

Ventajas:

• Facilidad de uso.
• Visualización (ayuda a encontrar obstáculos, simplifica la comprensión)
• Alta implicación del equipo en el propio proceso.
• Alta flexibilidad en el desarrollo.

Defectos:

• Lista de tareas inestable.
• Difícil de usar en proyectos a largo plazo.
• Sin plazos estrictos.

En conclusión sobre la metodología de desarrollo de software.

En mi opinión, las personas que ocupan puestos directivos o aspiran a ellos necesitan tener un conocimiento profundo de las metodologías de desarrollo de software, pero es recomendable que todos comprendan al menos los conceptos básicos. Esta es una parte integral del proceso de desarrollo y se utiliza no solo en el campo de TI. Gracias por tomarse el tiempo de leer mi artículo, espero que le haya resultado útil. Intenté describir sólo los puntos clave de la forma más clara y breve posible, por lo que el artículo no es exhaustivo. Estaré encantado de escuchar tu opinión al respecto y responder a tus preguntas. ¡Mis mejores deseos!