SCRUM

El Product Owner es el encargado de optimizar y maximizar el valor del producto, siendo la persona encargada de gestionar el flujo de valor del producto a través del Product Backlog. Adicionalmente, es fundamental su labor como interlocutor con los stakeholders y sponsors del proyecto, así como su faceta de altavoz de las peticiones y requerimientos de los clientes. Si el Product Owner también juega el rol de representante de negocio, su trabajo también aportará valor al producto.Tradicionalmente, se ha entendido la labor del Product Owner como un gestor de requisitos o un cliente que se encarga de gestionar el Product Backlog, pero es mucho más que eso. No solo tiene la responsabilidad de mantener el Product Backlog bien estructurado, detallado y priorizado, sino que además tiene que entender perfectamente cuál es la deriva que se desea para el producto en todo momento, debiendo poder explicar y trasmitir a los stakeholders cuál es el valor del producto en el que están invirtiendo. Con cada Sprint, el Product Owner debe hacer una inversión en desarrollo que tiene que producir valor. Marcar el Sprint Goal de manera clara y acordada con el equipo de desarrollo, hace que el producto vaya incrementando constantemente su valor.Es fundamental otorgar el poder necesario al Product Owner para que este sea capaz de tomar cualquier decisión que afecte al producto. En el caso de que el Product Owner no pueda tomar estas decisiones sin consultarlas previamente con otra persona, deberá ser investido para tomarlas él mismo, o ser sustituido por esa persona. A su vez, el Product Owner debe convertirse en el altavoz del cliente, en el transmisor de las demandas y del feeback otorgado por los mismos.

El Scrum Master tiene dos funciones principales dentro del marco de trabajo: gestionar el proceso Scrum y ayudar a eliminar impedimentos que puedan afectar a la entrega del producto. Además, se encarga de las labores de mentoring y formación, coaching y de facilitar reuniones y eventos si es necesario.1.    Gestionar el proceso Scrum: el Scrum Master se encarga de gestionar y asegurar que el proceso Scrum se lleva a cabo correctamente, así como de facilitar la ejecución del proceso y sus mecánicas. Siempre atendiendo a los tres pilares del control empírico de procesos y haciendo que la metodología sea una fuente de generación de valor.2.    Eliminar impedimentos: esta función del Scrum Master indica la necesidad de ayudar a eliminar progresiva y constantemente impedimentos que van surgiendo en la organización y que afectan a su capacidad para entregar valor, así como a la integridad de esta metodología. El Scrum Master debe ser el responsable de velar porque Scrum se lleve adelante, transmitiendo sus beneficios a la organización facilitando su implementación.Puede que el Scrum Master esté compartido entre varios equipos, pero su disponibilidad afectará al resultado final del proceso Scrum.

El equipo de desarrollo suele estar formado por entre 3 a 9 profesionales que se encargan de desarrollar el producto, auto-organizándose y auto-gestionándose para conseguir entregar un incremento de software al final del ciclo de desarrollo.El equipo de desarrollo se encargará de crear un incremento terminado a partir de los elementos del Product Backlog seleccionados (Sprint Backlog) durante el Sprint Planning.Es importante que en la metodología Scrum todos los miembros del equipo de desarrollo conozcan su rol, siendo solo uno común para todos, independientemente del número de miembros que tenga el equipo y cuales sean sus roles internos. Cómo el equipo de desarrollo decida gestionarse internamente es su propia responsabilidad y tendrá que rendir cuentas por ello como uno solo; hay que evitar intervenir en sus dinámicas.Habitualmente son equipos ‘cross-funcional’, capaces de generar un incremento terminado de principio a fin, sin otras dependencias externas.

Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua, adaptación, auto-gestión e innovación.

El Product Backlog o pila de producto en un proyecto que sigue la metodología Scrum consiste en una lista con todos los requerimientos iniciales del producto que se va a desarrollar. Se trata de una lista dinámica, que irá evolucionando a medida que lo hace el producto y el entorno del proyecto. La finalidad de crear esta lista no es otra que identificar las necesidades del producto para lograr su máxima utilidad.

