El ciclo de producción en Scrum

El ciclo de producción en Scrum

por | Jul 17, 2018

Scrum es la adaptación de las metodologías ágiles más conocidas, y como tal es un framework que persigue los 12 principios del Manifiesto Ágil.

Siguiendo con estos principios, Scrum asume la entrega continuada del producto en verisiones estables periódicamente. Esto significa que el cliente verá como su producto incrementa su valor con cada nueva versión. Es un proceso por tanto iterativo, que se repite continuamente mientras el cliente necesite añadir nuevas funcionalidades al producto.

Para organizar el trabajo y no solo mejorar el producto, sino su proceso de elaboración, Scrum define un ciclo con una serie de hitos, fases y artefactos.

Los hitos son eventos, generalemente reuniones, que se producen a lo largo del ciclo de Scrum. Las fases son periodos de tiempo en los cuales el equipo Scrum se organiza con un fin especifico. Ambos están relacionados entre si mediante los artefactos de Scrum que son objetos creados para guiar el trabajo. Vamos a ver y relacionar todos ellos a través de la siguiente imagen que resume bastante adecuadamente todo el proceso:

El Product Backlog

El Product Backlog es el elemento central de Scrum. Es la pila de tareas que se deberán desarrollar para la consecucion del proyecto. Este artefacto está únicamente manejado por el Product Owner, que añadirá, eliminará y modificará tareas. Estas tareas deberán estar correctamente explicadas y con objetivos de terminación claros para que el equipo de desarrollo las evalúe y añada las que consideren que pueden desarrollarse en un sprint al propio Backlog del sprint. El Product Backlog contiene las tareas ordenadas en funcion de la prioridad que el Product Owner considere, pero eso no garantiza que vayan a ser implementadas en ese orden, sino que depende del equipo de desarrollo.

Usualmente las tareas del Product Backlog comienzan siendo más abstractas y se concretan a medida que avanza el tiempo, pues el cliente va teniendo más claro qué es lo que quiere y el Product Owner podrá detallar mejor los requerimientos.

Este artefacto es icónico de Scrum. Se suele representar y se recomienda que sea así, mediante una serie de columnas en las cuales se pegan papeles adhesivos con un código de colores en funcion de otros parámetros que se quieran representar: urgencia, complejidad, tipo de tarea, etc. Muchas veces se suele usar una pizarra, pero sirve cualquier superficie que sea visible y accesible para los miembros de Scrum. A diferencia del Backlog del sprint, no contiene diferentes columnas, ya que el estado de las tareas no varía hasta que se introduce en un sprint.

Refinamiento del Backlog

El objetivo de esta reunión es la de refinar las tareas del Backlog para su mejor comprensión durante el sprint. En este refinamiento el equipo de desarrollo se hace una idea de los recursos y el tiempo que le va a llevar completar cada una de ellas, estableciendo dependencias y recursos necesarios. Posteriormente pueden existir errores de estimación, pero la idea es que en esta fase se consiga acercar lo más posible la estimación a los recursos y tiempo reales del sprint, así como aclarar aquellas tareas del Backlog que no estén lo suficientemente claras.

La planificación del Sprint

La planificación del sprint es una reunion del Equipo Scrum (Product Owner, equipo de desarrollo y Scrum Master) en la que se van a elegir las tareas que van a formar parte del sprint. Estas tareas deben estar en el Backlog Product y pasarán a formar parte del Backlog del sprint. El Produt Owner se encarga de que todo el equipo entienda cual es la finalidad de cada tarea y en conjunto dirimen sobre la complejidad y el tiempo de desarrollo de cada una de ellas para llegar al estado de terminación de cada tarea. Aunque el Product Owner haya ordenado las tareas en el Product Backlog en función de prioridad, corresponde al equipo de desarrollo el elegir aquellas que formarán parte del siguiente Sprint.

El sprint Backlog

El Backlog del sprint es el icono por excelencia de Scrum. Consiste en una tabla con una serie de columnas por las cuales van pasando las tareas en función de su estado actual. Estas tareas son las escogidas durante la planificación del sprint. A medida que van cambiando de estado, van llegando a la ultima columna, que debe ser la de «terminado».

El Backlog del sprint tiene también una característica visible en las tareas y es que durante la planificación del sprint, a cada tarea incluída se le asignó un peso o un numero de horas para completarla. Esto nos sirve para manejar mejor los tiempos del sprint y tambien para hacer después una revisión y retrospectiva de cómo fue la estimación y conocer mejor al equipo, como veremos en sus respectivos hitos.

