|
 La gestión ágil entrega de forma periódica y continua pequeñas partes del sistema completamente terminadas y operativas, por eso el cliente (propietario del producto, en terminología Scrum), decide qué le corre más prisa, según las necesidades de su negocio, y por tanto qué partes se deben programar antes; vamos, lo que Scrum llama "priorización del product backlog".
Pues bien, un criterio interesante para "priorizar el product backlog" puede ser obtener el mayor ROI posible, y cuanto antes. ¿A que sí? :-)
Si el desarrollo ágil puede entregar partes del sistema de forma temprana, merece la pena estudiar si también es posible comenzar el retorno de la inversión de forma anticipada.
Si un plan de inversión a tres años, de un tipo así... 
se puede plantear de otra forma: 
Para hacer el estudio, el propietario del producto agruparía las funcionalidades en MMF's (Minimal Marketable Feature o mínima cantidad de producto capaz de generar ingresos) a los que llamaría MMFA, MMFB, MMFC, MMFD, MMFE... y con los criterios técnicos del equipo el diseño de la arquitectura se plantearía de forma modular, compuesta por los elementos AE1 Y AE2 (por ejemplo). Y se podrían determinar las secuencias de desarrollo posibles, según las dependencias entre los módulos de funcionalidades y los elementos de arquitectura; porque quizá para realizar el MMFC sea necesario diponer del MMFA terminado y operativo, y a su vez que éste necesite AE1... Algunas secuencias (Strands) posibles podrían ser: - AE1<- MMFA <- MMFC
- AE1<- MMFB
- AE1<- MMFA <- MMFB
Pues bien, esto no es mas que la presentación a vista de pájaro de la técnica Incremental Funding Method (IFM), desarrollada por Mark Denne y Jane Cleland-Huang, descrita de forma completa en su libro Software by Numbers, y que puede ser un conocimiento muy útil en el curriculum del propietario del producto. En los proyectos pequeños con un ámbito de hasta media docena de MMF's, el análisis no tiene por qué ser muy complicado, y normalmente se pued determinar el "strand" óptimo por intuición, pero en los desarrollos de mayor tamaño, el cálculo de posibilidades se hace más complejo, por el número las combinaciones posibles y las restricciones de dependencia en el orden de desarrollo entre MMF's. Para saber más:
 |
RSS de los comentarios