El Sprint Planning es una reunión que se realiza al comienzo de cada Sprint donde participa el equipo Scrum al completo; sirve para inspeccionar el Backlog del Producto (Product Backlog ) y que el equipo de desarrollo seleccione los Product Backlog Items en los que va a trabajar durante el siguiente Sprint. Estos Product Backlog Items son los que compondrán el Sprint Backlog.Durante esta reunión, el product owner presenta el Product Backlog actualizado que el equipo de desarrollo se encarga de estimar, además de intentar clarificar aquellos ítems que crea necesarios.Si bien en el Sprint Planning participa el equipo Scrum al completo, no participan los stakeholders. En el Sprint Planning se inspeccionan el Product Backlog, los acuerdos de la Retrospectiva, la capacidad y la Definition of Done y se adaptan el Sprint Backlog, Sprint Goal y el plan para poder alcanzar ese Sprint Goal.El Sprint Planning se divide en dos partes. En la primera parte de la reunión se trata Qué se va a hacer en el siguiente Sprint y, en la segunda parte, se discute el Cómo. La primera parte está organizada y liderada por el product owner, mientras que de la segunda parte se encarga el Development Team. La única labor del Scrum Master es asegurarse de que la reunión existe como parte de Scrum y que se mantiente dentro de las duraciones estimadas.El Sprint Planning puede durar hasta 8 horas para Sprints de 4 semanas. En la práctica esta ceremonia suele llevar una mañana completa -alrededor de 5 horas- y, sólo si el producto o el Sprint definido por el Product Owner son complejos o están poco claros, se llegan a alcanzar las 8 horas definidas en la metodología. La razón del Sprint Planning es conseguir alineamiento entre negocio y desarrollo de producto en relación a las prioridades.

En palabras sencilla, el Sprint Scrum es un ciclo de trabajo en el que se planifican un número determinado de actividades y se plantean objetivos específicos.La finalidad del Sprint en Scrum es desarrollar nuevas funcionalidades o características de un producto para que puedan ser aprobadas por el cliente, favoreciendo el control de la calidad del proceso y del producto, mientras que el cliente se asegura de desarrollar solo lo que aporte valor a su producto para así evitar los desperdicios.

El Sprint Backlog es un plan realizado por y para los desarrolladores, en el que se detalla, en tiempo real, las tareas que estos planean realizar durante el Sprint para cumplir con el Sprint Goal.Las características del Sprint Backlog son las siguientes:Se compone del Sprint Goal (“por qué”), el conjunto de elementos del Product Backlog seleccionados para el Sprint (“qué”) y un plan para entregar el Incremento (“cómo”).El Sprint Backlog se realiza en el evento de planeación del Sprint (Sprint Planning).Se puede ajustar a lo largo de Sprint si es necesario, a medida que el equipo aprende más sobre la tarea. Debe tener suficientes detalles para que el Scrum Master pueda inspeccionar el progreso del equipo en el Daily Scrum.

En Scrum, durante el desarrollo de un sprint, el equipo mantiene una reunion diaria llamada el "daily scrum”.Usualmente estas reuniones se realizan en el mismo lugar y a la misma hora, en cada uno de los días.Idealmente:El daily scrum meeting se realiza en la mañana, a fin de definir el contexto para el resto del día de trabajo.Estas reuniones son estrictamente desarrolladas con un tiempo límite de 15 minutos. Esto hace que la reunión sea breve y se traten puntos importantes.Esta reunión diaria (daily scrum meeting) no se realiza con el fin de resolver problemas específicos.De existir problemas específicos, estos son tratados de forma externa al daily scrum meeting, con el subgrupo correspondiente, justo después de esta reunión.

Previo a la sesión, cada miembro del equipo debe hablar de los siguientes puntos:Qué ha funcionado bien en el último Sprint.Cuáles cosas hay que mejorar de cara al siguiente Sprint.Problemas que haya tenido para poder progresar correctamente en el último Sprint.Recomendaciones a aplicar en el siguiente Sprint.Al realizarse después del Sprint Review, podemos incorporar el feedback que hayamos obtenido dentro de los puntos a hablar.

