Scrum Fase I: Iniciar – Herramientas #scrum

Herramientas

Project Vision Meeting*

Project Vision Meeting es una reunión con el/los Program Stakeholder(s), Program Product Owner, Program Scrum Master, y Chief Product Owner. Ayuda a identificar el contexto empresarial, business requirements y las expectativas de los stakeholders con el fin de desarrollar un Project Vision Statement eficaz. Scrum cree en la participación y colaboración cercana con todos los representantes de las empresas para obtener su buy-in (convencimiento de su importancia) del project y para ofrecer un valor más significativo.

 

JAD Sessions

Joint Application Design (JAD) Session es una técnica de recopilación de requisitos. Se trata de un taller facilitado altamente estructurado que acelera el proceso de Create Proyect Vision, ya que permite al/a los stakeholder(s) y a otros que toman decisiones llegar a un consenso sobre el alcance, los objetivos, y otras especificaciones del project. Esta técnica consiste en métodos para aumentar la participación del usuario, lo que acelera el desarrollo y la mejora de las especificaciones. Los Relevant Program Stakeholder(s), Program Product Owner, Program Scrum Master y Chief Product Owner podrían reunirse para delinear y analizar los resultados de negocio deseados y visualizar su visión para el project Scrum.

 

SWOT Analysis

SWOT es un enfoque estructurado para la planificación que ayuda a evaluar los/las StrengthsWeaknesses, Opportunities y Threats (puntos fuertes y débiles, oportunidades y amenazas) relacionados con un project. Este tipo de análisis ayuda a identificar tanto los factores internos como externos que podrían afectar el project. Las fortalezas y debilidades son factores internos, mientras que opportunities y amenazas son factores externos. La identificación de estos factores ayuda a los stakeholders y a aquellos que toman decisiones a finalizar los procesos, las herramientas y las técnicas que se utilizarán para lograr los objetivos del project. La realización de un SWOT permite la identificación precoz de las prioridades, los cambios potenciales, y los risks.

 

Gap Analysis

 Gap Analysis es una técnica que se utiliza para comparar el estado actual con el estado deseado. En una organización, se trata de determinar y documentar la diferencia entre las capacidades actuales del negocio y el conjunto final deseado de capacidades. Normalmente, se inicia un proyecto para que una organización alcance una situación deseada, por lo que llevar a cabo un Gap analysis ayudaría a quienes toman decisiones a determinar la necesidad de un project.

Los principales pasos a seguir en Gap Analysis:

sc-h1

Scrum Fase I: Iniciar – Entradas #scrum

Los procesos de Scrum abordan las actividades y el flujo específico de un proyecto Scrum. En total hay diecinueve procesos que se agrupan en cinco fases: Iniciar, Planear y Estimar, Implementar, Revisión y retrospectiva y Lanzamiento.

Los procesos relacionados con la iniciación de un proyecto:

  1. Create Project Vision—En este proceso, el Project Business Case es revisado para crear un Project Vision Statement que servirá de inspiración y proporcionará un enfoque de todo el project. El Product Owner se identifica en este proceso.
  1. Identificar al Scrum Master y al/a los stakeholder(s)—En este proceso, el Scrum Master y los stakeholders se identifican utilizando criterios de selección específicos.
  2. Form Scrum Team—En este proceso, se seleccionan a los miembros del Scrum Team. Normalmente, el Product Owner es el responsable principal de la selección de los miembros del equipo, pero a menudo lo hace en collaboration con el Scrum Team.
  3. Develop Epic(s)—En este proceso, el Project Vision Statement sirve como la base para el desarrollo de epics. User Group Meetings pueden tomar lugar para discutir el/los Epic(s) apropiado(s).
  1. Create Prioritized Product Backlog—En este proceso, los Epic(s) son refinados, elaborados, y luego priorizados para crear el Prioritized Product Backlog del proyecto. Lo que se conoce como Done Criteria también se establece en este punto.
  1. Conduct Release Planning—En este proceso, el Scrum Core Team revisa los User Stories en el Prioritized Product Backlog para desarrollar un Release Planning Schedule, que es esencialmente un program de implementación por fases que se puede compartir con los stakeholders del project. Los Length of Sprints también se determinan en este proceso.

Entradas

Project Business Case

Un caso de negocio (business case) puede ser un documento bien estructurado o simplemente una declaración verbal que expresa la razón para iniciar un project. Puede ser formal y detallado, o informal y breve. Independientemente del formato, a menudo incluye información sustancial sobre los  antecedentes del project, los objetivos del negocio y los resultados deseados, un SWOT y Gap Analysis, una lista de los risks identificados, y las estimaciones de tiempo, el esfuerzo y costo.

El project se inicia con la presentación del Project Business Case. Un caso de negocio se le presenta a los stakeholders y patrocinadores (sponsors). Los stakeholders así comprenden los beneficios de negocio esperados de tal project y los patrocinadores confirman que van a proporcionar los recursos financieros para el project.

 

Program Product Owner

