Introducción: En teoría, Scrum dice que el equipo de desarrollo es completamente responsable y autoorganizado cuando se trata de todo lo relacionado con el desarrollo. Esto también incluye la calidad del código que, en mi humilde opinión, es el resultado de CI, pruebas automatizadas y más.
Escenario: un Product Owner de Scrum es responsable de algún producto de software. La calidad ha disminuido últimamente debido a la creciente complejidad.
Pregunta: ¿Cómo puede el propietario del producto Scrum influir en el desarrollo de una manera que se centre más en la calidad? Los elementos de la cartera de productos son características que tienen un valor directo para el cliente. La calidad del código solo tiene un valor indirecto para el cliente. ¿Puede el propietario del producto obligar al equipo de desarrollo a aumentar la calidad, por ejemplo, mediante el uso de CI, más/mejores pruebas automatizadas,...?
El propietario del producto tiene la responsabilidad de la acumulación y el equipo de desarrollo tiene la responsabilidad de la entrega. Sin embargo, en Scrum trabajamos en equipo y no hay nada que impida que el Product Owner discuta inquietudes sobre la entrega con el equipo de desarrollo. Del mismo modo, no hay nada que impida que el equipo de desarrollo discuta las preocupaciones sobre la acumulación con el propietario del producto. Favorecemos la colaboración sobre la negociación de contratos .
En su situación, la clave es tratar de influir en el equipo de desarrollo para mejorar la calidad de su código en lugar de obligarlos a hacerlo.
Sugeriría algunos o todos los siguientes:
Obligar al equipo de desarrollo a hacer algo puede funcionar a corto plazo, pero existe el peligro de que vuelvan a caer en viejos patrones de comportamiento. Un mejor enfoque es lograr que el equipo de desarrollo valore la calidad tanto como usted.
El propietario del producto puede agregar lo que quiera a la cartera de pedidos.
Es decir.
Configurar un servidor de compilación de CI
Agregue pruebas unitarias hasta que tenga una cobertura de código del 90 %
Sin embargo, la justificación comercial de estas cosas es bastante vaga y gira en torno a la productividad del equipo de desarrollo.
Si el equipo aún no está haciendo estas cosas en un 'sprint cero', necesitan algo de entrenamiento o algo de tiempo para hacerlo.
Aunque puede aplicar scrum al 'proyecto: configure un equipo de desarrollo', generalmente se supone que tiene un equipo y que tienen las herramientas, computadoras, licencias de software, escritorios, una oficina, etc. que necesitan para comenzar a trabajar en 'proyecto: escríbeme un programa' .
En estos días, un entorno de operaciones de desarrollo automatizado con varios entornos, control de fuente, pruebas unitarias y un servidor de compilación ci debe considerarse parte de ese conjunto de herramientas.
Me interesaría saber a qué te refieres con calidad. ¿Errores o algo más?
Si las preocupaciones están relacionadas con la calidad que es visible para el usuario final, entonces me centraría en lo que usted, como propietario del producto, puede hacer para definir mejor los criterios de aceptación de sus historias para evitar que los problemas que tiene se solucionen. aceptado.
Su función, como propietario del producto, es dar una dirección clara y proporcionar comentarios continuos sobre el trabajo completado. Asegúrese de que usted y su equipo se comuniquen regularmente sobre sus objetivos y sobre los criterios de aceptación de la historia, y asegúrese de brindar una buena dirección y comentarios honestos sobre el trabajo completado. Asegúrese de que su equipo entienda que deben acudir a usted regularmente para discutir cualquier pregunta con respecto a la ejecución y para aclarar cualquier ambigüedad en las historias/tareas. Asegúrese de estar disponible para escuchar y responder estas preguntas.
Más específicamente, aquí hay un par de formas de lidiar con diferentes problemas de "calidad":
Si se trata de errores, trabaje en su definición de hecho para garantizar que las funciones se prueben correctamente, incluidas las pruebas de regresión a medida que se integran. Trabaje en sus propias habilidades para escribir historias y cómo define y comunica las pruebas de aceptación de sus historias. Finalmente, si los requisitos para la prueba y la integración son claros, y la Definición de Listo impide que se acepte el código con errores, y el equipo no logra esto, discuta el problema con su equipo en la próxima retrospectiva y trabaje con ellos para abordarlo. Además, asegúrese de utilizar a su Scrum Master, quien debería intentar descubrir qué impide que los equipos puedan probar correctamente el trabajo realizado durante una iteración.
Si lo que quiere decir con un problema de calidad no son errores, sino algo más, como una solicitud de información que tarda demasiado en ejecutarse, o una interfaz de usuario que no es cohesiva entre pantallas, o algo de esa naturaleza, aquí hay algunos consejos. para manejar este tipo de problemas:
En primer lugar, céntrese de nuevo en desarrollar un mejor DOD y definir mejor las pruebas de aceptación durante la preparación del backlog y la planificación del sprint. Además, trabaje con su Scrum Master para asegurarse de que el equipo comprenda completamente sus responsabilidades. Si algo es ambiguo o poco claro, los desarrolladores son responsables de ponerse en contacto con el propietario del producto o el cliente para discutirlo y aclararlo. Idealmente, todo se aclara durante la planificación del Sprint, pero puede que no siempre sea así, y es importante que los desarrolladores sepan que son responsables de aclarar los requisitos y los criterios de aceptación de una historia o tarea discutiéndolo con el PO (o directamente con el cliente/usuario final).
En segundo lugar, si esta funcionalidad ya existe (por ejemplo, era parte de una historia anterior que ya fue aceptada) y simplemente no está satisfecho con la ejecución, simplemente cree otra historia para aclarar qué es lo que desea. Por ejemplo, si las solicitudes tardan demasiado en devolver información, escriba una historia "Quiero que X suceda rápidamente" y luego siga los consejos anteriores para trabajar con su equipo y aclarar qué será aceptable para satisfacer "rápidamente". O si el problema es con la interfaz de usuario, escriba una historia "La interfaz de usuario debe ser coherente al cambiar de pantalla". Una vez más, la aclaración de cualquiera de los dos tendría lugar idealmente durante la planificación del Sprint o la preparación del trabajo pendiente, ya que el equipo hace preguntas para estimar la historia o cuando comienzan a dividirla en tareas para ejecutar.
Finalmente, recuerde que son un equipo y que se reúnen regularmente para discutir y mejorar su proceso. Si cree que el equipo se beneficiaría de la integración continua, la programación en pares o alguna otra herramienta o estrategia de desarrollo, lo sugeriría durante una retrospectiva como algo que podría valer la pena probar. Sin embargo, en última instancia, depende del equipo de desarrollo decidir cómo quieren desarrollar. Como PO, usted es responsable de establecer los requisitos para el usuario final, y el equipo es responsable de desarrollar las soluciones para dichos requisitos.
Todd A. Jacobs
Tomas Owens