Práctica proceso SRUM - (Introducción) v1.pptx

introduccion scrum

1. Introducción al marco ágil: Scrum . Dinámica con la gestión de proyectos.

2. Indice Temario (1) Introducción. ¿Cómo surge?. Metodologías ágiles. Lean SDLC. ¿Cuando un método es ágil?. Diferencias entre metodologías. (4) Prácticas para la gestión del proyecto y del producto. (2) Introducción a SCRUM. Principios. Características. (5) Conclusiones. Plataforma requerida. Fortalezas de SCRUM. Reflexiones. (3) Practica SCRUM Propietario del Producto. El Scrum Master. El Equipo. Interdependencias de los roles. Historias de usuario. Product Backlog . Sprint. Planificación del Sprint. Estimación de póquer. Ejecución del Sprint. Fin del sprint: Sprint review . Sprint retrospective . Daily Scrum (Comenzar / Parar / Continuar). Incremento (6) Caso practico

3. Requerimientos fuera de control No cumplimiento de los tiempos planificados (desvíos) Estimaciones deficientes Re trabajo excesivo Baja calidad Costos excedidos Insatisfacción del Cliente Insatisfacción de los profesionales participantes ¿Cómo surge?

4. ¿Cuando un método es ágil? Simple pero duro. No se basa en el seguimiento de un plan sino en la adaptación continua a la evolución del proyecto. El desarrollo de software es: Incremental liberaciones pequeñas y ciclos rápidos. Cooperativo clientes y desarrolladores trabajando juntos. Simple y Directo el método es fácil de aprender y modificar. Adaptativo es posible realizar cambios de último momento.

5. Diferencias entre metodologías Metodologías Ágiles Basadas en heurísticas provenientes de prácticas de producción de código Especialmente preparados para cambios durante el proyecto Impuestas internamente (por el equipo) Proceso mucho más controlado, con numerosas políticas/normas No existe contrato tradicional o al menos es bastante flexible     Metodologías tradicionales Basadas en normas provenientes de estándares Seguidos por el entorno de desarrollo Cierta resistencia a los cambios Impuestas externamente Proceso menos controlado, con pocos principios Existe un contrato prefijado

6. El cliente interactúa con el equipo de desarrollo   Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio Pocos artefactos Pocos roles Menos énfasis en la arquitectura del software El cliente es parte del equipo de desarrollo mediante reuniones Grupos grandes y posiblemente distribuidos Más artefactos Más roles La arquitectura del software es esencial y se expresa mediante modelos     Metodologías Ágiles Metodologías tradicionales

7. Simple Complejo Anarquía Complicado Tecnología Requisitos Lejos de Acuerdo Cerca de Acuerdo Cerca de Certeza Lejos de Certeza Entornos en los cuales es mas conveniente el enfoque agil

8. Introducción a SCRUM La palabra SCRUM procede del vocabulario del rugby y significa melé; es decir, que los compañeros del equipo se amontonan, forman una piña y empujan todos en la misma dirección. SCRUM es una estrategia de gestión donde se aplican de manera regular un conjunto de prácticas para mejorar el trabajo colaborativo y obtener el mejor resultado posible en la gestión de un proyecto software.

9. Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo . Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes). El negocio fija las prioridades. Los equipos se auto-organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad. Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorandolo en otro sprint. Scrum en 100 palabras

10. El Manifesto Ágil – una declaración de valores . Aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que están a la izquierda. Fuente: www.agilemanifesto.org Individuos e iteraciones Sobre Procesos y herramientas Software funcionando Sobre Documentacion extensiva Colaboracion con el cliente Sobre Negociación contractual Respuesta ante el cambio Sobre Seguir un plan

11. Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. Es más importante construir un buen equipo. Desarrollar software que funciona más que conseguir una buena documentación. No producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante. La colaboración con el cliente más que la negociación de un contrato. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito. Responder a los cambios más que seguir estrictamente un plan. Se debe ser hábil en responder a los cambios y a los fracasos, la planificación no debe ser estricta sino flexible y abierta.

12. Scrum es un proceso iterativo e incremental que puede ser utilizado para desarrollar cualquier producto o administrar cualquier trabajo. Sus principales atributos son: Un enfoque orientado a que los equipos desarrollen productos de manera iterativa e incremental cuando los requerimientos cambian de manera rápida Un proceso que controla el caos de conflictos de intereses y necesidades Una manera de mejorar las comunicaciones y maximizar la cooperación Una manera de maximizar la productividad Escalable a múltiples proyectos y la organización Una forma que todos se sientan bien con su trabajo, entendiendo que cada uno con sus contribuciones hizo lo mejor que podía hacer

13. En lugar de hacer todo de una cosa a la vez ... ... los equipos Scrum hacen un poco de todo todo el tiempo Requisitos Diseño Código Test Desarrollo secuencial vs. superpuesto

14. Principios Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y continua de software con valor. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Entregamos software frecuentemente. Los responsables de negocio y los desarrolladores deben trabajar juntos permanentemente. Construimos proyectos con profesionales motivados. Conversación cara a cara. Software que funciona es la principal medida de progreso. Los procesos ágiles promueven el desarrollo sostenible. La atención continua a la excelencia técnica y los buenos diseños mejoran la agilidad. Simplicidad es esencial. Las mejores arquitecturas, requisitos y diseños surgen de equipos que se auto - organizan. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo.

