En el desarrollo de software hasta la década de 1990, todo era predecible y directo: una secuencia clara de procesos de trabajo, planificación paso a paso, documentación, pruebas e implementación del producto final.
La gestión de proyectos era demasiado rígida, y las desviaciones de un plan estricto interrumpían todo el flujo de trabajo.
El modelo Cascada (modelo de cascada o modelo “waterfall”) es un modelo de desarrollo de software inflexible con una secuencia clara de acciones donde es imposible pasar à la siguiente etapa hasta que la anterior esté completamente finalizada.
El desarrollo en Cascada se parece a un flujo de procesos que avanzan de etapa en etapa con requisitos claros. No ocurre ninguna transición à la siguiente etapa hasta que la actual esté completada.
En la década de 1990, una familia de métodos flexibles reemplazó a los rígidos.
Estamos hablando, por supuesto, de Agile (desarrollo de software ágil). Este nuevo enfoque de metodología de gestión de proyectos ingresó al mundo de TI y, más tarde, se expandió à la manufactura, ingeniería, desarrollo de inteligencia artificial y más.
Los primeros métodos flexibles incluyeron:
- RAD (enfocado en la calidad con un presupuesto mínimo y un plazo limitado)
- XP (Programación Extrema con propiedad colectiva del código)
- Scrum (donde cada miembro del equipo es responsable del resultado)
- Kanban (visualizando las etapas de desarrollo en un tablero), entre otros.
Cuatro ideas ágiles que deberías conocer:
- Las personas y las interacciones son más importantes que los procesos.
- La colaboración con el cliente es más importante que la negociación del contrato.
- Un producto funcional tiene prioridad sobre la documentación.
- Responder al cambio es más importante que seguir un plan.
| Agile | Cascada |
|---|---|
| Procesos de trabajo flexibles, permitiendo cambios en cualquier momento | Modelo de desarrollo en cascada con una secuencia rígida |
| Un producto funcional es más importante que la documentación | La documentación es más importante que el producto terminado |
| Responsabilidad individual de cada miembro del equipo por el resultado | La responsabilidad por el resultado general recae en el equipo |
| Interacción con el cliente durante el desarrollo | El cliente no está involucrado en el proceso |
| Máxima implicación del propietario del producto en el proceso | Mínima implicación del propietario del producto |
| El flujo de trabajo se divide en sprints cortos, generalmente de 1 semana a 1 mes | Cada flujo de trabajo es una fase separada que dura hasta que se completan las pruebas y la aprobación |
Sistemas de gestión de proyectos populares en Agile
Exploremos aquellos que han “echado raíces” y se utilizan más comúnmente en el desarrollo de software.
Scrum
Un enfoque flexible para el desarrollo de software donde una tarea equivale a un sprint. Un sprint en Scrum puede durar de 1 semana a 1 mes.
¿Para quién es Scrum?
Para pequeñas empresas o departamentos donde el propietario de la empresa o el jefe del departamento pueden integrarse físicamente en el proceso de trabajo y participar activamente. Este método también es ideal para startups.
Utilizar Scrum en la gestión de proyectos hace difícil pinpointar la responsabilidad por tareas incompletas. Cada miembro del equipo es responsable del resultado, priorizando la autoorganización para dar forma a los flujos de trabajo.
El equipo que elige Scrum para la gestión de proyectos debe estar preparado para la máxima flexibilidad. Por ejemplo, si un miembro del equipo “sale” temporalmente del proceso, otro debe hacerse cargo de sus tareas.
Scrum master – el gerente del proyecto y una figura clave en el equipo, supervisando la organización del proceso de negocio, reuniones, motivación del equipo, respuestas rápidas a cambios y resolución de problemas.
+ Pros
El software se desarrolla más rápido, con la mayor participación del equipo, reduciendo los costos de desarrollo al dividir el flujo de trabajo en sprints cortos.— Contras
Scrum no tiene reglas o requisitos estrictos pero permite espacio para la experimentación, cambio de presupuestos y plazos. No es adecuado para clientes que necesitan un plan claro y un contrato formal.Por ejemplo, si necesitas crear un producto para una organización gubernamental donde la firma del contrato es una prioridad, Scrum no es adecuado. La prioridad principal es el producto terminado, seguido de la documentación, informes de trabajo, etc.
Ejemplo de gestión de proyectos utilizando Scrum
Supongamos que la tarea es crear software en el menor tiempo posible. El flujo de trabajo se divide en sprints, cada uno finalizando con una demostración del resultado completado. Se llevan a cabo reuniones para revisar los resultados intermedios y avanzar al siguiente sprint.
Monitorear la velocidad de finalización del sprint es crucial en Scrum.
Para entender cuánto durará un sprint, el equipo puede iniciar un temporizador al principio. Rastrear el tiempo dedicado a cada tarea proporciona información sobre la duración requerida para tareas similares.
Kanban
Una representación visual del flujo de trabajo y movimiento paso a paso de tareas de “En Progreso” a “Hecho.” Entre estos dos estados, puede haber varias etapas más: “Desarrollo,” “Pruebas,” “Optimización,” etc. Kanban se presenta como un tablero donde las tareas se mueven de estación a estación. Cuando una tarea alcanza la estación final “Hecho,” se completa.
Scrum y Kanban son enfoques flexibles para la gestión de proyectos. Sin embargo, Kanban es aún más flexible porque:
- Permite tareas nuevas repentinas y “cambios” entre ellas.
- La responsabilidad colectiva por el resultado mejora la eficiencia.
- Las tareas no planificadas van al backlog, un espacio de almacenamiento para todas las tareas que aún no están en progreso. El backlog parece cualquier otra etapa del proceso de trabajo y contiene tareas listas para su trabajo cuando otras etapas terminan antes de lo esperado.
+ Pros
A diferencia de Scrum, Kanban no requiere reuniones regulares, discusiones o revisiones de sprints, ahorrando tiempo y añadiendo eficiencia donde todas las etapas son visibles en el tablero.— Contras
Kanban es desafiante para proyectos grandes donde los resultados intermedios son cruciales, rompiendo el proceso en sprints, y se necesita la aprobación previa de un plan de acción. Kanban es más adecuado para proyectos y tareas a corto plazo.Ejemplo de gestión de proyectos utilizando Kanban
La tarea es grabar un video instructivo para un cliente. Esto implicará crear varias tareas: “Escritura de Guión,” “Filmación,” “Edición Inicial,” “Post-Procesamiento.” Cada tarea será una columna separada en el tablero de Kanban.
Kanban o Scrum? ¿Qué sistema de gestión de proyectos necesitas?
Scrum proporciona más control y gestionabilidad al comienzo del desarrollo de un nuevo producto. Si Kanban ofrece máxima flexibilidad, Scrum se enfoca más en el control y la gestión. Cuando los procesos están en marcha, Kanban viene al rescate. Es perfecto para trabajar con tareas repetitivas.¿Cómo elegir una herramienta de gestión de proyectos?
El gestor de tareas correcto es la mitad del éxito. Una vez que hayas elegido un método de gestión de proyectos, es crucial transitar el trabajo y las tareas al sistema seleccionado.
6 señales de que has elegido el gestor de tareas adecuado:
- El equipo migró sin problemas todos los flujos de trabajo à la cuenta.
- La funcionalidad es intuitiva y utilizada por los miembros del equipo.
- El equipo utiliza fácilmente uno de los enfoques de gestión flexibles: Scrum o Kanban.
- La sistematización del flujo de trabajo está establecida, aumentando la eficiencia general.
- La comunicación del equipo se vuelve más coordinada: proyectos, tareas y comentarios no se pierden.
- El cliente recibe informes transparentes sobre tareas y proyectos, rastreando flujos de trabajo si lo desea.