[google-translator]

SCRUM Y KANBAN: Nuestro método de trabajo para ser eficientes con los clientes

NUESTRO MÉTODO DE TRABAJO UTILIZANDO “METODOLOGÍAS ÁGILES” (SCRUM Y KANBAN)

Nuestro objetivo es hacer proyectos para nuestros clientes con un valor de eficiencia mutuo. Para ello hemos incorporado como metodología de trabajo El SCRUM Y KANBAN, los cuales nos ayudan a la planificación y ejecución de proyectos de una manera ordenada y pudiendo cumplir los plazos comprometidos así como la calidad de producto a entregar a cliente.

El concepto de “metodología ágil”, nos permite progresar de manera adecuada e ir entregando al cliente fases del trabajo durante el proceso de creación, sobre las cuales se pueden tomar decisiones sin esperar a la entrega final del mismo.

Esto produce además de una mayor eficiencia, una mejor adaptación del producto, una toma de decisiones coherente y progresiva, un producto que se entrega en la calidad concertada continuamente con el cliente y por ende una mayor satisfacción para ambos (cliente y nosotros), pudiendo mejorar la eficiencia del proceso.

Como cliente tal vez te interese también trabajar con este proceso. En este artículo (realmente extenso) te vamos a dar las pautas de cómo hacerlo (de como lo hacemos nosotros) y el sentido del mismo.

LAS METODOLOGÍAS ÁGILES EN LA GENERACIÓN DE NUESTROS PROYECTOS

Antecedentes

La revolución industrial supuso un cambio en la sociedad, en los negocios y, por tanto, en la manera de concebir las empresas. La aparición de la imprenta, el motor de vapor y otros inventos propiciados de esta era hizo que las estructuras sociales y organizacionales cambiaran.

Esa era que tantos avances ha supuesto para la sociedad ha sido superada. La aparición de las nuevas tecnologías, internet y lo teléfonos móviles ha propiciado la generación de una gran cantidad de contenido y datos. En un estudio publicado en Science en el año 2011 se pretendía cuantificar la cantidad de información generada y almacenada en el mundo. En 2013 el CEO de Google, Eric Schmidt, afirmó que la Humanidad había creado hasta 2003 una cantidad equivalente a 5 Exabytes, añadiendo que ahora esta cifra se generaba en 2 días.

Las cifras que ofrece el estudio de Science son realmente abrumadoras. Entre algunas de ellas destacan la cantidad de información generada por la humanidad hasta el año 2007 que la estiman en 295 exabytes, aumentando a los a 1000 exabytes hoy, que es la capacidad que pueden contener un millón y medio de ordenadores de sobremesa actuales. El estudio también nos dice que, la tecnología digital domina claramente sobre la analógicas puesto que desde el 2007, el 99,9% de la información generada era en formato digital, o, al contrario, que sólo el 0,007% de la información del planeta está en papel. A este paso habremos creado en apenas unos años la misma cantidad de información que en el resto de la historia.

Es por ello que al vivir en una sociedad hipercomunicada, con grandes avances tecnológicos en el que te puedes comunicar con cualquier personal del mundo (al menos civilizado) a golpe de chat y email ha supuesto una revolución en la manera de hacer negocios. Nunca hacer estos negocios ha sido tan “fácil”. Con apenas un ordenador y unos pocos euros puedes dar de alta un dominio y programar una web que te permita hacer negocios.

Hasta el sector financiero, históricamente poco amenazado por el cambio, se está empezando a sentir amenazado ya que empresas tecnológicas como Google, Apple o Amazon están empezando a entrar en sus modelos de negocio. Por tanto, necesitamos formas de trabajo diferentes que se adapten a este momento que nos ha tocado vivir, que persigan la adaptación al cambio por encima de seguir un plan, que den importancia a las personas antes que al método y las herramientas o que impongan como medida de progreso lo que funciona antes que una documentación exhaustiva.

Asociación con Lean

Lean (sin grasa sería su traducción al castellano) es un término que se popularizó en la época de los 40 cuando se pretendía aligerar los procesos principalmente en la industria manufacturera. Toyota fue su principal impulsor creando incluso su propio proceso y cultura llamado Toyota Production System (TPS). No es hasta 1990 con la aparición del libro “The machine that changed the world” donde los autores acuñan el término Lean asociándolo a toda esta cultura japonesa. Los conceptos surgidos desde la industria automovilística se extrapolaron posteriormente al mundo del software dando lugar al concepto de Lean IT y poco a poco se han ido aplicando a otros modelos de negocio.

Aunque resulta más complejo de explicar, podríamos decir que Lean trata de aligerar los procesos, mediante una serie de principios y buenas prácticas, así como de darle mucha importancia a la mejora continua.

Podemos decir que Lean es el paraguas bajo el que se instala “Agile”, con parte de sus aprendizajes y prácticas incrustadas en su ADN.

Ciclo de Deming

Edward Deming era un estadista norteamericano que tras la segunda guerra mundial empezó a divulgar por Japón conceptos relacionados con la mejora de los procesos y el aumento de la calidad. Debemos recordar que Japón se encontraba desolada, habiendo sido perdedor de una gran guerra. Además, todos sus esfuerzos industriales años anteriores habían estado enfocados al sector armamentístico por lo que toda su industria se encontraba prácticamente en pañales.

Poco a poco los japoneses fueron adoptando los consejos de Deming principalmente en la industria automovilística, encabezada por Toyota. Deming se hizo popular por divulgar los conceptos de Walter Andrew Shewhart, otro estadista que realizó diferentes estudios sobre la optimización de procesos. Uno de los términos que popularizó Deming fue el posteriormente llamado Ciclo de Deming que básicamente consiste en establecer el modelo de aprendizaje empírico utilizando en otros ámbitos como las ciencias. Este proceso consta de cuatro fases:

  • Planificación
  • Hacer
  • Inspección de los resultados.
  • Adaptación en función de los resultados obtenidos

Veamos estas fases en más detalle:

  • Planificación (Plan): En esta fase dedicamos el tiempo a pensar en todo lo relacionado con el proyecto y con lo que haremos próximamente. Es un buen momento para pensar en qué tareas tendremos que realizar (con más o menos detalle) así como evaluar posibles riesgos y problemas futuros. Hay muchas leyendas que hablan de que en las metodologías ágiles no hay que dedicar tiempo a la planificación. Esto es totalmente falso ya que siempre deberemos pensar antes de actuar. Lo que sí que nos comentan estos enfoques ágiles es que no le dediquemos un tiempo excesivo si no el mínimo indispensable para poder empezar a funcionar.
  • Hacer (Do): En esta fase propiamente dicha es donde realizamos el trabajo. Los enfoques ágiles promueven el empezar a realizar esta fase lo antes posible, ya que solo cuando esto se produce empezaremos a ver los problemas reales que nos podamos encontrar.
  • Comprobación (Check): La fase más importante desde el punto de vista de la mejora continua. En esta fase es donde deberemos pararnos a reflexionar y comprobar cómo ha ido todo el trabajo realizado durante la fase de Hacer. Si queremos mejorar deberemos tener estos momentos de reflexión.
  • Actuar (Act): La reflexión sin acción no sirve de mucho. Una vez analizado y comprobado todo lo realizado y recibido feedback deberemos Actuar con una serie de cambios o mejoras. Hay veces que la actuación consiste en consolidar los cambios realizados y asimilarlos como acuerdos de trabajo.

Aunque pueda parecer muy sencillo de entender, la puesta en práctica no es tan sencilla. En muchos equipos, departamentos y empresas se olvidan de las dos últimas fases, estando en un continuo Plan-Do-Plan-Do-Plan-Do…, donde la mejora se realizar de una manera poco explícita y lenta.

Para recapitular, en estos conceptos se encuentra gran parte de la esencia de Agile. Es interesante esta aproximación ya que da especial importancia a la fase de feedback (inspección) y a la de adaptación, lo que nos permitirá de una forma continua validar los resultados obtenidos para, posteriormente, adaptarnos en función del resultado.

Triángulo de hierro

Tiempo que vamos a tardar en realizar el proyecto, Alcance como el conjunto de requerimientos a cubrir y el Coste como el dinero que deberemos invertir. Está directamente relacionado con las personas y recursos materiales que participen en el proyecto.

