DEMO gestión de proyectos ágiles con scrum

GESTIÓN DE PROYECTOS ÁGILES CON SCRUM

MANUAL

MANUAL GESTIÓN DE PROYECTOS ÁGILES

INDICE

Gestión de Proyectos Ágiles con Scrum........................................................................................ 3 1. Introducción a la gestión de proyectos Scrum...................................................................... 3 2. Roles y artefactos en Scrum................................................................................................ 19 3. Aplicación práctica de un ciclo de scrum ............................................................................ 35 4. Buenas prácticas de la gestión con Scrum .......................................................................... 53

2

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Gestión de Proyectos Ágiles con Scrum

1. Introducción a la gestión de proyectos Scrum

INTRODUCCIÓN A LAS METODOLOGÍAS ÁGILES

Antes de entrar de lleno en explicar la metodología Scrum es fundamental que tengamos unas nociones básicas de en qué principios está basado y por qué esos principios van a ser los que terminen definiendo la metodología. En otras palabras, es importante saber por qué las cosas funcionan para que no las saboteemos (por accidente). Scrum es una metodología ágil, pero, ¿qué son las metodologías ágiles? Eso es lo que aprenderemos en esta breve introducción.

3

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

 Manifiesto ágil Las metodologías ágiles surgieron inicialmente orientadas al mundo del desarrollo de Software. En una reunión que tuvo lugar en Snowbird, Utah, en febrero del año 2001, diecisiete críticos expertos en metodologías de desarrollo de software acuñaron el término “Metodología Ágil” para definir aquellas metodologías que surgían como alternativa a las metodologías tradicionales. Para especificar las características que debía reunir una metodología para poder pertenecer a la categoría de “Ágil” se definieron una serie de postulados que conformaron un manifiesto, el manifiesto Ágil: • Los individuos y su interacción deben estar por encima de los procesos y las herramientas. • El software que funciona debe estar por encima de la documentación exhaustiva. • La colaboración con el cliente debe estar por encima de la negociación contractual. • La respuesta al cambio debe estar por encima del seguimiento estricto de un plan establecido. Dentro de cada postulado se distinguen dos “partes”. Mientras que las de la izquierda son los “nuevos” valores a destacar en las metodologías ágiles, las de la derecha son valores tradicionales de suma importancia en metodologías tradicionales y, de hecho, al firmar el manifiesto se dejó constancia que era por el valor que se daba a la parte derecha de cada postulado por lo que se valoraba aún más la parte de la izquierda.  Principios básicos y objetivos de una metodología ágil Los cuatro postulados del manifiesto ágil son un resumen de los objetivos que se deben buscar a la hora de utilizar una metodología ágil. Llevados a la práctica se podría decir que los principios (y objetivos relacionados a ellos) de una metodología ágil son: • Nuestra máxima prioridad es satisfacer al cliente a través de entregas continuas y tempranas de un producto de calidad. • La gente dedicada a la gestión y la dedicada a la producción deben trabajar conjuntamente de manera continua, de manera que el objetivo sea común y homogéneo para todos. • Los cambios serán bienvenidos desde el principio e incluso en etapas avanzadas del proyecto, ofreciendo al cliente tener siempre la posibilidad de situarse en una posición de ventaja competitiva. • Los proyectos deben ser construidos basándose en trabajadores motivados para únicamente tener que facilitarles el apoyo y entorno adecuado de trabajo y confiar en que ellos harán su trabajo satisfactoriamente. • El método más eficiente y efectivo de comunicación entre miembros del equipo es la conversación cara a cara. European Open Business School

4

MANUAL GESTIÓN DE PROYECTOS ÁGILES

• La medida principal de progreso deberá estar basada en el producto funcional. • Todos los miembros del proceso deben ser capaces de mantener un ritmo de trabajo constante de manera indefinida. • Las mejores arquitecturas, requisitos y diseños emergen de equipos auto organizados.  Conclusiones Todos los conceptos vistos hasta el momento (priorizar al cliente, comunicación con el mismo, trabajo en equipo, ritmo de trabajo constante, trabajo terminado como unidad de medida, etc) no dejan de ser, por un lado, parecidos a los aplicados en casi cualquier metodología de trabajo tradicional y, por otro lado, lógicos si pensamos en cómo llevar un proyecto a buen puerto. Por tanto, no se debe pensar en las metodologías ágiles como un invento de la época actual, transgresor y atrevido, sino en un modo de trabajo lógico que busca la satisfacción del cliente a través de equipos de gente motivada con su trabajo.  ¿Qué es Scrum? Aunque inicialmente Scrum fue creado únicamente como un marco de trabajo para gestión de proyectos, actualmente es considerada una metodología en sí misma, ya que cumple los principios de las metodologías ágiles y facilita los mecanismos de control mínimos necesarios para la gestión de un proyecto. Tal y como se comentó en el apartado anterior, las metodologías ágiles no fueron un “invento novedoso” en el momento de ser acuñado el término, y prueba importante de ello es que Scrum, posiblemente la metodología más representativa dentro de las denominadas ágiles, fue descrita por Hirotaka Takeuchi e Ikujiro Nonaka en 1986 (15 años antes de la aparición del manifiesto ágil) y formalizada en 1995. Scrum nace de un estudio realizado sobre nuevos procesos de desarrollo utilizados en Japón y Estados Unidos en empresas importantes como Canon, Honda y HP. Dichas empresas realizaban proyectos que necesitaban ser actuales y novedosos, no pudiendo extender su tiempo de desarrollo excesivamente. Para ello se requería de una descripción de requisitos abierta a cambios y se utilizaron equipos multidisciplinares que trabajaban de manera conjunta muy estrechamente. INTRODUCCIÓN A SCRUM

5

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