Es importante que cada tarea del sprint le corresponda a una y solo a una persona. Esto no quiere decir que no pueda pedir ayuda a sus compañeros pero

Existen muchas formas de organizar el Backlog del sprint, por ejemplo usando múltiples filas en función de la temática de la tarea, pero en cualquier caso, el común denominador es el flujo de las mismas. Al igual que el Product Backlog, el Backlog del sprint debe estar en un lugar accesible y visible para que los miembros del equipo sean capaces de ver el estado actual del sprint y poder manipular el estado de las tareas.

tablero scrum

Sprint

El sprint es la parte central del ciclo de desarrollo. Aquí el equipo de desarrollo se afana en introducir e implementar todas las tareas definidas enm el Backlog del sprint. La duracion es variable, en funcion del numero de tareas pero se recomienda que se mantenga constante en todo el proyecto y comprenda entre 2 y 4 semanas. Durante este periodo de tiempo el equipo trabaja a contrareloj y el Scrum Master procura evitar los impedimentos que puedan afectar al ritmo del trabajo. Es obvio que en esta fase el equipo puede estar sometido a estrés. No es deseable. El sprint debe ser exigente, pero no estresante para el equipo de desarrollo. La manifestacion de sintomas de estres derivan en frustración y falta de motivacion, por lo que para Scrum es de vital importancia atajarlos rápidamente. Por desgracia, el sprint no se puede detener y aunque es cierto que el estrés no es algo que pueda aparecer el el plazo de tiempo que sucede un sprint, fallos de estimación continuados que lleven al limite al equipo de desarrollo pueden ser fatales para el desempeño del equipo.

Durante el sprint el equipo de desarrollo tiene que ser autosuficiente y autorganizarse de manera que consiga llevar a cabo todas las tareas sin ayuda externa.

El Scrum diario

El Scrum diario es el ritual más definitorio de Scrum. Consiste en un a pequeña reunion a primera hora de la jornada laboral con una duracion no superior a los 15 minutos en los cuales los miembros del equipo responden a tres preguntas: qué hicieron ayer, qué harán hoy y qué dificultades se están encontrando.

El Scrum diario sirve para que todo el equipo conozca el estado actual del proyecto y des sprint, pudiendo identificar qué cosas van funcionando y cuáles no. El Scrum Master deberá tomar nota de las intervenciones de la reunión y facilitar la labor del equipo de desarrolo en aquellas cuestiones que no estén funcionando correctamente.

Es recomendable llevar esta reunión preparada de antemano para no excederse de los 15 minutos estipulados.

La revisión del sprint

La revisión del sprint es el siguiente hito tras el sprint. En esta reunión el Product Owner repasa las tareas definidas en el Backlog del Sprint y pide al equipo de desarrollo que se las muestre. El encargado de cada tarea da un paso al frente y demuestra que la tarea efectivamente se ha hecho y cómo. De esta manera todo el equipo llega a tener un conociemiento profundo de la tarea.

El cliente o Stakeholders pueden estar presentes en la demostración de la nueva version del producto.

La retrospectiva del sprint

Durante la retrospectiva del sprint se hace una evaluacion de todo el ciclo. El Scrum Master debe llevar la moderación de la reunión y los miembros del equipo deben comentar cuales han sido sus impresiones del ciclo, desde la planificacion hasta la revision del sprint.

El objetivo de esta reunión es la de generar un espacio seguro para la crítica constructiva entre los miembros del equipo Scrum. Es una reunión para sacar a la luz los problemas y darles una solución grupal. Todos los miembros deben asistir con la mente abierta y asumiendo sus errores, pero sin autocomplacencia, sino buscando mejorar el siguiente ciclo de Scrum mediante su superacion.

La retrospectiva es el punto de inflexion y es lo que marca que el equipo avance realmente en todos los aspectos para lo que se ha implantado Scrum en la empresa: independencia, autogestión y responsabilidad.

El Scrum Máster además deberá tomar nota de todos esos problemas que van surgiendo en cada retrospectiva para proponer soluciones a aquellas cuestiones que se repitan ciclo tras ciclo y abordarlos en las retrospectivas.

Y vuelta a empezar…