15. Características Equipos auto-organizados El producto progresa en una serie de “ sprints ” que duran un mes Los requerimientos se encuentran en el “ product backlog ” reunidos en una lista No contiene practicas de ingeniería pre-descriptas Utiliza reglas generales para crear un ambiente ágil para la liberación de los proyectos Usado para proyectos complejos con requerimientos cambiantes Basado en un control de proceso empírico No hay prácticas de ingeniería prescritas Metodología de trabajo ágil Diseñada para acortar el ciclo de desarrollo Conseguir una mejor aproximación entre las funcionalidades del software y los requerimientos del cliente Evitar la burocracia innecesaria Mayor versatilidad frente a los cambios Comenzar el trabajo lo más rápidamente posible Manejo más eficiente de los requerimientos cambiantes en un proyecto Mejorar la comunicación entre el cliente y el equipo desarrollador No dice Qué hacer sino Cómo hay que hacer las cosas

16. Trazabilidad Establece de forma precisa e inequívoca el seguimiento de un producto y/o servicio durante todo su ciclo de vida. Formado por un conjunto de acciones, medidas y procedimientos técnicos que permite identificar y registrar cada requerimiento de manera que se pueda seguir su ciclo de vidas tanto para atrás, desde su origen, como hacia delante, en la entrega del producto. Toda la documentación, códigos y guiones de prueba deberán apuntar a su fuente de origen para permitir saber en todo momento el origen, la implementación y las pruebas que se hagan a cualquier requerimiento Bidireccional: A partir de un requisito se llega al código que lo implementa y a partir de un determinado código saber el o los requisitos a los que corresponde. Vertical: Garantiza que todos los requerimientos serán diseñados y que todos los diseños serán codificados y probados. Horizontal: Permite detectar si hay conflictos entre requerimientos, diseño, lógica de codificación y/o casos de prueba

17. Practica SCRUM Scrum es una a practica de desarrollo muy simple, no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto.

18. Cancel Gift wrap Return Sprint 2-4 semanas Objetivo del Sprint Sprint Backlog Incremento del producto potencialmente entregable Product Backlog Daily Scrum 24 horas Responsable del producto: “ Product Owner ” Responsables del desarrollo: “ Scrum Team ” Responsable del funcionamiento de Scrum : “ ScrumMaster ” Roles Planificación del Sprint Seguimiento del Sprint Revisión del Sprint Scrum diario Reuniones Product Backlog Sprint Backlog Incremento Graficos “ Burndown ” Artefactos Incremento en el Producto

19. Propietario del Producto Persona conocedora del entorno de negocio del cliente y de la visión del producto . Representa a todos los interesados en el producto final. Sus responsabilidades son: Define las funcionalidades del producto Decide sobre las fechas y contenidos de los releases Es responsable por la rentabilidad del producto (ROI) Prioriza funcionalidades de acuerdo al valor del mercado/negocio Ajusta funcionalidades y prioridades en cada iteración si es necesario  Acepta o rechaza los resultados del trabajo del equipo Financiación del proyecto Define funcionalidad requerida Retorno de la inversión del proyecto Lanzamiento del proyecto Representa a la gestión del proyecto Toma las decisiones de priorización Representa a todos los interesados en el producto final

20. El Scrum Master Sus responsabilidades son: Responsable de promover los valores y prácticas de Scrum Se asegura de que el equipo es completamente funcional y productivo Permite la estrecha cooperación en todos los roles y funciones Escudo del equipo de interferencias externas Garantiza el funcionamiento de los procesos y metodologías que se emplean. Formación y entrenamiento de procesos. Incorporación de Scrum en la cultura del equipo Garantía de cumplimiento de roles y responsabilidades Remueve impedimentos. Facilitador. Es un role flexible: Dirección de la empresa, con el conocimiento de gestión y desarrollo ágil y facilitando los recursos necesarios Responsables del Departamento Responsables del área de gestión de proyectos

21. El Equipo Responsable de transformar la pila del sprint en un incremento de la funcionalidad del software. Sus características son: Equipo multidisciplinar que cubre todas las habilidades necesarias para generar el resultado Se auto-gestiona y auto-organiza Dispone de atribuciones suficientes para toma de decisiones sobre cómo realizar su trabajo Típicamente de 5 a 9 personas Los miembros deben ser preferentemente full-time. Los equipos son Auto – gestionado y Auto – organizado Solo puede haber cambio de miembros entre los sprints Transforman los requerimientos en funcionalidad en cada incremento

22. Interdependencias de los roles Interesados PO PM SM Equipo >> Asegura que el proyecto cumple objetivos >> Administra al equipo Auto-organizado >> Administra el alcance y el presupuesto >> Administra la comunicación entre involucrados >> Gestiona riesgos y elimina obstáculos >> Administra el proceso >> Gestiona la visión Mejora continua >> Investigación de mercado. Visión, Voz del Cliente << Asegura que el proyecto logra los objetivos << Negocia el trabajo con el equipo << Gestiona el alcance, cronograma, y presupuesto << Gestiona la comunicación con los interesados >> Visualiza y distribuye información >> Remueve impedimentos

23. Otros roles: Propietario de la arquitectura : es el encargado de realizar las decisiones de la arquitectura para el equipo. Especialista : en la mayoría d equipos agiles no existe especialistas, sin embargo en proyectos a gran escala es necesario de conocimientos específicos. Experto de dominio : es parte del equipo de trabajo del propietario del producto, el cual ayudara a definir los requerimientos del sistema. Expertos técnicos : Son parte del equipo de manera temporal, los cuales ayudan a superar problemas con altas dificultades, así mismo transfieren parte de sus habilidades a los desarrolladores. Tester independiente : En algunas ocasiones se utilizan equipos de pruebas independientes, para ayudar a validar el trabajo realizado a lo largo del ciclo de vida. Integrador : es en el cargado de adaptar y construir todo el sistema desde los diversos subsistemas.

