Desarrollo agil, scrum, lean y kanban
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Desarrollo agil, scrum, lean y kanban

  • 870 views
Uploaded on

Resumen del paradigma del desarrollo de software agil. scrum planning poker, product owner

Resumen del paradigma del desarrollo de software agil. scrum planning poker, product owner

More in: Software
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
870
On Slideshare
561
From Embeds
309
Number of Embeds
8

Actions

Shares
Downloads
9
Comments
0
Likes
1

Embeds 309

http://desarollosagilesvistazo.blogspot.com.es 253
https://twitter.com 19
http://desarollosagilesvistazo.blogspot.com 18
http://desarrolloagilvistazo.blogspot.com.es 10
http://desarrolloagilvistazo.blogspot.com 4
http://www.slideee.com 3
https://www.linkedin.com 1
http://desarollosagilesvistazo.blogspot.mx 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Manifiesto Ágil User Story 2 Desarrollos ágiles, SCRUM, lean y Kanban de un vistazo El ciclo de vida ágil es iterativo e incremental SCRUM Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more MoSCoW INVEST Para comprobar la calidad de una user story se puede usar la técnica INVEST I Independent N Negotiable V Valuable E Estimable S Small T Testable Iteración Funcionalidad 1 Ciclo de Vida Mensaje 1: #Agilidad A bierto al cambio auto G estion del equipo I terativo L iderado por el product owner Marzo 2014 3 Predictivo Adaptativo El “product owner” Asigna valor a las User Stories Decide cuales pasan al product backlog y cuales no Los participantes (equipo, product owner, usuarios…) crean user stories Autor de la infografía: JM Salvatierra El “product owner” es aquella persona • con una visión muy clara del producto que se quiere desarrollar, • es capaz de transmitir esa visión al equipo de desarrollo y, • además, está altamente disponible para transmitirla • Acepta el producto software al finalizar cada iteración El “SCRUM master” es responsable de que se sigan las prácticas SCRUM. Lidera el equipo respetando el principio de autogestión. El “Equipo de desarrollo” tiene las siguientes características • Autogestionado • Multifuncional • No distribuido • Tamaño optimo 5-9 personas El “Product Backlog” es el listado de User Stories que se incorporará al proyecto. Evoluciona continuamente Está ordenado Product Owner y Equipo Mensaje 2: El que inventó el postit no sabe que gran avance aportó al mundo de la informática. @JoseMaria_SZ #Agilidad M Must S Should C Could W Won’t Para asignar valor a las user story se puede usar la técnica MoSCoW y así agruparlas según la prioridad SCRUM Es un “Framework”* popular que se centra en la gestión de proyectos ágiles. *Framework significa que es un conjunto de buenas practicas que necesitaran adaptarse al proyecto Un SPRINT es una iteración Duración entre 2 – 4 semanas Sprint release: Sprint especial en la que el software se pone en el entorno productivo To do Done :o)OnGoing El Sprint Backlog es el listado de User Stories seleccionadas para ser implementadas en el SPRINT El Tablero Scrum se usa para dar seguimiento al Sprint Backlog durante el sprint Daily Scrum Sprint Review Meeting Sprint Retrospective WEEK XWEEK 2WEEK 1 L M X J VL M X J V L M X J V El BurnDown chart representa dentro de un sprint, la evolución en el tiempo del trabajo pendiente (remanente) real frente al planificado Reunión Diaria 15 minutos Cada persona explica: • Lo que hizo el día anterior • Lo que va a hacer es este día • Problemas Final del sprint No más de 4 H • Se presenta lo que se ha hecho • EL PO verifica y obtiene input para actualizar el backlog Reunión al final del sprint Duración: No mas de 4H No se hace siempre Se utiliza para la mejora de procesos Se recoge en una tabla • Aspectos positivos • Aspectos negativos Sprint planning Meeting Reunión al Inicio del Sprint Duración: No más de 8 H El PO presenta las user stories Se seleccionan las US que se implementarán en el sprint y se confecciona el Sprint Backlog “Stakeholders” son usuarios, otros PMs, etc cualquier persona afectada por el proyecto, pueden proporcionar user stories pero solo a través del product owner SPRINT Mensaje 3: Si sacas un café al empezar la Daily Scrum meeting, al terminar tiene que estar todavía caliente @JoseMaria_SZ #Agilidad 4 Planificación Ágil Puntos Historia Los puntos historia sirven para estimar las user story Los PH estiman un compendio de esfuerzo complejidad tamaño Es una técnica subjetiva Lo que importa son los valores relativos de una historia frente a otra Planning Póker Una vez elegida el user story de referencia y el rango de valores, se puede emplear la planning póker como técnica para estimar el resto de user stories Se hace en grupo y se valora por consenso Velocidad Es la cantidad de trabajo que un equipo puede hacer en una iteración El trabajo puede medirse en horas, en puntos historia, u otro sistema TECNICA 1 Selecciona la historia más pequeñas y asignarle 1 punto historia. al resto se le asignarán puntos historia en función de su complejidad respecto a ésta. TECNICA 2 Elige un rango (de 1 a 10 o Fibonacci) Selecciona una historia media y dale valor 5. al resto se le asignarán puntos historia en función de su complejidad respecto a ésta. 1 Presentación de historia de usuario 2 Elección de la carta Estimación 4 Consenso 3 Publicación Velocidad Iteración: Por ejemplo las suma de los puntos historia de la user stories realizadas en un iteración seria la velocidad de esa iteración Velocidad media por sprint de un Proyecto: sería la media de las velocidades iteración para un proyecto dado Histórico de velocidad media del equipo: es el número de puntos historia que de media hace nuestro equipo por itereación y/o proyecto. Sirve para, en base al histórico: • Estimar para proyectos nuevos las iteraciones necesarias y por tanto el tiempo requerido para completar las user stories • Valorar el rendimiento del equipo 𝑡𝑖𝑒𝑚𝑝𝑜 = 𝑃𝑢𝑛𝑡𝑜𝑠 𝐻𝑖𝑠𝑡𝑜𝑟𝑖𝑎 𝑉𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 Estimación de tiempo 1. El equipo de desarrollo se reúne y estudia las user stories 2. Cada uno de manera secreta estima los puntos de la user story 3. Todos a la vez descubren la estimación 4. Si hay consenso se toma el valor consensuado, sino se reinicia el proceso volviendo a estudiar la user story Los valores son inherentes a un equipo concreto. No se pueden hacer extrapolaciones directas a equipos distintos LEAN y KANBAN Lean Lean significa fabricación esbelta, intenta evitar el efecto push. La estrategia lean se base en 3 pilares: • Construir sólo lo necesario • Eliminar lo que no añade valor • Parar si algo no va bien ( cero defectos) Principios lean 1 Eliminar desperdicios 2 Amplificar el aprendizaje 3 Decidir lo más tarde posible 4 Entregar lo más rápido posible 5 Capacitar y potenciar el equipo 6 Construir con calidad 7 Ver el todo Lean y desarrollo ágil son cosas distintas pero complementarias Los 7 desperdicios lean software 1 Trabajo realizado parcialmente 2 Características extra en el software 3 Reaprendizaje 4 De mano en mano 5 Las pausas 6 Los cambios de tareas 7 Defectos ordenes de trabajo entran tan pronto se generan, provoca sobrecargas, stock, tiempos de parada en los cuellos de botella, incluso pude colapsar el flujo To do Sprint Backlog Done :o) OnGoing WIP = 2 Tablero Kanban El tablero ha de ser visible para todo el equipo. En relación a ágil, el tablero kanban sería equivalente al tablero SCRUM Tarjetas Kanban Las tarjetas Kanban son las work orders, las tareas. En relación a ágil, las tarjetas kanban serían las user stories Proceso El tablero se divide en columnas, cada una representa un paso o fase en el workflow para procesar la work order. En el caso ágil, se puede asimilar a las columnas SCRUM WIP Cada fase tiene un WIP (work in progress limit). Limita el número de work orders que pueden estar en dicha fase a la vez. PULL Kanban evita el efecto push limitando las ordenes de trabajo que entran en el flujo mediante los WIP Una línea de producción organizada de este modo, regulada no por las ordenes de trabajo sino por la producción es PULL Kanban Es una forma visual de gestionar la producción, de hecho kanban significa tarjetas visuales. Kanban es una técnica Lean Kanban se base en 3 pilares: • El flujo de las tareas ha de ser visible • El trabajo en progreso está limitado • Hay que medir los ciclos de trabajo Flujo Kanban • Las work orders avanzan en el flujo de izquierda a derecha en la medida que el WIP se lo permite • Se recomienda que el tamaño de las work orders sea homogéneo El flujo Kanban se mide mediante los parámetros: • Lead time es el tiempo total que un ítem pasa en el tablero • Cycle time es el tiempo de trabajo efectivo sobre el ítem PUSH Una línea de producción PUSH es en la que las Más sobre ágil en: http://desarollosagilesvistazo.blogspot.com.es/ Más sobre ágil en: http://desarollosagilesvistazo.blogspot.com.es/ Mensaje 4: @JoseMaria_SZ #Agilidad AGILEAN = Agil + lean SCRUMBAN = SCRUM + kanban SCRUMBAGIELEAN = SCRUM + kanban + agil + lean