Actividad 2 - Diagrama de Gantt para proyecto LeSS



Problemática


La empresa Audi  cuenta con la mayoría de sus software ya  aprobados por la directiva en el área de producción. En el área administrativa, desean un sistema hecho a la medida, usted está liderando el proyecto, por lo que le piden una propuesta del proyecto desde el modelo de desarrollo hasta la última etapa que es la puesta en marcha del mismo. Presente el proyecto en un diagrama de Gantt con todas las etapas a realizar según el modelo de desarrollo que elija.
Tome en cuenta que tiene recursos ilimitados menos el tiempo, ya que tiene un año natural exactamente para la puesta en marcha de la planta y por supuesto del sistema administrativo que incluye contabilidad, recursos humanos y CRM.


Propuesta


Para poder realizar un Sistema a la medida, que parte de un conjunto de requerimientos y funcionalidades base (las que integran a todo sistema de contabilidad, de recursos humanos, y a todo CRM), pero que debe ser adaptado a las necesidades específicas de la planta Audi que iniciará operaciones dentro de un año, he decidido implementar un modelo de desarrollo ágil con la metodología Scrum, apoyado con el framework LeSS. De esta manera podemos integrar varios equipos Scrum que trabajan en conjunto con un solo objetivo. He decidido comenzar con 5 equipos Scrum, cada uno con 7 integrantes, un equipo por cada componente principal del sistema (Contabilidad, RH, CRM), un equipo para infraestructura y soporte, y otro equipo para centro de excelencia (encargados de aportar conocimientos y asesoría en las diferentes tecnologías que el equipo usará, así como apoyar en actividades de revisión de código, peer review, y pair programming). A medida que progresan las iteraciones, consideraré la posibilidad de agregar un par de equipos, en caso de ser requerido.
El proyecto se desarrollará en 17 iteraciones de 3 semanas cada una. Mi rol va a ser de Project Manager, para la coordinación de los esfuerzos. Entre mis actividades se encuentra: Formación de los equipos, Administración de Riesgos, Monitoreo de Actividades, Coordinación con las partes interesadas, Team Building, Facilitador.


Con lo planteado anteriormente, ahora pasaremos a representar la planeación general del proyecto utilizando un Diagrama de Gantt. El diagrama de Gantt es una herramienta que permite modelar la planificación de las tareas necesarias para la realización de un proyecto. En un diagrama de Gantt, cada tarea es representada por una fila, mientras que las columnas representan los días, semanas o meses, dependiendo de la duración del proyecto.


El proyecto se ha dividido en 17 iteraciones, cada una de 3 semanas. Todas las iteraciones cuentan con:
  • Sprint Planning 1: Donde se hace la planeación de las tareas a completar en la iteración, a nivel proyecto (con todos los equipos)
  • Sprint Planning 2: Donde cada equipo realiza su propia planeación
  • Design Workshop: Para el diseño de las soluciones
  • Development: El desarrollo tal cual de las funcionalidades
  • Quality Assurance: Tareas para asegurar la calidad que incluye pruebas unitarias, pruebas funcionales, pruebas de integración, y pruebas de regresión
  • Continuous Delivery and Integration: Control de versiones, administración de repositorio, y otras actividades para sincronizar código y despliegue de nuevas funcionalidades.
  • Documentation: Tanto documentacion tecnica como de usuario
  • Daily Scrum: Junta rápida donde cada miembro del equipo comparte sus avances, planes e impedimentos.
  • Product Backlog Refinement: Para revisar las funcionalidades pendientes de implementar, clasificarlas y redefinir las tareas que serán tomadas en las siguiente iteraciones.
  • Sprint Review: Espacio utilizado para presentar el producto resultante de la iteración, a las partes interesadas y obtener retroalimentación.
  • Team Retrospective: Junta para revisar lo que se hizo bien en la iteración, lo que debe mejorarse y los posibles experimentos.
  • Overall Retrospective: Junta de retrospectiva para el proyecto en general, con todos los equipos.


En el plan no hay distinción clara entre los subsistemas  (Contabilidad, RH, CRM), ya que en LeSS todo es considerado parte de un mismo esfuerzo, y es desarrollado al mismo tiempo por los diferentes equipos, y bajo la misma planeación como un solo equipo colaborando hacia una misma meta.