24. Historias de usuario Historia de Usuario (2) Como <Tipo de Usuario>, Quiero, <Hacer algo>, Para <Propósito> Personas (1) Personas, Usuarios o consumidores finales, Interesados, Patrocinadores, Equipo de desarrollo, Equipo de soporte Contexto (4) Necesidad origen, Escenarios de uso de la historia, Dominio del negocio, qué áreas del negocio usan o se impactan por la historia, Reglas del negocio que afectan la historia, Épica origen. No todas las historias provienen de una épica en particular pero si es así, es bueno conocerla, Alcance de la historia Definición de Preparado (5) Que se debe cumplir para que la historia se pueda construir? Definición de Terminado (6) Condiciones de Terminado especificas a la historia Criterios de Aceptación (3) Resultado Esperado (7) Solución esperada, Que se quiere cumplir con la Historia?, Valor a ganar Métricas (8) Puntos, Esfuerzo, Numero de iteraciones, Valor, Ganado, Calidad, Progreso, Numero de usuarios Retroalimentación (9 ) Nivel o Grado de Satisfacción de las personas, Nivel de Felicidad del usuario Impacto generado, Qué hacer para mejorar Importancia (10) Desde el punto de vista del negocio. Definido por Dueño de Producto. Categoría (12) Categorización básica de la historia. Estimación (11) Valoración inicial del Equipo del esfuerzo necesario para implementar la historia, comparada con otras historias.

25. El acrónimo INVEST para describir las características de una buena historia: Independiente: las historias pueden completarse en cualquier orden. Negociable: los detalles de la historia son co -creados por los programadores y los clientes durante el desarrollo. Valiosa: la funcionalidad es valiosa para los clientes o los usuarios del software. Estimable: los pgoramadores pueden encontrar una estimación razonable para construir la historia. Pequeña: las historias deberían construirse en poco tiempo, generalmente alrededor de "días/persona". Se tienen que poder construir muchas historias en una iteración. Testeable : se debe poder escribir pruebas que verifiquen que el software de la historia funcione adecuadamente. Una forma habitual de escribir las historias es "Como <rol>.... Quiero <característica>... Para <valor>". La parte del "Como..." se refiere a la persona que quiere la historia. La parte "Quiero..." describe la funcionalidad de la historia, y la parte "Para..." describe el motivo por el cual se pide esa funcionalidad.

26. Técnicas de priorización de historias de usuario: MoSCoW  se basa únicamente en dividir las funcionalidades en cuatro grupos en función de su prioridad. Es conveniente que el número de funcionalidades esté equilibrado en cada grupo. MoSCoW es un pseudo -acrónimo formado por las cuatro categorías en las que se tienen que dividir todas las funcionalidades: Must Have (Imprescindibles):  son funcionalidades que deben ser incluidas antes de que el producto pueda ser puesto en producción. En el contexto de gestión  lean , se denomina Mínimo Producto Viable (MVP por sus siglas en inglés) a aquel que contiene únicamente este conjunto de características. Sin alguna de ellas, el producto no tendría sentido. Should Have (Importantes):  son funcionalidades importantes y de gran valor para el usuario pero que no impiden poner el proyecto en marcha si no se tienen. Obviamente, son las siguientes en la lista de prioridad y deberían incluirse justo después de haber finalizado el Mínimo Producto Viable. Could Have o (Buenas):  son funcionalidades que sería deseable tener y podrían incluirse en caso de que hubiese recursos para ello. No obstante, en caso de que sea necesario, se podrían descartar. Won’t Have o (Excluidas):  son funcionalidades que el cliente ha solicitado inicialmente pero que se descartan por falta de recursos (tiempo, dinero, etc ). Como la priorización debe realizarse de forma iterativa a lo largo del proyecto, algunas de estas funcionalidades pueden considerarse en el futuro.

27. Theme Scoring  es una técnica que permite determinar la prioridad de las funcionalidades como una combinación de diferentes criterios, a los que se puede dar diferente importancia. A cada historia de usuario se le asigna un peso de 1 a 5 en cada una de las características. Para ello, por cada característica se elige una historia de usuario de referencia, que tenga un valor medio de 3. A las demás historias de usuario se les asigna el peso en cada característica en comparación con la historia de usuario de referencia. La estimación de una característica por comparación es siempre mucho más sencilla y rápida que la estimación de una medida absoluta. WSJF  es una técnica que prioriza en función del valor, coste y riesgo equitativamente y de forma sencilla. Consiste en sumar el valor al usuario, el valor de tiempo (necesidad de un plan B) y la reducción del riesgo que aporta la historia y dividirlo por el tiempo que llevaría realizarla. Es un algoritmo optimizado económicamente para la priorización y programación del trabajo en un ambiente en el que el coste de la demora y la duración de los elementos de trabajo varían. WSJF = (Valor de Negocio/Usuario + Valor del Tiempo + Reducción de Riesgo & Valor de Oportunidad) / Tamaño del trabajo

28. Donde los anteriores significan… Valor de Negocio/Usuario: Es el valor que da la empresa o el usuario. Aquí también hay que incluir los costes de penalización si los hubiera así como los ingresos. Para darle un valor podemos escoger una escala de 1,2,3,5,8,13, siendo 1 lo más bajo y 10 lo más alto. Valor de tiempo: En esta medida, lo que intentamos medir es la necesidad de un “plan B” por si las cosas salen mal, ya sea por la pérdida de contratos, clientes o ingresos. Podemos usar la misma escala de antes, en la que 1 sea una necesidad baja de este plan b, y el 13 una necesidad total el tenerlo. Reducción de Riesgo & Valor de Oportunidad: En esta parte damos un valor a la necesidad de la empresa de reducir riesgos o el potencial de las nuevas oportunidades de negocio que se derivan del trabajo actual. Como antes, usaremos la misma escala. Tamaño del trabajo: Estimación del tiempo necesario para poner una nueva característica o función del producto en producción. Podemos usar como antes la misma escala, o tomar una que sea en semanas, por ejemplo. El resultado que nos de la fórmula con los datos anteriores nos prioriza las tareas, pasando a hacer primero las de un valor más alto.