El estudio comparaba dichos grupos de trabajo con las melés de los jugadores de rugby (en inglés el termino utilizado en este deporte es Scrum) y de ahí el nombre de la metodología. Como se comentaba anteriormente Scrum no es más que una serie de mecanismos mínimos que facilitan la gestión de un proyecto. Estos mecanismos se dividen en una serie de principios y normas que deben ser tenidos en cuenta en la toma de decisiones de la gestión de un proyecto, una serie de roles necesarios dentro de un proyecto y las responsabilidades que deben tener cada uno de ellos, una serie de artefactos que facilitarán la gestión y seguimiento del trabajo y un ciclo de vida que el proyecto debe seguir.  Principios básicos de Scrum Como se ha comentado anteriormente, Scrum se basa en una serie de principios básicos y normas a tener en cuenta a lo largo del proyecto. Los principios fundamentales que describen Scrum y lo diferencian de otras metodologías de trabajo son: • Desarrollarse a partir de Sprints (o ciclos) • Dichos ciclos deben ser de una duración determinada a lo largo del proyecto. Podemos observar cómo la mayoría de estos principios hacen relación al ciclo de vida del proyecto, una de las características fundamentales de Scrum. Sin embargo, aplicar una metodología sería complicado disponiendo únicamente de estas claves o principios tan abstractos, por lo cual, a continuación, se detallan una serie de normas o prácticas que deben seguirse a la hora de aplicar Scrum y que definen el carácter ágil de esta metodología, así como sus particularidades frente a otras metodologías: 1. El ciclo de vida debe estar compuesto por iteraciones: como ya hemos comentado anteriormente, una de los rasgos más característicos de cualquier metodología ágil es estar abierta a los cambios. En el caso de Scrum se considera que dividir el ciclo de vida del producto en iteraciones brinda la posibilidad de utilizar el cambio de iteración como el momento apropiado para introducir posibles cambios. Para poner un ejemplo práctico de los beneficios que puede aportar este principio, imaginemos a un golfista a punto de empezar un hoyo de un circuito de golf donde dispone de 4 golpes. • Constar de grupos de trabajo auto-organizativos. • Realizar reuniones diarias con los miembros en pie. • Realizar una demo del trabajo realizado al final de cada iteración. • Aprendizaje continúo.

6

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

La previsión inicial podría ser perfectamente dar un golpe recto que deje la bola en la calle, luego otro recto que lo meta en el Green (región donde se encuentra el hoyo), un tercero para dejarlo cerca del agujero y por último un golpe que lo meta directo al hoyo. ¡La planificación es perfecta! Pero, ¿qué pasa si en el primer golpe la bola cae en uno de los bunker de arena laterales? Solo para sacar la bola de ahí y dejarla en la calle central como debía haber estado ya necesitaremos mínimo un golpe, con lo cual ya llevaremos un golpe de “retraso”. Sin embargo, si entre golpe y golpe (iteraciones) somos capaces de “re-planificar” nuestra estrategia, quizás seamos capaces de intentar un golpe desde la arena hasta el Green (aunque conlleve cierto riesgo que no estaba planificado) para continuar “entregando” la bola al hoyo “en tiempo”.

7

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Además de desde el punto de vista del producto, también debe verse desde el punto de vista del equipo de trabajo. Las iteraciones brindan la oportunidad de ver el estado del producto y pensar en posibles cambios, pero también brinda la oportunidad de valorar la metodología de trabajo del equipo y analizar sus pros y sus contras con el fin de mejorarla. Eso nos permitiría tener un equipo mejor en cada iteración, y detener malas prácticas al poco tiempo de empezar a producirse no permitiendo que se conviertan en costumbres. 2. Hay que intentar reducir riesgos lo antes posible: De cara a planificar un proyecto, lo más difícil de estimar son aquellas acciones que conllevan un riesgo y todas las que derivan de ellas. Se ha comentado antes que un proyecto “ágil” debe estar abierto a los cambios, pero eso no implica que no se puedan prever en la medida de lo posible y afrontarlos en el momento adecuado. Aquellas tareas que no sabemos si pueden hacerse o que su realización (el proceso mediante el cual se hacen) puedan derivar en tomas de decisiones o incluso cambios en el proyecto deben hacerse tan pronto sea posible.

8

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

De esta manera en caso de tener que rehacer trabajo o incluso desecharlo, el impacto será el mínimo, ya que la cantidad de trabajo realizado y relacionado con él será el justo y necesario para detectar esa necesidad de cambiar. El siguiente gráfico muestra cómo priorizar tareas en base al riesgo y al valor de negocio para el cliente (siguiente punto):

Si volvemos al ejemplo anterior, en el caso ideal teníamos 4 golpes de los cuales los dos primeros los íbamos a utilizar para conseguir llegar al Green. Esos dos golpes no cubren la misma distancia, ya que en el primero generalmente se intentará cubrir el máximo número de metros posibles y el segundo para afinar el primero y meter la bola en el Green. Es decir, en el primer golpe hacemos lo que más riesgo conlleva (al dar un golpe con más fuerza, es más posible que la bola se desvíe hacia los laterales saliéndose de la calle e incluso cayendo a un bunker) y a continuación las que menos riesgo entrañan. De esta manera, detecto las desviaciones a mi plan nada más comenzar y tengo tiempo suficiente para corregir posibles errores antes de terminar el hoyo.

9

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

3. Priorizar aquellas tareas o funcionalidades que impliquen valor de negocio: algo muy típico en el desarrollo de proyectos es centrarse en los detalles de todo aquello que se va a entregar. Por supuesto, es necesario entregar productos terminados y de calidad, pero a la hora de planificar un proyecto ágil, puesto que uno de los postulados es “La colaboración con el cliente debe estar por encima de la negociación contractual.”, es preferible priorizar aquellas tareas que sean más importantes para el cliente a nivel de negocio, realizar tareas completas en cuanto a funcionalidad se refiere, mostrárselas al cliente y, una vez obtenido un feedback por su parte, mejorarlas todo lo que sea necesario.

