Comprensión de Scrum

Question

He estado trabajando como desarrollador de .net siguiendo el modelo de cascada. Cuando estoy trabajando, digamos un proyecto de 12 meses, generalmente mi equipo sigue las fases de Análisis, Diseño, Codificación y Pruebas. Pero cuando se trata de seguir el proceso de Scrum, realmente no entiendo cómo debo enfrentarlo.

Considere un esprint durante 4 semanas y la acumulación tiene 10 elementos. Deje que el sprint comience ahora. Si los desarrolladores están trabajando en algunos elementos atrasados ​​durante los primeros 10 días, no sé si las pruebas (tanto SIT como UAT) requerirán SÓLO los 10 días restantes para completar el trabajo. Y ahora nuestro sprint no tiene tiempo para correcciones de errores de última hora y solo algunos errores podrían solucionarse EN EL SPRINT PLANEADO.

Y cuando hacemos desarrollo, ¿cómo podemos asegurarnos de mantener al equipo de pruebas ocupado aparte de solo preparar casos de prueba y esperar a que entreguemos la funcionalidad?

Esto plantea una pregunta si tenemos que entregar la primera tarea/función dentro de los primeros 3 días del sprint, para que los probadores puedan estar listos con sus casos de prueba para probar esa pieza.

También necesito educar a mi cliente para que me ayude a adaptar el proceso de Scrum.

Necesito algunas pautas, referencias o un estudio de caso para asegurarme de que nuestro equipo siga un proceso de Scrum adecuado. Cualquier ayuda sería apreciada.

Answer 1

En un equipo ideal Scrum, testers y desarrolladores son parte de el equipo y las pruebas deben producirse en paralelo del desarrollo, las fases se solapan, no secuencial (hacer las cosas de forma secuencial dentro de un Sprint es un anti patrón conocido como Scrumerfall). Y, por cierto, contrariamente a algunas opiniones expresadas aquí, una implementación definitiva de Scrum produce historias DONE DONE, por lo que las pruebas, incluyendo IST, UAT, deberían realizarse durante el Sprint.

Y no, los probadores no tienen que esperar a que elementos de la Pila de Producto (PBI) que se aplique plenamente a empezar a hacer su trabajo, puede empezar a escribir pruebas de aceptación scenarii, automatizar ellos (por ejemplo, con buena condición física), establecido subir el conjunto de datos de prueba, etc. (esto toma algo de tiempo, especialmente si el negocio es complicado) tan pronto como comience Sprint.

Por supuesto, esto requiere una colaboración muy estrecha y la liberación de interfaces o esqueletos UI temprano facilitará el trabajo de los probadores pero, aún así, los probadores no tienen que esperar a que se implemente completamente una PBI. Y, en realidad, los desarrolladores deben usar pruebas de aceptación como indicador de DONEness ("Sé que he terminado cuando se aprueben las pruebas de aceptación") .

No digo que esto sea fácil, pero eso es lo que están haciendo las implementaciones de Scrum maduras (es decir, Lean) y los equipos de Scrum maduros.

Sugiero leer Scrum And XP from the Trenches por Henrik Kniberg, esta es una muy buena guía práctica.

_{Como escribe María Poppendieck, el trabajo de los probadores debería ser prevenir defectos (esenciales), por no encontrar defectos (residuos).}

Answer 2

El sprint no termina con un código perfecto; si hay errores restantes, pueden ir en el próximo sprint, y algunos de los otros elementos que tendrían en el próximo sprint tendrán que ser eliminados. No estás deteniendo un sprint con algo perfecto, pero idealmente, con algo estable.

Answer 3

Está (irónicamente) aplicando demasiado rigor al proceso. El objetivo de un proceso ágil como el scrum es que el cronograma sea dinámico. Después de su primer sprint, usted trabaja con el equipo de usuarios/pruebas para evaluar el progreso. En ese momento, le pedirán que cambie los detalles y las funciones que le fueron entregados en el primer sprint, o le pedirán que haga más trabajo. Depende de ellos.

Es sólo con el tiempo, una vez que haya determinado la velocidad del equipo (es decir. ¿Cuántas historias se puede lograr razonablemente en un sprint) que puede empezar a estimar las fechas y cosas para proyectos más grandes

Answer 4

En primer lugar, no todos los Sprint producen un lanzamiento grande (si es que lo hacen). Es totalmente aceptable que los primeros sprints produzcan prototipos/versiones alfa tempranas, que no se espera que estén libres de errores, pero que aún así sean capaces de mostrar algo al cliente. Este algo ni siquiera puede ser una característica, simplemente puede ser una interfaz de usuario básica, solo para que el usuario vea cómo se verá y cómo funcionará.

Además, los propios desarrolladores pueden (y generalmente lo hacen) escribir pruebas unitarias, por lo que todo lo que se entregue en un sprint debería estar en un estado de trabajo bastante estable. Si una nueva característica está medio cocida, el equipo simplemente no debería entregarla. Se supone que las características grandes se dividen en trozos lo suficientemente pequeños para caber dentro de un único sprint.

Answer 5

Definitivamente no quiere hacer todo el desarrollo en la primera mitad del sprint y todas las pruebas en la segunda mitad. Esa es solo una cascada más pequeña.

Sus historias y tareas se deben dividir en piezas muy pequeñas y discretas de funcionalidad. (Puede tomar un tiempo acostumbrarse a hacer esto, especialmente si el software en el que está trabajando es una bestia monolítica, como un trabajo previo mío que pasó a usar scrum.) Al comienzo del sprint, los probadores están desarrollando sus pruebas y los desarrolladores están desarrollando su código, y durante todo el sprint las tareas y las historias se completan y prueban. Debe haber una interacción bastante constante entre ellos.