Por mucho que queramos no podemos cerrar los tres vértices ya que siempre al menos uno debe ser variable para que la calidad (en el centro) no se vea repercutida.

Esto quiere decir que nunca en un proyecto podremos fijar el tiempo de duración, el número de tareas o alcance a realizar, así como cuantas personas lo van a formar, es decir, no podríamos fijar que vamos a realizar un proyecto en tres meses, para realizar 25 tareas con 5 personas sin que la calidad el mismo se vea afectada. De esta manera podemos cerrar tiempo y alcance y dejar libre el número de personas necesarias (coste), o bien decidir el alcance del proyecto y las personas que lo van a formar y así dejar libre el tiempo que tardarán en realizarlo.

Nunca debemos perder de vista la calidad en el centro de todo. Por tanto, cualquier decisión que tomemos debería ir orientada a no repercutir en esta calidad. Construir proyectos de baja calidad a la larga nos traerá muchos problemas de mantenimiento e inestabilidad futuros.

En las metodologías ágiles lo normal es fijar el tiempo (entre 1 y 4 semanas) y el coste, es decir, el número de personas que participarán en cada sprint y variaremos el alcance o número de requisitos o funcionalidades que entregaremos en cada periodo de tiempo. De esta manera al fijar el tiempo estaremos consiguiendo un ritmo continuo por parte del equipo y si conseguimos que el equipo sea estable (sin demasiadas salidas y entradas de personas) conseguiremos también mayor efectividad con el consiguiente éxito en el proyecto.

Cono de incertidumbre

El cono de incertidumbre describe la de la medida de incertidumbre de un proyecto. Nos dice que al inicio de un proyecto tenemos mayor probabilidad de confundirnos en nuestras estimaciones ya que es la fase inicial cuando menos información y conocimiento tenemos sobre la resolución del problema. Lógicamente esto no se puede aplicar a todos los ámbitos ya que si nos paramos a pensar en la construcción de una casa o un avión esta incertidumbre no es la misma. En estas ingenierías conocemos de antemano los planos y hasta los más mínimos detalles del plan ya que es un resultado conocido (la casa o el avión) lo que se pretende construir.

Pero en los proyectos relacionados con la gestión del conocimiento, proyectos cuyo resultado es algo inmaterial (que no se puede tocar) como por ejemplo el desarrollo de una aplicación, una web, un planteamiento sobre actuación en marketing, una campaña de comunicación o de redes sociales o el desarrollo de un software de integración específico, no se puede aplicar los mismos esquemas ya que lo que estamos intentando construir ni siquiera sabemos cómo es.

Es por ello que las metodologías ágiles promueven el inicio de la fase de “hacer” lo antes posible para tratar de que aparezcan estos impedimentos tan pronto como sea posible. De esta manera pasamos del ámbito de lo teórico, al tratar de “adivinar” que impedimentos tendremos, al ámbito de lo práctico donde los impedimentos tarde o temprano terminan apareciendo.

Iterativo e incremental

Uno de los pilares en torno a las metodologías ágiles es que promueven el desarrollo de proyectos de forma iterativa e incremental. Este enfoque es diferente al de otros enfoques o metodologías como, por ejemplo, el enfoque en cascada donde se divide el proyecto en fases para acabar construyendo el proyecto al final.

Los enfoques ágiles promueven sin embargo el desarrollo iterativo e incremental ya que están pensados para proyectos con una alta incertidumbre y una gran variabilidad en los requisitos, es decir, muchos cambios. Por ello, lo que nos interesa en este tipo de proyectos es ir obteniendo feedback lo antes posible de nuestros clientes, con el objetivo de reducir la incertidumbre y saber si lo que estamos construyendo es realmente lo que quieren.

Por ello, necesitamos un enfoque de proyecto que priorice esta entrega frecuente (en el caso una app, web o e commerce de funcionalidades) que nos permita saber si vamos en la buena dirección. Veamos de qué manera nos puede ayudar.

El concepto de iterativo tiene que ver con dividir el proyecto en pequeñas fases (o iteraciones) con el objetivo de entregar al final de cada iteración un pequeño entregable de nuestro producto que añada (incremente) valor al anterior. Quizás el resultado final de cada iteración no sea el producto tal y como lo quiere nuestro cliente, pero si será algo que le aporte valor y que nos permita al equipo de desarrollo conocer si lo entregado se adapta o no a sus necesidades y cumple con sus expectativas.

Poniendo el símil con la pintura de un cuadro, seguir un enfoque solamente iterativo tendría que ver con dividir el cuadro en diferentes partes e ir haciendo cada una de las partes para al final tener el cuadro completo.

Este enfoque por sí solo no nos sirve ya que da por supuesto que sabemos exactamente cómo será el cuadro desde el principio. Por eso debemos añadirle el concepto de incremental.

Por otro lado, el concepto de incremental tendría más que ver con dividir el cuadro de tal manera que partamos de un lienzo con trazos muy sencillos y fuéramos poco a poco dotando de color y complejidad a nuestro cuadro.

Ninguno de los enfoques por separado nos aporta todo lo que queremos. Por ello, la clave está en mezclar ambos conceptos. En el cuadro vendría a ser algo así como seleccionar primero una parte del cuadro (por ejemplo, la cabeza) e ir dibujando esta cabeza desde una versión a mano alzada con trazos poco definidos, a una versión cada vez más precisa. Cuando acabáramos con esta cabeza ya tendríamos una versión del cuadro que potencialmente si quisiéramos podría ser expuesta en un museo.

En el desarrollo de productos de software debemos tener presente que no tenemos la certeza absoluta de lo que el cliente quiere al inicio del proyecto. Vamos a utilizar otra metáfora de Henrik Kniberg para explicar el concepto de iterativo e incremental.

En este caso supongamos que tenemos un cliente cuyas aspiraciones es ir a los sitios de una manera más rápida que a pie. Si enfocamos esta necesidad con la idea de construir un coche podemos enfocarlo de dos maneras esta construcción.

Una primera aproximación, la que siguen los enfoques más tradicionales en el que damos por supuesto que nuestro cliente lo que necesita es un coche. Dado esto por supuesto dividimos la construcción de este en diferentes fases. Al finalizar cada fase le entregamos a nuestro cliente un trocito de ese coche. Solo en la fase final nuestro cliente se sentirá contento y tendrá su coche listo. Por el resto de fases anteriores no le hemos aportado nada de valor ya que no ha podido hacer nada con solo dos ruedas, un chasis, etc.

Si, por el contrario, optamos por una aproximación iterativa e incremental trataremos de aportar valor en cada una de las diferentes fases del proyecto. Sabiendo que la necesidad real de nuestro cliente es viajar o transportarse a los sitios de una manera más rápida podemos optar en una primera iteración por construirle un pequeño monopatín. De acuerdo, este monopatín no es un coche, pero si pensamos en la necesidad que queríamos cubrir (viajar o transportarse más rápido) creo que de esta manera ya estamos cubriendo (al menos un poquito) con esa necesidad y nuestro cliente puede empezar a estar un poco más satisfecho.

Lo malo de las metáforas es que son reducidas y pueden llevar a confusión. Está claro que, si nuestro cliente tiene claro que quiere un coche, no estará muy contento si le entregamos un monopatín al inicio, pero, estamos utilizando estos enfoques porque es nuestro cliente precisamente el que no tiene claro lo que necesita.

 

MANIFIESTO ÁGIL

Podríamos decir que los principios y valores de cualquier enfoque son la base sobre la que se sustenta todo. Las metodologías ágiles no podían ser menos, por ello están basadas en una serie de principios y valores. Podríamos decir que todo lo demás se asienta sobre ellos. Sin principios ni valores las prácticas quedan vacías y sin sentido. Estos valores y principios se encuentran descritos en el Manifiesto Ágil.

Valores

Aunque hay muchas definiciones de valores nos gusta especialmente una que dice que valores es aquello que valoramos, es decir, a lo que damos mayor importancia y en base a lo que tomamos las decisiones.

En nuestro contexto, los valores del manifiesto ágil son la base sobre la que tomar decisiones y primar unas cosas por encima de las otras. En el manifiesto ágil así se indican estos valores. Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

  • Individuos e interacciones sobre procesos y herramientas.
  • App, Webs, e commerce o proyectos creativos funcionando sobre documentación extensiva.
  • Colaboración con el cliente sobre negociación contractual.
  • Respuesta ante el cambio sobre seguir un plan.