De esta manera el cliente tendrá un producto funcional lo antes posible y podrá obtener provecho de él, mientras que todos los flecos o posibles mejoras que desee podrán ser llevadas a cabo posteriormente (¡ojo! Hay que tener en cuenta aquellas que conlleven riesgo por lo comentado en el punto anterior). 4. Nunca extender una iteración para alcanzar el objetivo de la misma: no se debe confundir “ágil” y flexibilidad con un “todo vale”, error muy común en empresas nuevas en el uso de metodologías ágiles. Si los objetivos marcados para una iteración no pueden ser alcanzados, no debe ampliarse la duración de la iteración para “maquillar” el resultado. En su lugar, deberá asumirse que el objetivo no era realista y analizar el por qué (problemas en el entorno de trabajo, falta de formación del equipo, problemas técnicos, simplemente una mala planificación) para lograr resolverlo. Este ejercicio de autocrítica por parte del equipo de trabajo, lejos de desmotivarlos, debe enriquecerlos. En el fondo se trata de uno de lo principios fundamentales de Scrum: Aprendizaje continuo. Una vez localizado el problema y puesto el remedio, el equipo será más sólido y experimentado, lo cual favorecerá al proyecto en adelante.

10

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

5. La duración de las iteraciones debe tratar de mantenerse a lo largo del proyecto: dos posibles motivos de que los objetivos no se cumplan en una iteración puede ser debido a que la duración de la misma no es suficiente para terminar una tarea o, por lo contrario, que la iteración es tan larga que es complicado ajustar el número de tareas a incluir en ella. En ambos casos una posible solución sería cambiar la duración de las iteraciones para ajustarlas a lo que el proyecto requiere (pero siempre al término de una iteración y antes de comenzar la siguiente, nunca durante ninguna de ellas, eso atentaría contra el punto anterior). Sin embargo, lo ideal es mantener la duración de las iteraciones a lo largo de todo el proyecto, ya que genera, por un lado, una “costumbre” que facilita la planificación de las mismas por parte del equipo y, por otro lado, también facilita la obtención de medidas de velocidad del trabajo realizado y estimaciones del trabajo pendiente a los gerentes del proyecto. 6. Durante una iteración el tiempo, el coste y la calidad son fijos: son las funcionalidades o hitos a llevar a cabo los que deben variar. Si para una iteración se estima que solo se pueden realizar un número determinado de hitos, nunca este número debe aumentar a costa, por ejemplo, de reducir la calidad de lo realizado, ni de aumentar la presión de trabajo sobre el equipo para que produzca más rápido. Estas falsas soluciones lo único que conseguirían es reducir la calidad no solo de esos hitos, sino del proyecto completo (así como rebajar las expectativas de calidad dentro del propio equipo) y crear un ambiente y ritmo de trabajo no sostenible en el equipo que únicamente falsearía la estadística de velocidad de trabajo del equipo, que a su vez podría conllevar estimaciones no realistas en iteraciones futuras (es como una fila de fichas de dominó: una vez cae una pieza, el resto se ven empujadas por la anterior). Hay que recordar uno de los principios ágiles que se han comentado: “Todos los miembros del proceso deben ser capaces de mantener un ritmo de trabajo constante de manera indefinida.” 7. Mantener siempre las entregas o demos parciales al cliente: de nuevo entra en juego el postulado “La colaboración con el cliente debe estar por encima de la negociación contractual.”. Presentar a nuestro cliente el trabajo realizado regularmente facilita que él mismo pueda darte un feedback y replantearse la priorización de todos aquellos hitos que queden pendientes (hay que estar abierto al cambio). Además del valor que supone tener la opinión del cliente, también es un incentivo para el equipo de trabajo. Muchas veces los trabajadores no se sienten parte de una empresa o un proyecto porque no tienen ningún tipo de visibilidad del resultado de su trabajo.

11

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Sin embargo, en Scrum, gracias a las demos, van a poder comprobar de primera mano la reacción del cliente a su trabajo y lo normal es que tras una demo negativa no se quiera volver a defraudar en la siguiente y tras una positiva se quiera continuar recibiendo un reconocimiento al trabajo iteración a iteración. 8. Reforzar la importancia de la gente implicada en el proyecto y especialmente los equipos de trabajo: como se ha comentado anteriormente, Scrum se basa en equipos auto- organizados, a los que se expone el trabajo a realizar y se confía en su capacidad para llevar a cabo dicho trabajo. La figura del manager o directivo vigilante no tiene cabida en Scrum y, por tanto, es importante que la gente implicada en el proyecto sea consciente de la confianza depositada en ellos y les sirva como motivación para realizar bien su trabajo. Para ello es conveniente hacerles ver que, si ellos no funcionan, el proyecto podría derrumbarse, y de la misma manera, si el proyecto se derrumba, serán los primeros responsables de ellos. En Scrum las decisiones se toman en su mayoría en el lugar donde se realizan los hitos que las requieren. Es por ese motivo que los equipos suelen ser multidisciplinares para tener siempre, en la medida de lo posible, una persona más experimentada en cada una de las áreas implicadas en el proyecto que tome la decisión en cada problemática que pueda surgir. 9. Facilitar un entorno de comunicación apropiado: Uno de los principios de las metodologías ágiles era “El método más eficiente y efectivo de comunicación entre miembros del equipo es la conversación cara a cara.”. El motivo del mismo es tratar de evitar situaciones de “teléfono estropeado” que tan bien se expresa en la siguiente caricatura que hace referencia a los distintos pasos de un mensaje a lo largo de la estructura jerárquica de una metodología tradicional.