El final de la Sprint puede sentir un poco agitado mientras se está acostumbrando a la metodología. Los desarrolladores se sentirán abrumados mientras trabajan en el resto del código y, al mismo tiempo, los probadores les darán errores para corregir. Los probadores se impacientan porque ven que se acerca el final del sprint y todavía hay un código que no se ha probado. Hay una curva de aprendizaje y tomará un tiempo acostumbrarse, la empresa debe ser consciente de esto.

Es importante que los desarrolladores y probadores realmente trabajen juntos para crear sus estimaciones, no solo sumen las cifras de los demás para formar un total. Los desarrolladores deben ser conscientes de que no pueden planear la codificación de nuevas funciones hasta el último minuto, porque eso deja a los evaluadores allí durante el fin de semana para hacer su trabajo apurado, lo que acabará recayendo en los desarrolladores que vendrán. y cosas de corrección, etc.

tendrán que ser re-definido a lo largo de la manera Algunas tareas. Algunas historias fallarán al final del sprint. Está bien, lo conseguirás en el próximo sprint. La reunión de planificación al comienzo de cada sprint es donde se definirán esas historias/tareas. Recuerde ser paciente con los demás y asegurarse de que la empresa sea paciente con el cambio en el proceso. Pagará en el largo plazo, no en el primer sprint.

Answer 6

Un equipo de Scrum suele ser multifuncional, lo que significa que todo el equipo es responsable de construir las piezas completas de funcionalidad de cada Sprint. Entonces, si los evaluadores de QA no terminaron las pruebas, solo significa que el equipo de Scrum no terminó la prueba. Scrum cuenta con que todos hagan su parte.Cuando sea necesario, las personas con esas habilidades toman la iniciativa, pero todas tienen que hacer su parte.

Answer 7

Intente hacer una integración continua. El equipo debe tener este hábito e integrarse continuamente. Además, contar con un conjunto de pruebas de unidades automatizadas, construido y ejecutado después de cada check-in/entrega, debe proporcionar cierto nivel de confianza en su base de códigos. Esta práctica asegurará que el equipo tenga un código en buen estado de funcionamiento y en todo momento. También permitirá la integración y la prueba del sistema al principio del sprint.

La definición y creación (automatizada) de pruebas de aceptación mantendrán a las personas con habilidades primarias de control de calidad ocupadas e involucradas desde el comienzo del sprint. Asegúrese de que esto se haga en colaboración con los propietarios del producto para que todos estén en la misma página e involucrados.

Answer 8

Comenzamos nuestro proyecto ágil con los desarrolladores primero (mucho entrenamiento en Enterprise Framework, etc.) en el primer sprint. Luego agregamos control de calidad lentamente en el segundo sprint. Al final del sprint 2, QA comenzó a probar. Al acercarse al final del sprint 3, QA había acelerado el ritmo y estaba más o menos al lado de los desarrolladores. Desde el sprint 4 y out, QA se realiza más o menos con pruebas cuando los desarrolladores han completado las historias. Los elementos que generalmente se dejan para evaluar son los grandes elefantes que incluyen la replicación de datos entre el sistema nuevo y el heredado. Y es más un 'asegurar datos está bien' en lugar de pruebas reales.

Estamos teniendo algunos problemas con nuestra definición de Hecho. P.ej. no tenemos ninguno Estamos trabajando en una versión completamente nueva de un sistema, y ​​ahora que nos estamos acercando al final del sprint 6, nos estamos preparando para su implementación en la producción. Sprint 6 es en realidad algo que yo llamaría una pequeña cascada. Hemos reducido el número de elementos para implementar para garantizar que tengamos tiempo suficiente para gestionar los posibles nuevos problemas que surjan. Tenemos un congelamiento de código, y los desarrolladores básicamente comenzarán en el próximo sprint y corregirán problemas en la rama de necesario.

El propietario del producto está en la parte superior de la entrega, por lo que espero que no haya problemas con respecto a lo que implementamos.

Veo que Pascal escribe sobre equipos de sprint maduros + la definición de Listo. Y ágil, siempre concéntrese en 'la entrega inmediatamente después de que el sprint haya llegado a su fin'. Sin embargo, no estoy seguro de si hay muchos equipos en el mundo que realmente están haciendo esto. Al menos todavía no estamos :)

Answer 9

No hay ningún equipo de pruebas en Scrum. Su equipo de desarrollo que es multifuncional. Scrum desalienta a los especialistas en el equipo para evitar dependencias. Entonces, el rol de tester es algo diferente en Scrum que en Waterfall. Es otro debate, pero por ahora vamos a apegarnos a la pregunta que nos ocupa.

Le sugiero que recorte las historias verticalmente en las tareas más pequeñas que pueda durante la parte de la reunión de planificación del sprint. Se recomienda dividir las tareas en unidades pequeñas para que puedan completarse en uno o dos días.

Defina un DoD al inicio del proyecto y siga refinándolo. Trabaja en una tarea a la vez y limita el trabajo en progreso. Trabaje en orden de prioridad y reduzca los desperdicios en su sistema. No busque una planificación inicial detallada y postergue sus mejores decisiones hasta el momento menos responsable. Introduzca las competencias técnicas como BDD y Automatización.

Y recuerde que la calidad es responsabilidad de todo el equipo, por lo tanto, no se preocupe si las pruebas son realizadas por una persona dedicada.