El manifiesto ágil fue firmado por expertos de desarrollo de software que llevaban varios años en la industria. Fue firmado pues por personas con amplios conocimientos y experiencia. Fue en base a esta experiencia anterior lo que les había permitido darse cuenta de que podría haber maneras diferentes de desarrollar software ya que los enfoques hasta la fecha estaban centrados en metodologías y procesos que primaban más otras cosas.

Principios

Para complementar a los valores tenemos los principios que podríamos decir que son recetas más concretas que nos permiten llevar a la práctica los valores. En el propio manifiesto ágil se incluyen 12 principios que pasamos a enumerar a continuación:

  • Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
  • Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
  • Entregamos soportes funcionales frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
  • Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
  • Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
  • El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
  • El producto funcionando es la medida principal de progreso.
  • Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
  • La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
  • La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
  • Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.
  • A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Debemos tener siempre presente estos valores y principios en nuestro día a día ya que como comentamos anteriormente son la base sobre la que se asientan todo (reuniones, artefactos, roles). Ante la duda sobre cómo actuar o qué hacer resulta una buena solución acudir a estos principios y valores y ver que nos transmiten para decidir qué hacer.

SCRUM – INTRODUCCIÓN

En 1986 Hirotaka Takeuchi y Ikujiro Nonaka en el paper “El juego del desarrollo de nuevos productos” definen un nuevo marco de desarrollo de productos como “una estrategia de desarrollo de producto flexible y holístico, donde un equipo de desarrollo trabaja como una unidad para alcanzar un objetivo común, como oposición al enfoque tradicional donde se establece el desarrollo como una secuencia de fases “independientes” entre ellas”. Takeuchi y Nonaka explicar posteriormente que esto es una forma de creación de conocimiento en el ámbito organizacional especialmente bueno para entornos en los que la innovación continua, incremental e iterativamente deba estar presente.

Aunque todavía no le darían ningún nombre a este enfoque sí que podemos ver claramente ideas que posteriormente se acabarían aplicando a Scrum.

Ya en los 90, Ken Schwaber empezó a utilizar las primeras aproximaciones de lo que luego se llamaría Scrum como Métodos de desarrollo avanzado. Por otro lado, Jeff Sutherland comenzó a desarrollar un enfoque similar en Easel y fue el primero en utilizar la palabra Scrum.

En 1995, Sutherland y Schwaber presentaron un primer informe describiendo la metodología Scrum. En los posteriores años trabajaron juntos para unificar y aportar desde su experiencia las mejores prácticas en lo que hoy se conoce como Scrum.

Los autores describen Scrum como una nueva aproximación al desarrollo de producto que incrementaría la velocidad y flexibilidad. Para llevar a buen término este proceso este debería ser llevado a cabo por un equipo multifuncional a lo largo de todas las fases, en lugar del enfoque más tradicional que sugiere especialistas por cada una de las fases (analista funcional, orgánico, tester, etc.).

 

Scrum en 5 minutos

Scrum es un proceso iterativo e incremental utilizado para la construcción de productos. Esto significa que el proceso se compone de diferentes interacciones a las que llamaremos Sprints. Estas interacciones o sprints son fijos en el tiempo y se recomienda que tengan una duración de 1 a 4 semanas máximo. El objetivo de estos sprints es el de construir un incremento del producto que potencialmente se pudiera utilizar por parte de los clientes. Por tanto, no nos serviría entregar algo que no pudiéramos utilizar al final del proceso.

Pero para poder empezar a construir un producto antes debe haber una idea de negocio o unas necesidades que cubrir. Por ejemplo, de nada hubiera servido ponernos a construir Whatsapp si no tenemos claro que cubriría esta herramienta, en este caso, mejorar la forma en la que se comunican las personas.

Generalmente a las personas para las que construimos el producto o servicio se les llama Interesados o Stakeholders en inglés. Pueden ser todas las personas que tienen interés en lo que estamos construyendo. Por ejemplo, si estuviéramos construyendo una aplicación para un hospital, los interesados podrían ir desde el Director General del Hospital, pasado por Celadores, Enfermeras, Médicos, Supervisores, Recepcionistas y todas aquellas personas que de algún modo les afecte directa o indirectamente en su trabajo la construcción de la aplicación.

Una vez tenemos claro que personas son a las que les vamos a aportar valor es necesario recopilar en un único sitio todas las ideas, funcionalidades y demás elementos que van a componer nuestro producto. A este conjunto de elementos ordenados por valor de negocio (arriba los que más valor aportan) se le llama Pila de Producto o Product Backlog en inglés. A los elementos que componen esta Pila de Producto se les conoce como PBIs del inglés Product Backlog Items o Elementos de la Pila de Producto.

Para gestionar toda esta comunicación y gestionar la pila de producto existe un rol específico llamado Dueño de Producto o Product Owner en inglés, cuyo objetivo es maximizar la entrega de valor en cada Sprint, es decir, que el equipo construya lo que le aporte más valor a los Interesados.

Otro rol clave entonces es el Equipo de Construcción, encargado de las labores puramente de construcción del producto. Es el encargado en cada Sprint de entregar una parte del incremento.

Para que el equipo pueda entregar en cada Sprint un Incremento del producto este (el equipo de construcción) debe estar enfocado sobre una parte pequeña del mismo. Ese conjunto de PBIs mas sus tareas técnicas para construirlos se le llama Pila del Sprint y será necesario para poder comenzar el Sprint. Dentro, como acabamos de comentar, se encuentran los Elementos de la Pila del Producto que el Dueño de Producto a seleccionado para este Sprint como más importantes junto con una serie de tareas técnicas que el equipo ha desgranado para cada PBI.

Tanto la selección de los PBIs mas importantes como el desgranado de estos en tareas técnicas se realiza en la Reunión de Planificación del Sprint o Sprint Planning en inglés. A esta reunión acuden Dueño de Producto, Equipo de Construcción y Scrum Master y el resultado de la misma debería ser una Pila del Sprint junto con los objetivos claros del mismo. Debe quedar claro que en la Reunión de planificación el Dueño del producto junto con el Equipo de construcción deciden de forma colaborativa que elementos entrarán en el siguiente Sprint. Ya que puede haber elementos que aporten mucho valor a los clientes pero que técnicamente sean muy difíciles de realizar en este momento. Por tanto, debe ser algo consensuado entre ambos roles.

Una vez comienza el Sprint de duración fija entre una y cuatro semanas, el Equipo de construcción comienza a trabajar sobre la Pila de Producto. Para realizar una gestión de riesgos adecuada y fomentar la comunicación y sincronización entre los miembros del equipo Scrum introduce la Reunión diaria o Daily Meeting donde el principal objetivo es detectar problemas e impedimentos que afecten al desarrollo del Sprint. Esta reunión es una reunión corta de no más de 15 minutos.

Pues esto se repite durante todo el Sprint y el equipo va terminando todos los elementos de la Pila del Sprint. Por ello, al finalizar este, es necesario revisar todo lo construido para ver si se ajusta a lo que necesitan los Interesados y así poder recibir feedback de estos Interesados. Eso sucede en la Reunión de Revisión o Demo donde se inspecciona todo lo realizado por el Equipo de construcción. A esta reunión acuden el Dueño de Producto como representante de los Interesados, además del Equipo de Construcción y el Scrum Master. También puede acudir cualquier otra persona que quiera ver lo entregado. Sería muy recomendable que hubiera algún Interesado, aunque esto no siempre es posible.

Después de haberse producido esta reunión para inspeccionar el Incremento entregado en el Sprint el equipo debe reunirse para inspeccionar el proceso y la manera en la que han trabajado con el único objetivo de mejorar y detectar posibles problemas y dar soluciones a los mismos. Esta reunión, sucede después de la Reunión de revisión y se llama Retrospectiva. Es en la retrospectiva donde pondremos el foco en las personas y el proceso dejando a un lado el producto en sí que ya lo inspeccionamos en la reunión anterior.

A esta reunión deben acudir todos los miembros del Equipo Scrum, es decir, Dueño de Producto, Scrum Master y Equipo de Construcción. Es facilitada por el Scrum Master, aunque en algunas ocasiones puede ser interesante que sea facilitada por otra persona para que el Scrum Master pueda también participar como un miembro más el equipo.