29. Product Backlog Listado con los requisitos del sistema. Una lista de todos los trabajos deseados en el proyecto Priorizadas Documento "vivo" Accesible a todos los roles Todos pueden contribuir y aportar elementos El propietario del producto es su responsable: Representa los intereses del cliente dentro de la empresa. Es el nexo entre el cliente y el equipo. Tiene la visión global del producto buscado. Es el encargado de armar y priorizar el Product Backlog (Lista priorizada de requerimientos). Cada tema tiene valor para el usuarios o el cliente (desde el punto de vista del negocio) Repriorizada al comienzo de cada Sprint Es dinámico. Mientras exista un producto, el Product Backlog también existe.

30. Pila de producto -- Requisitos priorizados. -- Listado con los requisitos del sistema. Selección de la Pila de producto ( Product Backlog ) -- Funcionalidades Pila del sprint Nueva funcionalidad Product Owner (modificar cuidando la inversión). Stakeholders (usuario, soporte técnico, administradores,etc )

31. Sprint Cada iteración se llama sprint y se realiza una revisión de los requisitos con todas las personas involucradas en el proyecto Dentro de cada sprint, SCRUM gestiona la evolución del proyecto mediante reuniones breves de seguimiento en las que se revisa el trabajo realizado desde el hito anterior y los planes para el hito siguiente Las reuniones de seguimiento de cada sprint deben ser diarias La duración típica es 2–4 semanas o a lo sumo un mes calendario La duración constante conduce a un mejor ritmo El producto es diseñado, codificado y probado en el Sprint No hay cambios en un sprint. Planee la duración del sprint en torno a cuánto tiempo usted puede comprometerse a mantener los cambios fuera del sprint. El objetivo del Sprint. Una breve declaración de cual será el foco del trabajo durante el sprint.

32. Planificación del Sprint El equipo selecciona los temas a partir del Product Backlog que pueden comprometerse a completar Los Sprints duran, idealmente, menos de un mes. Se seleccionan los requerimientos del Product Backlog que entrarán en el sprint. Se hace un listado de todas las tareas necesarias para terminar el sprint backlog , indicando el esfuerzo de cada una. Se asignan responsables a las tareas El diseño de Alto Nivel es considerado

33. Sprint Planning meeting Priorización Analizar y evaluar el Product Backlog Seleccionar el objetivo del Sprint Planificación Decidir como alcanzar el objetivo del Sprint ( diseño ) Crear el Sprint Backlog ( tareas ) en base a los temas del Product Backlog (user stories / features) Estimar Sprint Backlog en horas Objetivo del Sprint Sprint Backlog Condiciones del Negocio Capacidad del Equipo Product Backlog Tecnología Producto Actual

34. Primera reunión ( Las primeras cuatro horas se dedican al Product Owner ): Se establece la meta del Sprint Se identifica la funcionalidad que se va a construir en el Sprint Segunda reunión (Las segundas cuatro horas el equipo planea su propio Sprint): Se identifican y estiman las tareas para satisfacer Se crea un Sprint Backlog Las tareas son distribuidas por decisión de los miembros del equipo Los miembros del equipo se comprometen a cumplir con la meta del Sprint Entradas: Backlog del producto actualizado Retorno del ultimo Sprint Rendimiento del equipo en los Sprints anteriores Salida: Pila del sprint (Sprint Backlog)

35. Pila del sprint (Sprint Backlog) Trabajo o tareas determinadas por el equipo para realizar en un sprint y lograr al final del mismo un incremento de la funcionalidad. Se recomienda que las tareas reflejadas tengan una duración comprendida entre las 4 y las 16 horas de trabajo. Las de mayor duración deben intentar descomponerse en sub-tareas de ese rango de tiempo.

36. Gestión del Sprint Backlog Los individuos eligen las tareas El trabajo nunca es asignado La estimación del trabajo restante es actualizada diariamente Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog El trabajo para el Sprint emerge Si el trabajo no está claro , definir un tema del Sprint Backlog con una mayor cantidad de tiempo y subdividirla luego . Actualizar el trabajo restante a medida de que más se conoce

37. Estimación de póquer La estimación no la realiza el  cliente / Product Owner , por que no es él quien se va a “ensuciar las manos” y luchar por cumplir con fechas. Todo el  equipo  realiza la estimación para: Reforzar el compromiso de todo el equipo respecto a las fechas que dan al cliente. Reforzar el compromiso de cada miembro del equipo respecto al resto. Hacer que todo el mundo se sienta oído. Estimar usando una unidad: Días ideales : los días necesarios para que el equipo pueda completar un objetivo, sin considerar interrupciones. Para pasar a días reales hay que aplicar un factor de corrección que puede ir del 60 % al 70 % de dedicación real al proyecto. Asimismo, habrá que tener en cuenta un margen para imprevistos.

38. Puntos de historia de usuario : la complejidad que tiene cada historia de usuario. Un equipo en un proyecto determinado es capaz de completar un número semi -regular de puntos de historia cada iteración (“velocidad”). Es una práctica ágil, para conducir las reuniones en las que se estima el esfuerzo y la duración de tareas. El modelo consta de 8 cartas: ½, 1, 2, 3, 5, 6, 7 e infinito. El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo estimado. Cuando se considera que éste es mayor de x horas ideales (el tamaño máximo considerado por el equipo para una tarea), se levanta la carta “infinito”. Las tareas que exceden el tamaño máximo deben descomponerse en sub tareas de menor tamaño Cada equipo u organización puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar.

