Nuestra Metodología
de Desarrollo Ágil
En los desarrollos tradicionales, cuando los requerimientos no están perfectamente definidos a nivel funcional y técnico, los proyectos se estiman con cierto margen de error, lo cual no es deseable por varios motivos:
- La probabilidad de desvío en tiempos y costos es muy alta.
- Se corre un alto riesgo de sobrestimar o subestimar el proyecto, comprometiendo las finanzas del cliente o de la consultora.
- Para cumplir con el plan, no se mantendrá la necesaria flexibilidad a los cambios en los requerimientos, lo que puede incidir en un producto final que no cumpla con los requisitos que el mercado necesita cubrir.
- Se produce un desgaste en el equipo por constantes discusiones de alcance, tiempos y costos.
Por todo ello, con el objetivo de realizar un desarrollo que mantenga la flexibilidad en los requerimientos pero sin afectar los costos del proyecto más allá de lo efectivamente necesario, implementamos la siguiente metodología ágil, basándonos en Scrum.
Ciclo de vida del proyecto
Nuestro objetivo es entregar un producto de calidad lo antes posible realizando un desarrollo evolutivo flexible a los cambios, por lo que utilizamos SCRUM implementando el proceso de la siguiente forma:
El cliente, como principal referente y stakeholder, deberá proveer al Product Owner, toda la información necesaria (en forma de user stories correctamente definidas) para que podamos transformar esas historias de usuario en product backlogs procesables por el equipo, lo cual no son otra cosa que las funcionalidades del sistema a desarrollar correctamente definidas. En caso de no contar con tal nivel de definición, proveeremos soporte al cliente para crear el mencionado backlog técnico*.
* El “backlog técnico” no es un documento de SCRUM propiamente dicho, sino un documento interno nuestro que provee el nivel de detalle suficiente para delimitar la arquitectura y el alcance técnico-funcional del producto a desarrollar. Los diagramas, estructuras o definiciones que contenga dependerá de la naturaleza de cada sistema en particular. El objetivo no es que sirva de documentación final del proyecto, sino de definición técnica precisa y suficiente para realizar una estimación con bajo margen de desvío.
Importante
Antes de avanzar con el primer sprint, es necesario contar con dicho backlog técnico que permita delimitar el alcance del proyecto y confirmar la estimación preliminar.
Cada uno de dichos product backlogs serán transformados en sprint backlogs (funcionalidades específicas a desarrollar en una iteración) en la reunión de Planning, la cual se realiza inmediatamente antes del inicio de cada sprint. Durante la misma, el main stakeholder o referente del cliente, junto con el product owner y el scrum team definen lo que se construirá en la siguiente iteración. Las iteraciones podrían ser tanto semanales como quincenales, dependiendo de varios factores.
Durante la misma se realizan diariamente varias actividades en forma cíclica y repetitiva. Una de las principales consiste en el proceso de refinamiento o reunión de Refinement de los product backlogs para que tengan toda la información necesaria para que el equipo lo pueda incluir en el siguiente sprint (no en el sprint en curso). En esta ceremonia es necesaria la participación del cliente.
Diariamente se lleva a cabo una daily meeting interna. A efectos de brindar transparencia, proponemos al cliente realizar una weekly meeting para tener un punto de contacto y control de avance.
Cada iteración finalizada produce un entregable más refinado que en la iteración anterior. Este proceso se repite hasta finalizar el desarrollo pactado. En la Sprint Review, al cierre de cada sprint, se presenta dicho entregable al cliente.
Durante el transcurso del proyecto se utiliza el software Agile.MyTaskPanel como herramienta de gestión online del proyecto para brindar visibilidad a través de todo su ciclo de desarrollo. Se le entregará un usuario al cliente para que pueda seguir el estado del proyecto diariamente.
Índice
Características principales
Equipos multidisciplinares y
auto-organizados
Desarrollo ágil
Aumenta la motivación
del equipo
Cliente integrado
en el equipo
Feedback rápido del
producto en desarrollo
Flexibilidad en la
incorporación de cambios
Reducción en el tiempo de
entrega final del proyecto
- Independent (independiente): cada historia del usuario debe ser auto-explicable, no debe depender de otras historias de usuario.
- Negotiable (Negociable): evitar incluir demasiado detalle, para que las historias de usuario sean flexibles y puedan ser modificadas.
- Valuable (Valiosa): las historias de usuario deben aportar algún valor al usuario final.
- Estimable: debes ser capaz de estimar los recursos necesarios para completar cada historia de usuario.
- Scalable (Escalable): haz simples las historias de usuario, para que puedan ser encaradas y priorizadas.
- Testable (Comprobable): explica los criterios de verificación y aprobación, para que el equipo los conozca y aplique cuando una historia esté completa.
Checklist para aceptar una User Story
- ¿Contiene la historia de usuario las tres “W”?
- ¿Cumple con el criterio INVEST?
- ¿Están claramente definidos los criterios de aceptación?
Ejemplo
Es un caso muy simple, pero creo que deja claros los conceptos antes explicados.
Como un startup founder, quiero poder crear una cuenta en el sitio XYZ, de forma tal de poder unirme a la comunidad de inversores y mentores.
Criterios de aceptación
- Poder crear una cuenta manualmente (completando el formulario de sign-up)
- Crear una cuenta vía Google
- Crear una cuenta vía Facebook
Product Backlogs
No es otra cosa que las user stories transformadas en una lista priorizada de entregables (deliverables) que deben implementarse a través del proceso de desarrollo. Un product backlog item (PBI) es un único elemento dentro de dicha lista. El mismo debe contener toda la información necesaria para que el equipo pueda incluirlo eventualmente dentro de una iteración (transformado para ello en un sprint backlog).
Podría parecer en principio que es lo mismo que una historia de usuario, pero no lo es. Esta última va más allá de un cambio o requerimiento en particular. Esta pone al usuario en el centro y describe una característica del sistema desde su punto de vista.
Sprint Backlog
Durante la reunión de Planning, se seleccionan los PBI que formarán parte del siguiente sprint y se los divide en uno o más sprint backlog item (SBI). Siendo simplistas, no es más que un PBI dentro de un sprint. En realidad, es un poco más, porque es necesario que ese SBI tenga un mayor nivel de detalle. Además, un PBI puede originar varios SBI diferentes.No son otra cosa que reuniones con diferentes participantes y diseñadas a efectos muy específicos. Para ser claros, no se comentará todo lo que se lleva a cabo en dichas reuniones, pero se dejará claro la finalidad de las mismas.
Planning
En esta reunión, la cual ocurre previo al inicio de un sprint, se seleccionan los PBI que se desarrollarán en el mismo y se los transforma en SBI.
Refinement
En esta reunión, que ocurre durante los primeros días del inicio de una iteración, se analizan los siguientes PBI a desarrollar en el siguiente sprint (no en el actual) y se los refina. Es decir, se los baja a un nivel de detalle suficiente para poder ser luego desarrollado.
Daily
Esta reunión diaria sirve para ver lo que se hizo el día anterior, lo que se hará en el día en curso y los impedimentos que pudieran existir.
Review
En esta reunión, que se realiza luego de terminada una iteración, se presenta al cliente el resultado de la misma.