Existe una última reunión cuyo objetivo es trabajar sobre los elementos futuros que entrarán en el Sprint, es decir, trabajar sobre los siguientes elementos de la Pila de Producto. A esta reunión donde el Equipo Scrum trabaja para refinar esos elementos, es decir, hacerlos más pequeños, claros y entendibles se le llama Reunión de Refinamiento.

Para asegurarnos que durante el Sprint se bloquea el menor número de elementos, contamos con la Definición de Listo que no deja de ser una lista de necesidades que necesita cada uno de los PBIs para poder empezarlos. Nos evitará desperdicios durante el Sprint por PBIs o tareas que se quedan bloqueadas o dependientes de agentes externos.

Por último, para asegurarnos que se terminan todas las tareas y PBIs de cada Sprint con calidad suficiente contamos con el concepto de Definición de Terminado, entendido como una lista de acciones que deben cumplirse para dar por terminada una tarea y/o PBI como podría ser, por ejemplo, que esté subido el código al repositorio, probado en desarrollo y pre-producción, validado por Marketing, etc.

Como resumen podemos decir que Scrum está formado por:

  • Artefactos, como los elementos con los que trabajamos. Estos son la Pila del producto, Pila del Sprint, el Sprint, el Incremento del producto, Definición de Listo y Definición de Terminado.
  • Reuniones, como los eventos donde se reúnen los diferentes roles. Estas reuniones son: Reunión de planificación, Reunión de revisión, Retrospectiva, Reunión diaria y Reunión de refinamiento. Roles, existen básicamente para dividir las diferentes responsabilidades que nos encontramos a la hora de construir un producto.
  • El Dueño de producto, encargado de maximizar la cantidad de trabajo que se realizará, es, por tanto, el encargado de mantener la visión del producto y la comunicación con los interesados.
  • El Equipo de Construcción, como encargado de construir el producto, el Scrum Master responsable de cumplir el proceso y preocupado de las personas. Los Interesados como esas personas para las que construimos el producto. Debe añadirse que, al equipo formado por Dueño de Producto, Equipo de Construcción y Scrum Master se le conoce como Equipo Scrum.

SCRUM  – ARTEFACTOS

Pila del producto

Es el conjunto de requisitos o características que debe tener nuestro producto.

Contendrá todo lo que se considere aporta valor, aunque estará priorizado de arriba a abajo, donde arriba estarán los elementos más prioritarios y por ello, más detallados y desgranados. En la parte inferior podremos tener elementos o requisitos que todavía no están muy claros.

Características (DEEP)

Las características que debe tener una buena Pila de Producto son:

  • Detallado. Los elementos de la pila del producto que vayan a ser realizados próximamente necesitan tener el suficiente grado de entendimiento como para que puedan ser completados en el siguiente sprint. Elementos que no vayan a ser desarrollados en un tiempo razonable pueden estar descritos con menos detalle.
  • Estimado. La pila de producto es más que una lista de todo el trabajo a hacer, es una excelente herramienta de planificación. Los elementos más lejanos de la pila que todavía no son bien entendidos tendrán asociados estimaciones menos precisas que los elementos de arriba de la pila.
  • Emergente. Una pila de producto no es estática, sino que irá cambiando a lo largo del tiempo según vayamos aprendiendo más sobre el producto. Se añadirán elementos nuevos, eliminarán otros que ya no tienen sentido y se repriorizarán otros tantos.
  • Priorizado. La pila de producto debería estar ordenada con los elementos más importantes en la parte superior, así como los menos en la inferior. Si trabajamos siempre en orden de prioridad, el equipo es capaz de maximizar el valor del producto o sistema desarrollado.

Priorización

Para priorizar los elementos se pueden utilizar diferentes técnicas:

Método MoSCoW

Es un método de priorización que nos indica la importancia de los elementos donde:

M: Must have, elementos que deben entrar ya que son muy importantes.

S: Should have, son elementos importantes, pero no necesarios para la entrega en la que nos encontramos. Suelen ser elementos importantes pero que pueden esperar o hay otra manera de obtenerlos en muchos casos.

C: Could have, elementos que solo entrarán si hay tiempo suficiente. Son elementos deseables, pero no necesarios.

W: Won’t have, elementos que seguro que no van a poder entrar.

El modelo Kano

El modelo Kano es una teoría de desarrollo de productos y de satisfacción del cliente, desarrollada en la década de 1980 por el profesor Noriaki Kano, que clasifica a las preferencias del cliente en cinco categorías:

Calidad atractiva

Estos atributos proporcionan satisfacción cuando se logran plenamente, pero no causan insatisfacción cuando no se logran. Estos son atributos que normalmente no son esperados, por ejemplo, un termómetro en un envase de leche que muestra la temperatura de la leche. Dado que este tipo de atributos de calidad deleitan a los clientes de forma inesperada, suelen ser no mencionados.

Calidad unidimensional

Estos atributos dan como resultado la satisfacción cuando se cumplen e insatisfacción cuando no se cumplen. Estos son los atributos que se mencionan y por los cuales las empresas compiten. Un ejemplo de esto sería un envase de leche que dice que tiene un diez por ciento más de leche por el mismo precio se traducirá en satisfacción del cliente, pero si solo contiene seis por ciento, entonces el cliente se sentirá engañado y que dará lugar a insatisfacción.

Calidad Requerida (Must-be Quality)

Estos atributos se dan por sentadas cuando se cumplen, pero dan lugar a insatisfacción cuando no se cumplen. Un ejemplo de esto sería envase de leche que se filtra. Los clientes están insatisfechos cuando se filtra el envase, pero cuando no se escape el resultado es que no se incrementa la satisfacción del cliente. Puesto que los clientes esperan que estos atributos y los consideran como básicos, es poco probable que vayan a decirle a la empresa acerca de ellos cuando se le preguntó acerca de los atributos de calidad.

Calidad Indiferente

Estos atributos se refieren a aspectos que no son ni buenos ni malos, y no resultan ni en ya sea satisfacción del cliente o la insatisfacción del cliente.

Calidad inversa

Estos atributos se refieren a un alto grado de rendimiento que resulta en la insatisfacción y al hecho de que no todos los clientes son iguales. Por ejemplo, algunos clientes prefieren los productos de alta tecnología, mientras que otros prefieren el modelo básico de un producto y no estarán satisfechos si un producto tiene muchas características adicionales.

Por Retorno de Inversión (ROI)

El retorno de inversión es el resultado de aplicar el valor que aporta un elemento dividido entre el tiempo que tardamos en construirlo

ROI = Valor / Tiempo

De tal manera que, si un elemento aporta mucho valor, pero su tiempo de construcción es muy elevado su ROI final será bajo, mientras que un elemento que quizás aporte menos valor, pero su tiempo de construcción sea bajo su ROI será mayor.

Idealmente buscaremos elementos que aporten mucho valor a los clientes y que su tiempo de construcción sea muy bajo ya que estos serán los que más Retorno de Inversión obtendrán.

PBI vs Historia de usuario

Vamos a ver qué tipo de elementos son los que pueden incluirse dentro de la Pila de Producto. La guía de Scrum nos habla que dentro de esta Pila de producto lo que hay son Elementos de la pila del Producto, PBI de sus siglas en inglés Product Backlog Item. Parece lógico, ¿verdad?.

Los elementos de la Lista de Producto tienen como atributos la descripción, el orden, la estimación y el valor. La guía de Scrum no habla de ningún atributo más relacionado con los PBIs. Además, estos pueden contener cualquier información adicional adjunta que pueda ser relevante para la terminación de ese elemento como por ejemplo diagramas de uso, borradores de pantallas, datos de encuestas, gráficas o cualquier otro elemento.

Por otro lado, es habitual hablar del concepto de Historias de Usuario. Incluso oirás hablar a algún que otro “experto” de que la Pila de Producto está formado Historias de Usuario. Espero que te haya quedado claro que esto no tiene porqué ser así. En una Pila de producto hay PBIs y estos, pueden tener un formato concreto de Historia de Usuario, o no. Pero es erróneo decir que dentro de una Pila de Producto siempre hay Historias de usuario.

Historias de Usuario

Vamos a hablar un poco más a fondo de lo que son ya que, como decíamos antes, son uno de los formatos más utilizados por equipos ágiles.