39. Procedimiento Cada participante de la reunión tiene un juego de cartas. Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que se va a estimar) el cliente, moderador o propietario del producto expone la descripción empleando un tiempo máximo. Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las posibles preguntas del equipo. Cada participarte selecciona la carta, o cartas que representan su estimación, y las separa del resto, boca abajo. Cuando todos han hecho su selección, se muestran boca arriba. Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido, la tarea debe dividirse en sub-tareas de menor tamaño.

40. Si las estimaciones resultan muy dispares, quien asume la responsabilidad de gestionar la reunión, con su criterio de gestión, y basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar, puede optar por: Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo? Tras escuchar las razones, repetir la estimación. Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes. Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las funcionalidades resultantes. Tomar la estimación menor, mayor, o la media. Este protocolo de moderación, evita en la reunión los atascos de análisis circulares en ping-pong entre diversas opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin discusiones, y además resulta divertido y dinamiza la reunión. Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por las razones que sean, no se puede precisar una estimación. También es posible incluir otra carta con alguna imagen alusiva, para indicar que se necesita un descanso

41. Ejecución del Sprint Periodo fijo de tiempo durante el cual el equipo desarrolla un incremento de funcionalidad (no mas de 30 dias ) No se aceptan cambios a los requerimientos acordados. El producto es diseñado, codificado, probado durante el Sprint. Solo el Scrum Master puede cancelar el Sprint cuando: La tecnologia no funciona Las circunstancias del negocio cambiaron El equipo tuvo interferencias Las iteracciones cortas permiten reducir los riesgos

42. Es el periodo de tiempo durante el que se desarrolla un incremento de funcionalidad. Constituye el núcleo de Scrum , que divide de esta forma el desarrollo de un proyecto en un conjunto de pequeñas “carreras”. Duración máxima: 30 días. Durante el sprint no se puede modificar el trabajo que se ha acordado en el Backlog . Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo lo puede hacer el Scrum Master si decide que no es viable por alguna de las razones siguientes: La tecnología acordada no funciona. Las circunstancias del negocio han cambiado. El equipo ha tenido interferencias. Diariamente se realiza una reunión diaria llamada Daily Scrum , y al final del Sprint, se realiza una reunión de revisión de Sprint, llamada Sprint Review

43. Fin del sprint: Sprint review Reunión donde se presenta al product owner y a los implicados todas las funcionalidades implementadas. Normalmente adopta la forma de una demo de las nuevas características o la arquitectura subyacente Informal Duracion de 4 horas. Regla de 2 hs preparación. No usar diapositivas Todo el equipo participa Se invita a todo el mundo El Product owner trata con los asistentes y con el team las posibles modificaciones en la pila de producto. Al final de la reunión se interroga individualmente a todos los asistentes para recabar impresiones, sugerencias de cambio y mejora, y su relevancia. Después del  Sprint review y antes de la proxima Sprint planning meeting, el ScrumMaster convoca a una Sprint retrospective del Sprint con el Team .

44. Objetivo : Presentar el Product Owner y demas involucrados del proyecto el trabajo realizado (incremento del producto) durante el Sprint. Participan : Equipo, Scrum Master, Product Owner , todas las personas involucradas en el proyecto. Reglas : El Equipo no invierte mas de una hora en preparar el Sprint Review Las funcionalidades no finalizadas completamente no se presentan Los miembros del equipo presentan las funcionalidades Las demostraciones se realizn en el equipamiento de los miembros del equipo Al finalizar la reunion se piden opiniones a los participantes, los cuales pueden sugerir cambios y mejoras. Al finalizar : El Product Owner decide si la funcionalidad presentada cumple con los objetivos del Sprint Se actualiza y vuelve a priorizar el Product Backlog El Scrum Master anuncia el lugar y la fecha de la proxima revision del Sprint.

45. Sprint retrospective Periódicamente , se echa un vistazo a lo que funciona y lo que no. Normalmente 30 a 90 minutos Se realiza luego de cada sprint Todo el equipo participa : ScrumMaster , Product owner , Equipo, Posiblemente clientes y otros El ScrumMaster hace que el Team  revise, su proceso de desarrollo Scrum , para hacerlo más eficaz y eficiente para el próximo Sprint. El ScrumMaster no proporciona respuestas, sino que ayuda al equipo a encontrar la mejor forma de trabajar con Scrum . En conjunto, Sprint planning meeting, Daily Scrum , Sprint review , y el Sprint retrospective , constituyen la inspección empírica y prácticas de la adaptación del Scrum .

46. Objetivo : Identificar que cosas se pueden cambiar para hacer el trabajo mas agradable y productivo en las proximas iteraciones. Se realiza al finalizar el Sprint Participan : Team , Scrum Master, Product Manager (opcional) Reglas : Dos preguntas que todos deben responder: Que cosas hicimos bien? En que cosas podemos mejorar? Todo aquello que afecte como el equipo construye se debe debatir. Permite al equipo evolucionar continuamente mejorando durante el proyecto. Al finalizar : Lista de oportunidades de mejora.

47. Daily Scrum ( Comenzar / Parar / Continuar ) Breve reunión diaria para repasar cada una de las tareas y el trabajo previsto de la jornada. Dura 15 minutos Sólo interviene el equipo de desarrollo No para la solución de problemas. No es dar un reporte de estado al Scrum Master, se trata de compromisos delante de pares Todo el mundo está invitado Sólo los miembros del equipo, ScrumMaster y Product Owner , pueden hablar Ayuda a evitar otras reuniones innecesarias Cada miembro responde a tres questiones : Trabajo realizado desde la reunión anterior, Trabajo que se va a realizar hasta la próxima reunión de seguimiento, Problemas que se deben solucionar para realizar el trabajo propuesto Todo el equipo se reúne y discute lo que les gustaría: Comenzar a hacer, Dejar de hacer, Continuar haciendo