p1.PNG
Nota: En el Sprint 0 se dedica más tiempo a la planeación inicial.
p2.PNG
Nota: Este mismo plan continúa igual hasta la iteración 8
p3.PNG
Nota: A partir de la iteración 8 se introduce el entrenamiento a los usuarios del sistema. Esto sirve también para captar retroalimentación de los usuarios finales, lo cual puede impactar en las decisiones del Product Owner. Se continua con el mismo plan hasta la iteración 14.


p4.PNG
Nota: El entrenamiento a los usuarios se intensifica en las iteraciones 14 y 15. A partir de la iteración 15 se introduce la Transición a Mantenimiento (T2M), lo cual consiste en capacitar al equipo que se hará cargo del soporte y mantenimiento del sistema por el resto de su vida operable.
p5.PNG
Nota: Se concluye el proyecto en la iteración 16, y la última semana se dedica a la transición formal del sistema, del equipo de desarrollo al equipo de mantenimiento.


Puntos a considerar sobre Scrum y LeSS
  • La mayoría de los equipos están enfocados en las funcionalidades centradas en el cliente.
  • Cada equipo es auto manejable y multidisciplinario
  • El Scrum Master se enfoca en los equipos, el Product Owner, la organización y las prácticas de desarrollo. No se enfoca en solo un equipo sino en sistema organizacional en general.
  • Scrum Master es un rol dedicado y de tiempo completo. Un Scrum Master puede servir de 1 a 3 equipos.
  • En LeSS, los Managers son opcionales, pero en caso de existir su enfoque va desde administrar el dia a dia en el desarrollo del proyecto hasta la mejora de la capacidad de entrega de valor.
  • Solo hay un Product Owner y un Product Backlog (lista de funcionalidades deseadas) para todo el proyecto, sin importar cuantos equipos existen.
  • El Product Owner no debe trabajar solo en el Product Backlog. Debe ser soportado por múltiples equipos trabajando directamente con los clientes, usuarios y partes interesadas.
  • Toda la priorización de las tareas es decidida por el Product Owner, pero la clarificación, en medida de lo posible, es de forma directa entre los equipos con los cliente o usuarios,
  • La definición de “hecho” es única para todos los equipos. Cada equipo puede tener su propia definición mejorada de “hecho”, al expandir la original.
  • Existe un Sprint (iteración) a nivel de producto, en lugar de diferentes Sprint para cada equipo. Todos los equipos inician y acaban el Sprint al mismo tiempo. Cada Sprint resulta en un solo producto integrado.
  • La planeación del Sprint, consiste de dos partes: Sprint Planning One, que es común para todos los equipo, y Sprint Planning Two que es usualmente realiza de forma separada para cada equipo. También existen Multi-Team Sprint Planning Two, cuando varios equipos tienen tareas muy relacionadas o dependientes.
  • Sprint Planning One es atendida por el Product Owner y los equipos, o representantes de los equipos. Juntos seleccionan los elementos que cada equipo va a trabajar en el Sprint. Los equipos identifican oportunidades para trabajar juntos y las últimas preguntas son clarificadas.
  • Cada equipo tiene su propio Sprint Backlog (tareas para la iteración)
  • Cada equipo tiene su propio Daily Scrum (Junta rápida donde cada miembro comenta lo que trabajo desde la última junta, lo que va a trabajar y si tiene impedimentos).
  • La coordinación entre equipos es decidida por los mismos equipos. Preferir coordinación descentralizada e informal sobre coordinación centralizada.
  • Hay solo un Sprint Review (revisión de la iteración) para todos los equipos.
  • Cada equipo tiene su propio Sprint Retrospective (junta de retrospectiva)
  • Se realiza un Retrospectiva General después de que cada equipo tuvo su propia retrospectiva, para discutir problemas entre equipos o defectos al nivel del sistema general, y crear experimentos de mejora.

Referencias Bibliográficas


  • Scrum: Novice to Ninja

By: M. David Green
Publisher: SitePoint
Pub. Date: January 26, 2016
Print ISBN-13: 978-0-9943469-1-9


  • Large-Scale Scrum: More with LeSS

By: Craig Larman; Bas Vodde
Publisher: Addison-Wesley Professional
Pub. Date: August 10, 2016
Print ISBN-13: 978-0-321-98571-2

Comentarios

Entradas populares de este blog

U3 - 1. Naturaleza de la negociación

U3 - 5. Estrategia y técnicas de negociación integrativa

U3 - Ensayo de la negociación