Lo primero que debemos saber es su origen. Este concepto fue acuñado por Kent Beck en su libro Extreme Programming (1999). Se define como una descripción simple y corta de una funcionalidad, expresada desde la perspectiva de la persona que desea cubrir esa necesidad, generalmente el usuario de nuestro sistema.

Ron Jeffries explica que una Historia de Usuario debe cumplir con la regla de las 3Cs. Esto es:

  • Card (Tarjeta): Las historias de usuario tradicionalmente se escriben en tarjetas de papel o post-its ya que recordemos que la principal intención de una historia de usuario es que sea corta, tratando de captar la esencia de la necesidad.
  • Conversation: Una historia de usuario debe ser el resultado final de una conversación. Esta conversación es realmente lo importante. Idealmente debería producirse entre las personas que van a construir la funcionalidad (equipo de construcción) y las personas que tienen esa necesidad (usuarios y clientes).
  • Confirmación: Es una parte importante de la historia de usuario ya que nos permite definir los criterios por los cuales sabremos si la historia resuelve el problema o no. Esta confirmación suele expresarse la mayoría de veces como Criterios de Aceptación y ya veremos que también se pueden escribir en un formato concreto.

Una evolución de esto sería construir arquetipos de tipología de clientes de tal manera que personificamos aún más la Historia de Usuario. A estos arquetipos también se les conoce como User Personas y no dejan de ser una representación de nuestros usuarios. Los User Personas son personificaciones ficticias que representan a un cliente.

En resumen, las Historias de usuario son uno de los formatos más utilizados como PBI dentro de una Pila de producto, pero no es lo único que puede haber dentro de esta pila. La Historia de usuario es una Tarjeta (Card) donde se refleja una Conversación entre nuestros usuarios y el equipo de construcción idealmente. Además, deberá tener unos criterios Confirmación para asegurarnos que se construye lo adecuado.

Incremento de producto

El incremento de producto es el resultado de cada Sprint. Las dos características más importantes que debe reunir este incremento son:

  • Potencialmente se pueda poner en producción. El Manifiesto Ágil lo deja claro, el incremento debe ser algo funcional. No sirve entregar algo de cartón piedra que no funcione realmente. No quiere decir que al final de cada Sprint este Incremento se vaya desplegar, pero sí que debería poder hacerse si quisiéramos.
  • Debe aportar valor a nuestros Clientes / Usuarios. No sirve de nada entregar funcionalidad que no cubra las necesidades de nuestros clientes ya que es el objetivo fundamental por el que estamos trabajando.

Pila del sprint

Recordemos que la Pila del sprint es el resultado de la Reunión de planificación al inicio de cada Sprint. Está compuesta por todos los PBIs que han sido seleccionados y además contiene las tareas técnicas de, al menos, los PBIs más prioritarios en el Sprint. Se aconseja que todos los PBIs tengan estas tareas técnicas ya desgranadas. Podríamos decir que la Pila del Sprint es una lista de PBIs pendientes de realizar.

La Lista de Pendientes del Sprint es una predicción hecha por el Equipo deDesarrollo acerca de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en un Incremento “Terminado”.

La Pila del Sprint es un plan con un nivel de detalle suficiente como para que los cambios en el progreso se puedan entender en la Reunión Diaria. El Equipo de Desarrollo modifica la Lista de Pendientes del Sprint durante el Sprint y esta Lista de Pendientes del Sprint emerge a lo largo del Sprint. Esto ocurre a medida que el Equipo de Desarrollo trabaja en lo planeado y aprende más acerca del trabajo necesario para conseguir el Objetivo del Sprint.

La ordenación de estos PBIs debería ser por importancia o valor que aportan. De tal manera que los más prioritarios deberían estar situados en la parte superior de la Pila del Sprint y serían por los que el equipo debería empezar. De tal manera que, si al finalizar el Sprint no se han completado todos los PBIs, serán los de menor importancia (los de abajo) los que no se hayan terminado, consiguiendo de esta manera siempre tener un Incremento con los PBIs más importantes para nuestros clientes.

Los PBIs de la Pila del Sprint además están estimados. Esta estimación la ha realizado el Equipo de Construcción. Hay diferentes maneras de realizar esta estimación. Hay equipos que van estimando cada una de las tareas técnicas que componen el PBI y posteriormente realizan una estimación global del PBI (generalmente basada en la suma de las tareas técnicas). Otros equipos, por el contrario, después de haber mantenido una conversación sobre las tareas técnicas y su complejidad realizan la estimación global de todo el PBI.

Al final una estimación no es más que eso, una aproximación o predicción del trabajo que se realizará. Puede ser un error pensar que la estimación es exacta y pensar que debe cumplirse a raja tabla. Lo importante de la estimación es poder tener una conversación entre los compañeros de equipo y poder ver qué tipo de dificultades, problemas y riesgos pueden surgir durante el Sprint.

Transparencia de los artefactos

En la guía oficial de Scrum podemos leer lo siguiente:

“Scrum se basa en la transparencia. Las decisiones para optimizar el valor y controlar el riesgo se toman basadas en el estado percibido de los artefactos. En la medida en que la transparencia sea completa, estas decisiones tienen unas bases sólidas. En la medida en que los artefactos no son completamente transparentes, estas decisiones pueden ser erróneas, el valor puede disminuir y el riesgo puede aumentar. El Scrum Master debe trabajar con el Dueño de Producto, el Equipo de Desarrollo y otras partes involucradas para entender si los artefactos son completamente transparentes. Hay prácticas para hacer frente a la falta de transparencia; el Scrum Master debe ayudar a todos a aplicar las prácticas más apropiadas si no hay una transparencia completa. Un Scrum Master puede detectar la falta de transparencia inspeccionando artefactos, reconociendo patrones, escuchando atentamente lo que se dice y detectando diferencias entre los resultados esperados y los reales. La labor del Scrum Master es trabajar con el Equipo Scrum y la organización para mejorar la transparencia de los artefactos. Este trabajo usualmente incluye aprendizaje, convicción y cambio. La transparencia no ocurre de la noche a la mañana, sino que es un camino.”

Transparencia pues es la clave para que todos los artefactos descritos anteriormente cumplan su función.

SCRUM – REUNIONES

En este módulo vamos a tratar en detalle los eventos o reuniones que se producen en Scrum. Como se indica en la Guía de Scrum: “En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son bloques de tiempo (time-boxes), de tal modo que todos tienen una duración máxima. Una vez que comienza un Sprint, su duración es fija y no puede acortarse o alargarse. Los demás eventos pueden terminar siempre que se alcance el objetivo del evento, asegurando que se emplee una cantidad apropiada de tiempo sin permitir desperdicio en el proceso.

Además del propio Sprint, que es un contenedor del resto de eventos, cada uno de los eventos de Scrum constituye una oportunidad formal para la inspección y adaptación de algún aspecto.

Estos eventos se diseñaron específicamente para habilitar los pilares vitales de transparencia e inspección. La falta de alguno de estos eventos da como resultado una reducción de la transparencia y constituye una oportunidad perdida de inspección y adaptación.”

Sprint

El corazón de Scrum es el Sprint, es un bloque de tiempo de entre una semana y un mes durante el cual se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable, es decir, que se pudiera utilizar por parte de los usuarios y clientes.

Es más conveniente si la duración de los Sprints es fija a lo largo del tiempo. De esta manera se conseguirá ritmo sostenido. Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint Anterior.

Según la guía de Scrum durante el Sprint:

  • No se realizan cambios que puedan afectar al Objetivo del Sprint (Sprint Goal).
  • Los objetivos de calidad no disminuyen.
  • El alcance puede clarificarse y renegociarse entre el Dueño de Producto y el Equipo de Desarrollo a medida que se va aprendiendo más.

Cada Sprint puede considerarse un proyecto con un horizonte no mayor de un mes. Al igual que los proyectos, los Sprints se usan para lograr algo. Cada Sprint tiene una definición de lo que se construirá, un diseño y un plan flexible que guiará su construcción, el trabajo del equipo y el producto resultante.

Los Sprints habilitan la predictibilidad al asegurar la inspección y adaptación del progreso al menos en cada mes calendario. Los Sprints también limitan el riesgo al costo de un mes calendario.

Reunión de planificación

