Es posible que herede un nuevo equipo que había jugado con Scrum pero que no encontró el enfoque correcto (en gran parte debido a la naturaleza paralela y no secuencial de los proyectos empresariales).
Están trabajando en un sistema Kanban bastante efectivo, pero el equipo de desarrollo no está contento. En roles anteriores, trabajaron en estrecha colaboración con los clientes y ahora son solo desarrolladores (sus palabras) que informan a un Product Owner o Project Manager que articula los requisitos del cliente.
Desafortunadamente, esto ha provocado una serie de retrasos en el proyecto, ya que la información técnica o las advertencias de los desarrolladores se ignoran hasta que el director del proyecto debe volver con el rabo entre las piernas al cliente comercial y explicar que los plazos no eran realistas.
Me han pedido que explore la viabilidad de un equipo de desarrollo en el que, teóricamente, cada desarrollador podría ser asignado a una serie de proyectos y estar fuertemente integrado en la recopilación de requisitos y la generación de trabajos pendientes junto con el Gerente de Proyecto o el Propietario del Producto. La gerencia quiere saber si ese enfoque sigue siendo "ágil", lo que parece ser una fijación.
El Propietario de Producto sénior todavía decidiría la prioridad de los proyectos que ingresan al entorno, pero los desarrolladores serían responsables de la prioridad de las tareas dentro de cada proyecto junto con un PM/PO adjunto.
¿Qué prácticas llevarían al éxito potencial de tal sistema?
Sé que la tentación para algunos puede ser obsesionarse con la parte "Scrum no funcionó" o la parte "desarrollador no está contento" de la pregunta, pero di esa información por contexto. Me siento confiado en cambiar la moral del equipo y mejorar la autoestima de cada individuo. Estoy ansioso por explorar si un ex equipo de Scrum puede sobrevivir cuando a cada desarrollador se le permite recopilar / volver a priorizar los requisitos junto con un propietario del producto.
Sé que esta pregunta es un tanto teórica y un poco más pesada que la tarifa normal en SE.PM, pero sentí que si alguien pudiera obtener el costo-beneficio de tal enfoque, estaría aquí. :-)
Creo que la cuestión de la "recopilación de requisitos" se basa en un malentendido de los principios ágiles involucrados, y especialmente de cómo se crean las historias de usuario y cómo los detalles de una historia deben desarrollarse en una implementación. Simplemente reformular adecuadamente las expectativas de todos puede ser de gran ayuda.
Si bien puede no ser factible tener 10 desarrolladores que actúen como analistas comerciales simultáneamente, no hay razón para que los desarrolladores no puedan participar en el proceso de redacción de historias, en las discusiones de refinamiento de la acumulación o en la colaboración directa con los clientes. De hecho, el Manifiesto Ágil declara explícitamente que la colaboración del cliente es un valor central, pero deja que el marco y el equipo identifiquen las mejores formas de implementar dicha colaboración.
Ofrezco un análisis en la siguiente sección y algunas recomendaciones prácticas para colaborar de manera efectiva en la sección final a continuación.
Una historia de usuario no es una especificación ni un conjunto de requisitos (consulte "Ventajas de las historias de usuario para los requisitos" § Las historias de usuario no son declaraciones de requisitos ). Más bien, una historia de usuario es un marcador de posición estructurado para una conversación sobre cómo implementar mejor una función determinada.
Incluso dentro de Scrum, que tiene una definición bastante rígida de los roles dentro del Equipo Scrum, no hay nada en la descripción del rol del Propietario del Producto que impida que el Equipo de Desarrollo aclare la intención de una historia de usuario o colabore directamente con el cliente. El propietario del producto debe participar en la recopilación de requisitos y el desarrollo de historias de usuarios para que pueda priorizar correctamente la cartera de productos, pero se supone que esta es una forma de estructurar las prioridades del proyecto en lugar de una barrera de comunicación.
La Guía Scrum dice:
El Product Owner es una persona, no un comité. El propietario del producto puede representar los deseos de un comité en la cartera de productos, pero aquellos que deseen cambiar la prioridad de un elemento de la cartera de productos deben dirigirse al propietario del producto.
El enfoque aquí está en la priorización de historias y, por extensión, la asignación de recursos del proyecto para cada iteración. El uso común del Propietario del Producto como representante de comunicaciones para un cliente ausente ciertamente no es obligatorio en el marco.
De hecho, en Programación Extrema el cliente siempre debe estar disponible para el equipo. Además, se espera que colaboren activamente con el equipo de desarrollo, como se ilustra en esta cita directa:
Debido a que los detalles se dejan fuera de las historias de los usuarios, los desarrolladores deberán hablar con los clientes para obtener suficientes detalles para completar una tarea de programación. Los proyectos de cualquier tamaño significativo requerirán un compromiso de tiempo completo por parte del cliente.
Se deben recopilar los requisitos, pero depende de cada proyecto determinar cómo debe suceder. Lo importante es que las historias de usuario no se traten como requisitos fijos o especificaciones detalladas, sino como un contexto bien enmarcado para una mayor elaboración y colaboración con el cliente.
Es preferible la colaboración del cliente a lo largo de la iteración, siempre que no cambie de forma invisible el objetivo o el alcance de la iteración actual. Los cambios en el alcance deben abordarse a través del marco, no a través de canales secundarios.
Este punto se puede hacer incluso un poco más general e independiente del marco. La preocupación es la posibilidad de que las comunicaciones de canal lateral puedan eludir los acuerdos existentes o introducir requisitos conflictivos, es decir, requisitos que satisfacen las necesidades de una parte interesada sin tener en cuenta el efecto sobre otras partes interesadas o sobre la experiencia del usuario del sistema en su conjunto.
Este riesgo se puede mitigar manteniendo a las personas apropiadas (propietario del producto, gerente del proyecto) al tanto: no necesariamente presentes en todas las reuniones, pero conscientes de los temas generales discutidos.
Por ejemplo: en uno de mis proyectos, soy el líder de desarrollo y tengo una contraparte que es el líder del cliente. Se alienta a los clientes a que se comuniquen directamente conmigo y con mis desarrolladores, lo que prefieren, porque es más eficiente, siempre que mantengan informados a sus clientes potenciales. De vez en cuando se olvidan y la invito. (Hacemos muchas cosas por correo electrónico, por lo que es bastante fácil enviar un cc a las personas adecuadas). Ella conoce el panorama general del lado del cliente y yo lo sé del lado del desarrollador. Hay un acuerdo explícito en el que no se compromete nada sin la aprobación de ambos. En las raras ocasiones en que no podemos llegar a un acuerdo, acudimos a la alta dirección y dejamos que ellos decidan. Es informal y eficaz.
Situación interesante. Mi mayor preocupación al leer el escenario es que tiene 1 persona (un desarrollador) con múltiples funciones (¿BA, PO, probador?) con muy poca responsabilidad potencial.
Lo más importante para este tipo de entorno sería garantizar que todo sea muy transparente y ayudar a los desarrolladores a evitar la trampa de pasar de ser un equipo a un grupo de trabajo con la propiedad de las historias en silos.
Probablemente miraría hacer algún tipo de Scrum-ban. Trabajos atrasados del tamaño de una historia, pero trabajando en un tablero kanban con límites WIP y mucha atención a los tiempos de ciclo en cada segmento de punto de la historia. Probablemente también sería bastante granular en el tablero kanban para diseñar claramente lo que está sucediendo en las áreas de proceso donde cada especialidad hace su trabajo.
visión y priorización del propietario del producto, detalles del analista comercial, código precomprometido del desarrollador, código postcomprometido del desarrollador, control de calidad manual y cualquier actividad de preparación o integración que también sea compatible.
Consideraría usar las 3 ceremonias de Scrum, pero considere flexibilizar la duración de la iteración hasta una semana para que el equipo pueda adaptarse a las prioridades que cambian rápidamente. Dependiendo de la madurez del equipo, las retrospectivas/revisiones podrían ser más informales.
Finalmente, dividiría el trabajo en prioridades altas, medias y bajas en lugar de clasificar, y establecería límites sobre la cantidad de tiendas de alta prioridad que pueden estar en una iteración para forzar una discusión constante sobre lo que es más importante lograr durante la iteración.
aventura2099