Scrum es un framework de mejora continua, no solo del producto sino del equipo. Una vez liberada la nueva versión, se debe volver a la fase de refinamiento del Backlog. Para este momento el Product Owner ya habrá colocado en el tablero del Backlog Product nuevas funcionalidades a ser implementadas y el equipo de desarrollo tendrá que volvera revisarlas, estimar el esfuerzo necesario y planificar el siguiente sprint.

 

El Scrum Master

El Scrum Master

por | Jul 17, 2018

¿Que es un Scrum Master?

El Scrum Master conecta a todas las partes implicadas en el proyecto. Participa con todos los demás actores, coordinando las actividades y los flujos de comunicación. Muchas veces esta figura es malinterpretada porque se le asocia un rol de “jefe” o responsable del proyecto, pero no es así. El Scrum Master es el facilitador para que todo el equipo pueda trabajar cómodamente y superando las eventualidades que puedan surgir durante el desarrollo. En definitiva, no es el responsable del éxito o fracaso del producto, sino el encargado de mantener al equipo motivado y activo, además del responsable de que se siga la metodología Scrum en todo momento

Funciones y características del Scrum Master

Si bien hemos comentado qué es el Scrum Master y algunas de sus funciones, no sabemos qué características debe tener un profesional con este perfil, ni de qué forma debe interactuar con los demás actores. El Scrum Master pasa la mayor parte de su tiempo solucionando posibles inconvenientes del equipo de desarrollo, y eso implica que debe ser una persona abierta, empática y asertiva. Debe saber manejar eficientemente conflictos o mejor aún, atajarlos antes de que se manifiesten, yendo en la medida de lo posible un paso por delante de todos los demás actores. Ten en cuenta que en un sprint el tiempo es oro y es importante saber resolver eventualidades de una forma eficaz y eficiente. Si por ejemplo en un sprint hay una tarea dependiente de otra, el Scrum Master debe ser capaz de establecer prioridades manteniendo a todo el equipo activo, otorgando una mayor prioridad a la tarea de la que dependen.

Es crucial que el Scrum Master conozca a su equipo a fondo, tanto profesional como personalmente. Profesionalmente porque durante el desarrollo de un producto es evidente que existirán personas que necesitarán mayor seguimiento y apoyo que otras y personalmente porque es evidente que la productividad está estrechamente ligada a la comodidad de un empleado en su puesto de trabajo.

El Scrum Master, al no poseer un carácter jerárquico puede ser virtualmente cualquier persona con las características anteriormente descritas aunque evidentemente tendrá que tener unas nociones básicas del marco profesional en el que se desarrolla el proyecto (de poca ayuda nos servirá un Scrum Master en el desarrollo de una aplicación Android que no tenga conocimientos de programación o un full-stack developer en un equipo financiero). Por supuesto el Scrum Master tiene que tener interiorizado el framework de Scrum para poder implementarlo.

A pesar de que no existir una jerarquía tradicional, el Scrum Master debe ser un líder dentro del equipo. No debe imponer ni ordenar, pero debe destacar como la punta de lanza y el referente al que acudir con confianza.

Existen cuatro tipos de Scrum Master:

  • El Scum Master rotativo, asignado aleatoriamente después de la finalización de cada ciclo a una persona perteneciente al equipo. La ventaja es que favorece la implantación de Scrum y posee un amplio conocimiento personal y profesional de los desarrolladores. La desventaja es que no todas las personas tienen las características que hemos descrito anteriormente, sobre todo a nivel interpersonal.
  • El Scrum Master de tiempo parcial, el cual compagina su trabajo como desarrollador del equipo con su faceta de Scrum Master. Tiene las mismas ventajas que el Scrum Master rotativo y elimina la posibilidad de que la aleatoriedad señale como responsable a una persona no enteramente capacitada para este rol.
  • El Scrum Master a tiempo completo, el cual se dedica exclusivamente a este rol en un equipo, lo que permite una mayor especialización y fluidez en el desempeño en su tarea y es típico de pequeñas y medianas empresas.
  • El Scrum Master a tiempo completo y compartido se diferencia del anterior en que maneja varios proyectos simultáneamente siendo más frecuente por tanto en empresas grandes.

Interacción del Scrum Master con el equipo de desarrollo