48. Incremento Demostración de los objetivos alcanzados en cada sprint Asistencia de todos los roles, “ Product Owner ” e incluso usuarios Sólo el Scrum Master puede abortar un Sprint debido a una de las siguientes razones: La tecnología seleccionada no funciona o es incompatible con los objetivos definidos Han cambiado las circunstancias de negocio El Scrum Team ha tenido inferencias

49. Prácticas para la gestión del proyecto Revisión de las iteraciones : al final de cada sprint Desarrollo incremental : Al final de cada sprint debe haber una parte del producto operativa que se pueda inspeccionar y evaluar Desarrollo evolutivo : No se define la estructura final, la arquitectura o el diseño final del producto ya que los requisitos son cambiantes. Se utilizan técnicas de refactorización en las fases de diseño y codificación Auto-organización : Los equipos son auto-organizados con márgenes de decisión suficientes para tomar las decisiones que se consideren oportunas en los sucesitos sprint Colaboración : Se apuesta por una colaboración abierta entre todos los integrantes según sus conocimientos y capacidades, no según su rol o puesto. Veremos como estructurar un proyecto ágil …

50. Estudio de viabilidad y de negocio. Las dos primeras fases son secuenciales. Estudio de viabilidad: Calcular los costes Ver si es técnicamente viable Asegurarse de que DSDM sea el enfoque adecuado Estudio de negocio: Modelado del proceso del negocio Fuerte colaboración cliente-equipo de desarrollo. Iteración funcional del modelo e Iteración de diseño y construcción: Iteración funcional del modelo: Refinar aspectos funcionales del negocio. Iteración de diseño y construcción: El producto se vuelve apto para los usuarios.

51. Las dos fases consisten en ciclos de 4 actividades: Identificación Planificación Producción Validación Implementación: Implementación, entrenamiento, revisión y aceptación de usuarios y revisión del negocio. Al final puede ocurrir: Falta una parte técnica Iteración de diseño y construcción Se ha descubierto una nueva funcionalidad Estudio del negocio Falta una funcionalidad secundaria Iteración funcional del modelo Todos los requerimientos cumplidos Fin

52. Iterativo e incremental Tradicional Cliente Equipo Control empírico: interactivo e incremental Hacer entregas cortas y regulares del producto final (2-4s) para obtener feedback e irse acercando a las expectativas del cliente. Participación del cliente , t ransparencia para que pueda guiar de manera regular los resultados del proyecto.

53. La planificación ágil parte de la idea de planificar en función de objetivos de negocio en lugar de tareas (a diferencia de la planificación tradicional), priorizando los que aportan más valor, y esperando a dar detalle a objetivos y tareas conforme se va acercando el momento de construcción de estos objetivos, cuando la indeterminación se va reduciendo, de manera que se amortiza el esfuerzo de planificar de manera detallada.

54. La planificación ágil toma como base el  control empírico  de la construcción de producto (inspección y adaptación)

55. Cliente Entregas de los objetivos más importantes Entrega final Equipo                    Priorización por valor de negocio Proporcionar resultados anticipados (“time to market ”) Orientar el proyecto a objetivos para el cliente , no a tareas, priorizando según el valor de negocio vs esfuerzo y riesgo.

56. Herramientas: Gráfico Burn -Up. Utilizado por el Product Owner . Muestra: las versiones previstas de un producto, funcionalidades de cada una de ellas, velocidad estimada, fechas probables para cada versión, margen de error previsto en las estimaciones, y avance real

57. Herramientas: Gráfico Burn -Down. Utilizado por el Scrum Team para seguimiento del trabajo de cada Sprint

58. Pruebas T est D riven D evelopment Diseño e implementación de las pruebas antes de programar la funcionalidad El programador crea sus propios tests de unidad Integración continua ( Integración diaria, Disponer de una máquina para integración) Tests funcionales ( Cliente) Semana de 40 horas El desarrollo de software es un ejercicio creativo hay que estar fresco y descansado Sin “héroes” Se reduce la rotación de personal Mejora la calidad del producto Se permiten excepciones, con cuidado más de una semana de horas extra: problema

59. Propiedad colectiva del código Cualquier integrante del grupo tiene autoridad para cambiar cualquier parte del código fuente Todos son dueños del código Siempre se utilizan estándares Los tests siempre deben funcionar al 100% Se integra con todo el sistema permanentemente Manejo de configuración Diseño simple, entregas pequeñas Se debe mantener el diseño lo mas simple posible (YAGNI): “No vas a necesitarlo” Tarjetas CRC Design for change vs Design for today Características útiles en términos del negocio No implementar características que no son necesarias Poner en producción lo antes posible Unas pocas semanas por entrega

60. Refactorización Si el código se está volviendo complicado modificar el diseño, volver a uno más simple Refactoring : modificar la forma del código sin cambiar su funcionamiento Ejemplos: extraer método, renombrar (clase, método, variable, etc.), reemplazar Hay herramientas C#Refactory ( Xtreme Simplicity ) Conciliar el enfoque ágil y contratos de precio fijo. Es posible ofrecer al Cliente: a) cambio de alcance dinámico gratis, b) generación de valor y c) riesgo compartido (evitando juego de suma cero). Simultáneamente, la organización mejora su flujo de caja, contiene sobre costos y el disparo del alcance. Aceptar cambios, de la siguiente forma Sobre lo no desarrollado, de lo contrario tiene costo Sobre lo no desarrollado, substituir requerimientos registrados por los nuevos, que tengan una estimación de esfuerzo similar, o de lo contrario tiene costo