Tiene una duración de 8 horas para sprints de un mes. Para sprints más cortos la duración es severamente más corta.

  1. Objetivo: El objetivo de la reunión es el de planificar la cantidad de trabajo a la que el equipo se va a comprometer a construir durante el próximo sprint.
  2. Estructura: La reunión de planificación responde a dos preguntas: ¿Qué puede entregarse en el incremento de Sprint que comienza?, ¿Cómo se conseguirá realizar el trabajo necesario para entregar el incremento? Por ello, para responder a estas dos preguntas, esta reunión se compone de dos partes:

Una primera, para tratar de responder a la pregunta ¿Qué puede entregarse en el incremento de Sprint que comienza?, más estratégica donde el dueño del producto explica al equipo de desarrollo las funcionalidades que habría que construir en este sprint.

La segunda parte de esta reunión es más táctica, para responder a la pregunta ¿Cómo se conseguirá realizar el trabajo necesario para entregar el incremento?, donde los miembros del equipo irán desgranando en tareas más técnicas cada una de las historias para posteriormente establecer una conversación sobre la mejor manera de realizarlas y el esfuerzo que será necesario. Para ello, algunos equipos utilizan una técnica llamada de Planning Poker.

Reunión diaria

  1. Objetivo: La comunicación entre los miembros del equipo resulta fundamental, por eso, para conseguir que esta no se pierda y el equipo pueda sincronizarse en su trabajo diario existe esta reunión diaria o daily stand-up en inglés. El objetivo es que el equipo establezca un plan para las próximas 24 horas.
  2. Estructura: Debe realizarse en el mismo lugar y a la misma hora. Todos los miembros del equipo comentan lo que hicieron el día anterior, lo que van a hacer hoy y si tienen algún impedimento o dependencia de algún tipo para conseguirlo. Es una reunión rápida, de apenas 15 minutos por lo que se suele realizar de pie y en frente del tablero de tareas.

Retrospectiva

  1. Objetivo: El objetivo de esta reunión es el de inspeccionar como ha estado el Equipo Scrum y cada una de las personas que lo componen. En la reunión se analizan mediante diferentes técnicas que se hizo bien y que se puede hacer diferente para el próximo sprint. El objetivo es que el equipo reflexione y saque como resultado posibles acciones de mejora. Debe asistir todo el Equipo Scrum (Dueño de Producto, Equipo de Desarrollo y Scrum Master). Es una de las reuniones más importantes ya que es un espacio de reflexión y mejora continua.
  2. Estructura: En el libro Agile Retrospectives se plantea una estructura básica de reunión, aunque esta puede ser variada en función de los objetivos perseguidos en ella. El Scrum Master es el encargado de facilitarla y se recomienda para ello utilizar diferentes técnicas de facilitación y gestión visual como pizarras, post-its o rotuladores.

 

Revisión / Demo

  1. Objetivo: En la guía oficial de Scrum se indica: “Al final del Sprint se lleva a cabo una Revisión de Sprint para inspeccionar el Incremento y adaptar la Lista de Producto si fuese necesario. Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint. Basándose en esto y en cualquier cambio a la Lista de Producto durante el Sprint, los asistentes colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor. Se trata de una reunión informal, no una reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación de información y fomentar la colaboración. Se trata de una reunión restringida a un bloque de tiempo de cuatro horas para Sprints de un mes. Para Sprints más cortos, se reserva un tiempo usualmente más corto. El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito. El Scrum Master enseña a todos a mantener el evento dentro del bloque de tiempo fijado.”
  2. Estructura: Se comentan los elementos sobre los que se han trabajado durante el Sprint. El formato puede ser variado ya que el objetivo es interaccionar con el producto construido.

Refinamiento

  1. Objetivo: De la guía de Scrum se indica que: “El refinamiento (refinement) de la Lista de Producto es el acto de añadir detalle, estimaciones y orden a los elementos de la Lista de Producto. Se trata de un proceso continuo en el cual el Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos de la Lista de Producto. Durante el refinamiento de la Lista de Producto, se examinan y revisan sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente consume no más del 10% de la capacidad del Equipo de Desarrollo. Sin embargo, los elementos de la Lista de Producto pueden actualizarse en cualquier momento por el Dueño de Producto o a criterio suyo.”
  2. Estructura: Es un proceso continuo donde se eligen diferentes elementos de la Pila de Producto para ser revisadas y examinadas en detalle. Hay equipos que realizan este proceso en diferentes sesiones a lo largo del Sprint u otros muchos en una sola reunión de varias horas. Creo que resulta recomendable que como proceso continuo se realice de forma frecuente.

SCRUM – ROLES

Dueño del producto

El dueño de producto es el responsable de mantener la visión del producto que se va a construir maximizando la cantidad de valor entregado al finalizar cada Sprint.

Para mantener esa visión el dueño de producto tiene diferentes interlocutores a los que llamamos Stakeholders o interesados en el proyecto.

Una de las funciones del dueño del producto es la de mantener la pila de producto o conjunto de funcionalidades actualizada y priorizada para que el equipo de construcción sepa en todo momento cuales son los elementos que aportan más valor a los usuarios.

Además, el dueño de producto asistirá a las reuniones de planificación y revisiones del sprint con el equipo de construcción para transmitir de una forma efectiva esta visión de producto a todos los implicados.

Scrum Master

El Scrum Master es un rol con un conjunto de responsabilidades muy variadas.

Realiza labores de facilitador de reuniones, así como acompañante del equipo para ayudarle a resolver las problemáticas que se vaya encontrando a lo largo del proyecto.

El scrum master es el vigía del proceso que vela porque este se lleve a cabo sin olvidar que está pendiente de las personas que conforman el equipo.

También debe tener una visión de la organización y buenas dotes de comunicación y gestión de conflictos que ayuden al equipo a mejorar.

Equipo de construcción

Equipo de construcción son los encargados de construir el producto. Si estamos hablando de equipos de construcción de una appvestará formado por desarrolladores, diseñadores, programadores, testers y cualquier persona que esté implicada de una u otra manera en la construcción del producto.

Las metodologías ágiles nos hablan de que estos equipos deben ser pequeños (de no más de 9 personas), multidisciplinares, es decir, que entre todos los miembros puedan dar servicio al proyecto y auto-organizados, es decir, que ellos mismos decidan la mejor manera de desarrollar su trabajo. Algunas tareas típicas de autoorganización de estos equipos son la de asignación de tareas y estimación, así como el desglose técnico de los requisitos en tareas de bajo nivel.

Diremos que estos equipos son más o menos auto-organizados en función de su nivel para lidiar con todos estos temas.

Clientes / Usuarios

Otro elemento fundamental son los clientes y usuarios. Son todas aquellas personas que de una manera u otra utilizan el resultado de nuestro producto. Si hablamos de aplicaciones de software serán los usuarios y clientes que se conectarán a la aplicación para utilizarla. Debemos distinguir a usuario (cualquier persona que utilice la aplicación) de cliente (aquella persona que realmente paga por ella). Realmente nuestros productos deben estar enfocados a los clientes ya que estos son los que están dispuestos a pagar por usarla.

ESTIMACIÓN ÁGIL

Las estimaciones son ampliamente utilizadas en la mayoría de proyectos tanto tradicionales como ágiles. Es bastante humano necesitar catalogar y relacionar las cosas. Eso nos permite poder tomar decisiones de forma muy sencilla. Por ello, al iniciarse un proyecto suele ser habitual preguntarse cuánto pensamos que nos va llevar. De ahí que se realicen estimaciones iniciales siguiendo diferentes técnicas para tratar de dar respuesta a esta pregunta.

No es malo estimar, al contrario, nos ayuda a hacernos una idea de la magnitud de las cosas y poder tomar decisiones. Lo que sí que debemos tener claro es que las estimaciones son sólo eso, estimaciones, es decir, valores aproximados que nos servirán para tomar decisiones. No son verdades absolutas o compromisos grabados en piedra que suele ser la cara B de las estimaciones.

Al pedir una estimación estamos en el fondo pidiendo un compromiso de la otra persona. Al dar una estimación nos estamos comprometiendo indirectamente. Es ahí donde se tergiversan las cosas y donde pierde el verdadero sentido las estimaciones, como herramienta de ayuda a la toma de decisiones y pasan a ser instrumento para exigir y culpabilizar.

Por eso, utilicémoslas con cabeza y cuidado como herramienta que fomente el dialogo entre todos los intervinientes en un proyecto y no como un instrumento de ataque o defensa. Recordemos que las metodologías ágiles se enmarcan dentro de un contexto de colaboración sobre la negociación por lo que para conseguir que los proyectos sean exitosos resulta de vital importancia no perder esto de vista.