En cada ciclo existen diferentes fases en las cual el Scrum Master se relaciona con diferentes actores. Posiblemente sea en el sprint cuando su tarea se vuelve más crucial, pues es el momento en el que debe sacar a la luz todas las cualidades resolutivas que se esperan de él. Como ya hemos dicho, el Scrum Master no es un jefe, no tiene capacidades ejecutivas sobre el equipo ni autoridad para tomar decisiones empresariales, lo tiene sentido ya que minaría su capacidad para generar espacios de comunicación abiertos y comportarse como un líder. Es un igual con el equipo de desarrollo y su única autoridad efectiva radica en la planificación de los rituales Scrum. En relación con el equipo, el Scum Master debe tener en cuenta que muchas veces más no es mejor. Hablamos de que puede existir la tentación por parte del equipo de desarrollo y otros actores de planificar un sprint con un número irreal de tareas. Un buen Scrum Master vela tanto por la seguridad del proyecto como por la integridad del equipo de desarrollo. De poco nos sirve un sprint ultra exigente si va a provocar que no se presten atención a los detalles, se incremente la deuda técnica (retrasando otros sprints) y genere burnout y frustración en el equipo. Hay que tener en cuanta que después de cada ciclo, viene otro y debemos afrontarlo con los desarrolladores lo más motivados posible. Unas estimaciones poco realistas en sprints sucesivos pueden ser letales para el equipo de desarrollo.

Interacción del Scrum Master con el Product Owner

El rol del dueño del producto en Scrum es, a diferencia de otros modelos de producción no ágiles, central para llegar al objetivo común, pues es parte activa durante la construcción/evolución del producto. El Product Owner es el encargado de transmitir las nuevas funcionalidades que aumentarán el valor del mismo mientras que el Scrum Master (junto con el equipo) son los encargados de seleccionar aquellas más relevantes para el siguiente ciclo de producción. El Scrum Master debe negociar con el dueño del producto los plazos y las características a implantar en el nuevo ciclo de producción, evitando la anteriormente mencionada sobrecarga en el siguiente sprint, haciéndole ver y orientándole en función de las capacidades del equipo, cuáles pueden ser las prioridades del mismo.

El Scrum Master en el Scrum diario

El Scrum Master es el encargado de que se cumpla el ritual de Scrum diario. Su papel es el de moderar las intervenciones y hacer que se cumplan los canónicos 15 minutos que debe durar la reunión. Y ojo, porque moderar no significa se el eje en torno al cual gira la reunión. De nuevo la palabra clave es la facilitación. El Scrum diario no se hace para informar al Scrum Master sobre los avances y problemáticas que encuentra cada desarrollador cada día (eso puede hacerse en cualquier momento de la jornada laboral), sino para informar al resto del equipo de ellos. De hecho, la reunión en equipos que hayan interiorizado Scrum puede perfectamente realizarse eventualmente sin la presencia del Scrum Master, aunque su asistencia es muy útil, pues es el mejor momento para analizar las relaciones entre los miembros y enterarse del estado real del proyecto.

El Scrum Master en la planificación del Sprint

El Scrum Master es el encargado de planificar con el equipo de desarrollo y el dueño del producto el siguiente Sprint. Como ya hemos dicho, el Scrum Master tiene que ser capaz de analizar los recursos y por tanto la carga óptima de trabajo que puede mantener el equipo de desarrollo. Al mismo tiempo debe negociar con el dueño del producto las nuevas funcionalidades del software que se van a añadir en función de la carga de trabajo capaz de mantener el equipo de desarrollo. Es posible y normal que el dueño del producto quiera tener el mayor numero de funcionalidades implementadas en el menor tiempo posible, sin embargo, el Scrum Master debe poder comunicarle de forma efectiva las capacidades del equipo del desarrollo, manteniendo un ritmo de trabajo adecuado, ni endiablado ni cómodo, sino desafiante pero asequible.

El Scrum Master durante la revisión del sprint

A diferencia de otros rituales de Scrum, en la retrospectiva, el Scrum Master se hace a un lado para dar el control de la reunión al dueño del producto que se encarga de explicar cómo afecta cada tarea completada del Backlog del sprint en la nueva versión del producto. El Scrum Master se debería limitar a mantener los tiempos y facilitar un marco a la reunión, facilitando los materiales necesarios para su desarrollo a ser posible antes de su celebración. Por ejemplo, un burndown chart o un pequeño resumen del ultimo sprint pueden ayudar a guiar la reunión, además de tener una perspectiva general y actualizada del proyecto.

