Introduction To Scrum
Primero es recomendable leer:
Qué soluciona Scrum
Tu cliente necesita
- Tener resultados a corto plazo
- Cambiar a menudo los requisitos del proyecto
- Ver si se cumplen sus expectativas
Tu quieres
- Equipos altamente productivos y motivados
- Solucionar los problemas que impiden que los equipos progresen
- Utilizar un proceso de gestión ligero aún en proyectos complejos
Definición
Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.
Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums.
What is Scrum methodology? (inglés)
Scrum project management is a software agile development process. Scrum models allow projects to progress via a series of iterations called agile sprints. Each sprint is typically two to four weeks, and sprint planning in the agile methodology and Scrum process is essential. While the agile Scrum methodology can be used for managing any project, the Scrum agile process is ideally suited for projects with rapidly changing or highly emergent requirements like software.
Agile Process for Software
Scrum is used in the agile process for software development. But rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the software development team. This is done because the team will know best how to solve the problem they are presented. This is why, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to a set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as would be provided in most methodologies.
Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. The Scrum team is cross-functional; everyone is necessary to take a feature from idea to implementation.
These agile development teams are supported by two specific individuals: a ScrumMaster and a product owner. The ScrumMaster can be thought of as a coach for the team, helping team members use the Scrum framework to perform at their highest level. The product owner represents the business, customers or users, and guides the team toward building the right product.
Scrum projects make progress in a series of sprints, which are timeboxed iterations no more than a month long. At the start of a Scrum sprint, team members commit to delivering some number of features that were listed on the project's scrum product backlog. At the end of the Scrum sprint, these features are done--they are coded, tested and integrated into the evolving product or system. At the end of the sprint, a sprint review is conducted during which the team demonstrates the new functionality to the product owner and other interested stakeholders who provide feedback that could influence the next sprint.
Características
Características de Scrum
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.
Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.2 Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.
Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.
Roles
Roles Principales
Product Owner
- El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
ScrumMaster (o Facilitador)
- El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.
Equipo de desarrollo
- El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).
Roles Auxiliares
Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.
Stakeholders (Clientes, Proveedores, Vendedores, etc)
- Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.
Administradores (Managers)
- Es la gente que establece el ambiente para el desarrollo del producto.
Reuniones en Scrum
Daily Scrum o Stand-up meeting
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama daily standup o Stand-up meeting. El scrum tiene unas guías específicas:
- La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, etc).
- Todos son bienvenidos, pero sólo los responsables pueden hablar.
- La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
- Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
- La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas:3
- ¿Qué has hecho desde ayer?
- ¿Qué es lo que harás hasta la reunión de mañana?
- ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).
Scrum de Scrum
Cada día normalmente después del “Daily Scrum”:
- Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.
- Asiste una persona asignada por cada equipo.
La agenda será la misma que la del Daily Scrum, añadiendo además las siguientes cuatro preguntas:
- ¿Qué ha hecho tu equipo desde nuestra última reunión?
- ¿Qué hará tu equipo antes que nos volvamos a reunir?
- ¿Hay algo que demora o estorba a tu equipo?
- ¿Estás a punto de poner algo en el camino del otro equipo?
Reunión de Planificación del Sprint (Sprint Planning Meeting)
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo.
- Seleccionar qué trabajo se hará
- Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo.
- Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint
- Ocho horas como límite
Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint”
Reunión de Revisión del Sprint (Sprint Review Meeting)
- Revisar el trabajo que fue completado y no completado
- Presentar el trabajo completado a los interesados (alias “demo”)
- El trabajo incompleto no puede ser demostrado
- Cuatro horas como límite
Retrospectiva del Sprint (Sprint Retrospective)
Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.
Concepts
1) Scrum projects deliver software application features iteratively.
2) Each iteration is called a sprint.
3) Scrum projects have 4 stages:
a) Planning – Definition of the vision, budget, and expectations. The first version of the product backlog should containing enough implementation items for the first sprint.
b) Staging – This is the first iteration where the requirements and product backlog created in the planning are refined.
c) Development – It is the set of sprints required to implement the project fully. It ends when the product backlog is empty.
d) Release – The final product is deployed, training is performed, documentation is finalized, etc… The release backlog can be used as the product backlog for the next release of the product.
4) There are 4 main roles in scrum projects: team member, product owner, stakeholders and scrum master:
a) A product owner is a customer representative acting as a single point of contact on the customer side.
b) A stakeholder is anyone having a vested interest in the project, providing information about requirements and participating to the decision process of features to be implemented.
c) A scrum master is a facilitator and single point of contact on the development team side. It is a support function, not a ‘controlling chief’ role. It is a mix between a team leader and a software engineering role, which does not include people management or profit & lost responsibilities.
d) A team member is a software engineer.
5) Scrum of scrum can be implemented when multiple scrum teams are working on the same large project. Scrum master and product representatives get together.
6) The product backlog is a list of features, use cases, enhancement, defect, etc… to be implemented in the project’s forthcoming sprints.
7) The release backlog is the list of features, uses cases, enhancement, defect, etc… which are postponed to the next version of the project (not next sprint).
Practice
1) Spring teams typically do not have more than 7 members.
2) A sprint duration is 30 days.
3) Scrum projects are client-driven. They select the features to be implemented.
4) Each sprint begins with two meetings:
a) The stakeholder meeting, with the scrum master and customer representative to re-prioritize the product backlog and update the release backlog.
b) The product owner and team meeting where tasks are created from the product backlog.
5) Each task must require between 4 and 16 hours of work. Bigger tasks must be subdivided into smaller tasks.
6) The scrum master and product owner check whether there are enough resources to support the efforts required to achieve the sprint and adjust the workload accordingly.
7) Team member pick their tasks and work on their implementations.
8) Each spring finishes with a presentation of implemented features to the stakeholders.
9) Every day, a stand-up meeting (15-20 mins) with the team members and eventually the product owner is organized in front of a white board. The following is discussed:
a) Which tasks have been achieved since the last meeting?
b) Are there new tasks? New requirements?
c) What is blocking? Any impediments?
10) If decisions have to be taken, the Scrum Master should take them quickly, within an hour if possible
11) The Scrum Master should deal quickly with any impediments and communication issues
12) Scrum teams should preferably operate from the same room
Conclusion
As for all Agile methods, the Scrum approach is best suited for new projects created from scratch. Over time, when successive application releases are implemented, the project can slowly transform into a continuous integration or even maintenance project, where less stakeholders input or daily supervision is required. The cogs are well oiled and operate naturally.
Guia 1 Hoja SCRUM
La siguiente es una guia muy simple y últis sobre SCRUM. Consta de 1 hoja!
http://es.scribd.com/doc/134880180/SCRUM-La-guia-de-1-pagina
Primero es recomendable leer:
Qué soluciona Scrum
Tu cliente necesita
- Tener resultados a corto plazo
- Cambiar a menudo los requisitos del proyecto
- Ver si se cumplen sus expectativas
Tu quieres
- Equipos altamente productivos y motivados
- Solucionar los problemas que impiden que los equipos progresen
- Utilizar un proceso de gestión ligero aún en proyectos complejos
Definición
Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.
Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums.
What is Scrum methodology? (inglés)
Scrum project management is a software agile development process. Scrum models allow projects to progress via a series of iterations called agile sprints. Each sprint is typically two to four weeks, and sprint planning in the agile methodology and Scrum process is essential. While the agile Scrum methodology can be used for managing any project, the Scrum agile process is ideally suited for projects with rapidly changing or highly emergent requirements like software.
Agile Process for Software
Scrum is used in the agile process for software development. But rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the software development team. This is done because the team will know best how to solve the problem they are presented. This is why, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to a set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as would be provided in most methodologies.
Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. The Scrum team is cross-functional; everyone is necessary to take a feature from idea to implementation.
These agile development teams are supported by two specific individuals: a ScrumMaster and a product owner. The ScrumMaster can be thought of as a coach for the team, helping team members use the Scrum framework to perform at their highest level. The product owner represents the business, customers or users, and guides the team toward building the right product.
Scrum projects make progress in a series of sprints, which are timeboxed iterations no more than a month long. At the start of a Scrum sprint, team members commit to delivering some number of features that were listed on the project's scrum product backlog. At the end of the Scrum sprint, these features are done--they are coded, tested and integrated into the evolving product or system. At the end of the sprint, a sprint review is conducted during which the team demonstrates the new functionality to the product owner and other interested stakeholders who provide feedback that could influence the next sprint.
Características
Características de Scrum
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.
Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.2 Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.
Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.
Roles
Roles Principales
Product Owner
- El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
ScrumMaster (o Facilitador)
- El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.
Equipo de desarrollo
- El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).
Roles Auxiliares
Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.
Stakeholders (Clientes, Proveedores, Vendedores, etc)
- Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.
Administradores (Managers)
- Es la gente que establece el ambiente para el desarrollo del producto.
Reuniones en Scrum
Daily Scrum o Stand-up meeting
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama daily standup o Stand-up meeting. El scrum tiene unas guías específicas:
- La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, etc).
- Todos son bienvenidos, pero sólo los responsables pueden hablar.
- La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
- Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
- La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas:3
- ¿Qué has hecho desde ayer?
- ¿Qué es lo que harás hasta la reunión de mañana?
- ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).
Scrum de Scrum
Cada día normalmente después del “Daily Scrum”:
- Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.
- Asiste una persona asignada por cada equipo.
La agenda será la misma que la del Daily Scrum, añadiendo además las siguientes cuatro preguntas:
- ¿Qué ha hecho tu equipo desde nuestra última reunión?
- ¿Qué hará tu equipo antes que nos volvamos a reunir?
- ¿Hay algo que demora o estorba a tu equipo?
- ¿Estás a punto de poner algo en el camino del otro equipo?
Reunión de Planificación del Sprint (Sprint Planning Meeting)
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo.
- Seleccionar qué trabajo se hará
- Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo.
- Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint
- Ocho horas como límite
Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint”
Reunión de Revisión del Sprint (Sprint Review Meeting)
- Revisar el trabajo que fue completado y no completado
- Presentar el trabajo completado a los interesados (alias “demo”)
- El trabajo incompleto no puede ser demostrado
- Cuatro horas como límite
Retrospectiva del Sprint (Sprint Retrospective)
Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.
Concepts
1) Scrum projects deliver software application features iteratively.
2) Each iteration is called a sprint.
3) Scrum projects have 4 stages:
a) Planning – Definition of the vision, budget, and expectations. The first version of the product backlog should containing enough implementation items for the first sprint.
b) Staging – This is the first iteration where the requirements and product backlog created in the planning are refined.
c) Development – It is the set of sprints required to implement the project fully. It ends when the product backlog is empty.
d) Release – The final product is deployed, training is performed, documentation is finalized, etc… The release backlog can be used as the product backlog for the next release of the product.
4) There are 4 main roles in scrum projects: team member, product owner, stakeholders and scrum master:
a) A product owner is a customer representative acting as a single point of contact on the customer side.
b) A stakeholder is anyone having a vested interest in the project, providing information about requirements and participating to the decision process of features to be implemented.
c) A scrum master is a facilitator and single point of contact on the development team side. It is a support function, not a ‘controlling chief’ role. It is a mix between a team leader and a software engineering role, which does not include people management or profit & lost responsibilities.
d) A team member is a software engineer.
5) Scrum of scrum can be implemented when multiple scrum teams are working on the same large project. Scrum master and product representatives get together.
6) The product backlog is a list of features, use cases, enhancement, defect, etc… to be implemented in the project’s forthcoming sprints.
7) The release backlog is the list of features, uses cases, enhancement, defect, etc… which are postponed to the next version of the project (not next sprint).
Practice
1) Spring teams typically do not have more than 7 members.
2) A sprint duration is 30 days.
3) Scrum projects are client-driven. They select the features to be implemented.
4) Each sprint begins with two meetings:
a) The stakeholder meeting, with the scrum master and customer representative to re-prioritize the product backlog and update the release backlog.
b) The product owner and team meeting where tasks are created from the product backlog.
5) Each task must require between 4 and 16 hours of work. Bigger tasks must be subdivided into smaller tasks.
6) The scrum master and product owner check whether there are enough resources to support the efforts required to achieve the sprint and adjust the workload accordingly.
7) Team member pick their tasks and work on their implementations.
8) Each spring finishes with a presentation of implemented features to the stakeholders.
9) Every day, a stand-up meeting (15-20 mins) with the team members and eventually the product owner is organized in front of a white board. The following is discussed:
a) Which tasks have been achieved since the last meeting?
b) Are there new tasks? New requirements?
c) What is blocking? Any impediments?
10) If decisions have to be taken, the Scrum Master should take them quickly, within an hour if possible
11) The Scrum Master should deal quickly with any impediments and communication issues
12) Scrum teams should preferably operate from the same room
Conclusion
As for all Agile methods, the Scrum approach is best suited for new projects created from scratch. Over time, when successive application releases are implemented, the project can slowly transform into a continuous integration or even maintenance project, where less stakeholders input or daily supervision is required. The cogs are well oiled and operate naturally.
Guia 1 Hoja SCRUM
La siguiente es una guia muy simple y últis sobre SCRUM. Consta de 1 hoja!
http://es.scribd.com/doc/134880180/SCRUM-La-guia-de-1-pagina