Combinando lo mejor de los métodos ágiles y tradicionales, la gestión de proyectos híbrida es una nueva tendencia que equilibra la estructura con la flexibilidad.
Ni siquiera puedo recordar cuánto tiempo ha pasado desde que leí por primera vez el libro Successful Intelligence de Robert Sternberg, principalmente porque lo he releído más de un par de veces y es una de mis cinco recomendaciones principales. Hay muchas cosas buenas en este libro, pero una parte que realmente me impresionó es una sección muy pequeña dedicada a la prisa y su relación con la inteligencia.
El autor realizó una encuesta preguntando a personas de todo el mundo qué creen que es una señal de que alguien es inteligente. Para su sorpresa, los estadounidenses respondieron con palabras como “rápido”, “rápido” y “rápido”, mientras que los europeos optaron por palabras como “contemplativo”, “perspicaz” o “creativo”. Continúa argumentando que en la vida tendemos a poner a prueba a las personas sobre la rapidez con la que pueden hacer su trabajo o resolver un problema, pero rara vez medimos la contemplación, la perspicacia o la sabiduría.
Hay pocas palabras más adecuadas para describir TI que “rápido”. Los gerentes de proyectos y desarrolladores escriben código a una velocidad vertiginosa, tratando de lanzar sus productos lo más rápido posible. Está tan arraigado en nuestra cultura que incluso tenemos conceptos sobre las consecuencias de un desarrollo apresurado (¿deuda técnica, alguien?).
Desafortunadamente, esa es la naturaleza de la bestia. A nadie le gustaban las noches en vela y los horarios estresantes , pero los desarrolladores no somos líderes, somos cazadores, perseguimos un mercado que se mueve muy rápido y perseguimos tecnologías que crecen y cambian minuto a minuto. O corres o te quedas atrás.
Equipos ágiles: ¿vacuna o curita?
Durante mucho tiempo, el desarrollo siguió la tendencia de los métodos tradicionales, más concretamente, el modelo en cascada. Todos nos sabemos los pasos de memoria: Requisitos, Diseño, Implementación, Verificar, Mantener . Y también somos muy conscientes de los riesgos y problemas que conlleva el modelo.
Por parte del desarrollador, Waterfall requiere un marco de referencia de trabajo (WBS), lo que significa "no dar un paso sin un plan". Esto puede provocar grandes retrasos y lo que me gusta llamar "esta reunión podría haber sido un síndrome de correo electrónico", donde los equipos pasan más tiempo discutiendo un cambio que implementándolo.
Del lado del cliente, Waterfall es como una caja negra: le das un conjunto de instrucciones, recibes algunas llamadas telefónicas cada dos semanas para informarte de lo que está sucediendo y, finalmente, cuando llega el momento de implementarlo, obtienes un producto que puede ser o no lo que tenías en mente.
En ambos casos, la rigidez es el principal problema. Según este paradigma, la estructura es importante para el proceso de desarrollo, pero también puede ser una camisa de fuerza. Los modelos lineales funcionaron en los años 70 porque los mercados eran más lentos en aquel entonces (literalmente había que viajar a la oficina del cliente con cintas o disquetes en la mano).
Por el contrario, la velocidad del siglo XXI exige algo diferente, razón por la cual tantos desarrolladores han adoptado el paradigma del equipo ágil, como un pequeño grupo de personas altamente independientes con un amplio conjunto de habilidades y una estructura básica, así como un desarrollo iterativo. . proceso.
El lema de Agile es "fallar rápido", implementar lo más rápido posible y esperar que su proyecto falle espectacularmente para poder solucionarlo. Parece descuidado, pero es todo lo contrario. El paradigma simplemente supone que A. la implementación rápida es una necesidad de los tiempos y B. todo el software fallará inevitablemente, pero un problema pequeño es más rápido de resolver que uno que puede pasar desapercibido hasta la implementación completa.
Los clientes están más involucrados en el desarrollo ágil, prueban software constantemente y brindan comentarios mientras prueban diferentes versiones. En cierto modo, son participantes activos en el proceso. Eso es si el cliente tiene tiempo para trabajar codo con codo con el equipo ágil.
Por supuesto, lo ágil también tiene una buena cantidad de problemas. Sin una estructura clara, se abre la puerta a cambios en el alcance y en el trabajo pendiente. Además, si el cliente no tiene un objetivo claro en mente, la retroalimentación constante y revisada puede terminar descarrilando el proyecto.
Quizás lo más importante es que lo ágil no es bueno para escalar: es la teoría del caos en su máxima expresión. Funciona perfectamente cuando hay pocas variables, pero a medida que el proyecto aumenta de tamaño, las posibilidades de que las cosas se salgan de control aumentan hasta llegar a un punto de no retorno. Es por eso que los equipos ágiles no siempre son la mejor opción para un equipo de desarrollo dedicado.
Obtenga más información sobre los equipos dedicados al desarrollo de software
Contáctenos
Equipos híbridos, la tercera vía
Aristóteles, uno de los más grandes filósofos griegos, propuso que la virtud es el punto medio entre dos extremos. Cómo encontrar el equilibrio adecuado entre dos fuerzas opuestas. Lo mismo ocurre con la gestión de proyectos híbrida, un compromiso entre la estructura del modelo en cascada y la soltura del modelo ágil. Volviendo a mi argumento original, se puede ser rápido y también contemplativo, lo que resulta en un desarrollo más “inteligente”.
Hagamos un resumen rápido de las funciones:
- Los equipos híbridos tienen un director de proyecto que también actúa como director de producto. Investigan al cliente, configuran una WBS y asignan roles generales a los equipos. A diferencia del método en cascada, el PM no es un gerente en el sentido tradicional, la toma de decisiones no necesita pasar por él a menos que al hacerlo cambie radicalmente la WBS.
- Mientras el gerente del proyecto maneja el front-end del proyecto, a otros miembros del equipo se les asigna el rol de Scrum Masters que lideran el desarrollo durante los sprints, ellos administran el back-end mientras el gerente del proyecto permanece en contacto con el cliente.
El proceso de desarrollo es algo como esto:
- Analizar: el director del proyecto investiga al cliente y crea una lista de requisitos para el proyecto.
- Plan: el PM se reúne con el equipo y crea una WBS con un cronograma aproximado del proyecto. En este punto, se nombra formalmente al primer scrum master.
- Diseño: Se inicia la fase de diseño y se planifica con antelación la primera sesión del sprint, estableciendo los objetivos y bases del proceso de desarrollo.
- Carrera: el Scrum master toma el control y comienza la codificación. El proceso suele durar entre 4 y 6 semanas mientras se prepara un producto de prueba para el cliente.
- Pruebas: el cliente prueba el producto y le da su opinión al PM para que la lleve al equipo.
- Sprint: Se puede nombrar un nuevo Scrum master cuando comienza la segunda fase del sprint, incorporando los comentarios de los clientes. Hay que tener en cuenta que en esta etapa los sprints ya no se planifican con antelación como ocurría con el primero. Aquí el equipo actúa como un equipo ágil.
- Iterar: continuar entre sprint y prueba hasta llegar al final del proyecto.
Como puedes ver, la idea detrás de los equipos híbridos es crear una estructura sólida desde el principio, manteniendo una estructura flexible y con la menor burocracia posible. Por supuesto, esto significa que un equipo híbrido, como un equipo ágil, funciona mejor cuando los miembros del equipo están en sintonía. Afortunadamente, la fase de planificación original ayuda a que todos adopten una mentalidad común.
En el mejor de los casos, un equipo híbrido tiene la estructura subyacente para asumir grandes proyectos con la flexibilidad de adaptarse y cambiar a medida que avanza el proyecto. Piense en ello como navegar en los viejos tiempos: la WBS es la estrella del norte, siempre apuntando hacia su norte. Puedes seguir el camino que quieras o necesites (flexibilidad), siempre y cuando no pierdas de vista tu estrella guía.
¿Existen desventajas para los equipos híbridos? Por supuesto, ningún sistema es perfecto. Como malla entre dos paradigmas, es posible que termine enfrentando los mismos desafíos que cada uno de los paradigmas principales. Afortunadamente, el método está diseñado específicamente para que los problemas que puedan surgir en un lado puedan ser compensados por las fortalezas del otro lado.
Fuente: BairesDev
