Management enfocado en proyectos ágiles (Diferente del Line Management, enfocado en la gestión de personas).
Principios y valores establecidos en la Declaración de Interdependencia
Reflexión: Cuando el cliente es uno mismo / la empresa, se paga por capacidad, y por tanto la parte Agile encaja muy bien. Sin embargo, cuando el cliente es externo, éste paga por entrega, la capacidad “le da igual”. Por tanto, en este segundo caso, hay que cambiar el discurso y facturar por entregable en vez de por capacidad, es decir, la factura atiende a lo entregado, no al tiempo dedicado. - Alinear el inicio-fin de sprint con las facturas: Así es fácil que el cliente entienda por lo que está pagando - Tomar la planning como una negociación con el cliente, donde se asume que el ~80% del sprint será entregado al finalizar. - Si esto no ocurre, y el cliente no quiere pagar el sprint, se renegocia: En caso peor, se termina lo acordado en el sprint anterior, el cliente paga la factura, y se para el proyecto. - APRENDIDO DE SA: PARAR el proyecto inmediatamente cuando esto ocurra, si se quiere continuar, que lo decidan los de arriba - Crear un dashboard del backlog (x ej con PowerBI) donde se vea el progreso general del proyecto, coste estimado, y progreso esperado en el sprint actual. - APRENDIDO DE SA: Personas vs Procesos, es decir, reducir el proceso al mínimo y evaluar continuamente si tiene sentido crear documentación o procesos para el cliente.
Avance por Hitos Un hito se define como un alcance o scope, un presupuesto, unos requisitos y un deadline Un hito es una Predicción basada en el cumplimiento de los requisitos Idealmente un hito debería coincidir con un sprint A nivel de facturación, puede llegarse al acuerdo de facturar el presupuesto acordado si se entrega al menos el 85% del alcance Reevaluación contínua El hito (la Predicción) debe reevaluarse de forma periódica a medida que se tiene nueva información Debe medirse el cumplimiento de requisitos Debe medirse el avance en el scope según el deadline Debe medirse el gasto Adaptación al cambio Según cambie la predicción, debe cambiar la definición del hito Búsqueda contínua de soluciones Negociación contínua con el cliente APRENDIDO DE SA: La negociación tiene un coste alto. Durante la negociación, se para el proyecto, o se paga por ella, ya que el equipo debe estar involucrado. Feedback contínuo El feedback del cliente a medida que se avanza es crucial Para ello es necesario crear micro-iteraciones verticales o “end-to-end” que puedan ser probadas El feedback debe ser parte de los requisitos Review de cada hito El punto más crítico en cada hito es la review Debe hacerse en el deadline del hito Debe mostrarse el presupuesto gastado, alcance desarrollado, Debe hacerse una demo del alcance desarrollado Debe hacerse un “freeze” del alcance una semana (u otro tiempo fijo) antes de la demo, y sólo admitir bug-fixing a partir de entonces. Hay que evitar la tentación de subir nueva funcionalidad después del freeze: Aumenta mucho el riesgo de fallar en la demo: Funcionalidad rota en el último momento, poco tiempo para probar todo. La parte más importante de la rewiew es la demo Hay que ser muy estricto con los requisitos: Si no se cumplen, TODO TODO quiero decir que los requisitos sirven para proteger al equipo de desarrollo, si estos no se cumplen, aumenta mucho el riesgo de fallar en la demo y/o el deadline. Este riesgo es inadmisible por el equipo, y por tanto debe comunicarse al cliente de que el hito no puede cumplirse. Existirá la tentación de asumir más riesgo para ayudar al cliente a cumplir con sus expectativas, pero esto es un error, ya que es mejor cancelar el hito tiempo antes del deadline, que sufrir una demo fallida. TODO añadir uat al final de cada hito Al menos un miembro del equipo debe ser senior en todas las skills necesarias Tecnología Mantenimiento y sostenibilidad de código ERROR: No controlar al cliente para que no escale sus quejas hacia arriba Cuando tenga problemas o les tenga que decir que no y se enfaden, llamar a rubén y llamar a quique Planificación por hito Planificar en sprints on kanban todo el trabajo de cada hito. Así el equipo tiene mayor visibilidad sobre toda la carga de trabajo que queda por delante. En el fondo cada hito funciona como un sprint / mini-proyecto.