61. Aplicar tarifas diferenciales Aplicable por cumplimiento de cronograma: 100% Aplicable por incumplimiento de cronograma: 90% Aplicable por mejora de cronograma: 115% Permitir la cancelación anticipada Penalidad del +20% luego de que el 85% del proyecto sea entregado. Luego de que avance el proyectos, y se podrá re estimar los sub entregables en base a cambios, riesgos descubiertos. Armado y entrega de paquete por funcionalidad Descomponer SOW en sub entregables, y pagar por paquete Considerar fijar dos alcances: a) prueba de concepto, al que se le aplica un metodología ágil y b) desarrollo, el que se realiza de forma también ágil o a través de un contrato fijo.

62. Dividir las historias Datos Casos especiales Operaciones (ABM “Altas, Bajas y Mantenimiento” o CRUD “Crear, Leer, Actualizar y Borrar”) Temas transversales y no funcionales: seguridad, log, manejo de errores, performance, volumen Prioridad No dividir Por debajo de 2/5 días En tareas Y no agregar trabajo no priorizado… Sprint 0, permite identificar los objetivos y reducir la incertidumbre respecto al alcance, definir viabilidad, o plataforma tecnológica. El objetivo último es obtener una visión clara de: Qué queremos implementar , en forma de Product Backlog y prototipos.

63. Cómo lo queremos implementar , en forma de Arquitectura técnica. Y cuánto (tiempo y dinero) aproximadamente nos va a costar llegar a cada una de las posibles fases principales de la implementación del proyecto. Dentro de ese  Product Backlog  es habitual encontrar clasificadas las Épicas en estos tres grupos: MVP (Producto Mínimo Viable), MMP (Producto Mínimo Comercializable) y Funcionalidades futuras. Evidentemente, las Épicas de los dos primeros grupos se habrán descompuesto en Historias de Usuario y se habrá estimado su complejidad lo que ha permitido priorizarlas, apoyadas además por Prototipos y Propuesta Gráfica (desde el punto de vista de Usabilidad) y por una Arquitectura propuesta e, incluso, Pruebas de Concepto de aquellos elementos tecnológicos más innovadores. Pero, dado que en este punto ya se tiene una orientación de alcance (MVP y MMP) lo que permite a “Negocio” obtener una visión muy aproximada de cuál será el resultado del proyecto, también es posible minimizar las inquietudes tanto de la Gerencia (orientación en cuanto a Costes y Plazos), como de los equipos de Tecnología (cuándo se estima que deberán estar disponibles los entornos y equipos que sustenten el nuevo producto, qué personas formarán el equipo, que recursos harán falta, qué nuevos productos o frameworks se introducen en el ecosistema a mantener, etc ).

64. Prácticas para la g estión del producto Técnica para entender y planear una entrega incremental de MVPs . La técnica organiza ideas y recursos en un modelo que busca entender la finalidad principal del producto, considerando las jornadas de los usuario para realizar las entregas incrementales de productos viables. Como un libro de recetas, con una secuencia de actividades, rápidas y eficaces, la técnica va a permitir que el equipo: Describa la visión del producto. El producto Es - No es - Hace - No hace Priorize los objetivos del producto. Entendiendo los trade-offs . Describa los principales usuarios, sus perfiles y sus necesidades Entienda las principales funcionalidades Comprenda los niveles de incertidumbre, esfuerzo y valor de negocio por uncionalidad Describa las jornadas más importantes de los usuarios Cree un plan de entrega incremental del producto, impulsado por el concepto de MVP Estime el esfuerzo por muestreo Calcule los costos y especifique fechas en el cronograma de entrega 07:55 71

65. El Canvas MVP Es una herramienta para validar ideas de productos. Es un marco visual que ayuda a los empresarios para alinear y ajustar la estrategia del MVP ( Minimum Viable Product , en inglés). Se divide en siete bloques: MVP Visión general – ¿Cuál es la visión de este MVP? Métricas para validar el modelo de negocio – ¿Cómo podemos medir los resultados de este MVP? Resultado esperado – ¿Qué esperamos como aprendizaje o resultado de este MVP? Características – ¿Qué vamos a construir en este MVP? ¿Qué acciones se simplificarán / mejorarán en este MVP? Personas y Plataformas – ¿Para quién es el MVP? ¿En qué plataforma estará disponible? Historias – ¿Qué historias se cumplen o mejoran con este MVP? Costo y horario – ¿Cuál es el costo y la fecha prevista para la entrega de este MVP? Al usar el Canvas MVP, ​​ponemos los dos bucles uno al lado del otro. De “Lean startup ”, el bucle de construir-medir-aprender. Del Design Thinking , el bucle de usuario- journey -acción. En ambos bucles, la respuesta a qué construir: las funcionalidades del MVP. 07:55 72

66. Cuando una composición de funcionalidades alcanza una versión simple del producto que podría estar disponible ? Usted debe planear una secuencia de ondas para agrupar las funcionalidades de manera que lo ayude a organizar la producción, considerando limites de funcionalidad, nivel de riesgo, esfuerzo y valor de negocio. El MVP debe de ser factible, usable, valioso. El Canvas MVP , permite validar ideas de productos. Es un marco visual que relaciona dos bucles. De “Lean startup”, el bucle de construir-medir-aprender . Del Design Thinking, el bucle de usuario-journey-acción . En ambos bucles, la respuesta a qué construir: las funcionalidades del MVP . 07:55 73 Personas y plataformas Usuario     Visión de MVP Resultado Esperado Aprender Funcionalidad   Jornadas de usuario        Métrica (validación hipótesis) Costo y Cronograma de Entrega Medir Aprender Construir Usuario Experiencia Acción