Puntos Historia

Existen diferentes técnicas y herramientas para estimar. También existen diferentes unidades en las que hacerlo. Veamos algunas de estas a continuación.

Días ideales:

Resulta bastante habitual el uso de los días u horas ideales para estimar los proyectos y las tareas. Es relativamente sencillo hacer este tipo de estimaciones y además el ser humano está acostumbrado a pensar en tiempo por lo que resulta bastante natural hacerlo. El principal problema de este enfoque es que es un enfoque subjetivo. Para cada persona en función de su experiencia, su contexto, su forma de ser (optimista, pesimista) puede emitir una estimación totalmente diferente al de otra persona. Además, que la concepción del tiempo en sí misma es algo subjetivo. ¿Cuánto son 4 horas? ¿mucho / poco?.

Además, hay que introducir otra variable en este tipo de estimaciones. Siempre pensamos en tiempo ideal, es decir, tiempo que nos llevaría sin interrupciones ni problemas. Ya sabemos que la realidad es muy diferente y 2 horas de trabajo real pueden haber sido 30 minutos de trabajo efectivo (o a veces menos). Sin embargo, utilizar esta medida de estimación nos lleva al error de pensar que la estimación en horas / días ideales es realmente una estimación de la “realidad”, es decir, que tendemos a pensar que si hemos realizado una estimación de 2 horas para una tarea vamos a tardar realmente 2 horas desde que nos ponemos hasta que la acabamos. Todos sabemos que esto nunca sucede y el tiempo real será muy diferente del estimado.

Estimación relativa, puntos historia:

Para evitar los problemas de las estimaciones en días ideales los enfoques ágiles promueven otro tipo de estimación relativa basada en puntos historia. El punto historia no es más que una medida “inventada” cuyo único objetivo es el de realizar estimaciones basándonos en complejidades y no en tiempos.

De esta manera, tendremos que elegir primero una tarea base sobre la que comparar el resto de tareas. A esta tarea base si es muy sencilla le podemos asignar el valor de 1. En otras ocasiones podemos seleccionar una tarea de complejidad media y asignarle por ejemplo un 3. De esta manera podremos ir comparando.

A continuación, una vez elegida esa tarea base y asignándole unos puntos historia concretos pasamos a seleccionar la siguiente tarea a estimar. Esta tarea la analizaremos desde el punto de vista de la complejidad con respecto a la tarea base. De tal manera que si la tarea base le asignamos un punto historia y la tarea con la que estamos ahora vemos que es bastante más compleja, lo suficiente al menos para que sea el doble, pues le asignaremos dos puntos de historia. Así iremos trabajando sucesivamente el resto de tareas.

El método que utilicemos es indiferente. La mayoría de equipos ágiles cuando están comenzando utilizan el Planning Poker como técnica de estimación, pero hay muchos equipos que según van avanzando evitan esta técnica y simplemente dialogan sobre ello en la reunión de planificación y durante el refinamiento.

Tipos de estimaciones

Para la estimación existen diferentes aproximaciones en función de los equipos. Hay que tener presente que el principal objetivo desde el punto de vista ágil es el de generar conversación entre los miembros del equipo de tal manera que aparezcan los problemas, bloqueos y soluciones de los PBIs del sprint en curso.

Hay equipos que prefieren desgranar los PBIs en tareas técnicas y estimar cada una de estas tareas técnicas para posteriormente sumar cada una de estas estimaciones y dar una estimación global de PBI.

Otros equipos, en cambio, prefieren estimar directamente el PBI, aunque hayan desgranado también en tareas más pequeñas.

Planning Poker

Planning Poker es una técnica para hacer estimaciones en equipo, y llegar al consenso sin perder demasiado tiempo.

El procedimiento es el siguiente:

En la reunión de planificación se le entrega a cada estimador un conjunto completo de tarjetas.

La reunión prosigue de la siguiente manera:

  • El Scrum Master, que no jugará, facilitará la reunión.
  • Se van presentando los distintos elementos a estimar donde se proporciona una breve introducción sobre el elemento. El equipo tiene la oportunidad de hacer preguntas y discutir para aclarar los supuestos y riesgos.
  • Cada persona coloca una tarjeta boca abajo que representa su estimación.
  • Las unidades utilizadas pueden ser variadas y definidas previamente. Pueden ser días de duración, días ideales o puntos de la historia.
  • Durante el debate, los números no debe ser mencionados en absoluto.
  • Todo el mundo muestra sus tarjetas de forma simultánea.
  • A las personas con estimaciones altas y bajas se les da un tiempo para ofrecer su justificación para la estimación y la discusión continúa.
  • Se repite el proceso de cálculo hasta que se alcance un consenso. Se puede utilizar un reloj de arena para asegurar que el debate sea estructurado, el moderador podrá en cualquier punto terminar el reloj y cuando se acaba toda discusión debe cesar y otra ronda de póker se juega.

Las cartas están numeradas de esta forma para explicar el hecho de que, cuanto una estimación es mayor, existe mayor incertidumbre. Así, si un desarrollador quiere jugar un 6 se ve obligado a reconsiderar y aceptar que parte de la incertidumbre percibida no existe y jugar un 5, o aceptar una estimación más conservadora de la incertidumbre y jugar un 8.

KANBAN

A continuación, vamos a ver un poco de historia de donde surge Kanban, cuáles son sus fundamentos y un poquito de contexto histórico.

Lo primero es que debemos distinguir lo que es el método Kanban de un sistema Kanban. De la wikipedia kanban: “También se denomina “sistema de tarjetas”, pues en su implementación más sencilla utiliza tarjetas (kanban) que se pegan en los contenedores de materiales y que se despegan cuando estos contenedores son utilizados, para asegurar la reposición de dichos materiales. Las tarjetas actúan de testigo del proceso de producción.”

El número de tarjetas puestas en marcha se corresponde con la capacidad del sistema. Cada una de estas tarjetas actúa como una señal visual que hace referencia a una unidad de trabajo determinada. Un ejemplo podría ser la construcción de una App o un Ecommerce donde cada uno de los requisitos solicitados por el cliente pueden ser tarjetas kanban que vayan circulando a lo largo del tablero.

Estas tarjetas se pueden representar, por ejemplo, con post-its, en un tablero (tablero Kanban) y ayudarnos así a visualizar el estado de nuestro trabajo.

Por otro lado, tenemos el método Kanban que fue desarrollado por David J. Anderson y presentado inicialmente en 2005. David J. Anderson define el método Kanban como “un método para definir, gestionar y mejorar servicios relacionados con la gestión de conocimiento, tales como servicios profesionales, trabajos o actividades en las que interviene la creatividad y el pensamiento incluyendo en estos tanto el diseño de productos de software como físicos.”

El método Kanban se basa en hacer visible lo que de otro modo es trabajo del conocimiento intangible, para asegurar que el servicio funciona con la cantidad de trabajo correcta distinguiendo entre el trabajo que es requerido y necesitado por el cliente y la capacidad que tiene el servicio de entregar.

Para realizar este trabajo, utilizamos un sistema kanban – un sistema de flujo de entrega que limita la cantidad de trabajo en progreso (WIP, del inglés Work In Progress) utilizando señales visuales.

Para prevenir la cantidad de trabajo máximo que se puede llevar a cabo, Kanban utiliza mecanismos de señalización que representan los límites del trabajo en progreso (WIP, work in progress en inglés), los cuales previenen cuanto de más o de menos trabajo entra en el sistema, de este modo mejora el flujo de valor a los clientes. Las políticas para limitar el WIP crean un sistema de arrastre: el trabajo es “arrastrado” al sistema cuando otro de los trabajos es completado y la capacidad queda disponible, en lugar de “empujar” estos trabajos al sistema cuando hay nuevo trabajo demandado.

Kanban se enfoca en la entrega de servicios de una organización – una o más personas colabora para producir (generalmente intangibles) productos de trabajo.

También puede ser utilizado de manera personal para la gestión de tareas.

Sin duda, lo importante en Kanban es que exista la necesidad de gestionar un flujo continuo de tareas o peticiones si estamos en un entorno organizacional.

Principios y prácticas

El método Kanban está basado en una serie de principios o valores, así como una serie de prácticas de uso.

Valores de Kanban

