Introducción a técnicas ágiles y Scrum
Curso taller
Visión
El asistente al curso aprenderá los principios y dinámica Scrum y la filosofía Agile, así como, en que situaciones aplicarla.
Valores y Principios de Agile
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.
Agile Manifesto
1. Nuestra máxima prioridad es satisfacer al cliente a través de una temprana y continua entrega de software de gran utilidad.
2. Son bienvenidos los cambios de requerimientos, incluso tarde en el desarrollo. Los procesos Ágiles aprovechan el cambio para obtener ventajas competitivas para el cliente.
3. Entregar software funcional con una cierta frecuencia, en un par de semanas a un par de meses, con preferencia a la escala de tiempo más corto.
12 Principios Agiles
4. La gente del negocio y desarrolladores deben trabajar juntos todos los días en todo el proyecto.
5. Construir proyectos en torno a individuos motivados. Brindarles el medio ambiente y el apoyo que necesitan, y confiar en ellos para hacer el trabajo.
6. El método más eficiente y eficaz de transmisión de información de un equipo de desarrollo es la conversación cara a cara.
12 Principios Agiles
7. Software funcional es la principal medida de progreso.
8. Procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y los usuarios deben ser capaces de mantener un ritmo constante indefinidamente.
9. La atención continua a la excelencia técnica y el buen diseño mejora la agilidad.
12 Principios Agiles
10. La simplicidad –el arte de maximizar la cantidad de trabajo innecesario– es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaces, luego ajusta su comportamiento en consecuencia.
12 Principios Agiles
Somos una comunidad de líderes de proyectos altamente exitosos en la entrega de resultados. Para alcanzar estos resultados: Aumentamos retorno de la inversión, haciendo del flujo continuo
de valor nuestro enfoque. Entregamos resultados fiables mediante la participación de los
clientes en las interacciones frecuentes y la propiedad compartida. Esperamos la incertidumbre y la gestionamos a través de
iteraciones, anticipación y adaptación. Liberamos la creatividad y la innovación al reconocer que las
personas son la fuente más grande de aporte de valor, y creando un entorno en el que pueden hacer la diferencia.
Impulsamos el rendimiento mediante rendición de cuentas del grupo para resultados y la responsabilidad compartida para la eficacia del equipo.
Mejoramos la eficacia y la confiabilidad a través de estrategias, procesos y prácticas específicas a la situación.
La Declaración de Interdependencia
Libertad para el cambio Equipo energizado Comunicación con el cliente Colaboración Atención a la calidad Incrementalismo Automatización
Factores de Éxito en Agile
Clientes satisfechos Mejora de la retorno de la inversión Reducción de costos Resultados rápidos Confianza para tener éxito en un
mundo complejo Más alegría
Beneficios de Scrum
Visión General de Scrum
Ikujiro Nonaka y Hirotaka Takeuchi (Harvard Business Review en 1986) “The New New Product Development Game,”
Jeff Sutherland(VP de Engineering en Easel, Inc) En 1993 Sutherland y su equipo desarrollaron dicho proceso combinando conceptos del artículo de Takeuchi y Nonaka con conceptos de desarrollo orientado a objetos, control de procesos empíricos, desarrollo iterativo e incremental, procesos de software e investigación de productividad y sistemas complejos adaptativos.
Ken Schwaber estaba buscando la manera de mejorar la productividad de los equipos de desarrollo de su empresa (Advanced Development Methods, Inc.), a través de la mejora de sus procesos.
En 1995, Ken Schwaber publicó el primer artículo sobre Scrum en OOPSLA 1995 (Schwaber 1995)
Scrum and the Perfect Storm“.
Origenes Scrum
Scrum es un framework agile para gestión de trabajos complejos tales como el Desarrollo de software
Scrum Framework
Roles x3
Product owner
ScrumMaster
Development team
Actividades x5
Sprint Sprint planning Product backlog
grooming Daily scrum Sprint
execution Sprint review Sprint
retrospective
Scrum Framework
Artefactos x3
•Product backlog•Sprint backlog•Potentially shippable product increment
Scrum Framework
Equipo Scrum
Equipos Pequeños < 7 Auto Organizado y autoadministrado Encargado de hacer la estimación de historias de
usuario o ítems del backlog Interdisciplinario(architect, programmer, tester,
database administrator, UI designer) Facultado para convertir ítems del backlog en
tareas en las cuales se van a trabajar. Seguimiento del progreso del proyecto Responsable de mostrar los resultados del Sprint
para el product owner y los stakeholders al final de cada sprint.
El Equipo Scrum
Drucker ExcersiseIntegración de Equipo
What Am I Good At
How do I perform?
What do I value?
What contribution can be expected from me on this project
Habilidades Técnicas
TÉCNICAS UTILES QUE EL PROGRAMADOR AGILE DEBE TENER
¿Qué es la programación por intención? Es una técnica central utilizada en
Programación eXtema (XP), donde se trata de comunicar de manera clara que es lo que se tenía en mente cuando escribíamos el código, dicho de otra manera, la intención con la cual se escribió el código.
TDD y Programación por Intención
Cuando hacemos Test Driven Development, y programamos la prueba antes de tener el código real, hacemos la suposición del método ideal que necesitamos, imaginamos los parámetros deberá tener y que valor deberá regresar, consideramos que nombre tendría más sentido para dicho método y pensamos en qué es lo que debe hacer, antes de pensar en el cómo
Prueba Primero (TDD) y Suposiciones
Dentro del ciclo de TDD una etapa fundamental que nos ayuda a hacer más claro y legible nuestro código es la etapa del refactor, en la cual contamos con las siguientes opciones para lograr dicho fin:
Renombrar métodos o variables para que tengan más sentido en el contexto de la clase
Extraer y generar métodos a partir de un código en un método extenso.
Extraer y generar clases a partir de código en un método extenso, en caso de considerarse que el comportamiento del código está fuera del contexto de la clase donde está definido.
Refactor
Product backlog
El uso de Scrum, siempre hacemos el trabajo más valioso primero.
El product owner, con el aporte del resto del equipo Scrum y los Stakeholders, es responsable de determinar y gestionar la secuencia de este trabajo y comunicarla en forma de una lista de prioridades (u ordenada),
Aprovechamos la conversación como una herramienta clave
La comunicación verbal tiene la ventaja de ser de alto ancho de banda y proporcionar una respuesta rápida,
Los ítems del product backlog(PBI) son características necesarias para cumplir con la misión del product owner.
A lo largo del proyecto el product backlog puede contener nuevas características, cambios en las características, defectos que debe arreglarse, mejoras técnicas, etc.
Se ponen en la secuencia correcta (usando factores tales como el valor, el costo, el conocimiento, y el riesgo) dando prioridad a los ítems de alto valor en el backlog
El product backlog es un artefacto en constante evolución.
En Scrum, los detalles de un requisito se negocian a través de conversaciones que suceden de forma continua durante el desarrollo y detalles se desglosan justo a tiempo y sólo lo suficiente para que los equipos comiencen a construir la funcionalidad para cumplir ese requisito.
Product Backlog Items (PBI)
Grooming En general, la
actividad de crear y refinación ítems del product backlog, la estimación, y la priorización de estos, se conoce como grooming
Tamaño
Antes de que finalicemos de priorizar, ordenar, u organizar el product backlog, tenemos que conocer el tamaño de cada elemento del product backlog
Tamaño equivale a los costos, y es necesario saber el costo para determinar su prioridad.
Una medida de tamaño relativo expresa el tamaño total de un elemento en una forma tal que el valor absoluto no se considera, pero el tamaño relativo de un elemento en comparación con otros artículos se considera
Ej. característica C es de tamaño 2 y característica E es de tamaño 8. Lo que podemos concluir es que la función E es aproximadamente cuatro veces más grande que la característica C.
Medida Relativa
Scrum no especifica ningún formato estándar para PBI User Stories son un formato conveniente para expresar
el valor de negocio deseado para muchos tipos de PBI, especialmente características.
Las Historias de los usuarios se elaboran de manera tal que sean comprensibles para las personas de negocios y técnicos.
Son estructuralmente simple y proporcionan un gran marcador de posición para una conversación.
Pueden ser escritos en varios niveles de granularidad y son fáciles de refinar progresivamente.
Las 3 Cs: Card, Conversation, Confirmation (Jeffries 2001).
User Stories (Historias de usuario)
Originalmente se escribían las User stories en tarjetas de: 3 x 5 pulgadas Un formato de plantilla
común para la escritura de historias de usuario(Cohn2004):◦ Especificar una clase de
usuarios (el rol de usuario)
◦ Lo que esa clase de usuario quiere lograr (la meta)
◦ ¿Por qué los usuarios quieren lograr el objetivo? (el beneficio)
Card
Los detalles de un requisito se exponen y comunican en una conversación entre el equipo de desarrollo, product owner, y las partes interesadas(stakeholders).
Puede haber una conversación inicial, cuando la historia de usuario se escribe, otra conversación cuando es refinado, aún otra cuando se estima, otra durante la planificación del sprint (cuando el equipo se sumerge en los detalles a nivel de tareas), y por último, las conversaciones en curso, mientras que el historia de usuario está siendo diseñados, construidas y probadas durante el sprint.
Aunque las conversaciones son en gran parte verbal, con frecuencia se complementan con documentos.
Conversación
Una historia de usuario también contiene información de confirmación en forma de condiciones de satisfacción.
Estos son los criterios de aceptación que aclaran el comportamiento deseado.
Son utilizados por el equipo de desarrollo para comprender mejor lo que se va a construir y probar y por el product owner para confirmar que la historia de usuario se ha implementado hasta su satisfacción.
Estas condiciones se pueden escribir al reverso de la tarjeta
Estas condiciones de satisfacción se pueden expresar como pruebas de aceptación de alto nivel.
Confirmación
Independent, Negotiable, Valuable, Estimatable, Small Testable
(Bill Wake 2003) Cuando se combina la información derivada
de aplicar cada uno de estos criterios, se obtiene una imagen clara de lo que algún cambio adicional podríamos hacer a la historia.
INVEST del Product Backlog
Las historias de usuario deben ser independientes o al menos sólo débilmente acoplados entre sí
Historias que muestran un alto grado de interdependencia complican la estimación, priorizando, y planificación.
Al aplicar el criterio de independencia, el objetivo no es eliminar todas las dependencias, sino escribir las historias de una manera que minimice las dependencias
Independent / Independiente
Las buenas historias captan claramente la esencia de la funcionalidad del negocio que se desea y por qué se desea. Sin embargo, dejan espacio para que el Product Owner, los stakeholders, y el equipo negocien los detalles.
Las historias deben ser acerca del ¿qué? y ¿por qué?, no del ¿cómo?
Historias negociables son agradables porque nos dan el margen de maniobra que a veces necesitamos para trabajar dentro de nuestros presupuestos.
Escribir historias negociables deja claro que el diálogo es necesario.
Un ejemplo común de donde se viola la negociabilidad es cuando el product owner le indica al equipo cómo implementar una historia
Negotiable / Negociable
Historias necesitan ser valiosas para un cliente, usuario, o ambos.
Está bien tener historias técnicos, siempre y cuando el product owner debe de entender por qué aporta valor esa historia
En la práctica, sin embargo, la mayoría de las historias técnicas no deben ser incluidas en el product backlog
En cambio, este tipo de historias deben ser tareas asociadas a satisfacer historias valiosas de negocio.
La clave de los criterios de valor es que todas las historias del backlog deben ser valiosa (valen la pena invertir en ellas) desde el punto de vista del product owner (vista de usuario y clientes)
No todas las historias son independientes, y no todas las historias son totalmente negociable, pero todos deben ser valiosas
Valuable /Valioso
Las historias deben ser estimables por el equipo que las va a diseñar, construir y probar.
Las estimaciones proporcionan una indicación del tamaño y, por tanto, el esfuerzo y el costo (PRIORIDAD)
El equipo Scrum, por otra parte, puede determinar a partir del tamaño de la historia si se requiere refinamiento o desagregación adicional.
Si el equipo no es capaz de dimensionar una historia, la historia es o demasiado grande o ambiguas para ser clasificada, o el equipo no tiene los conocimientos suficientes para estimar un tamaño.◦ Si es demasiado grande, el equipo tendrá que trabajar con el
product owner para dividirla en historias más manejables◦ Si el equipo no tiene el conocimiento, será necesario algún tipo de
actividad exploratoria para adquirir la información
Estimatable /Estimable
Las historias deben ser del tamaño adecuado para cuando tenemos la intención de trabajar en ellas.
Historias trabajadas en sprints deben ser pequeñas.
Debe tener en cuenta cuando la historia se trabajará cuando se aplica este criterio.
Small (Sized Appropriately) / Pequeña (Tamaño Apropiado)
Una historia sólo debe considerarse finalizada (hecha) , entre otras cosas, si se puso a prueba con éxito.
Si uno no puede probar una historia debido a la falta de información, la historia no debe ser considerada como buena candidata para ser parte del backlog
Las historias deben ser comprobable en una manera binaria ya sea que se apruebe o no.
Debido a que estas pruebas con frecuencia proporcionan importantes detalles de la historia, pueden ser necesarias antes de que el equipo incluso pueda estimar la historia.
No siempre puede ser necesario o posible probar una historia (Ej. Historias epicas)
Testable / Comprobable
Project Inception
Involucrar a los usuarios como parte del equipo que está determinando qué construir y está constantemente revisando lo que se está construyendo
La recopilación de historias
El objetivo del taller es generar una lluvia de ideas en conjunto alrededor de los valores de negocio que desee y crear marcadores de posición de la historia de usuario para lo que se supone que el producto o servicio debe hacer.◦ No se genera un conjunto completo de historias de usuario
desde un inicio.◦ El taller tiene un enfoque específico. Ej. Analizar los roles de
usuario o definición de personas El taller incluye frecuentemente al Product Owner,
ScrumMaster y el equipo de desarrollo, en colaboración con los stakeholders internos y externos.
Top- Down o Down- Top
Talleres de redacción de historias de usuarios.
Story mapping es una técnica popularizada por Jeff Patton (Patton 2009) Toma una perpectiva centrada en el usuario para generar el conjunto de historias.
La idea básica consiste en descomponer las actividades de usuarios de alto nivel en un flujo de trabajo que se puede descomponer aún más en un conjunto de tareas detalladas
Patton utiliza términos como actividad, tarea, y subtarea para describir la jerarquía dentro de un mapa de historias.◦ Epic -> Theme -> Sprintable story = Activity -> Task -> Subtask
Epic: Representan las actividades más grandes que aportan valor medible al usuario.
Mapeo historia combina los conceptos de diseño centrado en el usuario con descomposición de historias
Muestran un flujo de actividades, desde la perspectiva del usuario y proporcionan un contexto para entender las historias individuales y su relación con las unidades más grandes de valor para el cliente.
Mapeo de Historias
Seleccionar una historia épica Siguiente pensamos en la secuencia o flujo de
trabajo común de las tareas del usuario que conforman la épica(representado por temas-colecciones de historias relacionadas)
Exponemos los temas a lo largo de una línea de tiempo.
Cada tema se descompone entonces en un conjunto de historias implementables que están acomodadas verticalmente en orden de prioridad
Descripción :Story Mapping
Es una colección de diez preguntas difíciles y ejercicios creado originalmente por Robin Gibbons
Lo usamos para cubrir el área de iniciación del proyecto en métodos ágiles
Si podemos conseguir a la gente adecuada en la habitación y preguntarles las preguntas correctas, esto va a hacer maravillas para establecer colectivamente las expectativas acerca de nuestro proyecto.
Al poner el equipo a través de una serie de ejercicios y capturar la salida en un conjunto de diapositivas (generalmente PowerPoint), podemos conseguir colectivamente una idea bastante clara de lo que este proyecto es, lo que no es, y lo que va a tomar para entregar.
Inception Deck
Cualquier persona directamente involucrada en el proyecto◦clientes, stakeholder, los miembros del
equipo, desarrolladores, testers, analistas
Las personas adecuadas:
Descripción del Inception Deck: Por qué estamos aquí. Crear un discurso de
ascensor. Diseñar la caja del
producto. Cree una lista de NOs. Conocer a los vecinos Mostrar la solución. Preguntar lo que nos quita
el sueño. Asignarle un tamaño Ser claro sobre lo que va a
obtener Mostrar lo que va a
necesitar
Top Related