USANDO SCRUMCUANDO MI EMPRESA    Scrum         NO LO USA   Gathering                     Mayo del 2012  “HERRAMIENTAS AL  ...
¿QUIENES SOMOS?Matias Juan (mjuan@tecnosoftware.com.ar)• http://www.linkedin.com/pub/matias-juan/3/326/101• http://www.scr...
SCRUM EN UNA EMPRESA NO SCRUM               Planificación                 Fechas                 Cambios en el Negocio ...
PROBLEMA #1Nos piden fechas concretas para un grupo defuncionalidades del backlog. ¿Qué responder?
PROBLEMA #1FECHAS Y DISPONIBILIDAD
PROBLEMA #2Hay equipos trabajando en distintas ubicaciones(oficinas, horarios, idioma) ¿Cómo coordinarnos?
PROBLEMA #2VISIBILIDAD Y COMUNICACIÓN
PROBLEMA #3No todos somos grosos y nos equivocamos.¿Cómo contemplar los errores?
PROBLEMA #3ESTIMACIÓN Y EJECUCIÓN
PROBLEMA #4Mi cliente necesita incluir más funcionalidad, hayuna iteración en curso. ¿Cómo nos organizamos?
PROBLEMA #4MAYOR CAPACIDAD (VELOCIDAD DADA)
ALGUNAS CONCLUSIONES Un resultado malo no es bueno, pero un resultado muy  variable es aún peor (incluso con un resultado...
REFERENCIAS The Enterprise and Scrum: amazon.com/The-Enterprise-Scrum-  Ken-Schwaber/dp/0735623376 Agile Project Managem...
Usando Scrum cuando mi empresa no lo usa @ Scrum Gathering Buenos Aires 2012
Upcoming SlideShare
Loading in …5
×

Usando Scrum cuando mi empresa no lo usa @ Scrum Gathering Buenos Aires 2012

693 views

Published on

Presentación que dimos con Matias Juan y Pablo Russo en el Scrum gathering Buenos Aires 2012

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
693
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Para llevarse bien con la empresa/clientes debemos trabajar en estos puntos:Predictability & PlanningFechas: Muy difícil establecer deadlines/hitos, comprometerse con alcance a una fecha.Cambios del Negocio: Muchas veces no pueden esperar al fin de una iteración, pero tampoco se puede cancelar lo ya comprometido. Imposible!Errores:Tamaño (estimación): Se manifiesta sobre todo al inicio. Subjetividad, no existe un modelo repetible y confiable. Bugs: Difícil de evitarlos, difícil de estimarlos. Suelen impactar siempre en los compromisos.Ease of AdoptionComunicación: En equipos remotos o múltiples equipos se dificulta mucho la misma. Se pierde información y visibilidad del estado del proyecto.Difícil de implementarProduct owner no siempre disponible y suele estar sobrecargadoHusos horarios y distribución geográficaMultiples proyectos en simultaneoVamos a presentar cuatro escenarios de nuestro día a día que ejemplifican estas problemáticas y mostrar de que forma los solucionamos.
  • Que mostrar:Separacion entre el team backlog y el sprint backlog (scrums de scrums)Planning->Team Planning (product owner, poder planificar/asignar trabajo a cada equipo y ver velocidades pasadas para tener idea del tamaño de lo que está asignando)Planning->Sprint Planning (equipos planifican sus iteraciones en un solo lugar independientemente que estén distribuidos, visibiidad!)Visibilidad de estado/avanceTracking->Sprint Task Board (pizarra virtual, orientada a tareas)Tracking->Sprint Story Board (pizarra virtual, orientada a stories, para PO)Tracking->Sprint Task Burndown (visibilidad tiempo real de avance de cada equipo)Linkshttp://www.youtube.com/watch?v=Ht2xcIJrAXohttp://www.scrumalliance.org/resources/17Interesados: Scrum Master y Product OwnerEs el problema de la visibilidad y la comunicaciónVariables Típicas (SCRUM):Sprint Planning: Tamaño/Velocidad/EquiposRevisión diaria de statusScrums de ScrumsOtros ConceptosEmpezamos con pizarra, equipo crece y nos quedamos sin lugar.Pizarra: No es fácil registrar owner de las tareas ni la separación de un user story en tareas.Comunicación: Skype y teléfono.Visibilidad unificada: Dashboard multiequipo-multisprint en un solo lugar (Sprint Tracking).Scrum de ScrumsMultiples equipos trabajando en un mismo backlogMultiples Sprints en paraleloCalendarios y Velocidades por equipos
  • Que mostrar:Reports->Defects By SprintReports-> Armar un reporte hs en defectos vs en no defectos por iteración/equipo/proyectoAnalogíaPintor->Calcule mal los m2 o la complejidad, por lo que mi velocidad no vario pero en realidad había más para hacer de lo que pensaba.Pintor->Mi velocidad se redujo por algún factor intangible (motivación, cansancio, problemas personales, etc.)Pintor->Termine de pintar, pero el cliente encuentra que falta una mano de una determinada pared.Interesados: Equipo y Scrum MasterEs el problema de la estimación y la ejecuciónVariables Típicas (SCRUM):Estimación de Tamaño (estimación)Velocidad promedio (ejecución)Sprint Burndown Chart (esfuerzo pendiente, velocidad y proyección)Problemas con las variables típicasStaffing: persona idóneas para las tareas. De no ser así, cambio de persona. (no es un error)Causas: Motivación, Time-off, Tecnología o problema novedoso, Cambios en el equipo, falta de historia (primeras iteraciones).Efecto: Incertidumbre en las Estimaciones (difícil de detectar a priori)Variabilidad de Velocidad. Si la velocidad es muy variable, el promedio no significa nada.Contemplar errores -> conocer y administrar la variabilidad y la incertidumbreVariabilidad (velocidad)Velocidad a lo largo del tiempo (ver la curva de velocidad)Intervalo de confianza (no usar el promedio  2 desvíos standard)Incertidumbre (estimaciones)Técnicas: Planning Poker, Delphi o Comparación.Evidenciar errores de estimación en el momento (lean) -> aumento en el Sprint BurndownDefectosClasificar en dos tipos: 1.“Ya sé que es”, 2.“No tengo idea que pasa”Tipo 1) asociar a un userstory “Defectos” y estimarTipo 2) muy difícil de estimar, asignar un tiempo fijo x iteración a la solución de este tipo de issues (alcance variable, tiempo fijo)Con información histórica se puede acordar un tiempo razonable que de lugar a solucionar problemasSi aparece uno urgente, hacer de inmediato y desplazar user-story de menor prioridad
  • Que mostrar:Opción CAPACIDAD:Tracking->Release BurndownAnalogíaPintor->Estoy pintando y me piden que frene para pintar otra cosa. Que hago?Pintor->Estoy pintando el living y además me piden que pinte la cocina.Interesados: Producto Owner, Equipo y Scrum MasterEs el problema de la capacidad (dado una velocidad)Opciones TipicasDO-NOTHING: Esperar al fin de la iteración en cursoSTOP: Interrumpir la iteración en curso y comenzar una nuevaLuego:Entrego lo que esta listo (Sprint Review)Dimensiono y priorizo el backlogComienzo un nuevo Sprint con lo prioritarioOtras Alternativas (trabajar con la capacidad)Aumentar la velocidad: Sumar gente al equipo (Indirectamente es un STOP+START)Sumar otro equipo en paraleloPuedo agregar un equipo?Que velocidad tiene?
  • Tener un resultado malo no es bueno, pero tener un resultado muy variable es aún peor (incluso con un resultado bueno)Muchas veces no podemos mejorar la velocidad, pero sí podemos trabajar sobre la capacidad. (+gente, +equipos)En un escenario “complejo” (múltiples equipos, remotos, etc.) la visibilidad es clave para poder atacar a tiempo los problemasEn nuestro caso, las herramientas nos ayudaron en la toma de decisiones:Punto centralizado de acceso a la informaciónÚnica información válidaRecuerda toda la historia (velocidad, cambios pedidos, etc.)Permite calcular fechas/compromisosFacilita la interacción a pesar de hablar distinto idioma y trabajar en distintos horariosGenera reportes que muchas veces son exigidos por el negocio
  • Usando Scrum cuando mi empresa no lo usa @ Scrum Gathering Buenos Aires 2012

    1. 1. USANDO SCRUMCUANDO MI EMPRESA Scrum NO LO USA Gathering Mayo del 2012 “HERRAMIENTAS AL RESCATE”
    2. 2. ¿QUIENES SOMOS?Matias Juan (mjuan@tecnosoftware.com.ar)• http://www.linkedin.com/pub/matias-juan/3/326/101• http://www.scrumalliance.org/profiles/7204-matias-juan-rubiPablo Russo (prusso@tecnosoftware.com.ar)• http://www.linkedin.com/in/pablorusso• http://www.scrumalliance.org/profiles/42528-pablo-martn-russo• http://iterando.wordpress.com/• @pablorussoRodrigo Ponce (rponce@tecnosoftware.com.ar)• http://ar.linkedin.com/pub/rodrigo-ponce/3/235/50a• @rodrigoaponce
    3. 3. SCRUM EN UNA EMPRESA NO SCRUM Planificación  Fechas  Cambios en el Negocio  Errores Adopción  Comunicación  Disponibilidad  Equipos Distribuidos  Proyectos en paralelo
    4. 4. PROBLEMA #1Nos piden fechas concretas para un grupo defuncionalidades del backlog. ¿Qué responder?
    5. 5. PROBLEMA #1FECHAS Y DISPONIBILIDAD
    6. 6. PROBLEMA #2Hay equipos trabajando en distintas ubicaciones(oficinas, horarios, idioma) ¿Cómo coordinarnos?
    7. 7. PROBLEMA #2VISIBILIDAD Y COMUNICACIÓN
    8. 8. PROBLEMA #3No todos somos grosos y nos equivocamos.¿Cómo contemplar los errores?
    9. 9. PROBLEMA #3ESTIMACIÓN Y EJECUCIÓN
    10. 10. PROBLEMA #4Mi cliente necesita incluir más funcionalidad, hayuna iteración en curso. ¿Cómo nos organizamos?
    11. 11. PROBLEMA #4MAYOR CAPACIDAD (VELOCIDAD DADA)
    12. 12. ALGUNAS CONCLUSIONES Un resultado malo no es bueno, pero un resultado muy variable es aún peor (incluso con un resultado bueno ) Muchas veces no podemos mejorar la velocidad, pero sí podemos trabajar sobre la capacidad. (+gente, +equipos ) En un escenario “complejo” la visibilidad es clave para poder atacar a tiempo los problemas Las herramientas nos ayudaron en la toma de decisiones:  Punto centralizado de acceso a la información  Recuerdan toda la historia (velocidad, cambios pedidos, etc. )  Permiten estimar fechas/compromisos  Facilitan la interacción (distinto idioma y horarios)  Reportes que muchas veces son exigidos por el negocio
    13. 13. REFERENCIAS The Enterprise and Scrum: amazon.com/The-Enterprise-Scrum- Ken-Schwaber/dp/0735623376 Agile Project Management with Scrum: amazon.com/Agile- Project-Management-Microsof t-Professional/dp/073561993X Serena Agile Planner: serena.com /products/agile- software/index.html?hphdr Hallmarks of Agile Development Success: versionone.com/Agile101/Agile-Development-Success/ Agile Estimation: slideshare.net /sfnyc/agile-estimation-6478349 Solving the Scrum Deadline Debate: labs.openviewpartners.com/solving-the-scrum-deadline-debate/ Agile - Estimación y Planificación: http://dev - jeronimo.blogspot.com.ar/2012/04/scrum -estimacion-y - planificacion.html

    ×