67. Proceso de desarrollo del producto por etapas Evaluación de conceptos Valida ideas, planifica y especifica Desarrollo Evaluación y pruebas Lanzamiento Prospección. Investigación preliminar de cada uno de los proyectos o ideas generados en la fase de descubrimiento y se selecciona un subconjunto de ellos. Construir el modelo de negocio . Mediante una investigación minuciosa por parte de los equipos técnicos y comerciales definiendo y justificando el producto desarrollando el plan de proyecto. Desarrollo Establece el diseño y desarrollo de nuevo producto y el plan de producción y lanzamiento al mercado. Pruebas y validación. Se efectúa una prueba extensa del nuevo producto en el mercado, en el laboratorio, o en la planta. Lanzamiento. Como inicio de la producción y comercialización se establecen revisiones periódicas de post – lanzamiento. Visión Producto e EPICs Fundación técnica/negocio . Experiencia del usuario. Priorización de funciones.   Estructura del proyecto . MVP Funciones básicas y validación UX. Supuestos validados. UAT. MMP Retorno primario. Mejoras dirigidas por la visión del usuario. Adopción continúa.

68. Infraestructura requerida Plataforma para la implementación de tableros KAMBAN, fomentar el trabajo colaborativo, gestión de incidencias y automatización de QA/QC.

69. Lugar de trabajo Sala amplia (mejor, sin divisiones) Centro: pares de programadores Periferia: máquinas individuales Ventajas del espacio abierto: Mayor comunicación Agenda dinámica Cliente en el sitio Interacción continua No siempre se consigue muy junior, no sirve muy senior, no quiere Actualmente se pide un “analista”

70. Gestión regular de expectativas del cliente Priorización de requisitos Resultados anticipados (“time to market ”) Demostración del proyecto en cada Sprint Priorización de requisitos por valor/coste Flexibilidad y adaptación Re planificación en el inicio de cada iteración Retorno de inversión (ROI) Priorización de requisitos Mitigación de riesgos Desarrollo iterativo e incremental Productividad de calidad Mejora continua Comunicación diaria del equipo TimeBoxing Equipo multidisciplinar Estimación de esfuerzo conjunta Compromiso del equipo Demostración de resultados Alineamiento entre cliente y equipo Reuniones en cada itinerario (Sprint) Equipo motivado Equipo autosugestionado Reuniones diarias y en cada Sprint Fortalezas de SCRUM

71. Reflexiones Highsmith & Cockburn 2001 “lo que es nuevo en los procesos ágiles no son las prácticas que usan, sino que reconozcan a las personas como primeros implicados en el éxito de un proyecto, además de un intenso foco en la efectividad y la manejabilidad . Esto genera una nueva combinación de valores y principios que definen una visión ágil del mundo.” Hawrysh & Ruprecht 2000 Una sola metodología no puede funcionar para todo el espectro de proyectos, en vez de eso el administrador de cada proyecto debería identificar la naturaleza especifica de cada proyecto y seleccionar la mejor metodología de desarrollo aplicable. McCauley 2001 Hay una necesidad de ambos métodos [ágiles y orientados a procesos] ya que no hay un modelo de desarrollo que se ajuste a todos los propósitos imaginables.

72. Caso practico Un cliente se pone en contacto con una empresa que fabrica robots. El cliente les realiza el pedido . Quiero un robot que me sirva de escolta

73. El Cliente se reune con el Dueño de producto , que toma nota de lo que tiene en su cabeza . Cliente Dueño de Producto

74. El Duelo de Producto divide el proyecto en historias que son las que componen la pila de producto . Dueño de Producto Pila de Producto

75. El Scrum Master es un miembro del equipo que tiene el papel de comunicar y gestionar las necesidades del Dueño de Producto y la pila de Sprint. El Dueño de Producto le entrega la pila de producto para que estimen el coste de creación del producto . Dueño de Producto Scrum Manager

76. El equipo se reune para estimar el coste de cada historia de la pila de producto. En este caso utilizan Planning Poker . Equipo

77. El cliente , una vez aprobado el presupuesto , reordena la pila de producto para que el equipo vaya trabajando según la prioridad del cliente . Cliente Menos imporantes Urgentes

78. El equipo comienza su trabajo desglosando la primera historia de la pila de producto , la cual subdividen en tareas menores para crear la pila de sprint.

79. La pila de sprint tiene como utilidad fraccionar el trabajo de un periodo de 15 días en tareas mas pequeñas , que tarden como mucho dos días .

80. Estas tareas se colocan en una pila, la cual prioriza el Dueño de Producto, que ha consultado con el cliente, antes de comenzar el sprint. Dueño de Producto Menos imporantes Urgentes

81. El equipo comienza el sprint tomando las tareas priorizadas . Una vez concluida una se toma la siguiente de la lista . Se convoca todos los días una reunión del equipo donde se cuenta las tareas realizadas el día anterior y cuales se van a realizar ese día .

82. Una vez finalizado el sprint, el Dueño de Producto le muestra al cliente el resultado del trabajo realizado . El cliente ya tiene el primer contacto con su encargo y además puede volver a priorizar la pila de producto antes de que comience otro sprint. Cliente Dueño de Producto Buen trabajo

83. El equipo de trabajo celebra su buen hacer con una reunión de retrospectiva , donde se analiza lo ocurrido durante el sprint.

84. Muchas gracias ! Arturo Penas Rial [email protected]