12

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Es razonable que en un proyecto el cliente tenga un interfaz único de comunicación, para que sepa a quién puede acudir en todo momento para tratar cualquier tema relacionado con el proyecto. Sin embargo, es muy típico también que dentro del propio proveedor se establezcan largas cadenas de mando que separan a dicho interfaz del equipo final del trabajo. De esta manera, cuando surge una duda en el equipo de trabajo, debe comunicárselo a un tercero, que seguramente también tendrá gente entre medias de él y el interlocutor con el cliente, de modo que cuando la pregunta llega a este último puede hacerlo de manera deformada. Eso no queda ahí, ya que la respuesta suele seguir el mismo canal de comunicación solo que en sentido contrario, desvirtuando también la respuesta. No hay que decir que a este problema se suma que durante todo el proceso se ha perdido un tiempo precioso solo en pasar la información de un eslabón a otro de la cadena de mando. Ya veremos más adelante que, para reducir este efecto tan nocivo para cualquier proyecto, Scrum delimita qué roles deben existir en el proyecto y establece una comunicación directa entre ellos, de modo que el equipo siempre debe poder comunicarse rápida y directamente con el responsable de tratar con el cliente para tratar cualquier tema que requiera de su intervención. Por otro lado, la comunicación no solo se limita a las conversaciones entre miembros del equipo, sino también al estado del proyecto, las iteraciones, los hitos en los que se está trabajando e incluso el entorno de trabajo y el feedback del cliente. Toda esta información debe ser lo más accesible posible para todo el mundo y la comunicación para tratar cualquier tema fluida y frecuente. Para ello, Scrum propone una serie de artefactos y reuniones cíclicas donde todos estos aspectos se muestran y pueden ser discutidos. Los estudiaremos a fondo más adelante en el curso. 10. Los equipos deben estar conformados en base a las necesidades del cliente: como ya se ha comentado varias veces, el equipo debe ser multidisciplinar, pero no todos los proyectos requieren de las mismas disciplinas y, por tanto, no necesariamente un equipo debe ser el mismo independientemente de la naturaleza del proyecto en que trabaje. Adaptar la formación de un equipo a un proyecto determinado conlleva dos beneficios muy importantes: reducir los recursos externos de los que se pueda tener necesidad y, sobre todo, incrementar la calidad del producto final entregado.

13

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

DESVENTAJAS DE SCRUM

Hasta hora todo lo hablado de Scrum es positivo y eso podría hacer pensar que se trata de una metodología perfecta sin ningún tipo de inconveniente o dificultad. Sin embargo, no es así y, como cualquier otra metodología, tiene sus inconvenientes y riesgos, de los cuales los más importantes son: 1. Tendencia a no trabajar con fecha de fin: en muchos casos se piensa que por ser una metodología ágil, todo vale, y uno de los mayores errores que se puede cometer es comenzar un proyecto con un presupuesto fijo pero sin una fecha de fin. La agilidad sí que pasa por poder variar los requisitos a desarrollar en función de los progresos logrados y demostrados o de los riesgos surgidos. Sin embargo, hay veces que los clientes utilizan ese concepto de ágil para pedir más y más funcionalidades que se les van ocurriendo para el proyecto. Esto no es negativo, pero puede serlo si no se les hace ver que el introducir nuevas funcionalidades casi siempre supone descartar alguna de las ya propuestas. Si tienes fijada una fecha de fin, esto puede parecer más evidente al cliente, ya que a medida que se acerca dicha fecha él va viendo que está realizado y qué puede quedarse sin realizar. Sin embargo, si no tienes una fecha, el cliente tenderá a pedirte que continúes desarrollando todo lo que se le ha ocurrido en el producto convirtiéndolo en infinito. 2. La dependencia en el compromiso del equipo: en Scrum la parte más importante de la metodología es el equipo. Sin duda, el ceder el control al propio equipo puede incrementar la productividad y satisfacción del equipo enormemente. Sin embargo, es importante detectar si algún miembro no está comprometido con la metodología, porque, si es así, es probable que las ventajas que ofrece Scrum (al respecto del equipo) desaparezcan, como la motivación, el afán de superación y el incremento de velocidad y conocimientos a lo largo de los sprints. Y lo peor es que existiendo una sola persona en el equipo que presente este problema, podría darse el caso de “la manzana podrida”, que dice que, si tienes un miembro no comprometido con la metodología, lo más normal es que su negatividad contagie al resto de miembros del equipo y al final este se desmorone. 3. Solo se recomienda aplicar en equipos pequeños y ágiles: Scrum es una metodología pensada para equipos de tamaño no superior a 8 personas. Los motivos para esto pasan por la capacidad de coordinación de grupos, que cuanto más grandes son más se complican, y por la metodología en sí, que define una serie de reuniones y mecanismos que veremos en próximas asignaturas y que se alargan en función del

14

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

