Para seguir este post, quizás sea interesante leer estos otros antes:
- Métrica v3 vs Metodologías Ágiles
- Scrum para Dummies
Soy consciente de que es más beneficioso no tener que realizar este tipo de adaptaciones, y trabajar directamente con metodologías ágiles, pero algunas veces nos vemos obligados a ello por los requerimientos del cliente de trabajar con otro tipo de metodologías más pesadas (sobretodo si es Administración Pública), y no por ello vamos a renunciar a una forma de trabajar (internamente, en este caso) que nos ha traído grandes beneficios.
En este post voy a aportar el enfoque que le damos a estos proyectos en la División de Ingeniería de Software de Soltel.
Me centraré en la adaptación que realizamos en fase de análisis, y su posterior aprovechamiento en las distintas fases del desarrollo. Los más puristas dirán que lo que hacemos no es Scrum, ya que ni tenemos alta implicación del cliente, ni podemos enseñarle "producto" desde la primera iteración. Coincido, así que en este caso, no lo llamaremos Scrum.
El documento de análisis en Métrica v3 es el ASI (Análisis del Sistema de Información). Creo que lo más conveniente es empezar apuntar las actividades y artefactos que tiene nuestro ASI:
Como observamos, todo estos componentes nos van a generar muchísimo trabajo, por lo que debemos optimizar al máximo para reaprovechar todo lo que podamos. Empezaremos por los Requisitos Funcionales.
¿Qué pasa si escribimos los requisitos funcionales como si fueran historias de usuario? Métrica no es prescriptiva al respecto, por lo que al final se traduce a un problema de granularidad. Nuestros requisitos funcionales conformarán nuestro Product Backlog. Así, cuando termine la fase de análisis, podremos estimar los sprints, y empezar a usar Scrum.
Por otro lado, merece la pena invertir tiempo en los Requisitos de Información. Si los describimos bien, automáticamente tendremos el Modelo de Clases de Análisis.
Al final, cada equipo de trabajo debe buscar la forma de trabajar que más le aporte, aunque no le podamos poner el cartelito con el nombre de la metodología de moda. A nosotros esta pequeña adaptación nos ha servido.
¿Y tu?, ¿cómo haces Métrica v3 más ágil?
- Métrica v3 vs Metodologías Ágiles
- Scrum para Dummies
Soy consciente de que es más beneficioso no tener que realizar este tipo de adaptaciones, y trabajar directamente con metodologías ágiles, pero algunas veces nos vemos obligados a ello por los requerimientos del cliente de trabajar con otro tipo de metodologías más pesadas (sobretodo si es Administración Pública), y no por ello vamos a renunciar a una forma de trabajar (internamente, en este caso) que nos ha traído grandes beneficios.
En este post voy a aportar el enfoque que le damos a estos proyectos en la División de Ingeniería de Software de Soltel.
Me centraré en la adaptación que realizamos en fase de análisis, y su posterior aprovechamiento en las distintas fases del desarrollo. Los más puristas dirán que lo que hacemos no es Scrum, ya que ni tenemos alta implicación del cliente, ni podemos enseñarle "producto" desde la primera iteración. Coincido, así que en este caso, no lo llamaremos Scrum.
El documento de análisis en Métrica v3 es el ASI (Análisis del Sistema de Información). Creo que lo más conveniente es empezar apuntar las actividades y artefactos que tiene nuestro ASI:
Catálogo de Requisitos:Requisitos FuncionalesRequisitos de InformaciónRestricciones y Reglas de NegocioRequisitos No Funcionales
Catálogo de casos de uso:Modelo de Casos de UsoEspecificación de Casos de Uso
Modelo de Clases de Análisis
Matrices de Trazabilidad
Peticiones de cambio
Como observamos, todo estos componentes nos van a generar muchísimo trabajo, por lo que debemos optimizar al máximo para reaprovechar todo lo que podamos. Empezaremos por los Requisitos Funcionales.
¿Qué pasa si escribimos los requisitos funcionales como si fueran historias de usuario? Métrica no es prescriptiva al respecto, por lo que al final se traduce a un problema de granularidad. Nuestros requisitos funcionales conformarán nuestro Product Backlog. Así, cuando termine la fase de análisis, podremos estimar los sprints, y empezar a usar Scrum.
Por otro lado, merece la pena invertir tiempo en los Requisitos de Información. Si los describimos bien, automáticamente tendremos el Modelo de Clases de Análisis.
Al final, cada equipo de trabajo debe buscar la forma de trabajar que más le aporte, aunque no le podamos poner el cartelito con el nombre de la metodología de moda. A nosotros esta pequeña adaptación nos ha servido.
¿Y tu?, ¿cómo haces Métrica v3 más ágil?
Comentarios
Publicar un comentario