El Program Product Owner es la persona responsable de maximizar el valor del negocio para un program. Él/ella es responsable de la articulación de requisitos de los customers y de mantener business justification para el program y puede aportar de forma importante sobre qué projects deben ser implementados, y de que manera, en un program. El Program Product Owner también administra el Program Product Backlog.

El Program Product Owner interface con el Portfolio Program Owner para asegurar la alineación del programa con las metas y objetivos del portfolio. Él/ella también tiene que ver con el nombramiento de los Product Owners para los proyectos individuales, y debe asegurar que la visión, los objetivos, los resultados, y las liberaciones de los projects individuales en el program estén alineados con los del programa.

 

Program Scrum Master

El Program Scrum Master es un facilitador que asegura que todos los equipos del project en el program dispongan de un entorno propicio para completar con éxito sus projects. El Program Scrum Master guía, facilita y les enseña las prácticas de Scrum a todos los que participan en el program; también sirve como guía para los Scrum Masters de los distintos projects; elimina los impediments de los diferentes equipos del project; coordina con el Scrum Guidance Body para definir los objetivos relacionados con la normativa de calidad, el gobierno, la seguridad y otros parámetros claves de la organización; y asegura que los procesos de Scrum se estén siguiendo de manera efectiva a lo largo del program.

El Program Scrum Master debe interactuar con el Portfolio Scrum Master para segurar la alineación del program con las metas y objetivos del portfolio. También tiene que ver con el nombramiento del Scrum Masters para projects individuales y debe asegurar que la visión, los objetivos, los resultados, y las liberaciones de los proyects individuales en el program estén alineados con los del program.

 

Program Stakeholder(s)

Program Stakeholder(s) es un término colectivo que incluye a los customers, los usuarios y patrocinadores para un program. Influyen en todos los projects del program durante todo el desarrollo del project. El/Los Program Stakeholder(s) también puede(n) ayudar a definir la visión del project y a proporcionar orientación en relación con el valor del negocio.

El/Los Program Stakeholder(s) debe(n) interactuar con los Portfolio Stakeholders para asegurar la alineación del program con las metas y objetivos del portfolio. Ellos también están involucrados con el nombramiento del/de los Stakeholder(s) para projects individuales y se aseguran que la visión, los objetivos, los resultados, y los lanzamientos de los projects individuales en el program estén alineados con los del program.

 

Chief Product Owner

En el caso de grandes projects con numerosos Scrum Teams, podría ser neceario tener un Chief Product Owner. Esta función se encarga de coordinar el trabajo de los múltiples Product Owners. El Chief Product Owner prepara y mantiene el Prioritized Product Backlog para los projects grandes, usándolo para coordinar el trabajo a través de los Product Owners de los Scrum Teams. Los Product Owners, a su vez, gestionan sus respectivas partes del Prioritized Product Backlog.

El Chief Product Owner también se comunica con el Program Product Owner para asegurar la alineación de los projects grandes con las metas y objetivos del program.

 

Program Product Backlog

El Program Product Owner desarrolla el Program Product Backlog del product que contiene una lista de prioridades de negocios de alto nivel y los requisitos del project escritos preferiblemente en forma de Program Backlog Items del program. Luego, estos son refinados por los Product Owners de los projects individuales, ya que crean y dan prioridad a pedidos pendientes del product para sus projects.

Estos Prioritized Product Backlogs tienen User Stories más pequeños pero detallados que pueden ser aprobados, estimados, y aplicados por miembros del Scrum Team.

El Program Product Owner mantiene de forma continua el Program Product Backlog para garantizar que los nuevos business requirements se añadan y que los requisitos existentes estén debidamente documentados y priorizados. Esto asegura que a los requisitos más valiosos en el cumplimiento de los objetivos del program se les esté dando alta prioridad y que los restantes reciban una prioridad más baja.

El Program Product Backlog creado para el program presenta una imagen más grande de todos los projects que forman parte del program. Por lo tanto, puede servir de orientación en relación con los objetivos del project, el alcance, los objetivos y los beneficios esperados del negocio.

 

Trial Project

Si es factible, un demo o prueba del project en pequeña escala podría ser ejecutado como un experimento para predecir y evaluar la viabilidad, tiempo, costo, risks, y los posibles efectos del project. Esto ayuda a evaluar el entorno de práctica y guías del diseño del project con anterioridad a la iniciación del project.

Proof of Concept

Proof of Concept demuestra y verifica que la idea detrás del proyecto actual es potencialmente viable en el entorno real. A menudo esto se hace en la forma de un prototipo diseñado para determinar la viabilidad técnica y financiera, ayudar a comprender los requisitos, y ayudar en la evaluación de las decisiones de diseño al principio del proceso. Sin embargo, Proof of Concept no necesita representar necesariamente los verdaderos Deliverables (Entregables) del project.

Company Vision

La comprensión del Company Vision ayuda a que el project mantenga su enfoque en los objetivos de la organización y el futuro probable de la empresa. El Product Owner se puede guiar por el Company Vision para crear el Project Vision Statement.

 

Company Mission

Company Mission ofrece un marco para la formulación de las estrategias de la empresa y orienta la toma de decisiones en general en la empresa. Project Vision debe enmarcarse de tal manera que su cumplimiento ayuda a la organización a llevar a cabo su misión.

 

