15. Profesionales que entregan un Incremento de
producto “Terminado”, que potencialmente se
pueda poner en producción, al final de cada
Sprint.
• Auto organizados
• Multifuncionales
• No hay “títulos”
• Sin Sub-equipos
• Hay especializaciones pero la responsabilidad es colectiva
16. •¡El equipo es el que
estima!
•El PO pone énfasis en
el valor para el negocio
•El SM defiende al
equipo
Recordemos roles
17.
18.
19.
20.
21.
22.
23.
24.
25.
26. • Visualiza el flujo de trabajo
• Limita el WIP (Work in Progress, trabajo en curso)
• Ayuda a que el trabajo fluya
• Haz las políticas de proceso explicitas (definición
de Terminado p.ej)
• Implementa ciclos de feedback
• Mejora colaborativamente, evoluciona
experimentalmente (modelos y datos científicos)
Notas do Editor
Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo cómo convertir elementos de la Lista del Producto en Incrementos de funcionalidad potencialmente desplegables;
Los Equipos de Desarrollo son multifuncionales, contando como equipo con todas las habilidades necesarias para crear un Incremento de producto;
Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo, todos son Desarrolladores, independientemente del trabajo que realice cada persona; no hay excepciones a esta regla;
Scrum no reconoce sub-equipos en los equipos de desarrollo, no importan los dominios particulares que requieran ser tenidos en cuenta, como pruebas o análisis de negocio; no hay excepciones a esta regla; y,
Los Miembros individuales del Equipo de Desarrollo pueden tener habilidades especializadas y áreas en las que estén más enfocados, pero la responsabilidad recae en el Equipo de Desarrollo como un todo.
El trabajo en curso (Work In Progress, WIP) debería limitarse, y sólo deberíamos empezar con algo nuevo cuando un bloque de trabajo anterior haya sido entregado o ha pasado a otra función posterior de la cadena
El trabajo debe hacerse visible