Contacto +34 93 737 62 70
           
Contacto +34 93 737 62 70
DAD_lifecycle
En algunas ocasiones he hablado con empresas piden presupuestos de proyectos a proveedores que afirman usar metodologías basadas en Scrum, y que les ofrecen fundamentalmente una bolsa de horas. En general esto ya representa una ventaja para muchos proyectos de riesgo medio y bajo, pues permite a estas empresas:
  1. Controlar mejor el presupuesto, dedicándolo a obtener las funcionalidades más prioritarias antes y con más calidad.
  2. Obligarse a una mayor implicación con el proveedor, para obtener un mejor producto antes.
Aun así, este enfoque presenta otros riesgos que suelen mitigarse con una planificación tradicional (o “BPUF”, Big Planning Up Front), como son:
  1. Se crean unas expectativas de plazos en los usuarios que facilitan la planificación interna de los despliegues de las aplicaciones.
  2. Se identifican mejor requisitos de integración con otros sistemas que requieren trabajo por parte de otros equipos o proveedores.
De esta manera, parece razonable establecer sendos mínimos análisis de los requisitos y de la arquitectura que permitan a los proveedores ofrecer una estimación más precisa de un “release plan” e internamente una mejor coordinación con los usuarios y otros equipos de sistemas. Disciplined Agile Delivery (DAD) propone como criterio para decidir “cuanto análisis es necesario” que todos los actores (usuarios, otros técnicos y proveedor) decidan que el riesgo para comenzar el nuevo proyecto es asumible. Esto en Scrum, aunque oficialmente no se recomiende hacerlo, se llama “Sprint 0” y lo hacen muchos equipos. En caso de identificar (no decimos “definir”) estos requisitos iniciales, se pueden estimar los N sprints necesarios para su desarrollo (y posiblemente alguno más como “colchón”) y por tanto tener un release plan que ayude a los usuarios y otros equipos técnicos a sincronizarse con el proyecto. Para no caer en la tentación de querer definir con precisión los requisitos a priori, y por tanto volver a un proyecto de cascada, podemos pautar la precisión que queremos lograr, p.e.:
  • Epics (bloques de funcionalidad todavía no detallados): +/- semana
  • Historias de usuario (requisitos concretos): +/- día
Para proyectos pequeños (p.e. menores a 200 horas) deberíamos intentar identificar inicialmente todo el trabajo a nivel de historias de usuario. Estos consejos intentan que este análisis inicial sea el suficiente, pero no volver al modelo de requisitos definidos. Imagen: DisciplinedAgileDelivery.com

¿Podemos ofrecerte más información?

Newsletter mensual

Cada mes enviamos una newsletter a más de 1.000 personas con contenido interesante que hemos encontrado en Internet, artículos nuestros y nuestras novedades. Queremos ofrecer contenido de calidad y no saturarte con muchos correos.

Formulario de contacto

Si crees que podemos ayudarte con alguna duda o necesidad de soporte, no dudes en contactar con nosotros. Estaremos encantados de ayudar.

Ir arriba

Newsletter mensual

Un boletín mensual. Respetamos tu privacidad.