Market Study

Market Study se refiere a la investigación organizada, la recopilación, la comparación y el análisis de datos relacionados con las preferencias de los customers sobre los products. A menudo incluye numerosos datos sobre las tendencias del mercado, la segmentación del mercado y los procesos de comercialización.

Estudio de mercado podría incluir también un estudio analítico de los competidores que proporciona una mejor comprensión de las fortalezas y debilidades de los competidores y puede ayudar a los que toman decisiones a formular productos mejor posicionados.

Recomendaciones del Scrum Guidance Body

El Scrum Guidance Body (SGB) es una función opcional. Por lo general, se compone de un grupo de documentos y/o un grupo de expertos que normalmente están involucrados en la definición de objetivos relacionados con la calidad, las regulaciones gubernamentales, la seguridad y otros parámetros claves de la organización. Estos objetivos guían la labor llevada a cabo por el Product Owner, Scrum Master, y el Scrum Team. El Scrum Guidance Body también ayuda a capturar las mejores prácticas que se deben utilizar en todos los projects Scrum en la organización.

El Scrum Guidance Body no toma decisiones relacionadas con el project. Este actúa como una consultoría o una estructura de orientación para todos los niveles de jerarquía en el project de organización del portfolio, program y project. Los Scrum Teams tienen la opción de pedirle asesoramiento al Scrum Guidance Body.

Es importante asegurarse de que la visión del project esté alineada con las recomendaciones proporcionadas por el Scrum Guidance Body y que los procesos cumplan con las normas y directrices establecidas por el Body (la Administración).

Reflexión de una Venezolana

Hoy quiero expresarme como Venezolana, si bien es cierto vivo en un país que está pasando por una crisis humanitaria profunda, con una hiperinflación que nos arrolla y que muchos de los que aún estamos aquí en nuestra tierra sentimos que estamos en medio de una tormenta, somos gente que día a día lucha no solo por sobrevivir en medio de este caos, también soñamos con superarnos, crecer, aportarle a la sociedad algo que deje huella para ser mejores como seres humanos y profesionales.

Al igual que muchas personas en mi país he despedido con dolor familiares y amigos que han decidido migrar a otros países, porque en éste, el nuestro las oportunidades cada vez son más pequeñas.  Ingenieros Civiles, Industriales, de Sistemas, Arquitectos, Médicos, Fisioterapeutas, Enfermeras, Administradores, Abogados, también gente de oficios loables muy buenos en lo que hacen mecánicos, costureras, reposteros, etc.  Sin contar a una juventud maravillosa que apenas esta saliendo de formación básica y se ha ido también. En fin no es un secreto para el mundo la migración masiva que se ha dado en los últimos años.

Cuando reflexionas y confirmas que este fue un país por muchos años atractivo para recibir emigrantes, Venezuela estaba llena de Italianos, Españoles, Portugueses, Asiáticos, Árabes, Peruanos, Bolivianos, Colombianos, Argentinos, etc……. (Quizás por ello tenemos dentro de nuestra cultura una fusión de costumbres, una riqueza en gastronomía entre muchas otras cosas); que dolor me inunda cuando leo noticias de discriminación hacia los venezolanos, donde tratan a la mujer venezolana de prostituta solo por tener esta nacionalidad.  En Venezuela habemos cientos de miles de mujeres que salimos todos los días a trabajar día a día con dignidad, con valentía, con entusiasmo, ganas de aprender, dar lo mejor siempre y sobre todo de aportar. Que dolor cuando veo publicidad donde incitan en otros países a golpear a un venezolano y eso es motivo de una premiación.

Habemos cientos de miles de Venezolanos que a pesar de la crisis siempre buscamos construir, no destruir, superarnos, aportar a la sociedad, es fácil juzgar desde fuera por qué mucha gente se ha ido, que fácil es tildarlo de invasores que van a robarle oportunidades a otros, mucho peor que feo es decirle a una mujer Venezolana prostituta, quizás porque esta fusión de muchas razas ha hecho que las mujeres Venezolanas sean muy lindas. Pero es que muchos se han ido por sobrevivencia, porque necesitan trabajar y salir adelante con sus familias.

Admiro países como Chile donde han albergado a muchísimos profesionales de mi país y reconocen que se han ido a aportar una mano de obra calificada, preparada que los ayuda a nutrirse.

Obviamente todo debe ser medido, evaluado, cada país tiene sus propios problemas y quizás solo puedan recibir cierto número de extranjeros. Eso es entendible, es lógico.

Lo que no es lógico es que estamos en la era de la sociedad global y que la discriminación exista en forma radical y absurda.

Quizás esto no lo lea mucha gente, pero sentía la necesidad de expresarme, así como me siento a compartir material de lectura profesional con la ilusión de que a alguien en el mundo este blog va a beneficiar (estudiante, profesional) sin esperar nada a cambio, solo aportar un grano de arena a una sociedad, así mismo espero que esta lectura nos invite a reflexionar sobre el maltrato al Venezolano emigrante

Artefactos Scrum #scrum