El Scrum Master durante la retrospectiva

Durante la retrospectiva el Scrum Master reúne al equipo de desarrollo e inicia un proceso de autoevaluación de todo el ciclo. La función principal del Scrum Master en el equipo de desarrollo es la de generar un espacio seguro para la crítica constructiva y el reforzamiento del espíritu de grupo. Debe procurar que se expongan aquellas cosas que no funcionaron bien, y a ser posible, que sean verbalizadas por los propios desarrolladores. Al mismo tiempo, debe guiar al grupo en la búsqueda de las soluciones para aquellos problemas que se puedan repetir en los siguientes ciclos.

Estas reuniones deben ser puntos de inflexión para aquellos problemas que se vengan repitiendo en varios sprints. No se trata de buscar culpables, sino soluciones, pero no hay que tener miedo a exponer los fallos de otros compañeros siempre que se haga de una forma respetuosa y constructiva. Sobre todo, es importante que la exposición de fallos y cosas a mejorar no sea la meta, sino la excusa para encontrar una solución.

Es muy recomendable exponer y hacer énfasis en aquellas cosas que se van mejorando en cada retrospectiva, sobre todo al final de la reunión, ya que sirve como bálsamo para aquellas situaciones que hayan podido minar la motivación del equipo, pero si los errores no deben ser tratados como catástrofes o errores individuales, la revisión de los puntos positivos deben evitar la autocomplacencia.

La retrospectiva es un proceso para buscar soluciones grupales, y por tanto la responsabilidad de solucionarlos debe ser grupal, por ello, es recomendable realizar un diario de retrospectivas en el que se recojan los errores, aciertos y soluciones propuestas. De esta forma es más fácil ver los patrones que se repiten en los ciclos. Además, la implementación de las soluciones debe procurar ser colectiva, salvo en los casos en los que la difusión de la responsabilidad se haya constatado en sucesivos ciclos o la propia naturaleza de la tarea lo impida.

El Product Owner

El Product Owner

por | Jul 17, 2018

Qué es un Product Owner

El Product Owner es el encargado de añadir valor al producto. Aunque su nombre se traduzca como “dueño del producto” en realidad no tiene por qué ser así. El Product Owner es la persona más implicada con el proyecto, o mejor dicho, con la correcta realización del proyecto. Lo óptimo es contar con el propio cliente pero muchas veces no puede ser así. A veces no tiene tiempo y otras veces no lo ve necesario. En el peor de los casos no se implica lo suficiente, con lo que el resultado es frustrante para todos: si el Product Owner no colabora (en realidad cualquier actor de Scrum), todo se paraliza.

Decíamos que el Product Owner no tiene que ser el que paga por el producto. En ocasiones es incluso una persona del equipo de desarrollo, y aunque no es lo deseable, para proyectos simples o muy manidos es una solución al peor de los males descritos. Lo verdaderamente importante del Product Owner es que tenga una visión clara del proyecto, no solo interna (cómo funciona, cómo son los ritmos, etc), sino externa (cuáles son las fortalezas y carencias del sector al que va dirigido el proyecto, las oportunidades que ofrece, etc). En definitiva, el Product Owner se encarga de añadir valor al proyecto.

Funciones y características de un dueño de producto

Idealmente el dueño del producto debería ser una persona abierta al cambio, comunicativa, activa en el desarrollo, comprometida con todos los actores de Scrum y estar disponible frecuentemente para aclarar las dudas del equipo de desarrollo. La función principal del Product Owner es la de añadir al Backlog del proyecto aquellos requerimientos que supongan un incremento del valor del producto. Únicamente el Product Owner puede añadir y eliminar tareas al Backlog, asignándoles distintas prioridades y especificando cuándo se considera completa.

El dueño del producto debe además poseer unas buenas dotes comunicativas. Si quieres que el equipo de desarrollo junto con el Scrum Master hagan lo que quieres, será mejor que sepas comunicarlo adecuadamente. Pero no solo se comunicará con el equipo de desarrollo, el Product Owner va a tener muchos canales abiertos, y en cada uno va a existir una persona interesada en que se satisfagan sus necesidades en la siguiente versión. Por eso, es importante comprender que el Product Owner no es alguien que paga por el desarrollo, sino la persona que tiene la visión global y de futuro de todo el producto. Obtiene información de muchas fuentes, pero en última instancia es él o ella quien decide qué se debe implementar y qué no, en definitiva, qué aporta valor al producto.

