Seminario de metodologías ágiles, bloque I

2,473 views
2,361 views

Published on

Pequeño seminario o recopilacióno de varias fuentes sobre productividad, scrum, kanban y pomodoro.

Published in: Technology

Seminario de metodologías ágiles, bloque I

  1. 1. Metodologías Ágiles y Productividad Autor: Juan Carlos Rubio Pineda
  2. 2. Creative Commons
  3. 3. Recursos utilizados para el curso Este curso se realizó a partir de estos recursos:  “Flexibilidad con Scrum”, Juan Palacio  “Scrum Manager: Gestión de proyectos, v1.3”, autores: Juan Palacio, Claudia Ruata  “The new New product development Game”, artículo de Takeuchi & Nonaka  “Kanban VS Scrum”: Henrik Kniberg & Mattias Skarin  “Scrum y XP desde las trincheras”, Henrik Kniberg  “The Pomodoro Technique”, Francisco Cirillo, autor de esta técnica  Información de libre acceso sobre la técnica GTD (autor: David Allen):  ThinkWasabi (es el blog de Berto Peña, escritor especializado en Organización, Gestión Personal y Productividad). La información de GTD es 100% suya.  Mi propia experiencia personalPuede contener variaciones y apreciaciones, fruto de mi propia interpretación y de milpropia experiencia (y por ello, errores, o quizás aportaciones)
  4. 4. Scrum: Orígenes I/II Scrum es una metodología ágil para gestionarproyectos de software, que toma su nombre de losestudios realizados sobre nuevas prácticas deproducción por Hirotaka Takeuchi e Ikujiro Nonakaa mediados de los 80 (Ikujiro & Takeuchi, 1986). Aunque surgió como práctica en el desarrollo deproductos tecnológicos, resulta válido en los entornosque trabajan con requisitos inestables, y necesitanrapidez y flexibilidad; situaciones habituales en eldesarrollo de algunos sistemas de software.
  5. 5. Scrum: orígenes II/II En 1993, Jeff Sutherland aplicó el modelo Scrum aldesarrollo de software en Easel Corporation (Empresaque en los macro-juegos de compras y fusiones seintegraría en VMARK, luego en Informix y finalmente enAscential Software Corporation). En 1996, Jeff presentó, junto con Ken Schwaber, lasprácticas que empleaba como proceso formal, paragestión del desarrollo de software en OOPSLA 96(Schwaber & Sutherland, 1996). En 2001 formaron parte de los firmantes delManifiesto Ágil. Las prácticas Schwaber y Sutherlandestán incluidas en la lista de modelos ágiles de AgileAlliance.
  6. 6. SOFTWARE PERSONAS Y PROCESOS
  7. 7. SOFTWARE PERSONAS Y PROCESOS Formas de trabajar (madurez)  A la buena de Dios (programación heroica): puede funcionar si y sólo si existe mucho talento entre los técnicos y buena auto- organización, pero sobre todo, de la motivación.  Usar una metodología orientada a procesos: organización madura.
  8. 8. Software personas y procesos Ejemplo: montaje mueble IKEA. ¿Cómo sería según cadaenfoque?
  9. 9. Software personas y procesos Factores clave de la gestión por procesos: – Repetitividad de resultados. Al conseguir que la calidad del resultado sea consecuencia del proceso, producir aplicando el mismo proceso garantiza la homogeneidad de los resultados. – Escalabilidad. No sólo un equipo consigue resultados homogéneos en todos los proyectos, sino que los obtienen todos los equipos de la empresa. – Mejora continua. Aplicar medidas que mejoran de forma continua los procesos base, y por tanto de los resultados. – Un know-how propio, consiguiendo la clave para hacer las cosas bien, con eficiencia y de forma homogénea
  10. 10. Relevancia del capital estructural y relevancia del capital humano Capital estructural: bienes que quedanen la empresa cuando las personas se van:patentes, licencias, equipos, cartera declientes, maquinaria, etc. Capital humano: valor aportado por laspersonas.
  11. 11. Relevancia del capital estructural y relevancia del capital humano Las barras de color azul indican el potencial de cada activosegún el sistema de producción del negocio (ej.- ¿dónde importamás el talento de un cocinero, en un restaurante francés(artesanía) o en una pizzería (p. industrial) ?
  12. 12. Las características del softwarePuntos clave: Coste de la materia prima.• Maleabilidad del producto.• Valor aportado por las personas.• Factor de escala del producto (cómo varíalos costes cuando se producen grancantidad de unidades del producto).
  13. 13. Las características del software Gris: capital estructural. Naranja: capital humano
  14. 14. Características del software Coste materia prima: un ingeniero de software puede hacer ungran producto sólo con su intelecto. Ingenieros navales oarquitectos, no pueden. Maleabilidad: el software no es algo físico; lo podemos“moldear”. Valor aportado por las personas: El factor “personas” es unamezcla de “ejecución” y “talento”.  En el mundo del diseño informático, los mejores lo hacen entre 50 y 100 veces mejor que el promedio, y la cifra aumenta, conforme se incrementa la complejidad de la tecnología. Pilar Jericó: “La gestión del talento” Factor de escala: El software tiene un factor de escalaprácticamente infinito: cuesta lo mismo producir uno que mil.
  15. 15. Metodologías ágiles y optimización del tiempo Scrum Management
  16. 16. Scrum Management En los 80 y 90 comienza la primera base de conocimiento(metodologías “pesadas”):  Los modelos de procesos específicos: ISO9000-3 CMM’s, SPICE-ISO 15504 , Bootstrap, etc.  Aplicación del mismo patrón predictivo de gestión de proyectos, aplicado en otras ingenierías: PMI , IPMA  Primer borrador de consenso sobre el cuerpo de conocimiento de la Ingeniería del Software: SWEBOK (IEEE Computer Society, 2000).
  17. 17. Scrum Management Elementos en un entorno de producción:  Las personas,  Los procedimentos  La tecnología CMMI: la calidad y la eficiencia de la producción sedeben sobre todo a los procesos empleados. El Manifiesto Ágil, sin embargo, afirma en su primerenunciado que el protagonismo deben tenerlo laspersonas, y no los procesos.
  18. 18. Scrum Management Los procedimientos de trabajo pueden ser:  Procesos  Rutinas
  19. 19. Scrum ManagementDefiniciones: Cuando el procedimiento de trabajo contiene la mayorparte del conocimiento necesario para obtener elresultado (conocimiento explícito), se trata de unproceso. Cuando son las personas las poseedoras delconocimiento clave para obtener el resultado(conocimiento tácito) entonces los procedimientos detrabajo son rutinas.
  20. 20. Scrum management Criterios de referencia de la gestión por scrum: – Beneficio del trabajo en equipos pequeños (productividad, comunicación directa) – Desarrollo incremental e iterativo (producción frecuente de partes del producto que puede evaluar el cliente, integración y pruebas tempranas) – Diseño de procesos o rutinas en función de la principal necesidad del proyecto: previsibilidad o creatividad e innovación. – Grado de institucionalización de los procedimientos (procesos o rutinas) adecuado al tamaño y previsión de crecimiento de la organización. – Gestión sistémica de la organización (organización como un TODO relacionado)
  21. 21. Metodologías ágiles y optimización del tiempo Scrum: Introducción a la práctica
  22. 22. Scrum: Introducción a la prácticaIntroducción al modelo (I / III):Scrum es una metodología ágil: Es un modo de desarrollo de carácter adaptable.  Énfasis en la capacidad de adaptación, más que en la finalización exacta según los plazos. Orientado a las personas antes que a los procesos.  Énfasis en las aportaciones, en el talento individual y de grupo, más que en seguir ciegamente la metodología. Emplea desarrollo ágil: iterativo e incremental.  El software es un producto vivo, que no tiene valor como ente estático, sin capacidad de cambiar y adaptarse.
  23. 23. Scrum: Introducción a la prácticaIntroducción al modelo (II / III): El desarrollo de inicia desde la visión general delproducto.  Sólo damos detalle a las funcionalidades que se van a desarrollar en primer lugar, por orden de máxima prioridad. Sprint: iteración que produce un incrementoterminado y operativo del producto (ciclo de desarrollo)  Dura entre 15-60 días (entre 2 y 8 semanas)
  24. 24. Scrum: Introducción a la prácticaIntroducción al modelo (III / III ): Las iteraciones o sprint’s son la base del modelo. Se revisa el trabajo realizado desde la reunión anterior y elprevisto hasta la reunión siguiente. Las reuniones han de ser breves.  El protocolo de desarrollo de Software definido por Jeff S. y Ken S. define que debe haber reuniones de seguimiento de la iteración en curso DIARIAS (ver más adelante el significado del término: REUNIONES DE SEGUIMIENTO).
  25. 25. Scrum: Introducción a la práctica.Control de la evolución del proyecto (I/II)Se controla con las siguientes prácticas: Revisión de las iteraciones o sprints  Tras un sprint, se convoca una revisión con todas las personas implicadas en el proyecto (responsables o representantes de cada área implicada).  Una revisión es el periodo máximo que se tarda en reconducir una desviación en el proyecto. Desarrollo incremental: Se inspecciona y evalúa elproducto operativo resultante de cada iteración. Desarrollo evolutivo: el diseño y la estructura delresultado se construyen de forma evolutiva (sigue…)
  26. 26. Scrum: Introducción a la prácticaControl de la evolución del proyecto (II/II)(continuación…) ¿Para qué predecir los estados finales de laestructura, arquitectura o diseño si van a estar cambiando?Scrum toma a la inestabilidad como premisa.  Para evitar la degradación por la evolución continua, se deben incluir prácticas de refactorización periódicas en las tareas de diseño y codificación. (pEj, tras 3 iteraciones). Ante imprevistos, la gestión predictiva confía la responsabilidadal gestor de proyectos. En Scrum los equipos sonautoorganizados, con margen para tomar decisiones. Colaboración: Debe ser abierta entre todos según losconocimientos y capacidades de cada persona, y no según su rolo puesto.
  27. 27. Metodologías ágiles y optimización del tiempo
  28. 28. Scrum: Iniciación a los componentes y conceptosVisión general del proceso:
  29. 29. Scrum: Iniciación a los componentes y conceptosLos componentes y conceptos empleados enSCRUM son:  Las reuniones  Los elementos  Los roles o responsabilidades  Las herramientas  Conceptos y Métricas de control  Los valores
  30. 30. Scrum: Iniciación a los componentes y conceptosLas reuniones:• Planificación del sprint: Jornada de trabajo previa al inicio de cada sprint enla que se determina cuál es el trabajo y los objetivos que se deben cubrir conesa iteración. Una vez cada 15 ó 60 días (al INICIO del sprint). • Esta reunión genera la “sprint backlog” o lista de tareas que se van a realizar, y en ella también se determina el “objetivo del sprint”: lema que define la finalidad de negocio que se va a lograr.• Seguimiento del sprint: Breve reunión diaria para dar repaso al avance decada tarea, y al trabajo previsto para la jornada. • Sólo interviene el equipo de desarrollo, y cada miembro responde a: • 1.- Trabajo realizado desde la reunión anterior. • 2.- Trabajo que se va a realizar hasta la próxima reunión de seguimiento. • 3.- Impedimentos que se deben solventar para que pueda realizar el trabajo, si existen.Revisión de sprint: Análisis y revisión del incremento generado. Esta reunión•no debe tomarse como un “acontecimiento especial”, sino como lapresentación normal de los resultados. Una vez cada 15 ó 60 días (al FINALdel sprint).
  31. 31. Scrum: Iniciación a los componentes y conceptosIlustración
  32. 32. Scrum: Iniciación a los componentes y conceptosLos elementos (I/II): Product Backlog: Es el inventario de características queel propietario final del producto desea obtener, ordenadopor orden de prioridad, SEGÚN SU CRITERIO.  Es accesible a todas las personas que intervienen en el desarrollo. Todos pueden contribuir y aportar sugerencias.  El responsable del product backlog es una única persona y se le denomina: propietario del producto.  Conocedora del entorno de negocio del cliente y de la visión del producto. No es un desarrollador del equipo. Es el cliente.
  33. 33. Scrum: Iniciación a los componentes y conceptosLos elementos (II/II) Sprint Backlog: Lista de los trabajos que realizará elequipo durante el sprint para generar el incrementoprevisto.  El equipo asume el compromiso de la ejecución. Las tareas están asignadas a personas, y tienen estimados el tiempo y los recursos necesarios. Incremento: Resultado de cada sprint.  Diferencia perceptible de una versión a otra del producto.
  34. 34. Scrum: Iniciación a los componentes y conceptosLos roles o responsabilidades (I / III ) Grado de funcionamiento en la organización:depende directamente de estas tres condiciones:  Características del entorno (organización y proyecto) adecuadas para desarrollo ágil.  Conocimiento de la metodología de trabajo en todas las personas de la organización y las implicadas del cliente.  Asignación de responsabilidades:  Del producto.  Del desarrollo.  Del funcionamiento de Scrum
  35. 35. Scrum: Iniciación a los componentes y conceptosLos roles o responsabilidades (II / III) Propietario del producto: En el proyecto hay unapersona, y sólo una, conocedora del entorno denegocio del cliente y de la visión del producto, queactúa como intermediario.  Se le denomina propietario del producto  Es responsable de la financiación necesaria para el proyecto  Es el responsable del proceso de adquisición del cliente.
  36. 36. Scrum: Iniciación a los componentes y conceptosLos roles o responsabilidades (III / III ) Responsabilidad del desarrollo: El equipo  Todo el equipo de desarrollo, incluido el propietario del producto conoce la metodología Scrum, y son los auténticos responsables del resultado. Responsabilidad del funcionamiento de Scrum (scrummanager)  En el modelo de Scrum definido por Jeff Sutherland, esta responsabilidad se garantiza integrando en el equipo una persona con el rol de ScrumMaster
  37. 37. Scrum: Iniciación a los componentes yHerramientas (I/III) conceptos Gráfico Burn-Up: Presenta las versiones de productoprevistas, las funcionalidades de cada una, velocidad estimada,fechas probables para cada versión, margen de error previsto enlas estimaciones, y avance real.
  38. 38. Scrum: Iniciación a los componentes y conceptosHerramientas (II/III)Gráfico Burn-Down: Representación gráfica del avance delsprint. Un sprint estaría representado por la diagonal que reduceel esfuerzo pendiente en horas de forma continua y gradual hastaterminarlo en el último día del sprint:
  39. 39. Scrum: Iniciación a los componentes y conceptos• Herramientas (III/III)  Juegos y protocolos de decisión:  Estimación de póker: Juego para agilizar y conducir la estimación de las tareas en la reunión de inicio del sprint.  Evita las reuniones que se eternizan; se usan cartas que representan días de esfuerzo  Si es más de 10 horas, se usa la carta INFINITO.  Variante: sucesión de Fibonacci (0,1,1,2,3,5,8, etc)  El juego de cartas está compuesto por números de la sucesión de Fibonacci.  La estimación no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra más aproximada a la estimación.
  40. 40. Scrum: Iniciación a los componentes y conceptos Conceptos y métricas (I/III)  Tiempo real o tiempo de trabajo: Tiempo efectivo para realizar un trabajo. Se suele medir en horas o días.  Tiempo teórico o tiempo de tarea (también llamado tiempo IDEAL): Tiempo que sería necesario para realizar un trabajo en “condiciones ideales”: si no se produjera ninguna interrupción, llamadas telefónicas, descansos, reuniones, etc.  Puntos de función o puntos de funcionalidad: Unidad de medida relativa para determinar la cantidad de trabajo necesaria para construir una funcionalidad o historia de usuario del product backlog. Por ejemplo, en horas ideales.
  41. 41. Scrum: Iniciación a los componentes y conceptosConceptos y métricas (II/III) Estimaciones: Cálculo del esfuerzo que se prevé necesariopara desarrollar una funcionalidad. Las estimaciones se puedencalcular en unidades relativas (puntos de función) o en unidadesabsolutas (tiempo teórico). Velocidad absoluta: Cantidad de producto construido en unsprint. Se expresa en la misma unidad en la que se realizan lasestimaciones (puntos de función, horas o días reales o teóricos). Velocidad relativa: Cantidad de producto construido en unaunidad de tiempo de trabajo. P. ej.: puntos de función / semana de trabajo real; ó horas teóricas / día de trabajo real…
  42. 42. Scrum: Iniciación a los componentes y conceptosConceptos y métricas (III/III) Valores: Las prácticas de Scrum son una “carrocería”.La carrocería sin motor, sin los “valores” (motor deldesarrollo ágil), no funciona. Estos son:  Delegación de atribuciones (empowerment) al equipo que le permita auto- organizarse y tomar las decisiones sobre el desarrollo.  Respeto entre las personas. Los miembros del equipo deben confiar entre ellos y respetar sus conocimientos y capacidades.  Responsabilidad y auto-disciplina (no disciplina impuesta).  Trabajo centrado en el desarrollo de lo comprometido  información, transparencia y visibilidad del desarrollo del proyecto
  43. 43. Metodologías ágiles y optimización del tiempo Scrum: los elementos
  44. 44. Scrum: los elementosLos principales elementos de Scrum son:• Product Backlog. Lista de las funcionalidadesque necesita el cliente, priorizada según lo queél (propietario del producto) determine.• Sprint Backlog: Lista de tareas que se van arealizar en un sprint.• Incremento: Parte del sistema desarrollada enun sprint.
  45. 45. Scrum: los elementosLos requisitos en el desarrollo ágil: La ingeniería delsoftware clásica diferencia dos áreas de requisitos Requisitos del sistema Requisitos del software
  46. 46. Scrum: los elementosProyectos predictivos VS proyectos ágiles: Especificación de requisitos de sistema:  En P. Predictivos los requisitos de sistema se especifican en documentos formales.  En P. Ágiles el product backlog se convierte en lista de historias de usuario (ePics). Desarrollo de los Requisitos de sistema:  En P. Predictivos, los requisitos son recogidos del cliente por un equipo especializado en ingeniería de requisitos, directamente con el cliente.  En P. Ágiles, la visión del cliente es conocida por todo el equipo (el cliente, “forma parte del equipo”).
  47. 47. Scrum: los elementosEn SCRUM, lo que se incluye o no en el product backlog, y elorden de prioridad, son responsabilidad del cliente.
  48. 48. Scrum: los elementosRequisitos y visión del productoScrum para software emplea dos formatos para elregistro y comunicación de los requisitos:  Product Backlog  Sprint BacklogPara que Scrum alcance niveles elevados de eficienciacuando responde a una visión clara, conocida ycompartida por todo el equipo, tanto a nivel de productoen general (visión del producto) como del sprint en quese está trabajando (objetivo del sprint).
  49. 49. Scrum: los elementosProduct Backlog: los requisitos del cliente  El product backlog es el inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones de desarrollo.  Representa todo aquello que esperan los clientes, usuarios, y en general los interesados en el producto. Todo lo que suponga un trabajo que debe realizar el equipo tiene que estar reflejado en el backlog.  Nunca se da por completo; está en continuo crecimiento y evolución.  […] mientras el producto esté en el mercado, para darle valor y mantenerlo útil y competitivo.
  50. 50. Scrum: los elementosEstos son algunos ejemplos de posibles entradas de unbacklog:  Permitir a los usuarios la consulta de las obras publicadas por un determinado autor.  Reducir el tiempo de instalación del programa.  Mejorar la escalabilidad del sistema.  Permitir la consulta de una obra a través de un API web.
  51. 51. Scrum: los elementosProduct Backlog:
  52. 52. Scrum: los elementosFormato del product backlogSe recomienda formato de lista que incluya al menos la siguienteinformación para cada línea:  Identificador único de la funcionalidad o trabajo.  Descripción de la funcionalidad.  Campo o sistema de priorización.  EstimaciónNotas  Puede tener otros campos (observaciones, persona asignada, etc.)  El formato del product backlog no es cerrado.  Los resultados de Scrum no dependen de la rigidez en la aplicación del protocolo, sino de la institucionalización de sus principios
  53. 53. Scrum: los elementosEjemplos:
  54. 54. Scrum: los elementosSprint backlog  Realizado de forma conjunta por todos los miembros del equipo.  Cubre todas las tareas identificadas por el equipo para conseguir el objetivo del sprint.  Sólo el equipo lo puede modificar durante el sprint.  El tamaño de cada tarea está en un rango de 4 á 16 horas de trabajo.  Es visible para todo el equipo. Idealmente en una pizarra o pared en el mismo espacio físico donde trabaja el equipo.
  55. 55. Scrum: los elementosFormato y soporte  Hoja de cálculo.  Pizarra o pared física.  Herramienta colaborativa o de gestión de proyectos.Esta última será nuestra opción. Usaremos nuestraversión modificada del software FLYSPRAY. Otrasopciones: mantenerlo en la nube, como por ejemplo,con basecamp:http://basecamphq.com
  56. 56. Scrum: los elementosCriterios para elegir la herramienta:  Incluye la información: lista de tareas, persona responsable de cada una, estado en el que se encuentra y tiempo de trabajo que queda para completarla.  Sólo incluye la información estrictamente necesaria.  El medio elegido es la opción que más facilita la consulta y comunicación diaria y directa del equipo.  Sirve de soporte para registrar en cada reunión diaria del sprint, el tiempo que le queda a cada tarea.
  57. 57. Scrum: los elementosEjemplos: H.Cálculo VS Pizarra
  58. 58. Scrum: los elementosEl incremento Parte de producto realizada en un sprint, y potencialmenteentregable: TERMINADA Y PROBADA (condocumentación, con verificaciones, etc.). No se refiere a trabajos internos del tipo “diseño de labase de datos” Se produce un “incremento” en cada iteración.
  59. 59. Scrum: los elementosLas reunionesTres reuniones que forman parte del modelo:  Planificación del sprint  Monitorización del sprint  Revisión del sprint
  60. 60. Scrum: los elementos: planificación
  61. 61. Scrum: los elementos: planificaciónPlanificación del SprintConsiste en dos reuniones:  En la primera (EXPOSICIÓN), con el cliente, que puede tener una duración de una a cuatro horas, se decide qué elementos del product backlog se van a desarrollar  En la segunda (RESOLUCIÓN), en la que se puede prescindir del cliente*, se desglosan éstos para determinar las tareas necesarias, estimar el esfuerzo que necesita cada una y asignarlas a las personas del equipo.La planificación del sprint no debe durar más de un día.
  62. 62. Scrum: los elementos: planificaciónReunión de planificación: EXPOSICIÓN (I/III)Pre-condiciones:  La organización (desarrolladora) tiene determinados los recursos posibles para llevar a cabo el sprint (personal y otros).  El propietario del producto tiene preparado el backlog del producto: con su criterio de prioridad para el negocio, y un nº de elementos (de la pila) para desarrollar en el sprint.  Si el propietario del producto debe haber trabajado ya previamente con el equipo, su estimación de qué cantidad de producto se puede desarrollar en el sprint será bastante ajustada => EXPERIENCIA.  El equipo tiene un conocimiento de las tecnologías empleadas, y del negocio del producto suficiente para realizar estimaciones y para comprender los conceptos del negocio que expone el propietario del producto.
  63. 63. Scrum: los elementos: planificaciónReunión de planificación: EXPOSICIÓN (II/III)Entradas:  El backlog del producto  El producto desarrollado hasta la fecha a través de los sucesivos incrementos (excepto si se trata del primer sprint)  Circunstancias de las condiciones de negocio del cliente y del escenario tecnológico empleado.
  64. 64. Scrum: los elementos: planificaciónReunión de planificación: RESOLUCIÓN (III/III)Resultados:  Backlog del sprint.  Duración del sprint y fecha de la reunión de la revisión.  Objetivo del sprint.
  65. 65. Scrum: los elementos: planificaciónFormato de la reunión de planificación  Esta reunión marca el inicio de cada sprint.  Un Scrum Manager (pEj el Scrum Master del proyecto) es el responsable de su organización y gestión. Duración máxima: un día.  Deben asistir: el propietario del producto, el equipo y el Scrum Manager.  Pueden asistir: es una reunión abierta a todos los que puedan aportar información útil. Consta de dos partes separadas por una pausa de café o comida.
  66. 66. Scrum: los elementos: planificaciónReunión de planificación: Primera parte: EXPOSICIÓN: funciones decada ROL (NOTA: Duración de 1 a 4 horas. ) Propietario del producto:  Presenta las funcionalidades del backlog del producto que tienen mayor prioridad y que estima se pueden realizar en el sprint. Equipo:  El equipo realiza las preguntas y solicita las aclaraciones necesarias. Propone sugerencias, modificaciones y soluciones alternativas. Las aportaciones del equipo pueden/deben suponer modificaciones en el backlog.  El equipo define el “objetivo del sprint” o fase que define de forma sintética cuál es el valor que se le aportará al producto.
  67. 67. Scrum: los elementos: planificaciónReunión de planificación, RESOLUCIÓN.FUNCIONES DE CADA ROL: El papel del propietario del producto en esta parte es atendera dudas. Depende del proyecto, y del cliente, que seaaconsejable o no que esté. La experiencia lo determina. El equipo:  desglosa cada funcionalidad en tareas, y estima el tiempo para cada una de ellas.  Los miembros del equipo se auto-asignan las diferentes tareas teniendo como criterios sus conocimientos, intereses y distribución homogénea del trabajo. El scrum manager: modera la reunión, pudiendo alterar laasignación de tareas.
  68. 68. Scrum: los elementos: planificación
  69. 69. Scrum: los elementos: planificaciónFunciones del rol de Scrum Manager (I/)1.- Que se realiza la reunión de planificación antes de cadasprint.2.-Que antes de la reunión, el propietario del producto dispongade un backlog3.- Que el diálogo principal de la reunión se realice entre elpropietario del producto y el equipo. Otros asistentes puedenparticipar, pero sin toma de decisiones ni limitar el diálogoprincipal.(SIGUE...)
  70. 70. Scrum: los elementos: planificaciónFunciones del rol de Scrum Manager (II/)4.- Que la reunión sea un trabajo de colaboración activa entrecliente y equipo, y concluyen con el incremento de producto quevan a realizar en el sprint.5.- Que el equipo comprende la visión y necesidades de negociodel cliente.6.- Que el equipo ha realizado una descomposición y estimacióndel trabajo realistas y ha considerado las posibles tareasnecesarias de análisis, investigación o apoyo.(SIGUE...).
  71. 71. Scrum: los elementos: planificaciónFunciones del rol de Scrum Manager (II/)7.- Que al final de la reunión están objetivamente determinados:  Los elementos de la pila o partes del producto que se van a ejecutar.  El objetivo del sprint.  La pila de sprint con todas las tareas estimadas y asignadas.  La duración del sprint y la fecha de la reunión de revisión.El Scrum Manager modera la reunión para que no dure más deun día.
  72. 72. Scrum: los elementos: planificaciónPizarra de trabajo Es recomendable emplear una hoja de cálculo, o el soporte deotra herramienta para guardar en formato digital la pila delproducto. Se supone que hay dos pizarras, la que empleapropietario del producto y la que usa el Scrum Manager para elSprint Backlog No es aconsejable emplearla como base para trabajar sobreella en la reunión proyectándola sobre la pantalla de la sala. Es mucho mejor trabajar y manipular elementos físicos; y usaruna pizarra y fichas/notas removibles.  Lo más barato y útil en mi opinión, es una pizarra de corcho, donde pinchamos los post-its u octavillas (incluso de papel reciclado) y los movemos. Así da igual el adhesivo y podemos cambiarlos muchas veces de sitio. Además, se puede hacer tan grande como necesitemos, pues se venden rollos de corcho como si fuera papel de vinilo.  Para cambiar la prioridad de las tareas basta con cambiarlas de sitio.
  73. 73. Scrum: los elementos: planificaciónEn la pizarra, se delimita: Un área superior donde el Scrum Manager coloca:  A: al principio de la reunión la capacidad del sprint a 3, 4 y 5 semanas  D: al final, las notas con: el objetivo establecido, duración del sprint, funcionalidades de la pila del producto comprometidas, hora fijada para las reuniones diarias y fecha prevista para la reunión de revisión del sprint. B.- Una franja para ordenar los elementos de la pila delproducto de mayor a menor prioridad. C.- Una franja paralela para descomponer cada elemento de lapila del producto en las correspondientes tareas de la pila delsprint.
  74. 74. Scrum: los elementos: planificación
  75. 75. Scrum: los elementos: planificación
  76. 76. Scrum: los elementos: planificaciónA
  77. 77. Scrum: los elementos: planificaciónB
  78. 78. Scrum: los elementos: planificaciónC
  79. 79. Scrum: los elementos: planificación D
  80. 80. Scrum: los elementos: monitorizaciónMonitorización del Sprint (Reunión de seguimiento)Reunión diaria breve, de no más de 15 minutos en la quetodos los miembros del equipo dicen las tareas en las queestán trabajando, si se han encontrado o prevénencontrarse con algún impedimento y actualizan sobre elsprint backlog las tareas ya terminadas o los tiempos detrabajo que les quedan.
  81. 81. Scrum: los elementos: monitorizaciónMonitorización del Sprint (R. Seguimiento): Pre-condiciones Disponibilidad de un lugar físico en la organización pararealizar diariamente la reunión. Sprint backlog actualizado en el soporte que emplee elequipo (dibujado en pizarra, con post-it’s, sobre hoja decálculo…)  IMPORTANTE: recordemos que PUEDEN existir dos pizarras, la que ve el cliente, y la nuestra (más técnica) Asiste todo el equipo Asiste un responsable con rol de Scrum Manager Un miembro del equipo (team leader o Scrum Master –puede coincidir con Scrum Manager -) conduce y garantizael protocolo, formato y tiempos de la reunión.
  82. 82. Scrum: los elementos: monitorizaciónMonitorización del Sprint: Entradas • Sprint Backlog y gráfico Burn-down actualizados con la información de la reunión anterior. • Información de las tareas realizadas por cada componente del equipoMonitorización del Sprint: Resultados: • Backlog y gráfico de avance (Burn-down) actualizados. • Identificación de necesidades e impedimentos. • Necesidades que tiene que intentar remediar el Scrum Manager.
  83. 83. Scrum: los elementos: monitorizaciónMonitorización del Sprint: formato de la reuniónCada miembros del equipo expone 1. Tarea en la que trabajaron ayer. 2. Tarea o tareas en las que trabajarán hoy. 3. Si van a necesitar alguna cosa especial o prevén algún impedimento.Al final de la reunión: 1. El team leader actualiza el gráfico de avance del sprint. 2. El Scrum Manager (responsable gestión procesos / calidad) gestiona necesidades e impedimentos.
  84. 84. Scrum: los elementos: RevisónRevisión del Sprint Reunión que se realiza al final de cada sprint (de 4 horasmáximo) en la que el equipo muestra el incrementoconstruido, y se genera feedback entre todos losparticipantes para preparar el product backlog para el iniciodel siguiente sprint.
  85. 85. Scrum: los elementos: RevisónReunión de revisión: Pre-condiciones  Se ha concluido el sprint.  Asiste todo el equipo de desarrollo, el propietario del producto, el responsable de procesos / calidad de la empresa (Scrum Manager) y todas las personas implicadas en el proyecto que lo deseen (sin voz ni voto)Entradas  Incremento terminado.
  86. 86. Scrum: los elementos: RevisónReunión de revisión: Resultados  Feedback para el propietario del producto:  Hito de seguimiento de la construcción del sistema.  Información para mejorar el valor del producto.  Feedback para el responsable de procesos (Scrum Manager):  Buenas prácticas del sprint  Problemas durante el sprint.  Convocatoria de la reunión del siguiente sprint.
  87. 87. Scrum: los elementos: RevisónReunión de revisión: formato  Es una reunión informal con el objetivo de ver el incremento y trabajar en el entorno del cliente.  Sin presentaciones gráficas ni “powerpoints”.  El equipo no debe invertir más de una hora, y lo que se muestra es el resultado final: terminado, probado y operando en el entorno del cliente (incremento)  El resto del tiempo (hasta cumplir las 4 horas) corresponde a resolver las cuestiones del cliente.
  88. 88. Scrum manager: los elementos: herramientasLas herramientas (I/II):Gráfico Burn-UpEs una herramienta de planificación y seguimiento delpropietario del producto, que muestra en un gráfico muysimple el plan general de desarrollo del producto, y la trazade su evolución.
  89. 89. Scrum manager: los elementos: herramientasPartimos de la estimación de esfuerzo en product backlog
  90. 90. Scrum manager: los elementos: herramientas
  91. 91. Scrum manager: los elementos: herramientasExplicación:  El eje Y representa el esfuerzo (en puntos de función u otra métrica), y sobre él se marcan los hitos de versiones previstas en el backlog.  El eje X representa el tiempo de desarrollo con las fechas de los sprints previstos.  La línea que representa la velocidad de desarrollo estimada del equipo se obtiene sobre el histórico de velocidad en proyectos o sprints anteriores (la primera vez, tiempo real estimado, partido por tres; ver ejemplo).  Si las estimaciones se realizan considerando valores optimistas y pesimistas de velocidad, se pueden obtener rango de fechas probables.
  92. 92. Scrum manager: los elementos: herramientasEjemplo: Para un equipo de 5 personas y sprints de 20 díaslaborables, el tiempo disponible es de: 5 * 20 = 100 díasdisponibles. Velocidad previsible (un tercio): 100/3 = 33 díaslaborables, por 8 horas laborables = 264 horas  Otra opción, más optimista, considerar velocidad estimada un 20% por debajo: 100*4/5 = 80 días, por 8 horas = 640 horas útiles. La diferencia entre un equipo mediocre y uno apto, es significativa.
  93. 93. Scrum manager: los elementos: herramientasLas herramientas (I/II):Gráfico Burn-Down Herramienta de seguimiento para el equipo, que muestrael avance del sprint día a día y revela de forma tempranaposibles desviaciones. Representa en el eje X los días laborables del sprint, y enel Y la cantidad de esfuerzo estimada.
  94. 94. Scrum manager: los elementos: herramientas
  95. 95. Scrum manager: los elementos: herramientasExplicación:  En la reunión diaria cada miembro del equipo actualiza en el sprint backlog si ha terminado alguna de las tareas en las que ha trabajado, o cuánto esfuerzo estima que les quedan  Al final de la reunión la columna del día del sprint backlog muestra el esfuerzo que según el equipo falta para terminar el sprint (se actualiza la gráfica en consecuencia)
  96. 96. Scrum manager: los elementos: herramientas• Ideal: línea punteada• Por encima: subestimación del backlog.• Por debajo: sobre estimación del backlog.
  97. 97. Metodologías ágiles y optimización del tiempo Scrum Management: RESPONSABILIDADES
  98. 98. Scrum management: responsabilidadesCambio a Scrum: Algunas organizaciones abordan el cambio en la capa delas formas de trabajo: incorporan backlogs, reuniones deScrum, gráficos de seguimiento y desarrollo en intervaloscortos.  Mejora pequeña Otras saben también necesita una cultura adecuada en laorganización.  PERO: el objetivo tampoco es trabajar de forma ágil (¿y el resto? Valores, compartir conocimiento, etc) El objetivo es trabajar de la forma más adecuada a lascaracterísticas de la empresa y del tipo de trabajos quedesarrolla (mejorar en la organización del trabajo y cómonos enfrentamos a él)
  99. 99. Scrum management: responsabilidadesScrum es un éxito si se implican tres áreas: Management o gestión de la organización Calidad o procesos Producción
  100. 100. Scrum management: responsabilidadesResponsabilidades de Management Equilibrio sistémico de la empresa (alineación total con lavisión, misión y “negocio” de la empresa). Coherencia del modelo Medios y formación para incorporar prácticas ágiles
  101. 101. Scrum management: responsabilidadesResponsabilidades de procesos Configuración de Scrum: se diseñan las formas yprácticas ágiles más adecuadas.  Mejora continua de la configuración de Scrum (uso de feedbacks) Garantía de funcionamiento de Scrum: Se identifican,periódicamente:  Impedimentos en los proyectos para que el equipo pueda llevar a cabo el objetivo del sprint.  Prácticas o decisiones en la organización que impiden o dificultan la metodología Scrum.
  102. 102. Scrum management: responsabilidadesResponsabilidades de producción Visión del producto: el cliente impone las restricciones,funcionalidades y prioridades Auto-organización: equipo autogestionado (“tutorizado”por team leader y scrum master, pero aportan como unmiembro más en la mayoría de las ocasiones). Tecnología ágil: Aplicación de integración continua,pruebas automáticas, refactorización…
  103. 103. Scrum management: responsabilidades
  104. 104. Scrum management: responsabilidades¿Responsabilidades o roles? Resulta más difícil integrar Scrum en la empresa, si elmodelo prescribe roles fijos que suelen suponermodificaciones en la estructura organizativa. Para lograr trabajo de equipo es más importante pensaren las responsabilidades de toda la organización que enlos roles del equipo.
  105. 105. Scrum: conclusiones¿Cuáles son, entonces, las preferencias en una metodología ágil como Scrum?Personas y su interaccción Procesos y herramientasSoftware que funciona Documentación exhaustivaColaboración con el cliente Negociación contractualRespuesta al cambio Seguimiento de un plan Prioridad
  106. 106. Scum: conclusiones¿En qué podemos basarnos para elegir una metodología adaptable o predictiva? ADAPTABLE PREDICTIVA Prioridad de negocio Valor Cumplimiento Estabilidad de requisitos Entorno inestable Entorno estable Rigidez del producto Modificable Difícil de modificar Coste del prototipado Bajo Alto Criticidad del sistema Bajo Alto Tamaño del equipo Pequeño Grande
  107. 107. Metodologías Ágiles y gestión del tiempo Kanban
  108. 108. Kanban<<El trabajo se expande hasta llenar el tiempo disponible para que se termine.>> Ley de Parkinson Kanban es un sistema de señalización para comunicar información relativa y necesaria en la ejecución o monitorización de un trabajo. Su autor es Taichi Ohno, que lo creó a principios de los 50 en los centros de producción de Toyota en Japón.
  109. 109. Kanban
  110. 110. Kanban Kanban no es un modelo o marco de gestión, sino una herramienta de señalización. No hay por tanto un formato cerrado de tarjetas o tableros kanban Concepto WIP: “WIP”(Work In Process”) delimita el número máximo de tareas o de historias que pueden estar de forma simultánea en el estado “en curso”. Los estados básicos que se suelen representar en un tablero kanban son “pendiente”, “en curso” y “terminada”. Kanban Produce un ritmo sostenido y evita la ley de Parkinson. Si no se puede trabjar con sprints, porque tenemos entrada contínua de tareas urgentes, es necesario un mecanismo de trabajo SOSTENIDO.
  111. 111. Kanbanl Ejemplo de uso: autogestión de equipo
  112. 112. kanbanKanban boxLa organización mantiene una “pila de producción” o lista de historias de usuario (ePics), pendientes,estimadas y priorizadas.Si la organización trabaja en un único producto, la“pila de producción” es en definitiva la pila del producto o product backlog.Una historia se representa en una caja:
  113. 113. kanbanKanban Box: en cada caja se representa: Puntos totales de esfuerzo estimados Tarjetas con las tareas Un fondo de escala graduado con los puntos totales de esfuerzo estimados Barra dibujada con rotulador “borrable” que representa la velocidad prevista Barra de velocidad real Una descripción de la historia de usuario.
  114. 114. kanban ¿Qué cantidad de trabajo o tareas pueden realizarse simultáneamente? – Empezar con un WIP igual al número de miembros del equipo x 1.5, redondeando el resultado por exceso, o x2. – En ningún caso es aconsejable trabajar con tareas de tamaño que se prevea superior a un día de trabajo, y si esto ocurre lo aconsejable es dividirlas en otras de menor tamaño. – TAMAÑO MÁXIMO DE UNA TAREA: 1 DÍA DE TRABAJO – Conclusión: KANBAN LIMITA EL NÚMERO DE TAREAS EN PROCESO. Con la práctica, encontraremos nuestro WIP idóneo.
  115. 115. Scrum VS Kanban¿Cómo se relacionan entre sí?
  116. 116. Scrum vs kanban ¿Qué herramienta utilizar?  Depende. A veces Scrum, a veces Kanban, a veces la mezcla de ambas.  Por ejemplo, Scrum te obliga a tener iteraciones de duración fija y equipos interdisciplinarios, y Kanban te obliga a usar tableros visibles y a limitar el tamaño de tus colas.  Scrum prescribe el uso de iteraciones de duración fija, Kanban no.  Kanban: tamaño máximo de una tarea, 1 día (8 horas). En SCRUM, el tamaño máximo son 16h.
  117. 117. Scrum vs kanban
  118. 118. Scrum vs kanbanScrum prescribe 3 roles:  Product Owner o dueño de producto (establece la visión del producto y las prioridades),  Equipo (implementa el producto) y  Scrum Manager (elimina los impedimentos y proporciona liderazgo en el proceso).Kanban no establece ningún rol. Combinemos lo que nos interese. Veamos algunos ejemplos
  119. 119. Scrum VS Kanbanl Equipo 1: hacemos iteraciones SCRUM:
  120. 120. Scrum vs kanbanEquipo 2: Cada semana entregamos lo que está listo para su entrega. Cada dos semanas tenemos una reunión de planificación, actualización de nuestras prioridades y los planes de entrega. Cada cuarta semana tenemos una reunión retrospectiva o de revisión para modificar y mejorar nuestro proceso".
  121. 121. Scrum vs kanbanEquipo 3: por eventos.- Lanzamos una reunión de planificación cada vez que comenzamos a quedarnos sin cosas que hacer. Lanzamos una entrega siempre que hay un conjunto mínimo de características listo para entregar. Lanzamos un círculo de calidad espontáneo siempre que nos topamos con un mismo problema por segunda vez. Además hacemos una revisión más en profundidad cada cuatro semanas.
  122. 122. Scrum vs kanbanCuestiones: Scrum dice que debemos tener equipos multidisciplinares. Entonces, ¿Quién debe estar en cada equipo?  No lo sé, experimenta. Scrum dice que el equipo selecciona cuanto trabajo incluir en un sprint. Entonces, ¿Cuánto deben incluir?  No lo sé, experimenta. Kanban dice que debemos limitar en trabajo en curso. Entonces, ¿Cuál debe ser ese límite?  No lo sé, experimenta.
  123. 123. Scrum vs kanban Diferencia de tableros
  124. 124. Scrum vs kanbanTanto SCRUM como kanban permiten el trabajo de varios “productos” a la vez. Una recomendación es con tarjetas de diferente color y diferentes filas:
  125. 125. Scrum vs kanban Un ejemplo real
  126. 126. Scrum VS Kanban Simple kanban
  127. 127. Scrum VS KanbanFuente del tablero:lP_Q,F16,Arreglar problema Web ServiceP,F3,Eliminar duplicidad clave 01.23 en CVNPdfD_Q,F13,Chequear doctores activosD,F17,Do Comprobar introducción datos formulario siform01DE,F18,Eliminar capacidad de duplicidad de producciónDE,F7,Alta de grupos con más de 3 doctores activosDE,F10,Cambio de direcciones de correo de asistencia según provinciaDE,F39,Mejora de la velocidad de carga de las páginas: cambio en los gráficosDE,F4,Reconstruir la clase cliente del WS CVNPdfT,F1,Construir nuevo módulo validador
  128. 128. FIN

×