lunes, 11 de junio de 2012

Revisando: Scrum (10/06/2012)

  • Scrum. (Definicion Wikipedia)
  • Explicando Scrum a mi abuela.
  • Una Introduccion a Scrum. (Presentacion)
  • Scrum orgánico - AOL V.  (Presentacion)
  • Scrum: Metodología ágil de gestión de proyectos. (Videos)
  • Una lista de herramientas Scrum de uso gratuito.




Scrum.

Fuente: wikipedia.org

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.

Contenido

Historia

En 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximación holística que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales.1

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 en Scrum

Roles Principales

Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja 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

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". 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, llevar colgando una gallina de plástico del cuello, 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 estás planeando hacer hoy?
  • ¿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.

Sprint

El Sprint es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración de los sprints sea constante y definida por el equipo con base en su propia experiencia. Se puede comenzar con una duración de sprint en particular (2 o 3 semanas) e ir ajustándolo con base en el ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada sprint, el equipo deberá presentar los avances logrados, y deberán entregar un producto con características de utilizable por el cliente. Asimismo, se recomienda no cambiar los objetivos del sprint o sprint backlog a menos que la falta de estos cambios amenace al éxito del proyecto. La constancia permite la concentración y mejora la productividad del equipo de trabajo.

Documentos

Product backlog

El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su retorno sobre la inversión (ROI) . Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menor tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto.

Sprint backlog

El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser divida en otras menores. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno.

Burn down

La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.

Scrum aplicado al desarrollo de software

Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.
Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1995 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 95. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.

La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son:
  • Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.
  • Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento.
  • Reuniones: Planificación del sprint, Revisión diaria, Revisión del sprint.
  • Sprint

 

Notas

  1.  Takeuchi and Nonaka: The New New Product Development Game (Harvard Business Review, Jan-Feb 1986)
  2.  Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-X
  3.  page 135

Referencias

Véase también

Enlaces externos

Comunidades o grupos de usuarios

Libros originales o traducciones al español

Portales temáticos y blogs

Artículos y otros recursos




Explicando Scrum a mi abuela.

Fuente: scrumagil.blogspot.com.ar


El otro día me encontraba hablando con un compañero de trabajo a través del teléfono móvil, cuando mi abuela me escuchó nombrar palabras raras en la conversación.Una de esas palabras era Scrum, y por la forma en la que hablaba fue lo que más atención la llamó, así que cuando colgué, lo primero que me preguntó fue con quién hablaba, de qué hablaba, y que era eso de Scrum.Imaginaros la cara que se me quedó, porque... ¿cómo explicar Scrum a mi abuela?.Aunque mi abuela es muy avanzada para la mayoría de la gente de su edad, la verdad es que no es fácil explicarla muchos de los aspectos tecnológicos emergentes, pero bueno, es mi abuela y tenía que intentar explicárselo de forma convincente.Aquí, os transcribo aquella inverosímil conversación.....


Publicado por 

Fuente original: geeks.ms - Por Jorge Serrano



Una Introduccion a Scrum.

Fuente:docs.google.com

Ver Presentacion   

Por Ernesto Grafeuille.

       

Scrum orgánico - AOL V.

Fuente: slideshare.net

Scrum orgánico es un enfoque de inducción de scrum a organizaciones, equipos y personas que se basa en la introducción de los procesos, métodos y herramientas paso a paso de manera "orgánica".


       

Scrum: Metodología ágil de gestión de proyectos.

Fuente: youtube.com

1-


2-


3-

4-

5-

6-

7-

8-

9-

10-

11-

12-

13-

14-

15-

15 b-

16-

17-

18-

19-

20-

21-

22-



Una lista de herramientas Scrum de uso gratuito.

Fuente: javiergarzas.com

Aunque lo más común es llevar la gestión de un proyecto Scrum utilizando un soporte “artesanal” (post-it, pizarras, etc.), también hay quien prefiere gestionarlo todo con algún tipo de herramienta. Bien porque necesite dejar evidencias de la gestión del proyecto, para afrontar una auditoría de procesos (te recomiendo aquí estos post Scrum y CMMI y ISO 15504 y prácticas ágiles), porque el equipo esté distribuido, o por cualquier otra razón. Por ello, al igual que en aquel post de herramientas Kanban, os dejo en este post cinco de las herramientas Scrum de uso gratuito más populares.

Herramientas Scrum

Kunagi. Herramienta Web que proporciona un sistema de gestión de proyectos basado en Scrum. Ofrece herramientas colaborativas y otras facilidades, como un cuadro de mando del proyecto, un panel interactivo para el Sprint o soporte a la estimación con Planning Poker.
ScrumDo. Herramienta Scrum muy centrada en la simplicidad y en la facilidad de uso. Permite gestionar las listas de tareas e historias de usuario, crear y gestionar iteraciones, obtener gráficos de avance “burndown” y también dar soporte a la estimación con Planning Poker.
SprintoMeter. Herramienta para la gestión, medición y seguimiento de proyectos Scrum y eXtreme Programming. Para simplificar el intercambio de datos permite exportar gráficos e informes a Excel. Posee gráficos de avance burndown en 3D.
IceScrum. Herramienta Scrum y Kanban. Ofrece las opciones de operación, consulta y estimación de historias de usuario. Permite añadir historias de usuario a la pila de producto, dividir el tiempo en Sprints y mover estas historias de la pila de producto a cada uno de los Sprint. Posee la técnica de Planning Poker para la estimación y paneles virtuales.
Pango Scrum. Otra de las herramientas Scrum online, con una interfaz sencilla y amigable que permite escribir, estimar y priorizar la pila de producto. Facilita en gran medida la planificación de Sprints y las reuniones.
Hay más herramientas Scrum, pero en mi opinión las anteriores son las más populares. 

Otros listados de este tipo: 

Post recomendados y relacionados:

Por jgarzas Apr.02, 2012 

                
         

No hay comentarios:

Publicar un comentario