Interacción del dueño de producto con el equipo

Hablábamos anteriormente de la necesidad de contar con un Product Owner con buenas dotes comunicativas. Esto se hace indispensable cuando interactúa con el equipo. El Product Owner es el encargado de decir qué quiere al equipo y dependerá de esa buena comunicación la realización más o menos fiel del proyecto que imagina. La comunicación se efectúa a través del Backlog. A mayor concreción de lo que se pretende conseguir en el Backlog, menos debería ser el uso de otros tipos de canales, que pueden ralentizar el flujo de desarrollo. Solamente el Product Owner es capaz de añadir, y eliminar requerimientos del Backlog, pero no puede obligar al equipo a efectuar un numero determinado de tareas en cada sprint. Serán otros factores los que determinen esto último.

El Product Owner debe velar porque todo el equipo comprender qué es lo que quiere y en ningún momento actuar como un “jefe” imponiendo sus ritmos o la forma en la que se implementan sus ideas. Debe ser el equipo el que encuentre las soluciones a los distintos problemas o requerimientos del cliente, pues el Product Owner debe entender que ellos son los profesionales y quienes tienen más experiencia en el campo. El Product Owner es el encargado de guiar todo el proceso hacia la idea que tiene en mente.

Interacción del dueño de producto con el Scrum Master

El punto de encuentro entre estos dos actores es el Backlog, pero ambos lo usan de forma distinta. Mientras que para el Product Owner es el tablero sobre el que pone las ideas para añadir valor al producto, el Scrum Master es el encargado de velar por la integridad del equipo. Esto no quiere decir que deba existir un conflicto. Este punto de encuentro puede ser muy enriquecedor para ambas partes. Por un lado, el Product Owner puede reinterpretar ciertas tareas para aprovechar al máximo las capacidades del equipo cuyo máximo conocimiento está en manos del Scrum Master y por otro, el Scrum Master puede tener una idea mucho más cercana de lo que se pretende para comunicársela al equipo. La sinergia entre estos dos roles deriva muchas veces en una motivación mayor en el equipo, pues se concretan mucho más los objetivos y se hacen más realistas.

El Scrum Master actúa además como un intermediario entre el equipo y el Product Owner. Aunque el Product Owner se comunica indirectamente con el equipo a través del Backlog, éste puede transmitirle sus preocupaciones o ideas al equipo a través del Scrum Master, que a su vez podrá hacer lo propio con el Product Owner.

El dueño de producto en el Scrum diario

Como todos los miembros del equipo el Product Owner está invitado a participar en el Scrum diario para conocer cómo se está desarrollando el proyecto. Es recomendable su asistencia porque pueden existir malinterpretaciones de las tareas existentes en el Backlog y es útil detectar estas a tiempo, pues de otra forma se habrá perdido un tiempo valioso.

Durante el Scrum diario, el Product Owner deberá dejar el protagonismo a los demás miembros del equipo limitándose a aclarar las dudas que existan. Bajo ningún concepto debe guiar el flujo de trabajo, añadir tareas que no estaban en el Backlog o pisar el terreno de otros roles. Por mucho que tenga conocimiento de la tarea que se esté realizando, no debe imponer su criterio sobre el equipo de desarrollo, ya que lo que busca la metodología Scrum es el aprendizaje mediante el fallo al final de cada ciclo y estas actitudes aunque pueden prevenir el error, hacen al equipo dependiente e impide que madure.

El dueño de producto durante la planificación del Sprint

La planificación del Sprint es un ritual de vital importancia para el Product Owner. Al ser la única persona con conocimiento profundo del producto y el único que es capaz de modificar el Backlog, se hace indispensable su presencia en la planificación del sprint. Para ello, debe priorizar las tareas que hay en el Backlog, así como asignar las dependencias entre ellas con el objetivo de no introducir el sprint tareas que no se pueden llevar a cabo sin la inclusión de otras.

Es necesario que se cercione de que las tareas son claras, entendibles y tienen un punto de finalización o un objetivo concreto y mesurable. Durante este proceso el Product Owner debe ser capaz de transmitir la importancia de las tareas que pretende llevar al sprint para hacer partícipe al equipo de la necesidad de su correcta realización y el impacto que tendrán en el producto que se está desarrollando. Una vez explicadas las tareas, hay que fijar los objetivos del sprint. Este objetivo pueden ser varios, una mejora de la experiencia del usuario, una funcionalidad y en resumen, cualquier añadido que el Product Owner considere que agrega valor al producto.

