• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ALM Sessions 2012 - Implementando Scrum con TFS
 

ALM Sessions 2012 - Implementando Scrum con TFS

on

  • 3,991 views

Presentación de la sesión sobre Scrum con TFS en las ALM Sessions 2012

Presentación de la sesión sobre Scrum con TFS en las ALM Sessions 2012

http://bit.ly/yinf7K

Statistics

Views

Total Views
3,991
Views on SlideShare
2,717
Embed Views
1,274

Actions

Likes
7
Downloads
0
Comments
0

4 Embeds 1,274

http://geeks.ms 1271
http://courses.scrum.org 1
http://www.slashdocs.com 1
http://translate.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Demo:Construir el Product Backlog (Excel)Incluircriterios de aceptación, estimaciones y orden
  • Demo:ConstruirDoD y publicarla en TFS
  • Demo:Obtener la velocidad de los burndownsIntroducir los detalles del SprintIncluir el pronóstico y el Objetivo del Sprint
  • Demo:Construir el Sprint Backlog (Excel)Asignarestimaciones, personas, etc.
  • Demo:Construir el Sprint Backlog (Excel)Asignarestimaciones, personas, etc.
  • Demo:Sacarunahistoria del alcance
  • Demo:RetrospectivaIntroducirmodificaciones en el Backlog
  • Demo:Cambio de Sprint