Según la identificación de las historias de usuario, se priorizan y se descomponen en mini-versiones. La planificación se va a ir revisando. Cada dos semanas aproximadamente de iteración, se debe obtener un software útil, funcional, listo para probar y lanzar.

En este paso se intentará trabajar con un código sencillo, haciendo lo mínimo imprescindible para que funcione. Se obtendrá el prototipo. Además, para el diseño del software orientado a objetos, se crearán tarjetas CRC (Clase-Responsabilidad-Colaboración).

La programación aquí se hace «a dos manos», en parejas en frente del mismo ordenador. Incluso, a veces se intercambian las parejas. De esta forma, nos aseguramos que se realice un código más universal, con el que cualquier otro programador podría trabajar y entender. Y es que deber parecer que ha sido realizado por una única persona. Así se conseguirá una programación organizada y planificada.

Se deben realizar pruebas automáticas continuamente. Al tratarse normalmente de proyectos a corto plazo, este testeo automatizado y constante es clave. Además, el propio cliente puede hacer pruebas, proponer nuevas pruebas e ir validando las mini-versiones.

Si hemos llegado a este punto, significa que hemos probado todas las historias de usuario o mini-versiones con éxito, ajustándonos a los requerimientos del clientes. Tenemos un software útil y podemos incorporarlo en el producto.

Extreme Programming es una metodología de desarrollo que pertenece a las conocidas como metodologías ágiles, cuyo objetivo es el desarrollo y gestión de proyectos con eficacia, flexibilidad y control. Ambos conceptos, aunque relacionados estrechamente, son distintos. Agile es el marco de trabajo para el desarrollo del software, se hace mediante un proceso iterativo y define las prácticas y roles del equipo. Por su lado, el Extreme Programming es una metodología basada en la comunicación, la reutilización del código desarrollado y la realimentación.

Como comunicación entendemos no solo una buena interacción interna entre los propios miembros del equipo de desarrolladores, sino también con los clientes. El objetivo es romper las barreras entre negocio y desarrollo. Para ello, la programación XP promueve que todos los requisitos sean comunicados y trabajados con el equipo y no mediante documentación.

Empezar con la solución más simple es clave en la programación XP. Esta metodología pone el foco en codificar las necesidades de hoy, no las de un futuro. Además, también se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Para conservar la simplicidad hay que mantener la refactorización del código, así podremos preservar el código simple a medida que va creciendo

Una de las mayores ventajas de que el cliente esté integrado en el proyecto es que su opinión sobre el estado de este lo podemos conocer en tiempo real. Gracias a que se hacen ciclos muy cortos de presentación de resultados, se minimiza el riesgo de tener que rehacer partes que no cumplen con las expectativas del cliente. También, por otro lado, ayuda a los programadores a centrarse en las tareas más importantes.

El respeto mutuo es fundamental para que un equipo pueda trabajar de forma eficiente y ofrecer un buen rendimiento. Implica desde que un desarrollador no realice modificaciones que puedan tener un impacto negativo en el trabajo de un compañero hasta la forma de llegar al cliente. El respeto se manifiesta de varias formas y todas son cruciales para una mejor autoestima en el equipo, que lleva consigo un mayor ritmo de producción.

Diseñar y programar para hoy y no para mañana implica valentía en la metodología XP, así como reconocer los errores tan pronto como se detecten. Ningún miembro del equipo puede perder el tiempo en intentar hacer de menos su responsabilidad en un error cometido, ya que esto significará dejar de centrarse en otras cosas e impedirá avanzar al resto, por lo que la productividad bajará.

En general, no obstante, los participantes en este tipo de equipos no siempre toman un rol fijo y contribuyen con los conocimientos de cada uno en aras del beneficio colectivo.

Establecen las prioridades y marca el proyecto. Suelen ser los usuarios finales del producto y quiénes marcan las necesidades.

Serán los que se encargarán de desarrollar el Extreme Programming.

se encargan de ayudar al cliente sobre los requisitos del producto.

Asesoran al resto de componentes del equipo y marcan el rumbo del proyecto.

Ofrece recursos, es el responsable de la comunicación externa y quien coordina las actividades.