número de componentes del equipo (uno de los objetivos de Scrum era reducir las reuniones lo máximo posible). 4. Se requieren miembros del equipo experimentados : este inconveniente va ligado al anterior. Los equipos de Scrum deben ser multifuncionales y de tamaño limitado, lo cual deriva en que los miembros que lo formen deben tener ya una experiencia. Aunque quizás no sea necesario en todos los miembros del equipo, sí que se requiere que al menos la mitad de ellos tengan la experiencia suficiente para ser capaces de estimar el trabajo de manera correcta y aportar soluciones a las tareas a las que se tengan que ir enfrentando. 5. Scrum solo funciona si el Scrum Master confía en el equipo: el Scrum Master, como veremos más adelante será el encargado de asegurarse que la metodología se cumple y que el equipo es capaz de auto gestionarse. Si el Scrum Master no confía en el equipo y en su capacidad de auto organización, al final se dedicará a “vigilar” al equipo y a decirles qué tienen que hacer en todo momento. Con esto se pierde una de las grandes virtudes de Scrum y se tiende a una organización más jerárquica, propia de las metodologías tradicionales. 6. La rotación en el equipo: en Scrum es muy importante que el equipo trabaje como tal. Con el paso de los Sprints, cada miembro va adoptando un rol dentro del equipo y se adquieren mecanismos en la organización del trabajo que beneficia mucho la velocidad de desarrollo del producto. El cambio de un miembro del equipo distorsiona esa dinámica más que en otras metodologías más tradicionales, ya que en ellas la persona que entra lo hace con un rol asignado, mientras que en Scrum, tendrá que adaptarse al resto del equipo y encontrar su rol dentro de él. Por tanto, la curva de aprendizaje es más elevada y la productividad podría verse mermada en los primeros Sprints de un nuevo miembro. Diferencias entre Scrum y una metodología tradicional Durante la exposición de los principios de Scrum, se ha recurrido en varias ocasiones a la comparación de esta metodología con las llamadas “tradicionales”. En dichas comparaciones se proponían soluciones a problemas de las que no son ágiles, sin embargo, eso no significa que Scrum sea la metodología definitiva para cualquier proyecto ni que las metodologías tradicionales estuviesen equivocadas y se deba evitar su uso.

15

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

La inclusión de “ágil” en el mundo de las metodologías, lo que hace es ofrecer una alternativa válida para la gestión de cierto tipo de proyectos, a los que las metodologías tradicionales no se ajustaban o cuyo rendimiento podía mejorarse. En concreto, el cambio más significativo podría ser la forma de plantear los proyectos. En una metodología tradicional, lo primero de lo que se dispone es de que los requisitos están completamente fijados. A partir de ellos, las empresas que van a desarrollar el producto realizan una estimación de los recursos necesarios para entregar en una fecha concreta o de la fecha de entrega en función de los recursos. En las metodologías ágiles eso cambia sustancialmente. En este caso, lo que tendremos fijo será el equipo de trabajo que va a realizar el proyecto, la fecha en la que se quiere fijar un límite para tener el producto y lo que puede variar a lo largo del proyecto son las funcionalidades o el nivel de detalle del producto, es decir, sus requisitos.

A continuación, se muestra una tabla que ofrece de un simple vistazo las diferencias más significativas entre una metodología tradicional y una ágil (en concreto Scrum) teniendo en cuenta los proyectos a los que pueden ser aplicados:

16

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Tal y como se puede intuir del gráfico anterior, cada columna muestra un tipo de proyecto muy específico (el primero, por ejemplo, podría corresponderse con un producto bien definido, de presupuesto muy acotado, y el segundo con un proyecto de investigación con presupuesto variable) que se ajusta a una metodología tradicional en el caso de la primera y ágil en el caso de la segunda y donde no tendría sentido utilizar la otra. Otro de los cambios significativos entre las metodologías tradicionales y las ágiles (en concreto Scrum) es el lugar que ocupa cada persona involucrada en un proyecto dentro del mismo, o lo que es igual, los roles.

17

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Cada empresa y proyecto puede presentar unas características que le impidan realizar una u otra metodología. Como hemos visto a lo largo de la asignatura, una empresa muy grande con mucha rotación y gente poco experimentada, quizás no esté preparada para hacer Scrum, mientras que una muy pequeña con gente especializada, quizás no tiene suficiente gente para todos los roles de una tradicional y, por el contrario, su estructura se acerca a lo deseado para Scrum. Por tanto, antes de utilizar Scrum u otra metodología ágil en un proyecto habrá que estudiar si sus características se ajustan al mismo o es más conveniente recurrir a una metodología tradicional.

18

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

2. Roles y artefactos en Scrum

INTRODUCCIÓN

Scrum es una metodología ágil que principalmente ha sido utilizada en el ámbito del desarrollo de software, aunque no deja de consistir en una serie de herramientas (principios, roles y artefactos) que facilita una metodología de trabajo flexible y dinámica. A lo largo de esta formación, haremos un repaso a los roles y artefactos que son utilizados en Scrum para más adelante ver como interactúan todos ellos a lo largo del ciclo de vida de un proyecto Scrum.

ROLES EN SCRUM

Uno de los principios más importantes todas las metodologías ágiles, tal y como dice su postulado es “Los individuos y su interacción deben estar por encima de los procesos y las herramientas” y en concreto, uno de los fundamentos de Scrum es “Facilitar un entorno de comunicación apropiado”.

Uno de los mecanismos para asegurar dicha comunicación, a parte del propio ciclo de vida de Scrum es restringir la cadena de mando del proyecto a una serie de roles con responsabilidades bien definidas para evitar que los procesos burocráticos habituales en las metodologías tradicionales dificulten que el equipo de trabajo tenga claro el objetivo final del proyecto así como los pasos que deben darse para alcanzar dicho objetivo. European Open Business School

19

MANUAL GESTIÓN DE PROYECTOS ÁGILES