ALM Sessions 2012 - Implementando Scrum con TFS ALM Sessions 2012 - Implementando Scrum con TFS Presentation Transcript

  • jlsoria@plainconcepts.comhttp://geeks.ms/blogs/jlsoria
  • http://bit.ly/AsvWvK
  • http://bit.ly/AsvWvK
  • Una historia desuperaciónÉrase una vez un equipo que quería mejorar suforma de trabajar.Conocían Scrum, pero no estaban seguros deestar aprovechándolo al máximo.Habían oído hablar de herramientas quepodían ser de ayuda, pero desconocían cómosacar todo el partido de ellas.
  • Afortunadamente, contaban con un buen ScrumMaster, dispuesto aayudar al equipo en suafán de mejoraLo primero que hizo el Scrum Master, fueasegurarse de que todo el mundo conocía losfundamentos de Scrum.
  • El Manifiesto Ágil – El alma deScrumEstamos descubriendo formas mejores de desarrollarsoftware tanto por nuestra propia experiencia comoayudando a terceros. A través de este trabajo hemosaprendido a valorar:Individuos e interacciones sobre procesos yherramientasSoftware funcionando sobre documentación extensivaColaboración con el cliente sobre negociacióncontractualRespuesta ante el cambio sobre seguir un plan
  • Scrum en esenciaScrum es un framework empírico para el desarrollo deproductos complejos.Se trabaja en iteraciones fijas de 2 a 4 semanasllamadas Sprints, que se suceden hasta que secompleta el proyecto.Los requisitos y peticiones de cambio se gestionanusando una lista ordenada y priorizada llamada ProductBacklog.El Product Backlog es gestionado por el ProductOwner, que colabora con los interesados y con el
  • Scrum en esencia (II)El Scrum Master se asegura de que Scrum seaprovecha al máximo, entrena al equipo y gestionaproblemas que surjan.Los Equipos son auto-organizados ymultifuncionales, y se componen de 6±3 personas.Al principio de cada Sprint, se lleva a cabo la Reuniónde Planificación de Sprint, en la que el equipopronostica la parte del Product Backlog que serácompletada. El plan se refleja en el Sprint Backlog.
  • Scrum en esencia (III)Para el final de cada Sprint, el Equipo intenta completarun incremento de funcionalidad devalor, potencialmente entregable, que se resume en elobjetivo del Sprint.Una vez que se ha seleccionado un objetivo del Sprint, elalcance, Equipo y duración se consideran fijos para eseSprint.Todos los días durante el Sprint, el Equipo lleva a cabo lareunión Daily Scrum, en la que se sincronizan losesfuerzos, se comprueba el progreso, se sacan a la luzimpedimentos y se planifican los siguientes pasos.
  • Scrum en esencia (IV)El estado del proyecto y de la iteración son conocidos entodo momento. Las métricas esenciales son el trabajorestante y la velocidad.
  • Scrum en esencia (V)Al final de cada Sprint, el Equipo muestra el incrementoque ha sido completado en la Revisión de Sprint. ElProduct Owner recopila todo el feedback a tener encuenta para Sprints futuros.Después, el Equipo mantiene una reunión deRetrospectiva para hablar de la marcha del Sprint eidentificar acciones de mejora.Durante todo el proyecto, el Product Owner promueve el“grooming” del Product Backlog, para introducircambios y reordenaciones según las necesidades denegocio.
  • samgu@microsoft.com
  • Después, se plantearon qué tipode herramientas podrían serútiles para aplicar todas esosconceptos y prácticas.Tras mucho buscar, encontraron algo que podría cubrirla mayoría de sus necesidades.
  • Construyendo el ProductBacklogEl Equipo Scrum quería aplicar cuanto antes losconceptos y prácticas que acababan de conocer.“Pero, antes de empezar, deberíamos asegurarnos deque tenemos un buen Product Backlog”Recuerda: sólo con los requisitos no es suficiente. Vas anecesitar el orden y las estimaciones.
  • El Product Owner construyó elbacklog inicial, y pidió al Equipoayuda para las estimaciones.Entonces tuvo mejor criteriopara tratar con la ordenación.Empezaron a utilizar las características de gestión deelementos de trabajo de Team Foundation Server.
  • Scrum NorrisScrum Norris completa todoel Product Backlog en cadaiteración.Scrum Norris no estima. Élsabe.Scrum Norris gana alPlanning Poker
  • La Definición de HechoUna vez que el backlog inicial estaba listo, surgió unapregunta… ¿cómo podremos saber si hemos terminadode trabajar en un elemento en particular?El Scrum Master se apresuró a responder: deberíaispreparar una Definición de Hecho, que resuma lascondiciones que se deben cumplir para que unafuncionalidad se considere lista para ser entregada.
  • El Equipo acordó una Definiciónde Hecho, lo suficientementebuena para garantizar queentregarían valor al final de cadaSprint.A continuación la publicaron en Team FoundationServer, para que todo el mundo pudiese consultarlacuando fuese necesario.
  • Scrum NorrisCuando Scrum Norris dice“hecho”, es que está “hecho”.Scrum Norris hace laIntegración Continua una vezcada 5 años
  • El Objetivo del Sprint“Hemos llegado a la Reunión de Planificación deSprint, y es el momento de pronosticar qué seremoscapaces de completar. Nos vendría muy bien teneralguna pista….”“Después, una vez que estemos a gusto con elpronóstico realizado, lo resumiremos en el Objetivo delSprint, que servirá de guía durante la iteración.”
  • “Estaría muy bien tener una ideade nuestro rendimiento en elpasado, para poder hacer unpronóstico en base a esainformación”Enseguida se dieron cuenta de que esa información sela iba a proporcionar TFS, sin mucho esfuerzo. Así quehicieron el pronóstico, acordaron un Objetivo del Sprint ylo reflejaron todo en TFS.
  • Scrum NorrisLa velocidad de Scrum Norrises de 50.000 puntos porSprint.
  • El Sprint BacklogLa segunda parte de la Reunión de Planificación deSprint fue dedicada a determinar cómo transformar loselementos del Product Backlog pronosticados, en unincremento de valor del producto.El Equipo construyó un Sprint Backlog inicial, teniendopresente que se trata sólo de una ayuda para guiar eltrabajo, y que, como tal, cambiaría y evolucionaría a lolargo del Sprint.
  • “Comenzaremos diseñando eltrabajo, y descomponiendo lastareas resultantes para quetengan un tamaño manejable”Como ya se habían familiarizado con la gestión deelementos de trabajo en TFS, trabajar con el SprintBacklog no fue nada complicado.
  • Scrum NorrisScrum Norris ya haimplementado todo alterminar la reunión deplanificación.Scrum Norris no planifica. Élya sabe lo que hay quehacer.
  • Durante el SprintEl Equipo comenzó a auto-organizarse para trabajar enlos elementos pronosticados, sabiendo que el alcanceno sería alterado durante el Sprint. Los Daily Scrums sesucedieron sin mayor problema.El Sprint Backlog se actualizaba con regularidad, y lasgráficas de Burndown reflejaban el progreso hacia elObjetivo del Sprint.Mientras tanto, el Product Owner continuaba con el“grooming” del resto del backlog, evolucionándolo paraque reflejase mejor las necesidades de negocio, ypidiendo ayuda al Equipo cuando lo necesitaba.
  • Completando el trabajoEl Equipo era consciente de que cualquier característicaimplementada, debía cumplir la Definición deHecho, para poder presentarla en la Revisión de Sprint.Se trataba de un Equipo multifuncional, así queconsiguieron asumir casi todas las tareas que ibanapareciendo.El Scrum Master se mantenía alerta para asegurarse deque el Equipo trabajaba en un entorno adecuado, y deque cualquier problema era gestionado antes deconvertirse en una amenaza para el Objetivo del Sprint.
  • Una vez más, el Equipo utilizósabiamente las herramientasque tenían a su disposiciónVisual Studio y Team Foundation Server están repletosde características útiles para el Equipo durante el Sprint.
  • Scrum NorrisA Scrum Norris se le permitellegar tarde a la reunióndiaria.Scrum Norris sabe que unburndown real necesitanapalm.Scrum Norris puede hacerSprints de 6 meses.Scrum Norris escribe primeroel código, y después el test.
  • Tratando con lo inesperadoUn día, durante el Sprint, el Equipo se encontró contrabajo no planificado que debía ser realizado. Cuandoactualizaron el Sprint Backlog para reflejarlo, el SprintBurndown reveló que no iban a ser capaces de entregartodo lo que habían pronosticado.Inmediatamente, el Scrum Master y el Equipo se locomunicaron al Product Owner, para que pudierandecidir qué hacer.
  • Decidieron cancelar las subidasde sueldo al Equipo, y despedira alguien, para que aprendiesena tener más cuidado la próximavez.
  • El Product Owner y el Equipoacordaron qué sacar del alcanceen el Sprint actual, e intentaronaprender del error de cara alfuturo.
  • La entregaSe llevó a cabo la Revisión del Sprint, para que losinteresados pudiesen ver qué había sido completado yexpresasen sus opiniones sobre ello.Todo el mundo tuvo la oportunidad de dar feedback, elcual se tuvo en cuenta para la evolución futura delproducto.
  • El Product Owner se sirvió delProduct Backlog y de lavelocidad, para proyectarposibles fechas de entrega.También recogió todo elfeedback para poder actualizar elbacklog.
  • MejorandoTras la Revisión del Sprint, el Equipo siguió con laRetrospectiva, en la que trataron de resumir cómo habíaido el Sprint que estaba terminando, buscandoprácticas, herramientas, artefactos o cualquier elementosusceptible de ser mejorado, reutilizado o descartado.
  • Tomaron nota de los resultadosde la Retrospectiva, y hablaronde cómo aprovecharlosUna vez más, utilizaron las herramientas que tenían amano para registrar y gestionar toda esta información.
  • Scrum NorrisScrum Norris no hacerevisiones o retrospectivas.No hay mejora posible parael proceso de Scrum Norris.
  • Al final, estaban listos paracomenzar con el siguienteSprint, siguiendo con el empeñode entregar valor.Usando Visual Studio y TeamFoundation Server, habíanconseguido mejorarsustancialmente la forma en laque trabajaban.
  • http://bit.ly/aC5Lb2 http://bit.ly/hmgkRU http://www.scrum.org/scrumguides/ http://bit.ly/dMsz01 http://bit.ly/xc3rPEMadrid 12 de MarzoBilbao 19 de MarzoPalma de Mallorca 7 de MayoPamplona 4 de Juniojlsoria@plainconcepts.comhttp://geeks.ms/blogs/jlsoria