El Método Kanban está basado fuertemente en una serie de valores. La filosofía principal radica en que es necesario respetar a todas las personas que trabajan en un equipo, departamento u organización. Esto a su vez viene heredado de la filosofía Lean donde el respeto por las personas es uno de sus pilares.

Los valores de Kanban se podrían resumir en una sola palabra, “respeto”. Sin embargo, es importante desgranar esto en una serie de nueve valores (incluyendo respeto) que encapsulan el porqué de la existencia de los principios y las prácticas de Kanban.

Transparencia: Compartir información abiertamente mejora el flujo de valor de negocio. También utilizar un lenguaje claro y directo es parte del valor. La transparencia mejora la confianza que resulta fundamental para la buena consecución de los proyectos (y en la vida en general)

Equilibrio o Balance: Los diferentes aspectos, puntos de vista y capacidades deben ser equilibradas para conseguir efectividad. Algunos aspectos (como demanda y capacidad) causarán colapso si no se encuentran equilibradas por un periodo prolongado.

Colaboración: Según David J. Anderson “El Método Kanban fue formulado para mejorar la manera en que las personas trabajan juntas, por ello, la colaboración está en su corazón.”

Foco en el Cliente: Lo importante es centrarnos en las necesidades de nuestros clientes. Desde Kanban se plantea como la resolución de una serie de demandas de estos clientes. Por tanto, realizar este flujo de la manera más efectiva aportando valor resulta fundamental.

Flujo: Entendemos flujo como la realización continua de una serie de tareas o peticiones. Este flujo puede ser continuo o puntual. Este flujo se denomina de valor ya que al terminar cada tarea estas aportan de una u otra manera valor a los solicitantes.

Liderazgo: David J. Anderson lo define como “La habilidad de inspirar a otros a la acción a través del ejemplo, de las palabras y la reflexión. Muchas organizaciones tienen diferentes grados de jerarquía estructural, pero en Kanban, el liderazgo es necesario a todos los niveles para alcanzar la entrega de valor y la mejora”.

Acuerdo: Según David J. Anderson: “El compromiso de avanzar juntos hacia los objetivos, respetando – y donde sea posible, acomodando – las diferencias de opinión o aproximaciones. Esto no es gestión por consenso sino un co-compromiso dinámico para mejorar.”

Respecto: Valorando, entendiendo y mostrando consideración por las personas. Se puede decir que este principio es la base fundamental del resto.

Por otro lado, David J. Anderson El autor sigue evolucionando el método, orientándolo hacia el uso en grandes organizaciones. En su último libro, Essential Kanban, destacan los siguientes principios fundamentales:

Principios de gestión del cambio:

  • Empieza con lo que tengas en estés momento
  • Acuerda buscar el cambio evolutivo
  • Fomenta el liderazgo en cada nivel de la organización, desde las contribuciones individuales de cada persona hasta las posiciones más senior de la organización.

Principios de entrega de servicio:

  • Entender las necesidades y expectativas de tus clientes y focalizarse en ellas.
  • Gestionar el trabajo: dejar que la gente se auto-organice alrededor de las tareas.
  • Evolucionar las políticas para mejorar los resultados hacia el cliente y del negocio.

Estos principios hacen hincapié en que el foco debe estar en los consumidores del servicio (los clientes) y en el valor que reciben del mismo.

Prácticas

Existen una serie de prácticas por las que empezar a trabajar con Kanban. Estas son:

  1. Empieza donde estés: Cualquier momento en el que te encuentres o se encuentre tu equipo es bueno para empezar. No es necesario ningún requisito previo para comenzar.
  2. Visualiza flujo de trabajo Lo primero que debemos hacer siempre es visualizar los pasos o fases por los que pasan las tarjetas o tareas de mi proceso. Visualizar esa serie de pasos y plasmarlos en el orden en el que se realizan resulta un ejercicio básico y fundamental para entender ese flujo. Si estamos trabajando en equipo, al realizarlo junto a otros miembros nos servirá esta visualización para generar una visión compartida del proceso en cuestión.
  3. Limita el trabajo en progreso.
  4. Mide y gestiona el flujo.
  5. Inspecciona y adapta

Clases de servicio

Las clases de servicio nos indican los tipos diferentes de tareas que vamos a ser capaces de gestionar en nuestro tablero. Tenemos que tener presente que pueden aparecer diferentes tipos de tareas dentro de nuestro tablero. Cada uno de estos tipos de tarea tendrán generalmente una gestión diferente.

Pongamos algunos ejemplos de clases de servicio:

Normal: Es una tarea cotidiana en el tablero. Su tratamiento puede ser priorizarla en función de su urgencia e importancia y se realizará tan pronto como no quede otra más prioritaria dentro del tablero.

Urgente: Son tareas que necesitan ser realizadas lo antes posible. El tratamiento que realizaremos sobre estas tareas puede ser muy variado. Podemos decidir que en el momento que entren este tipo de tareas dejamos de hacer lo que estábamos haciendo y comenzamos con esta tarea más urgente. Otros equipos, sin embargo, pueden decidir ponerse con esta clase de servicio tan pronto acaben lo que están haciendo (o al menos una persona acabe su tarea en curso y pueda comenzar esta urgente.

Fecha fija: Son tipos de tareas que tienen una fecha concreta en la que deben ser terminadas. La acción sobre este tipo de clases de servicio puede ser muy diferente en función del equipo.

Pueden existir muchas más clases de servicio. Lo que debemos tener claro es cuales forman parte de nuestro tablero y como queremos tratarlas cuando aparezcan.

Además, recordamos que Kanban se basa mucho en la transparencia, por tanto, podremos establecer estas políticas de tratamiento de tareas explícitamente en lugares visibles. De esta manera conseguiremos que las personas que conforman el equipo sepan claramente cómo tratar cada una de las clases de servicio.

Ejemplos de uso

Productividad personal

Un ejemplo de uso muy habitual de tableros Kanban es todo lo relacionado con la productividad personal. Hay incluso diferentes libros relacionados con este tema.

A continuación, vemos como podría ser un tablero sencillo

Podemos observar las diferentes columnas:

Tareas pendientes: El conjunto de todo lo que en algún momento debo realizar.

Hoy: Todas las tareas que he seleccionado para hoy.

Esperando: Aquellas tareas que estamos esperando por parte de alguien.

Terminadas esta semana: Todo lo terminado esta semana.

De esta manera podemos llevar una gestión sencilla de lo que tenemos entre manos. El simple hecho de vaciar nuestra cabeza con todo aquello que debemos hacer nos servirá para centrarnos en lo importante y no en retener ese tipo de información.

Debes notar como la columna Hoy y Esperando tienen límites de tareas máximas que se aceptan en esas columnas. De esta manera conseguiremos limitar nuestro trabajo y centrarnos en terminar cosas y no tanto en empezarlas. Recuerda que una de las máximas de la filosofía Lean es: Empieza a terminar y deja de empezar tareas.

Equipos de trabajo

Otro uso muy habitual de uso de tableros Kanban es en equipos que deben dar un determinado servicio. Realmente todos los equipos tienen objetivos, por tanto, el uso de tableros Kanban puede aplicarse a cualquier tipo de equipo.

Podríamos utilizar tableros para equipos de Marketing o ventas, así como para departamentos de Recursos Humanos donde se pretende gestionar procesos de selección como vemos en el ejemplo a continuación:

Podemos observar las diferentes columnas que forman el flujo de selección para este equipo.

CONCLUSIÓN

Incluso en una Agencia Creativa como la nuestra requerimos de procesos para hacer las cosas de una manera eficiente. Para poder cumplir nuestros compromisos necesitamos ejecutar procesos . Esta es la razón por la que lo hacemos bien siempre (No unos dias si y otros no). El resultado de nuestros trabajos no es fruto de la casualidad y la inspiración, para nosotros TIENE MÉTODO. Te animamos a que tú también lo apliques.

En Estrategias y Marketing .com desarrollamos plataformas web responsive, app para negocios y app internas para empresas, gestión de redes sociales, posicionamiento SEO/SEM, diseño publicitario y mantenimiento para herramientas de acciones online y Estrategias de Marketing. Queremos ser tu socio. Somos los adecuados para ayudarte a conseguir tus objetivos.

Añadimos cookies para mejorar tu experiencia como usuario. Leer Política de cookies
SI, ACEPTO