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.
Modalidad de pago
Si bien no podemos como consultora financiar el desarrollo del proyecto, nuestra intención es que el cliente pague sólo por el trabajo realizado. Por ello, proponemos el siguiente esquema.
Al inicio del proyecto, haremos una estimación preliminar y de alto nivel del mismo, en un rango de horas/hombre. Luego de la creación del antes mencionado backlog técnico, confirmaremos esa estimación preliminar. En caso de producirse un desvío significativo en los tiempos estimados previamente, el cliente podrá decidir si continuar o no con el desarrollo del proyecto. Sólo abonará el análisis técnico realizado por nuestro equipo.
Enfocados en lograr una modalidad ágil de trabajo manteniendo la flexibilidad a los cambios, proponemos planificar y ejecutar iteraciones semanales o quincenales con objetivos concretos a cumplir. En las primeras iteraciones de cada nuevo proyecto, los objetivos redundarán en análisis, diseño y maquetación, más adelante en el desarrollo e implementación de componentes. De esta forma se irá avanzando en un modelo ágil de desarrollo generando deliveries en cada iteración, acercándonos poco a poco al producto final deseado.
Se emitirá una única factura mensual por todas las horas empleadas en las iteraciones cerradas en el mes. Siempre y cuando el alcance no varíe, el total de horas nunca será superior al total estimado en cada caso y siempre será proporcional al grado de avance realizado. De esta forma, se podrá ir abonando sólo el trabajo efectivamente realizado y a su vez se tendrá un gran control del alcance del proyecto, quedando a criterio del cliente si desea realizar más cambios o no.
Í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
Consúltanos sin compromiso
Cuéntanos tu idea y te preparamos una propuesta
Glosario de Términos y Buenas Prácticas
Si bien no pretendemos explicar SCRUM en profundidad ni mucho menos, en este espacio aclararemos varios puntos que seguramente serán de utilidad o interés en caso de trabajar con nuestros equipos de desarrollo ágil.
Definición de Scrum
Scrum: Es un marco de trabajo a través del cual las personas pueden abordar problemas
complejos adaptativos, a la vez que se entregan productos de forma eficiente y creativa con el
máximo valor.
Si tienes dudas conceptuales o bien deseas ampliar información, sugiero recurrir a https://www.scrum.org/ para resolverlas.
Los Principios de Agile
Nos pareció oportuno incluir en este artículo lo que para nosotros son el TOP 5 de los 12 principios de Agile, para que se entienda mejor nuestra filosofía.
- Deliver Value Faster: Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso.
- Welcome Changes: Bienvenidos los cambios en los requisitos, incluso al final del proyecto. Los procesos ágiles aprovechan ese cambio para generar una ventaja competitiva para el cliente.
- Work Together Every Day: El product owner, el scrum master y todo el scrum team deben trabajar juntos a diario durante todo el proyecto y con un mismo objetivo.
- Working Software is Key: El software funcionando es la principal medida de progreso.
- Simplicity: El arte de maximizar la cantidad de trabajo no realizado es fundamental.
Roles Clave
Merecen aclaración los siguientes roles dentro de nuestra implementación de SCRUM.
Product Owner
Es la persona que conoce el producto, sabe lo que necesita, qué es lo realmente importante y qué no lo es. Su responsabilidad clave está en interpretar al cliente (funcionalidades clave, prioridades, presupuesto, mercado, deadlines, etc.) y transmitir al equipo lo que desea sea construido, facilitando toda la información necesaria para llevar adelante el desarrollo.
Scrum Master
Además de ser un “facilitador” para que se ejecute SCRUM como debe ser, será el principal punto de contacto con el product owner para ayudarlo en todo lo que sea necesario.
Artefactos
Los siguientes artefactos son los que consideramos merecen una detallada explicación.
User Story
Es una definición a muy alto nivel de un requisito. Debe contener la suficiente información para que los desarrolladores puedan estimar el esfuerzo para implementarlo.
Una buena historia de usuario debe considerar las tres “W” (who, what, why). Es decir, quién (who) realizará algo, qué (what) es lo que hará y para qué (why). Además, debe cumplir con el criterio INVEST:
- 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.Ceremonias
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.