No hay que olvidar que mientras en el caso de las metodologías tradicionales, la especificación de requisitos del producto final suele ser detallada y cerrada por motivos contractuales, en un proyecto “ágil”, la flexibilidad y el cambio son habituales e incluso predominantes. Para que tanto los cambios solicitados por el cliente sean reflejados en el proyecto lo antes posible, como que las dudas que surjan en el equipo reciban una respuesta lo antes posible, las líneas de comunicación entre ambos, cliente y equipo, deben ser lo más directas posibles. Sin embargo, en casi ningún proyecto es habitual que el equipo de trabajo pueda tener línea directa con el cliente, ni tampoco sería recomendable, ya que es lógico que el cliente tenga un interfaz único de comunicación con la empresa para que la información no se disgregue y sea persistente en el proyecto. Este rol Scrum lo denomina Product Owner, ya que más allá de su comunicación con el cliente, su responsabilidad final dentro del proyecto será el producto entregado. Ya se ha nombrado en varias ocasiones el concepto de equipo de trabajo, que si bien en otras metodologías se podría dividir a su vez en una serie de roles (probablemente con un sentido jerárquico) en Scrum serán considerados como una sola entidad. Por otro lado, ya comentamos que las metodologías ágiles, lejos de ser sencillas o indisciplinadas, están regidas por una serie de principios que deben seguirse para que un proyecto no se convierta en caótico. Dichos principios podrían interpretarse de manera que beneficiase a algunas de las partes implicadas en el proceso, en este caso al Product Owner o al equipo en caso de que surgiesen complicaciones. Para mediar en cualquier conflicto y asegurarse que la metodología se sigue convenientemente, existe un tercer rol muy importante en Scrum, el Scrum Master. Pese a que se ha utilizado la palabra “mediar” para definir una de las responsabilidades del Scrum Master, no se debe pensar en él como un intermediario de la comunicación entre el Product Owner y el equipo, sino como un facilitador de la comunicación entre ambos:

20

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

De esta manera la comunicación es siempre directa entre todos los roles de la metodología, lo cual se ciñe a uno de los principios vistos de las metodologías ágiles: “El método más eficiente y efectivo de comunicación entre miembros del equipo es la conversación cara a cara.” Como curiosidad (aunque bastante instructiva), se incluye, a continuación, la fábula de los cerdos y las gallinas siempre vinculada a Scrum:

Lo que esta fábula quiere hacer ver es que, mientras que el cerdo se juega su propia carne en el negocio, la gallina solo implica aquello que es suyo, los huevos que pone, sin llegar a estar realmente comprometida.

21

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

En el caso de Scrum, se denominan cerdos a aquellos que ponen el 100% en el proyecto, los que realmente están comprometidos, que serían aquellos que pertenecen a los roles anteriormente expuestos. Alrededor de ellos, también “pendientes” del proyecto, aunque no tengan una dedicación completa, se encontrarían las “gallinas”: recursos externos que puedan necesitarse, los directivos de la empresa proveedora, quizás un comité de negocio implicado, los posibles usuarios finales del producto e incluso el cliente para el cual se trabaja. Todos ellos forman parte del “negocio”, pero no están igualmente comprometidos con el desarrollo del producto, sino con el fin. Una vez introducidos los distintos roles, así como la comunicación existente entre ellos, es conveniente ver cada uno de los roles en más profundidad para entender cuáles son sus responsabilidades y cuáles serán las interacciones más habituales entre ellos.  El equipo Si se busca “Equipo” en Wikipedia se encontrará: “Un equipo comprende a cualquier grupo de 3 o más personas unidas con un objetivo común (una investigación o un servicio determinado). Un grupo en sí mismo no necesariamente constituye un equipo”. Es una buena definición donde la clave de la misma es “unidas con un objetivo común”. Sin ese matiz, tal y como indica, no son más que un grupo de personas. Los equipos deben estar constituidos por miembros con habilidades o conocimientos complementarios (imagina un equipo de fútbol formado únicamente por delanteros, aunque todos fuesen Messi, difícilmente serían un equipo competitivo) que generen juntos una sinergia mediante la cual cada miembro potencia lo mejor de sí mismo y minimiza sus debilidades. Si cumplen estas condiciones, los equipos son especialmente apropiados para la realización de tareas de alta complejidad y compuestas de muchas tareas independientes. En Scrum, esto es precisamente lo que busca. Un equipo tendrá que realizar tareas de alta complejidad (requisitos del producto) dividiéndolas en tareas independientes y trabajando en ellas de forma que la resolución de todas dé lugar, finalmente, a un “todo” complejo de nuevo. Ya habíamos hablado que en Scrum se recomendaban equipos de trabajo multidisciplinares, que permitirán en la medida de lo posible disponer siempre de un “experto” para cada posible tarea compleja que aparezca. Por otro lado, también se ha comentado que los equipos de Scrum deben ser auto- organizativos (es uno de los principios básicos de Scrum) o, lo que es lo mismo, deben gestionarse ellos mismos.

22

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

El motivo no es otro que generar un ambiente óptimo de trabajo, beneficioso no solo para los miembros del equipo, sino para la propia marcha del trabajo, teniendo en cuenta los siguientes puntos: • La gente es más productiva cuando se organiza a sí misma, siempre que el enfoque del trabajo sea el adecuado. • La gente se toma los compromisos adquiridos por ellos mismos más en serio que los adquiridos por otro en su nombre. • Escondidos entre los ratos ociosos del día pueden aparecer los momentos más creativos. • Bajo presión para “trabajar más duro”, la gente suele sacrificar calidad a cambio de velocidad. Lo que viene a decir esto es que la gente se ve mucho más motivada cuando es ella misma la que asume los retos que aparecen a lo largo de un proyecto, en lugar de que les sea impuesta por un mando superior. Probablemente no deje de ser una cuestión psicológica o de orgullo, pero se ha comprobado que un equipo que asume retos por sí mismo es más exigente consigo mismo y ambicioso con los retos asumidos que aquellos a los que se les impone unos objetivos. En cierta ocasión se realizó el siguiente experimento: Se crearon 3 grupos de trabajo independientes con el mismo número de componentes para mover cajas de un lado a otro. • Al primer grupo se le pagó una cantidad de dinero X por 5 minutos moviendo cajas. Movieron 159 cajas. • Al segundo grupo se le pagó una décima parte de lo que al primero. Movieron 101. • Al tercer grupo no se le pagó. Únicamente se les planteó (no se les exigió) como un reto entre los 3 grupos. Movieron 168 cajas. Tener un objetivo común (mover más cajas que los otros dos) autoimpuesto les motivó más que ningún tipo de recompensa económica. Lo que sí se le impone al equipo es una serie de responsabilidades, como a todos los roles de Scrum. En este caso las suyas serán: • Estimar esfuerzo necesario y dependencias de los distintos hitos del proyecto: al ser el equipo el que está compuesto por expertos y los que tienen que realizar el grueso del trabajo, habrán de ser capaces de analizar cada uno de los hitos para saber si pueden hacerse y cuánto esfuerzo costará. • Crear en cada una de las iteraciones un plan de ejecución: como equipo autogestionado, una de las responsabilidades del mismo es trazar un plan de ruta de los hitos asignados a cada iteración (cuando se estudie el ciclo de vida en Scrum, se verá que incluso la cantidad de trabajo de cada iteración viene determinada por el propio equipo).

