Iteraciones (sprints)
Como un método de Administración de Proyectos, Agile se centra en la liberación de características – o resultados – tan a menudo como sea posible. Como parte de la definición, el entregable debe ser completado, probado, depurado y utilizable.
el núcleo de cualquier método ágil son las iteraciones. Iteraciones son de una una longitud fija de tiempo, de 1 a 4 semanas (por lo general 2) en el que tratamos de lograr una lista de cosas o proporcionar ciertas características.
La idea detrás de las iteraciones es para darle al equipo un objetivo a corto plazo que crea un sentido de urgencia y un sentimiento de realización, una vez que se haya completado – un cóctel adictivo. A corto plazo, objetivos realizables que ayudan a mantener la moral alta.
Sprint Backlog:
El sprint backlog se compone de un conjunto de elementos de alta prioridad elegido del Product backlog por parte del equipo. Una vez que el equipo ha seleccionado y estimado los art?culos, hay un compromiso por parte de ellos para?? finalizarlas dentro de la duración del Sprint, con el fin de que sea un éxito.
El objetivo de un sprint es liberar o poner en práctica uno (o muchos) característica(s) de trabajo(s). El equipo para ello se repartirá las user-stories en tareas más pequeñas más manejables para su liberación. Normalmente, estas tareas se llevará un máximo de 16 horas para terminarlas.
User-stories (o artículos)
Agile es muy orientado al cliente. Por lo tanto, las características son traducidas en User-stories. Una historia explica cómo una característica sera usada y darle el contexto. La forma correcta de escribir historias es empezar por:
Como [role], quiero [objetivo / necesidad / deseo] (opcional: para que [los beneficios])
ejemplo: como usuario, quiero buscar a mis clientes por sus nombres y apellidos.
ejemplo: como un usuario no administrativo, quiero modificar mi propio horario, pero no los horarios de otros usuarios.
El propietario del producto es responsable de escribir claro y conciso, User-stories por lo general después de “INVEST” method: Independent, Negotiable, Valuable, Estimable, Small, Testable.
(Independiente, Negociable, Estimable, Valuable, Pequeño, comprobable.)
Product Backlog
el Product Backlog contiene la lista de las necesidades del cliente, la prioridad, por lo general lo que le da valor al negocio. Esta lista está dividida en pequeños artículos o user-stories.
el Product Backlog reagrupa todas las demás historias para un proyecto determinado. Está destinado a ser mantenido y priorizado. Una vez que una iteración se completa, las historias son seleccionados del backlog, con base en las prioridades y se envían al nuevo sprint.
Idealmente, el Product Backlog se crea antes de que el proyecto esté en marcha y nuevas historias sean agregadas a él, en caso de necesidad o si tuvieran que ser divididas, las historias en el backlog deberán ser estimadas por el propietario del producto (Owner Product).
El equipo contribuye al backlog por una estimación correcta de historias de los usuarios, ya sea en el modo Story-points o en las horas estimadas. Algunos de los equipos se basán en la asignación de puntos por medio del juego “Poker Planning” para facilitar el proceso de estimación.
Story Points.
Un Story point es una medida arbitraria de esfuerzo utilizado por los equipos de Scrum. Se utiliza para acelerar la estimación del esfuerzo requerido para implementar un user-story. Por lo general, las historias varían de 1,2,4,8,16 o la serie de Fibonacci (1,2,3,5,8,13,21,34,45).
Los puntos son un valor relativo que no están directamente corelaccionados a las horas reales que ayuda a los equipos scrum para pensar en abstracto sobre el esfuerzo necesario para completar una historia. Los equipos normalmente estiman la historia mas pequeña en su sprint backlog a modo de que todos se pueden identificar y determinar que es una historia que vale un punto y utilizar esto como un punto de referencia para calcular otras historias.
Los puntos estimados y las horas son tan incompatibles que se recomienda utilizar sólo uno de ellos como una medida de la estimación. Las agencias usualmente tienen la obligación de registrar el tiempo para facturar a sus clientes. En este caso, el registro de tiempo y en la estimación de puntos es un método correcto.
Comparando la velocidad por puntos entre los equipos es casi imposible y no se debe intentar ya que es una medida arbitraria – es como comparar manzanas con naranjas.
Iteration Review
La iteración o revisión del Sprint se re?ne el Scrum team, el Scrum Master, y el Product Owner.
El objetivo de un Interaction Review es que presente un informe realista de los progresos del equipo para el propietario del producto. También es una excelente oportunidad para el equipo para obtener información sobre las historias de usuario que entrega al cliente.
Por último, es una gran herramienta para entender lo que pasó durante el sprint, si las historias fueron subestimadas y si el equipo ha sido capaz de mantener su compromiso. Esto permite al equipo, Scrum Master y el propietario del producto para conocer la capacidad del equipo y mejorar su precisión de la estimación.
El formato típico de una Iteration review:
Revisar el tema de iteración y la meta
Rexamine el Sprint Backlog y sus user-stories; el alcance ha cambiado? Se introdujo algo nuevo? Cómo podemos evitar esto en el futuro? ?algo no fue completado? ?Por qué?
Demostrar user-stories y determinar si el objetivo del User-Story se ha logrado o no. (Aceptar o rechazar) Ha habido algún cambio en el user-story? Fue dividido o fusionado?
La Iteration Review es generalmente seguido por la Iteration Kickoff.
Iteration Kickoff
La reunión de Iteration Kickoff? por lo general sigue después de la reunión de Iteration review y el último día de un Sprint, en la preparación del próximo Sprint.
El objetivo de la reunión es que el dueño del producto presente al equipo Scrum, y al Scrum Master las características de alta prioridad para ser liberadas. dandole al equipo la oportunidad de hacer preguntas y aclarar las user-stories.
En conjunto, el equipo de Scrum y el dueño del producto decidir? sobre un tema y el objetivo para el próximo Sprint. El equipo de Scrum proceder? a estimar estos artículos con máxima prioridad a fin de seleccionar el número de elementos que pueden comprometerse. Aunque siempre puede haber negociación entre el equipo y el propietario del producto, sólo el equipo Scrum puede comprometerse.
El éxito de la Sprint será determinado durante la reunión del siguiente Iteration review, al final del próximo sprint.
Compromiso
Al final del Iteration Kickoff, viene el compromiso. Una vez planificado y estimado, cada individuo dentro del equipo scrum debe estar dispuesto a comprometerse a completar las User-Stories en el Sprint Backlog.
Con el fin de hacer eso, uno debe entender el carácter vinculante de un compromiso. Un compromiso es un compromiso contractual vinculante que el equipo está tomando.
Los equipos comprometidos tienden a hacer un esfuerzo adicional para hacer las cosas como se acordó Están muy motivados y comprometidos y sus miembros están fuertemente unidos por un objetivo común. A “el total es más que la suma de sus partes” el tipo de alianza.
Antes de comprometer al equipo y el Scrum Master debe asegurarse de que:
Las historias no están subestimadas;
Las personas están aceptando la responsabilidad de las historias;
Pueden mantener el alcance fijado para la duración del sprint;
Pueden ser protegidos de las influencias externas;
Pueden mantener la concentración en los objetivos que les ocupan.
Burndown
El Burndown es una de las características de la información ?gil. Se trata de un simple indicador visual de progreso del trabajo (avance) y del trabajo que queda por hacer en el sprint, día a día.
Durante la reunión de planificación del sprint, el equipo determinará las historias específicas del backlog y la estimación de las tareas que deben completarse para que el sprint tenga éxito.
Un sprint es exitoso si todas las user-stories del backlog? son completadas al final del sprint.
Cuando las historias son completadas lo que queda por realizar es el burndown le da al equipo la visibilidad (motivación y compromiso) sobre el progreso del sprint.
Tener una línea de tendencia en su burndown puede ayudar a visualizar si el equipo está en camino hacia la realización de todas las user-stories a tiempo.
Agile Roles
Hay cuatro funciones típicas de Agile. Dueño del Producto, Gerente de Proyecto, los trabajadores y las partes interesadas. (Product Owner, Project Manager, Worker and Stakeholder)
Los grupos de interés (stakeholder) son por lo general el promotor del proyecto o el inversionista.
El propietario del producto (product owner) es la parte representativa de los StakeHolder. Es el encargado de dar prioridad al Backlog y escribir las historias de usuario (user-stories).
El Scrum Master es un facilitador para el equipo. el que organiza el equipo, elimina los obstáculos, supervisa el proceso, gestiona el sprint backlog y el progreso general del proyecto.
De los Trabajadores o el Equipo Scrum son los que hacen que las cosas se hagan. Ellos estiman que las historias en puntos y las tareas en horas. si la historia se estima que es demasiado grande para un sprint, pueden solicitar al Product Owner que la historia sea repartida en partas mas pequeñas.
La auto-organización
A los equipos se les pide que se organicen mediante la creación de las tareas relacionadas con las historias y la estimación de estas, ya sea por horas estimadas o por puntos. Posteriormente, asignar tareas entre sí e iniciar la iteración.
Reuniones (scrum) Diarias
El objetivo de una reunión al día es proporcionar una actualización del progreso y el estatus con el resto del equipo. Estas reuniones se celebran a diario y no debe durar más de 15 minutos. De pie por lo general refuerza esa norma.
Durante la reunión de pie, cada miembro del equipo se anima a responder a tres preguntas:
Lo que se hizo ayer;
?Qué va a hacer hoy?;
Estoy bloqueado o no preveo ningún impedimento.
Las reuniones diarias son una forma eficaz de promover el compromiso y dar seguimiento al equipo para ver si capaz de cumplir su compromiso.
Releases (Comunicados)
Las Liberaciones son una parte del gran esquema de cosas. Un comunicado por lo general se compone de unas pocas iteraciones, donde muchas características o entregables son enviados al cliente o en producción.
fuente: www.planbox.com
Deja un comentario