Una vez el Product Owner haya explicado cual pretende ser su meta para el sprint, la reunión girará en torno a la negociación para la creación del Backlog del sprint. En este momento, el Product Owner debe respetar las impresiones del resto del equipo, ya que los recursos, conocimientos y tiempos para el sprint no son infinitos y una sobrecarga del Backlog del sprint puede evitar que se llegue a buen término el ciclo de Scum. Por tanto, la ultima palabra sobre lo que se añade o no a la pila de tareas del sprint la tiene el equipo.

Debe mantener en todo momento un ambiente estimulante e intentar que el equipo se esfuerce al máximo pero sin llevarlo más allá del límite. Para ello, el Scrum Master intentará llegar a un consenso entre ambos actores, pues es quien tiene el conocimiento y la impresión global más experta de las virtudes y carencias del equipo.

El dueño de producto durante la revisión del Sprint

Durante la revisión del sprint todos los actores se reúnen para ver y probar todos los avances que se han realizado durante el sprint. El Product Owner tiene que guiar la reunión, revisando una por una todas las tareas introducidas en el sprint y pidiendo al equipo que le demuestre que se han completado. Aquí es donde cobra especial relevancia la clarificación del objetivo de cada tarea y que sea cuantificable. En el caso de que una tarea haya cumplido con todos los requisitos de finalización se considerará terminada y en el caso de que no haya podido ser así, tendrá que actualizarse si así lo considera el Product Owner para futuros sprints.

Una vez exploradas las nuevas funcionalidades del producto el Product Owner explicará como afectan esos cambios al sprint y cual es la visión a futuro para hacer a todos los integrantes partícipes.

El dueño de producto durante la retrospectiva

Aunque a primera vista no parece que tenga mucho sentido que el dueño del producto aparezca en esta reunión, su presencia no es menospreciable. A pesar de que su intervención en un sprint debe ser mínima, esta reunión puede servirle para enriquecer su conocimiento del equipo, ver sus dificultades e incluso hacer autocrítica. Puede que descubra que algunas tareas que no fueron implementadas correctamente en el sprint y fueron marcadas como incompletas en su revisión, no hayan salido adelante por una falta de clarificación de las mismas en el Backlog, o por diversas dificultades del equipo. Puede que se de cuenta de que algunas funcionalidades que tiene pensadas sean excesivamente complejas para verlas en una versión a corto plazo y eso puede ayudar a planificar mejor las nuevas funcionalidades en función de su prioridad y hacerse una idea más precisa de los tiempos del proyecto.

 

Los roles de Scrum

Los roles de Scrum

por | Jul 14, 2018

Scrum es un framework en el cual son necesarios la implicación de varias personas, que se agrupan en tres roles bien diferenciados.

Por una parte tenemos al Product Owner, que buscará introducir nuevas funcionalidades en el producto para añadirle valor. Por otra parte tenemos al equipo de desarrollo que implementará las ideas del Product Owner, y entre ambos estará el Scrum Master que engrasará todo el proceso para mantener motivado al equipo y satisfecho al Product Owner.

Estos tres roles conforman lo que se denomina el Equipo Scrum, el núcleo del desarrollo del proyecto.

El equipo Scrum se relaciona con el exterior mediante el Product Owner. La persona que desempeñe este rol se comunicará con los clientes o stakeholders, para intentar plasmar lo más concretamente posible sus ideas de una forma que todo el Equipo Scrum las pueda comprender. El Equipo Scrum tambien desarrolla unas relaciones internas que en el mejor de los casos sirven para crear un ambiente de confianza y camaradería muy utiles para el desarrollo. De estas relaciones se debe ocupar el Scrum Master, quien debe facilitar el trabajo principalmente al equipo de desarrollo, pero cuyas acciones y formas de liderar podrán tener un efecto positivo tambien el el Product Owner.

Scrum es una forma de trabajar que presta mucha atencion a la aplicacion de ciertas rutinas y el correcto desempeño de los roles. Saber como implementar esta forma de trabajar en la empresa puede mejorar mucho la productividad en proyectos complejos y cambiantes.

 