23

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

• Trabajar de cara a producir entregables periódicos de valor funcional o estratégico completo: ya se comentó que uno de los principios de Scrum es trabajar en funcionalidades completas y de utilidad para el cliente, de manera que a medida que avanza el proyecto, y no únicamente a su finalización, pueda disponer de un producto del que obtener rentabilidad.  El Product Owner Como su propio nombre indica, el Product Owner es el “dueño” (manera drástica de decir “responsable”) del producto. Su objetivo es que el producto sea el esperado por el cliente y que, dentro de la flexibilidad que ofrece Scrum a los cambios, los entregables que se van ofreciendo al cliente, contengan siempre los hitos o funcionalidades que más valor le ofrezcan al cliente. Sus responsabilidades son: • Crear una visión del producto: el Product Owner va a ser el interfaz único con el cliente (al menos en lo que a requisitos del producto se refiere) y, por tanto, es su responsabilidad no solo extraer del cliente toda la información necesaria del producto, así como el feedback de lo ya realizado, sino también saber transmitir al equipo esa visión. Es el responsable de crear el objetivo por el que todos trabajan y que este sea claro y homogéneo para todos. • Crear un plan de entregas: es una de las responsabilidades que más dificultad entraña. En un proyecto ágil es difícil determinar qué se va a entregar en un periodo de tiempo, ya que el proyecto está muy abierto a cambios. Sin embargo, para evitar que este se eternice o que nunca se pase de una primera fase al introducir cambios constantemente y no llegar nunca a nada tangible, el Product Owner deberá marcar al cliente fechas de entrega parciales del producto, para que este sea consciente de que los cambios introducidos no son una suma gratuita al producto, sino que nuevas funcionalidades reemplazan a otras ya existentes en los plazos estimados. • Determinar valor de negocio en las funcionalidades: teniendo en cuenta el punto anterior, una de las responsabilidades del Product Owner es guiar al cliente a la hora de introducir cambios o mejoras, ayudándole a priorizar aquellas funcionalidades que más valor aportan al producto final, de manera que sean las primeras integradas o implementadas en el mismo. De esta manera, el producto que el cliente tiene en cada momento, le aportará el máximo rendimiento y rentabilidad posibles, pudiendo incluso considerarse un producto acabado aún en el caso de que el proyecto se tuviese que finalizar quedando funcionalidades o mejoras pendientes (por cuestiones económicas o de tiempo). • Definir los criterios de aceptación de cada hito: de cara a asegurar una calidad mínima de cada uno de los hitos del producto, y de dotar al equipo de una base sobre la que trabajar, el Product Owner deberá marcar una serie de criterios

24

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

mínimos para cada hito, que se deben cumplir para considerar dicho hito como terminado. • Obtener feedback del producto por parte del cliente y/o el usuario final: aunque ya se ha comentado anteriormente como parte del primer punto, el feedback del trabajo ya realizado tiene la importancia suficiente como para considerarlo una responsabilidad en sí misma.

En metodologías ágiles, el cambio es bienvenido, pero cuanto antes se detecte esa necesidad de cambiar, mejor. Por tanto, obtener un feedback lo antes posible aumentará considerablemente la productividad del proyecto.

 El Scrum Master Como hemos visto hasta ahora, metodología ágil y más en concreto Scrum, no es sinónimo de metodología fácil. Aun siendo una metodología flexible, no deja de tener una serie de normas o principios que aseguran que la metodología sea eficiente y no caótica. Y no son pocas. Para asegurarse que todas esas normas se cumplen, que cada rol asume sus responsabilidades, que la metodología se aplica correctamente y que es adecuada para el proyecto, existe el rol del Scrum Master. Habitualmente se suele decir que el Scrum Master es un facilitador. Paradójicamente, siendo mayormente un observador y el encargado de hacer cumplir las responsabilidades al equipo y al Product Owner, el Scrum Master es el único que en el fondo trabaja para todos. Sus responsabilidades son: • Naturalizar la auto-organización del equipo: que el equipo sea auto-organizado es fundamental en Scrum y, por tanto, es responsabilidad del Scrum Master lograr que el equipo logre ese objetivo. Para ello, debe apoyarles siempre que lo necesiten, proveyendo de mecánicas o rutinas que ayuden al equipo a organizarse, asegurándose de que realmente este tiene el control sobre el trabajo que realizan (se ayudará de los artefactos, como veremos a continuación) y protegiéndolos de las posibles presiones externas que pudiesen hacer que la organización no fuese del propio equipo, sino que estuviese guiada desde el exterior (Producto Owner o incluso gente más allá de los roles de Scrum). • Ayudar al equipo a ser productivo: si el equipo no es productivo, el proyecto no avanzará debidamente. Puede haber muchos motivos que reduzcan la productividad, tanto técnicos (falta de conocimientos o formación, material de trabajo inadecuado, etc.) como humanos (falta de entendimiento en el equipo, entorno hostil de trabajo, falta de motivación, etc.). • Es responsabilidad del Scrum Master mantener una comunicación constante con el equipo para ser consciente de esas limitaciones y proponer alternativas tanto a ellos como a los responsables de la empresa para solventarlas. European Open Business School