En Scrum los Artefactos son los resultados, o productos, de las actividades de gestión. Están diseñados para aumentar la transparencia de la información relativa a la entrega del proyecto, y propiciar oportunidades para la inspección y adaptación del mismo.

En Scrum hay seis artefactos:

  1. El Backlog de Producto (https://proyectosagiles.org/lista-requisitos-priorizada-product-backlog/): una lista ordenada de todos los elementos que podría necesitar el producto final, conocidos como historias o historias de usuario.
  2. El Backlog del Sprint (https://proyectosagiles.org/lista-tareas-iteracion-sprint-backlog/ ): se compone de los artículos seleccionados (historias) del Backlog del Producto que se entregarán a través de un Sp int, junto con el objetivo del Sprint y los planes para la entrega de los artículos y la realización del objetivo del Sprint.
  3. Incremento (https://www.scrummanager.net/bok/index.php?title=Incremento) : se refiere al conjunto de todos los elementos “completos” del Backlog del Producto hasta el fin del Sprint actual.
  4. La definición de “Completo” (http://managementplaza.es/blog/la-definicion-completo-scrum/) : es la comprensión compartida entre todos los miembros del Equipo de Desarrollo de lo que significa que un elemento de trabajo se considere “completo”, 100% realizado.
  5. Monitoreo del progreso hacia la meta (http://managementplaza.es/blog/seguimiento-del-progreso-proyectos-scrum/) se refiere a la medición de los resultados y las previsiones para todo el proyecto
  6. Monitoreo del progreso hacia el Sprint (http://managementplaza.es/blog/seguimiento-del-progreso-del-sprint-scrum/) : es la medición de los resultados y las previsiones para un solo Sprint

Les invito a visitar cada uno de los link que hace explicación de calidad para entender en forma correcta cada uno de los artefactos

Los 05 Eventos Scrum: Evento 5 Retrospectiva del Sprint #scrum

Es una reunión de tres horas para Sprints de un mes, y proporcionalmente más corta en función de la duración del Sprint.

Después de la Revisión de Sprint y justo antes del final del Sprint, se lleva a cabo una reunión cuyo objetivo es la mejora de procesos (lecciones aprendidas), que se conoce como Retrospectiva del Sprint.

En Scrum la regla es que debemos buscar constantemente formas de mejorar, no importa lo pequeña que sea la mejora, pero debe haber una mejora. Esta reunión es una oportunidad formal para generar mejoras, aunque no debemos limitarnos ni esperar a los resultados de esta reunión; debemos buscar y aplicar mejoras constantemente.

Durante la Retrospectiva del Sprint inspeccionaremos el Sprint actual en lo referente a las personas, los procesos y las herramientas, e identificaremos formas de mejorar para el próximo Sprint.

Refinamiento del Backlog del Producto

Además de los eventos de tiempo limitado (time box) que hemos comentado, existe una actividad en los proyectos Scrum conocida como “refinamiento” del Backlog del Producto.

Consiste en revisar y modificar los elementos del Backlog del Producto y normalmente implica añadir detalles, estimaciones y ordenar los elementos. Mientras que el Dueño del Producto es responsable de ordenar (priorizar) los artículos, el equipo de desarrollo es responsable de estimar el esfuerzo requerido para completarlos.

La principal diferencia entre esta actividad y los cinco eventos de Scrum es que los eventos de Scrum se realizan todos en “bloques o cajas de tiempo” pero el “refinamiento” es una actividad constante que sucede a lo largo de todo el Sprint. Esta actividad no debe consumir más de un 10% del tiempo del equipo de desarrollo.
 

Los 05 Eventos Scrum: Evento 4 Revisión del Sprint #scrum

La duración de esta reunión es normalmente de cuatro horas para Sprints de un mes. Si los Sprints son más cortos, la reunión será proporcionalmente más corta.

Al final del Sprint el Equipo Scrum y las otras partes interesadas se reúnen y mantienen una reunión de tiempo limitado en función de la duración del Sprint, para presentar y revisar los artículos “Completos”, el incremento del actual Sprint, y actualizar el Backlog del Producto. El propósito de presentar el incremento en esta reunión, es recabar información y conocer las solicitudes de cambio a la mayor brevedad.

El equipo de desarrollo no presentará un elemento a menos que este completo al 100% en base a la definición acordad de “Completo”. El Dueño del Producto debe asegurarse antes de la Revisión del Sprint, que los elementos que se presentan están “completos”. El Equipo de Desarrollo es responsable de demostrar y explicar los elementos.

El Dueño del Producto examina el estado del Backlog del Producto y las fechas de probables de finalización y los progresos realizados.

Por último, todo el equipo de Scrum participa en la revisión del backlog delproducto en base a los resultados del Sprint y el feedback del cliente.

 

Los 05 Eventos Scrum: Evento 3 Scrum Diario #scrum

El Scrum Diario es una reunión de 15 minutos para que el Equipo de Desarrollo inspeccione el trabajo realizado desde la última reunión, se sincronice, y establezca el plan para las próximas 24 horas. Debe realizarse, como su nombre indica a diario.

Durante el Scrum Diario cada miembro del Equipo de Desarrollo debe responder a estas tres preguntas:

  1. ¿Qué he hecho desde la última reunión?
  2. ¿Qué voy a hacer antes de la próxima reunión?
  3. ¿Qué obstáculos he encontrado en el camino?

El Equipo de Desarrollo debe evaluar el progreso hacia el objetivo del Sprint y pronosticar la probabilidad de completar los artículos antes de que concluya el Sprint.

Para evitar complicaciones el Scrum Diario debería celebrarse siempre en el mismo lugar y a la misma hora durante todo el Sprint. Es una reunión sólo para el Equipo de Desarrollo, no una reunión para todos los grupos de interés.

El Equipo de Desarrollo también debe monitorear el progreso del Sprint cada día y por lo tanto es una buena idea que el tablón del Sprint, que podría ser un mural o un grafico en la pared, este visible durante esta reunión. Podríamos además utilizar un gráfico de avance (burn-down chart) para monitorear el trabajo restante y prever si todos los artículos se completaran antes del final del Sprint. Observa el siguiente tablón de Sprint que incluye un diagrama de avance, para monitorear el progreso del sprint, en base a la cantidad pendiente de trabajo.

El tablón del Sprint anterior incluye una gráfica de avance del Sprint (Sprint Burn-down chart) que nos ofrece información para el seguimiento del Sprint, y que podría actualizarse después de cada reunión de Scrum Diario. Hablaremos sobre las gráficas de avance del Sprint en la próxima sección.
 

Los 05 Eventos Scrum: Evento 2 Planificación del Sprint #scrum

La reunión de planificación del sprint es uno de los eventos de scrum técnico.  Les recomiendo visitar el siguiente link para ver detalles antes de leer este post.

El Equipo de desarrollo no tiene que esperar hasta que el Backlog de Producto esté planificado al 100% para comenzar a desarrollar el proyecto. Tan pronto como el Backlog de Producto esté lo bastante maduro, tenga el número necesario de historias como para proporcionar la información de primer Sprint, el Dueño del Producto y el Equipo de Desarrollo comienzan con el primer Sprint.

El equipo de desarrollo debe estimar la capacidad de trabajo que puede ofrecer en un solo Sprint. Previamente el Dueño del Producto ya ha clasificado y ordenado los elementos del Backlog del Producto en base al valor de los artículos. El Dueño del Producto también es responsable de asegurarse de que los elementos (historias) sean fáciles de entender.

A continuación el equipo de desarrollo selecciona un número de elementos de la parte superior del Backlog del Producto y los pone en el Backlog del Sprint, para completarlos y entregarlos en el Sprint actual. Es el Equipo de Desarrollo el que calcula la cantidad de trabajo que requiere cada artículo. La cantidad total de trabajo de los elementos seleccionados del Backlog del Producto, debería estar cerca de la capacidad de trabajo estimada del Equipo de Desarrollo.

Seleccionados los artículos, el Equipo Scrum debería redactar el objetivo del Sprint. El objetivo del Sprint es el objetivo que debería alcanzarse durante el Sprint a través del desarrollo de los elementos seleccionados del Backlog del Producto, y proporciona orientación al Equipo de Desarrollo sobre por qué se está construyendo el incremento.

El Backlog del Producto debería estar ordenado de forma que facilite el establecimiento del objetivo del Sprint. Establecer y redactar el objetivo del Sprint es responsabilidad de todo el equipo Scrum.

El alcance del Sprint, que está compuesto por los distintos elementos seleccionados del Backlog del Producto, podría necesitar un mayor grado de detalle conforme el Sprint vaya evolucionando. Este mayor grado de detalle, deberá estar siempre alineado con el Objetivo del Sprint, y en el caso que fuera necesario negociarse, deberá estar presente el Dueño del Producto. El objetivo del Sprint también se incluye en el Backlog del Sprint.

Una vez seleccionado los elementos a entregar y establecido el objetivo del Sprint, es momento de planificar cómo los distintos artículos del Backlog del Sprint van a “transformarse” en un incremento del producto “Completo”, y como a través de estos se hará realidad el objetivo del Sprint. Esta es la última parte del Backlog del Sprint.

Un plan detallado es un elemento del Backlog de Producto (historias de usuario) descompuesto en tareas que habrá que hacer con el fin crear dicho elemento. Cada tarea puede contener estimaciones, dependencias y cualquier otra información similar necesaria para su seguimiento.

Las notas adhesivas amarillas (post-its) son las tareas que se crean al descomponer cada una de las historias de usuario (azules). Estas tareas (en amarillo) definen lo que el equipo de desarrollo va a hacer para entregar cada elemento, y son responsables de su preparación. Algunas tareas se crean en la reunión de Planificación del Sprint, y otros a lo largo de todo el Sprint.

El Backlog del Sprint está compuesto de:

  1. El Objetivo del Sprint
  2. Los artículos seleccionados del Backlog de Producto, que se entregarán a través de la Sprint (en azul)
  3. Un plan detallado para convertir los elementos seleccionados (historias o historias de usuario) en un Incremento “Completo” del producto y realizar el objetivo del Sprint

Puedes observar en el Tablón del Sprint los tres elementos del Backlog del Sprint: 1) el Objetivo del Sprint, 2) los elementos seleccionados del Backlog del Producto para completar en el Sprint, y 3) el plan detallado. El tablón cuenta además con otras características adicionales que permiten el seguimiento de las tareas en las columnas “Pendiente“, “En Progreso” y “Completado“.

tablero1

También puedes observar que se han añadido tareas adicionales a los elementos situados en la parte baja del cuadro (item # 3 al # 5). Son el resultado de la planificación detallada que se lleva a cabo durante el Sprint.

tablero2

Los elementos del Backlog del Sprint guardan por lo general el mismo orden que tenían en el Backlog del Producto, por lo tanto, el equipo de desarrollo debe trabajar primero en los artículos de la parte alta de la tabla.

Cuando escalamos Scrum, los miembros de cada uno de los equipos de desarrollo se reúnen con el Dueño del producto y seleccione sus elementos. De esta manera, cada equipo forma su propio Backlog del Sprint por separado, pero sobre un único Backlog de Producto.

Te recomiendo visitar:  Ejemplo de uso del tablero o pizarra de tareas (Scrum Taskboard)

 

Los 05 Eventos Scrum: Evento 01 El Sprint #scrum

Un proyecto que sigue Scrum se gestiona en base a cinco eventos claves:

scrum evento 1

Evento 1: El Sprint

En un proyecto Scrum el producto final se entrega después de un número de iteraciones, que se llaman Sprints. En cada Sprint se desarrolla un incremento, que es una parte potencialmente entregable del producto final. Un incremento es la suma de todos los elementos del Backlog de Producto completados hasta un punto determinado del proyecto, que continuará creciendo tras de cada Sprint hasta que el proyecto concluya.

Puedes considerar que cada nuevo Incremento al final de un Sprint es una versión actualizada del Incremento anterior, con nuevos características y funcionalidades, y que puede o no entregarse al cliente, pero siempre debe ser potencialmente entregable.

La clave está en que generalmente los clientes solicitan cambios cuando ven el incremento, durante la Revisión del Sprint. Estas nuevas solicitudes se añaden al Backlog de Producto y se desarrollaran en función de su valor (valor de negocio). Recuerda que es el Dueño del Producto el encargado de esta establecer los criterios para determinar el valor de cada uno de los elementos del Backlog de Producto.

Cada elemento del Backlog del Producto (historia de usuario) debería poder completarse en un Sprint, ya que así son mucho más fáciles de gestionar. El Dueño del Producto y el Equipo de Desarrollo seleccionan los artículos de la parte superior del Backlog de Producto, que ya ha sido previamente ordenado por el Dueño del Producto. Su objetivo es conseguir que estos estén “Completo” al 100% cuando el Sprint termine, y generar un incremento. Un incremento es la suma de todos los elementos completados durante el Sprint actual y todos los Sprints anteriores.

Es importante llegar a un acuerdo sobre una definición de “completo” al inicio del proyecto. No diremos que algo está “completo”, a menos que se ajuste a dicha definición. Un elemento hecho al 99.999% no puede ser considerado como “completo”, no sería parte del incremento y por lo tanto no sería mostrado al cliente durante la Revisión del Sprint.

Sprint time box: La mayoría de las organizaciones trabajan con Sprints de entre 2 y 4 semanas. Si trabajamos con Sprints más largos es probable que los cambios no aplicados sean lo suficientemente “grandes” como para generar problemas, aumentando la complejidad y el riesgo. Por lo tanto debemos limitar los Sprints a no más de un mes de calendario. Pero por otro lado, los Sprints tampoco deben ser demasiado cortos porque entonces no seremos capaces de producir artículos completos durante los mismos. Recuerda que nuestro objetivo es ofrecer al cliente el producto, o solución final, artículo por artículo, dentro de los límites de los Sprints; no queremos dividir la realización de un artículo del Backlog de Producto entre varios Sprints.

¿Puede cancelarse un sprint? A pesar de que como ya sabemos los Sprint son “bloques de tiempo” que no cambian, el Dueño del Producto tiene la autoridad para cancelar un Sprint. Esto puede suceder cuando el Objetivo de Sprint ha quedado obsoleto, bien por cambios en el Backlog de Producto, en la estrategia, en el enfoque, etc. Cuando se cancela un Sprint, los elementos que están “completos” son revisados y aceptados, y el resto de los artículos (aquellos que no se han iniciado o están parcialmente completos) se añaden de nuevo al Backlog del Producto para completarse en el futuro, en caso de que fuera necesario.

 

Scrum – Metodología Agil #Scrum

scrum1

En esta oportunidad quiero presentarles algunas nociones básicas de Scrum como marco de trabajo que nos permite encontrar prácticas emergentes en dominios complejos, como la gestión de proyectos de innovación.

Scrum es un proceso agil que nos permite centrarnos en entregas de valor para el negocio en tiempos cortos. Es decir, manejamos proyectos basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan con el tiempo según la necesidad del mismo. Así el trabajo es realizado mediante la colaboración de equipos auto-organizados y multidisciplinarios, inmersos en un proceso compartido de toma de decisiones a corto plazo.

Trabajar con este esquema permite una inspección rápida y continua del software en proceso de desarrollo en intervalos de tiempo cortos.  El negocio establece prioridades y el equipo se auto organiza para encontrar la forma de entregar las funcionalidades con mayor prioridad.  Cada dos o cuatro semanas cualquiera puede ver el trabajo real realizado, decidiendo así mismo si se puede liberar el producto o se debe continuar mejorando.

Veamos a continuación como nos organizamos para trabajar con Scrum.

scrum2.png

Lo primero que debemos definir es el o los equipos de trabajo, es decir tener  uno o más equipos de trabajo, con al menos 3 tres roles básicos dentro del equipo los cuales son:

1.dueño del producto,  Product Owner

Tiene la visión del negocio y conoce a detalle requerimientos del producto que se debe construir, lo que conlleva a ser el líder en cuanto a la toma de decisiones del desarrollo del producto.

2 ScrumMaster

El ScrumMaster es el responsable de que todos los involucrados entiendan y adopten los valores, principios y prácticas de SCRUM.

3 el equipo de desarrollo.

Responsables del diseño construcción y prueba del producto

Para entenderlo mejor veamos las características principales de cada rol.

scrum3

El Product Owner tiene la visión del negocio,  es quien tiene claro los requerimientos del desarrollo del software, siendo este quien tiene definido cada funcionalidad que debe desarrollarse es quien fija orden y prioridades en el product backlog; decide que debe construirse y que no.  En caso de hacer una modificación sobre alguna funcionalidad del software, es el product owner  quien fija las características minimas viables del software.

El Product Owner no da ordenes al equipo de desarrollo, solo debe asegurarse de hacer de conocimiento a cada integrante del equipo el product backlog, debe estar disponible y accesible al equipo para explicar las funcionalidades requeridas cada vez que sea necesario, participar en las reuniones diarias de avance , en los sprint de planificación, revisión y retrospectiva.

El Product Owner debe conocer la velocidad del equipo, para poder realizar las estimaciones de cuando estarán implementadas las necesidades en el producto.

En caso de que se requiera cancelar un Sprint por algún imprevisto externo, es el único responsable de  comunicar la cancelación.

El Product Owner es quien valida las entregas del equipo de desarrollo.

Es indiferente si el producto es una aplicación interna o un producto externo; el dueño del producto tiene la obligación de entregar el mayor valor posible, que incluye el foco en el desarrollo técnico.

scrum4

El Scrum master se encarga de que todo el equipo entienda scrum y lo aplique correctamente, es como un instructor, ayuda al equipo scrum y al resto de la organización a desarrollar la metodología dentro de la organización.  Implementar scrum es un proceso de cambio, el Scrum master apoya a todo el equipo en la adopción de la metodología

El ScrumMaster no tiene autoridad sobre el equipo de desarrollo, este rol no es similar al del jefe de proyecto de desarrollo. El ScrumMaster actúa como un líder, no como un jefe.

Las características más resaltantes del scrummaster:

1.Planifica la Implementación de scrum en conjunto con la organización

2.Ayuda al Product Owner que es quien tiene la visión del negocio a entender la agilidad.

3.Como instructor enseña al product owner a gestionar la planificación, elaboración del product backlog

4.Ayuda al equipo de desarrollo a convertirse en auto-organizado y multifuniocnal

5.Participa en las resuniones y se asegura que cumplan tiempo y objetivos establecidos.

6.Junto al equipo de desarrollo actualiza el progreso del trabajo

7.Promueve las buenas practicas de programación

8.Organiza y ejecuta cursos de aprender scrum si es necesario

scrum5

Equipo de desarrollo

Scrum define el rol de Equipo de Desarrollo, como una colección de diferentes actores, responsables de diseño, construcción o pruebas.

El equipo de desarrollo se debe auto organizar para presentar la mejor manera de cumplir con los requerimientos del usuario.

El equipo de desarrollo por lo general es de 5 a 9 personas; en forma colectiva tienen todas las habilidades necesarias para producir software de calidad.

Si el proyecto requiere de muchas más personas, digamos unas 35 personas, estas deben ser organizadas en equipos de desarrollo de máximo nueve personas.

scrum6

Los procesos de Scrum corresponden a todas aquellas actividades y al flujo de las mismas dentro de un proyecto Scrum.

En total la metodología desarrolla 19 procesos que se agrupan en 5 fases. Cada fases describe cada proceso en detalle, incluyendo sus entradas, herramientas y salidas asociadas. En cada proceso, algunas entradas, herramientas y salidas son obligatorias, y existen otras que son opcionales, cuyo uso dependerá de la naturaleza del proyecto.

Conozcamos un poco las fases y los procesos que incluyen cada una:

  1. Iniciación (6 procesos) 

En esta fase se crea la Visión del Proyecto que sirve de enfoque y dirección del mismo. Se crean e identifican roles claves del proyecto como el Scrum Master, Product Owner, interesados, equipo del proyecto. Así mismo, se define la lista de prioridades o el Product Backlog la cual sirve de base para la elaboración del plan de lanzamiento y tamaño de cada Sprit.

Procesos

Crear la visión del proyecto (Create Project Vision)

Identificar al Scrum Master y a los interesados o socios del proyecto (Identify Scrum Master and Stakeholder(s))

Formación del equipo Scrum (Form Equipo Scrum)

Desarrollo de épica(s) (Develop Epic(s))

Creación de la lista priorizada de pendientes del producto (Create Prioritized Product Backlog)

Realizar el plan de lanzamiento (Conduct Release Planning)

2. Planificación y Estimación (5 procesos):

Aquí se definen y aterrizan en los Sprints las historias de usuarios, se alinean a todo lo que genera valor a la organización y se hacen las estimaciones de tiempo y esfuerzo para cumplirlas, los cuales se traducen en listas de tareas cuyos tiempos de desarrollo se definen en reuniones de equipo correspondientes, así como el proceso de definición del Sprint Backlog que contiene todas las tareas que deben completarse en el Sprint.

Procesos

Elaborar historias de usuario (Create User Stories)

Aprobar, estimar y asignar historias de usuarios (Approve, Estimate, and Commit User Stories).

Elaboración de tareas (Create Tasks)

Estimar tareas (Estimate Tasks)

Elaboración de la lista de pendientes del Sprint (Create Sprint Backlog)

3. Implementación (3 procesos):

En esta fase se trabaja en las tareas del Sprint Backlog para crear Sprint Deliverables, para ello se utiliza a menudo un Scrumboard para realizar el seguimiento del trabajo y de actividades que se llevan a cabo. También,los inconvenientes o problemas que enfrenta el Equipo Scrum se actualizan en un Impediment Log. Durante esta fase se realizan las llamadas Daily Standup Meeting que son reuniones cortas y eficientes en tiempo donde el equipo da el estatus de sus actividades diarias y manifiesta cualquier inconveniente que pueda tener. Igualmente se actualiza o revisa la lista de prioridades de pendientes del producto.

Procesos

Crear entregables (Create Deliverables),

Llevar a cabo el standup diario (Conduct Daily Standup)

Mantenimiento de la lista priorizada de pendientes del producto (Groom Prioritized Product Backlog)

4. Revisión y Retrospectiva (3 procesos):

Para proyectos grandes que involucran varios equipos Scrum, se realiza en esta etapa, reuniones que permitan juntar a estos equipos y discutir y revisar avances, dependencias e impedimentos en el desarrollo del proyecto. También en esta etapa se lleva a cabo el proceso donde el Equipo Scrum le demuestra el Sprint Deliverable al Propietario del producto y a los Socios relevantes en un Sprint Review Meeting. Igualmente, el Scrum Master y el Equipo Scrum se reúnen para discutir las lecciones aprendidas a lo largo del Sprint, información que se documenta como las lecciones aprendidas que pueden aplicarse a los futuros Sprints.

Procesos

Convocar Scrum de Scrums (Convene Scrum of Scrums)

Demostración y validación del Sprint (Demonstrate and Validate Sprint)

Retrospectiva de Sprint (Retrospect Sprint)

5. Lanzamiento (2 procesos):

Finalmente, esta es la fase más esperada por los interesados o socios del proyecto así como del Scrum Master y Equipo Scrum. En esta fase se presentan los entregables y se les entregan a los Socios relevantes. Un acuerdo formal llamado Aceptación de Entregables, documenta la finalización con éxito del Sprint. Del mismo modo, se realizan actividades de restrospectiva que permite identificar mejoras y lecciones aprendidas del proyecto.

Envío de entregables (Ship Deliverables)

Retrospectiva del proyecto (Retrospect Project)

scrum7

Con Scrum El desarrollo se realiza de forma iterativa e incremental. El corazón de Scrum es un Sprint, es un intervalo prefijado durante el cual se crea un incremento de producto “Hecho o Terminado” utilizable, potencialmente entregable. A lo largo del desarrollo hay Sprints consecutivos de duración constante

Cada iteración, denominada Sprint, tiene una duración preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versión del software con nuevas prestaciones listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya construida y se añaden nuevas prestaciones priorizándose siempre aquellas que aporten mayor valor de negocio.

Veamos otros conceptos….

Product Backlog: Conjunto de requisitos demoninados historias descritos en un lenguaje no técnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversión considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.

Sprint Planning: Reunión durante la cual  el Product Owner presenta las historias del backlog por orden de prioridad. El equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint, para en una segunda parte de la reunión, decidir y organizar cómo lo va a conseguir.

Sprint: Iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product Backlog a las que se ha comprometido, en una nueva versión del software totalmente operativo.

Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint.

Daily sprint meeting: Reunión diaria de cómo máximo 15 min. en la que el equipo se sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el día anterior, que hará hoy y si hay impedimentos.

Demo y retrospectiva: Reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstración del producto. Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien, qué procesos serían mejorables y discute acerca de cómo perfeccionarlos.