Charla ofrecida por Federico Toledo y Gabriel Montero Según la guía de Scrum, el equipo que construye es responsable de entregar incremento de producto que potencialmente pueda ser puesto en producción. Estas entregas suceden de forma iterativa, en períodos de trabajo que duran menos de un mes. Esta declaración, promueve que el equipo ponga foco en agregar valor de negocio en cada iteración, buscando tener una calidad suficiente para que la liberación se realice cuando el negocio lo requiera. ¿Qué sucede cuando el equipo descuida esto último y la calidad ya no es tan “suficiente”? En esta charla queremos compartir algunas experiencias y reflexiones sobre cómo Scrum por sí solo, sin buenas prácticas de ingeniería que acompañen, podría convertirse en nuestro peor enemigo. Gabriel Montero y Federico Toledo https://www.linkedin.com/in/gabrielmontero/ https://www.linkedin.com/in/federicotoledo/

1. Federico Toledo
@fltoledo
El día que Scrum
mató a la
calidad
Gabriel Montero
@gmonterol
QUALITY

2. ¿ESTAMOS
HACIENDO
SCRUM?
“Desarrollo trabaja en
un Sprint y nosotros
‘testeamos’ en el
Sprint siguiente”
“Desarrollo es un
equipo y Testing es
otro”
“Hacemos Scrum pero
no hacemos
retrospectivas” ...

4. 1. “No saben lo que quieren”

5. USER STORIES
ACCEPTANCE CRITERIA

6. CARACTERÍSTICAS DE LAS
BUENAS USER STORIES

8. “Only conducting performance
testing at the conclusion of system
or functional testing is like
conducting a diagnostic blood test
on a patient who is already dead.”
— Scott Barber

9. www.scrumpractitioners.nl

10. 2. “No llegamos con lo prometido”

11. “El problema es que
somos malos
estimando.”
— Dijo un Manager

13. DOS / TRES DÍAS PARA
TERMINAR

14. 3. “No tuvimos tiempo de probar todo”

15. DECIDO NO HACER
NO TENGO TIEMPO

16. ¿Qué dejo
sin
probar?

17. TESTING BASADO EN
RIESGOS
Costos por fallas Costos por testing
Esfuerzo de testing

18. Baja
Probabilidad
Alto
Impacto
Alta
Probabilidad
Alto
Impacto
Baja
Probabilidad
Bajo
Impacto
Alta
Probabilidad
Bajo
Impacto

19. Baja
Probabilidad
Alto
Impacto
Alta
Probabilidad
Alto
Impacto
Baja
Probabilidad
Bajo
Impacto
Alta
Probabilidad
Bajo
Impacto

20. Baja
Probabilidad
Alto
Impacto
Alta
Probabilidad
Alto
Impacto
Baja
Probabilidad
Bajo
Impacto
Alta
Probabilidad
Bajo
Impacto
MOSCOW
MUSTSHOULD
COULDWONT

21. MOSCOW
Test Case #1 M
Test Case #2 S
Test Case #3 M
Test Case #4 C
Test Case #5 S
Test Case #6 M
MIND
MAP
Recomendado: Charla en TestingUy de Claudia Badell
www.claudia-badell.com

22. 4. “Tuvimos que sacarlo sin probar”

25. To Do Dev (2) Test & fix (2) Done
Story #6
Story #5 Story #4
Story #3
Story #1
Story #2Story #7
Story #8
Story #9

26. 5. ¿Alguien llegó a testear esto?

27. QA = QUALITY ASSURANCE

28. ¿Cuál es la
calidad del
proceso de
desarrollo?

29. DEFINITION OF DONE

30. RETROSPECTIVA

31. RETROSPECTIVA

32. ¡No nos crean
nada!
- @ l e o b a j e r

33. Federico Toledo
@fltoledo
Gabriel Montero
@gmonterol
¡GRACIAS!
El día que Scrum
mató a la calidad

34. ALGUNAS REFERENCIAS
www.federico-toledo.com
Curso:
6 y 7 diciembre (Uruguay): “Técnicas
de testing para equipos ágiles” por
Abstracta y Peregrinus