testing - revisión - En un proyecto de Scrum, ¿se deben trabajar las pruebas y las revisiones por pares en cada sprint como tareas individuales?
revision por pares software ejemplo (5)
Este parece ser un punto de discordia donde trabajo. Algunos se quejan de la falta de estructura de verificación en los proyectos de Scrum, mientras que los puristas de Scrum dicen que no es de lo que se trata Scrum. Ambas partes presentan grandes puntos, pero me gustaría ver qué dicen las personas fuera de mi círculo sobre el tema. ¿Cuáles son tus pensamientos? ¿Por qué?
Debería, porque si no los ingresas explícitamente como tareas, entonces es posible que no se completen. Tan sencillo como eso.
Piense en verticales, en lugar de capas horizontales.
Si considera el diseño, la programación, las pruebas unitarias, las pruebas, etc. como capas en un pastel de desarrollo , supongo que podría ver las características (historias) que entrega como rebanadas de pastel , cada una de las cuales consiste en un pequeño diseño, código, prueba y rendimiento , etc. Esto de alguna manera gusta "balas de rastreo" del programador pragmático.
Antes del scrum, seguimos el paradigma de desarrollo de cascada que incluía revisiones de código antes de comprometer cualquier cosa con el control de la versión. Desde que pasamos al scrum, no asignamos tareas separadas para la revisión del código, ya que está implícito en las historias de desarrollo.
En un proyecto de Scrum, todo lo que debe hacerse debe ingresarse como una tarea.
Uno de los puntos clave de Scrum es poder predecir con precisión qué puede hacer un equipo en un sprint. Para hacer esto, debes contabilizar todo lo que va a consumir el tiempo de un desarrollador.
Esto significa que cosas como la documentación, las pruebas y las revisiones entre pares deben tenerse en cuenta como tareas.
Editar: Basado en la publicación de Mendelt, voy a aclarar un poco las cosas.
De la Wikipedia :
Retraso del producto: el retraso del producto es un documento de alto nivel para todo el proyecto. Contiene descripciones amplias de todas las características requeridas, elementos de la lista de deseos, etc. Es el "Qué" que se construirá. Es abierto y editable por cualquier persona. Contiene estimaciones aproximadas, generalmente en días. Este cálculo ayuda al propietario del producto a medir el cronograma y, hasta cierto punto, la prioridad (por ejemplo, si la función "agregar revisión ortográfica" se estima en 3 días frente a 3 meses, eso puede afectar el deseo del propietario del producto).
Sprint Backlog: el resumen de sprints es un documento muy detallado que contiene información sobre cómo el equipo implementará los requisitos para el próximo sprint. Las tareas se dividen en horas sin tareas que superen las 16 horas. Si una tarea es mayor a 16 horas, debe desglosarse más. Las tareas en el atraso de sprint nunca se asignan, sino que los miembros del equipo registran las tareas a su gusto.
Los elementos de la Lista de pedidos del producto no mostrarán elementos como la documentación o las pruebas, pero las tareas en la Lista de espera de Sprint deberían serlo .
Daré un ejemplo. Supongamos que hay una "Característica A" en la cartera de pedidos del Producto, y su tiempo estimado es de 1 semana. En la acumulación de Sprint, podría dividirse en las siguientes tareas:
Initial design document: 4 hours Development of subset 1 of Feature A: 8 hours Peer review of subset 1 of Feature A: 2 hours Testing of subset 1 of Feature A: 6 hours Development of subset 2 of Feature A: 8 hours Peer review of subset 2 of Feature A: 2 hours Testing of subset 2 of Feature A: 6 hours User Documentation for Feature A: 4 hours --------------------------------------------- Total time 40 hours
Editar # 2: la idea detrás de Sprint Backlog es ser lo más humanamente posible sobre exactamente dónde tienes que pasar tu tiempo. Esta es la razón por la que las tareas no pueden durar más de 16 horas y es la manera de llegar a un punto en el que puede ser muy confiable en las predicciones de su cronograma.
Si sigue los lineamientos de Sprint Backlog religiosamente y se asegura de incluir todo lo que gasta en tiempo de desarrollo, se sorprenderá gratamente de la precisión de su programación después de algunos sprints de práctica.
Una de las estructuras de verificación clave que está incorporada en Scrum es que el propietario del producto es responsable de aceptar las historias. El equipo solo obtiene crédito por la velocidad basada en la entrega de valor comercial.
Una herramienta común para los equipos de Scrum es definir las pruebas de aceptación para los elementos atrasados del producto (a menudo estos elementos atrasados vienen en forma de historias de usuarios).
Como parte de unirse como equipo de Scrum, debe responder la pregunta de qué prácticas de ingeniería usará el equipo para ayudarlo a entregar un producto de alta calidad. Scrum en sí mismo no habla de estas prácticas (creo que intencionalmente permite que estas prácticas evolucionen con el tiempo a medida que aprendemos cómo hacer las cosas mejor).
Estas prácticas pueden ser cosas como pruebas unitarias, programación de pares, revisión por pares, etc. Muchas veces estos se vuelven parte de la definición del equipo de lo que significa que se debe hacer algo. Si un equipo tiene problemas con las estimaciones o con las tareas de finalización, puede ser útil mencionarlas como tareas en la acumulación de sprints. Mi recomendación es que el proceso sea liviano; no es necesario que invoque todos los detalles (pero es necesario que tenga en cuenta el tiempo que llevará realizar los elementos de rutina en las estimaciones).