The War of Software

En SCRUM tenemos varios artefactos que se deben llevar, estos se utilizan en tarea especificas dentro del proceso de desarrollo.

Como todo en esta vida no es echar código, en una serie de correos les estaré empapando de estos temas.

Iniciemos con el Product Backlog

El dueño del producto (internamente son los directores de proyecto) deben articular la visión del producto. Esto se lleva a cabo listando las características requeridas, priorizadas en orden de que es de MAYOR VALOR PARA EL NEGOCIO (No empezando por los maestros), cual puede tener mayor ROI para la compañía (nota: Que no hagamos parte de las empresas clientes, no quiere decir que no sepamos que es de mayor valor para el negocio del cliente, y hacer propuestas). Esta priorización pone los ítems de mayor valor en el TOP. Si lo vemos desde el punto de vista de la mejora de procesos, esto es un proceso de toma de decisión para DESARROLLO DE REQUISITOS y SOLUCION TECNICA, desde el punto de vista de saber que componentes se van a desarrollar primero, es la forma de sustentar por que empezamos el proyecto por donde empezamos. Este listado priorizado debe quedar sustentado en el PRODUCT BACKLOG, el cual es un artefacto que debe existir en todo momento y evolucionar conforme el producto se va desarrollando. Ojo: Evolucionar para cambiar la priorización o para adicionar características.

Este PRODUCT BACKLOG incluirá una variedad de ítems, como características (“Permitir a todos los usuarios ingresar a la aplicación dependiendo del rol”), requisitos no funcionales (“Mejorar el procesos cache para que sea distribuible y escalable en cluster”, “Mejorar la consultas de base de datos para que utilicen el optimizador por ESTADISTICAS”, etc.), trabajo exploratorio (“Investigar soluciones para acelerar el llenado de la planilla con AJAX”), y bugs conocidos (“Diagnosticas y arreglar los errores de Javascript cuando se asigna un BUG en Mantis (BUG 1232) ”).

Uno de los errores que se comete cuando se definen ítems (no actividades, ni tareas, sino ítems) es no definir el detalle en el cual se escribirán. Mi recomendación es que en los primeros sprints se definen características y/o funcionalidades generales. Pero después se debe ir refinando para dar un mayor detalle a cada uno de los ítems. Sugerencia: Utilizar el menor espacio para dar el mayor detalle. Ej.:

1. Mejorar el procesos cache para que sea distribuible y escalable en cluster

2. Mejorar el procesos cache para que sea distribuible y escalable en cluster, soportar 500 transacciones simultaneas, Granja de 3 servidores OAS en cluster.

Se supone que este product backlog será partido en piezas mas pequeñas en las Sprint Planning Meetings.