25

MANUAL GESTIÓN DE PROYECTOS ÁGILES

• En el caso de limitaciones técnicas, podrá buscar la formación adecuada para el equipo y lograr introducirla como parte del proyecto tanto en tiempo como económicamente. También deberá proveerlos de las herramientas necesarias para que la calidad del producto sea la máxima posible. • En el caso de limitaciones humanas, deberá dotar al equipo de un entorno adecuado de trabajo y ayudarles a encontrar una motivación (la motivación es un sentimiento personal de cada uno, no se puede dar, pero se puede ayudar a encontrarla). • Orientar al cliente sobre los beneficios que puede obtener de Scrum: nadie conoce la metodología más a fondo que el Scrum Master. En caso de que sea necesario, será su responsabilidad trasladar su conocimiento al cliente para que este sepa los beneficios y dificultades derivados de utilizar esta metodología y colabore en su correcta utilización. • Eliminar impedimentos: la imagen de facilitador ofrecida por el Scrum Master viene determinada por esta responsabilidad. Más adelante se verá que el ciclo de vida de Scrum ofrece al equipo la posibilidad de reportar diariamente impedimentos que les hayan surgido durante la implementación de un hito y que les impide seguir trabajando en él. El Scrum Master será responsable de hacer desaparecer dicho impedimento, bien sea buscando un recurso que lo solucione o dotando al equipo de las herramientas para hacerlo por sí mismos. • Facilitar las comunicaciones: la comunicación directa entre los distintos componentes del proyecto es otro de los pilares fundamentales de Scrum. El Scrum Master deberá asegurarse que se disponen de los medios para que esa comunicación se produzca y que los términos de comunicación entre las distintas partes, con distintos intereses, son los adecuados. • Manejar el entorno de proyecto: parte de la comunicación entre miembros del proyecto se realiza a través de sus artefactos. El Scrum Master deberá asegurarse que estos artefactos son utilizados e incluso responsabilizarse de su uso y actualización en el caso de alguno de ellos. • Asegurarse que todas las personas implicadas están comprometidas con la metodología: como en cualquier entorno de trabajo o metodología utilizada, para lograr el éxito, las personas implicadas en proyecto deben creer en él. Especialmente si la metodología utilizada se sale de lo habitual (de las llamadas metodologías tradicionales). Es responsabilidad del Scrum Master lograr que todo el mundo crea en la metodología y neutralizar cualquier conato de “manzana podrida” (se denomina así a una persona que no cree en la metodología y arroja negatividad sobre el resto de personas, logrando que finalmente tampoco crean en ella).

ARTEFACTOS DE SCRUM

Scrum es una metodología sencilla en conceptos y fácil de aplicar siempre que se mantenga un nivel aceptable de disciplina. Para garantizar que esa disciplina existe, aparte de la propia motivación y convencimiento de los integrantes del proyecto, hemos visto que existe una figura o rol que es el Scrum Master.

26

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

El Scrum Master hace uso a su vez de una serie de artefactos o ayudas, que deben ser puestos a disposición y utilizados por los distintos miembros del proyecto para gestionar el trabajo de manera correcta. A continuación, se describen los principales artefactos utilizados en Scrum, explicando el porqué de su importancia en el proceso.

 Product Backlog En cualquier proyecto, al inicio del mismo, el responsable o responsables del proyecto realizan una toma de requisitos del producto requerido por el cliente. En las metodologías tradicionales, estos requisitos son la meta a alcanzar y se reflejan normalmente de manera contractual, de manera que permanecen inmóviles desde el inicio hasta el final del proyecto. En el caso de Scrum, como metodología ágil que es, esa toma de requisitos inicial es más un punto de partida, susceptible a ser modificado a lo largo del proyecto tanto en volumen como en prioridad. Por tanto, tenerlo reflejado en un papel, sería engorroso, ya que este tendría que ser reescrito en cada cambio solicitado. En lugar de eso, se propone al Product Owner (responsable del producto e interfaz con el cliente) mantener una pila de producto (Product Backlog), que no es más que un soporte, en principio físico, aunque podría ser virtual, donde poder ordenar fichas que reflejen los distintos hitos que componen o podrían componer potencialmente el producto. Dichos hitos se denominan en Scrum historias de usuario y suelen ser reflejadas en tarjetas de la siguiente manera:

27

European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Y en el revés de la tarjeta se escribirán los requisitos mínimos de calidad requeridos por el Product Owner, llamados “criterios de aceptación”.

Una vez todas las historias de usuario han sido trasladadas a tarjetas, se colocan sobre el product backlog en orden de prioridad, de modo que la más prioritarias estén situadas lo más arriba posible. Este tipo de organización permite que el Product Owner, ya sea por decisión propia o por conversaciones mantenidas con el cliente, pueda reordenar los elementos de este Backlog en caso de que las prioridades cambien, e introducir nuevas historias de usuario, en el punto que les corresponde por su prioridad, según vayan surgiendo. Aparte de con todas las historias de usuario, la pila de producto en ocasiones se completa con otra información de vital interés para tener un objetivo claro del producto. Por ejemplo, en el caso de la construcción de un coche se puede tener como prioridad principal del producto su aerodinámica y su fiabilidad a la hora de conducir. En ese caso, se añadirá una columna a la derecha de la pila de historias de usuario, donde se añadirá una tarjeta por cada una de esas constantes que se quieren mantener a lo largo de todo el proyecto. En el caso de que el producto responda a una imagen, también es muy útil tener un boceto de cómo se quiere que sea el resultado final o de las normas de estilo que deben cumplir cada uno de sus componentes. Igualmente, en muchas pilas de producto, se añade también una columna que enumera los distintos actores y entidades relacionados con el proyecto y la interacción que existe entre ellos. Se llama área del modelo.

28

European Open Business School