¿Qué es y por qué usar Scrum?

¿Qué es y por qué usar Scrum?

por | Jul 14, 2018

Posiblemente si estas leyendo este texto, es porque has escuchado recientemente este conglomerado de consonantes asociado a un entorno de trabajo, y no sabes de qué diablos es. O posiblemente ya habías escuchado o leído algo de metodologías ágiles y quieres profundizar de qué tratan y que ventajas poseen.

La era de la informacion ha traído consigo una nueva forma de comunicarse, relacionarse y tambien de producir. Todo se mueve y cambia con una rapidez extraordinaria y si en algun momento queremos implantar nuestro producto en un mercado que evoluciona a una velocidad tan vertiginosa, no podemos asumir la forma de produccion de la segunda revolución industrial. Hoy en día no es dificil oír hablar de la venta de servicios y no de productos. Se habla de la venta de algo cambiante, dinámico, en continuo cambio y expansión. Hoy en dia estancarse es morir y ya no podemos pensar (al menos en el campo de la tecnologia y software) en sacar productos a diez años vista porque los requerimientos del mercado habrán cambiado drásticamente para ese entonces.

Scrum es una metodología ágil, una categorización bajo la cual se encuentran otras muchas otras con algunas diferencias, pero con esencialmente las siguientes características:

  • Orientada al crecimiento de un producto o servicio de forma continua, proveyendo siempre una version estable pero no completa del mismo en cada ciclo de desarrollo.
  • Integra al cliente en el desarrollo del producto y lo satisface rapidamente con una version funcional en un periodo relativamente corto de tiempo.
  • Mejora la creatividad, comunicacion y satisfaccion del equipo de desarrollo al disponer de mayor libertad, disposicion de su tiempo y tener siempre un objetivo claro a corto plazo.

Aunque las metodologías ágiles se asocian por defecto con empresas de desarrollo de software, no son las únicas que pueden implementarlo. Al fin y al cabo, las herramientas roles y filosofía de trabajo es extrapolable a otros muchos ámbitos, como el emprendimiento de start-ups.

Desarrollo en cascada vs. Scrum

Anteriormente decíamos que no podiamos asumir la forma de producción de la segunda revolucion industrial para según que productos enmarcados dentro de un mercado cambiante y dinámico. Es obvio que existen otras muchas formas de producción, y en este apartado vamos a difereniciar entre dos de las metodologías más populares para realizar proyectos.

La metodología en cascada se caracteriza por un desarrollo en etapas para llegar al resultado final. Primero se toman en cuanta los requerimientos, luego se diseña, se desarrolla el producto, se testea y por ultimo se lanza al mercado. Es un proceso ordenado y con etapas bien diferenciadas, con un inicio y un final y con una duracion variable. No es un proceso cíclico ni tiene por qué integrar durante todo el ciclo de desarrollo al cliente. Además tiene una contraprestación, y es que si una parte fundamental falla, todo lo que deriva de ella no servirá de nada. SI no hemos hecho una investigacion exhaustiva y un diseño correcto, podemos llegar a la fase final del proyecto con un producto sin las caracteristicas necesarias y un montón de horas de trabajo perdidas. Además, habrán personas que no estarán en todos los momentos de la producción trabajando. Si una empresa no tiene ningun proyecto iniciado, es posible que los diseñadores o las personas que se entrevistan con el cliente para los requerimientos estén paradas y eso suponga una fuga de capitales importantes.

Usar Scrum adecuadamente

Aunque Scrum es una de las metodologías más populares en empresas de todo tipo, tal y como vemos en el cuadro de arriba, hay proyectos que no siempre se pueden realizar bajo su paraguas. Incluso es posible que aunque hayas decidido implantar esta metodología para proyectos que efectivamente, resultan más eficientes de desarrollar de esta manera, pero no hayas encontrado los resultados que buscabas. Scrum no es solo una metodología. Scrum es un enfoque integral de las relaciones entre empresa, trabajadores y clientes. Para usar adecuadamente Scrum los trabajadores tienen que saber expresarse en publico, ser responsables, estar motivados y es deseable que existan buenas relaciones entre ellos, los clientes tambien tienen que estar comprometidos y disponibles y el Scrum Master, una figura que veremos más adelante, tiene que saber rodearse de buenos profesionales dentro y fuera de la empresa para conseguir que todos los actores involucrados realizen sus tareas cómodamente.