Gestión de proyectos con metodologías ágiles, Apuntes de Fundamentos de Administración y Gestión

¡Descarga Gestión de proyectos con metodologías ágiles y más Apuntes en PDF de Fundamentos de Administración y Gestión solo en Docsity! DHB Gestión de proyectos con metodologías ágiles Material complementario Preparado por: David Hinostroza GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB Contenido 1. Manifiesto ágil ……………………………………………………… 2. Introducción a scrum…….……………………………………….... 3. Artefactos de scrum…….…………………………………………. 4. Reuniones de scrum………………………………………………. 5. Roles de scrum…………….………………………………………. 6. Estimación ágil………..……………………………………………. 7. Kanban………………………………………………………………. Pág. 2 Pág. 3 5 10 20 25 27 31 GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB 2Introducción a scrum Pág. 5 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. Breve historia 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB Introducción a scrum2 Pág. 6 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 (ya sea software o cualquier otro) 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 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 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB 2Introducción a scrum Pág. 7 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB Artefactos de scrum3 Pág. 10 Pila de 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. 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. 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB 3Artefactos de scrum Pág. 11 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 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 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 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB Artefactos de scrum3 Pág. 12 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB 3Artefactos de scrum Pág.15 Nombre: Luis Pérez Registrado: Si Descripción: Luis es gerente de unos grandes almacenes. Es una persona muy dedicada en su trabajo donde hace jornadas de 8am a 8pm. Tiene poco tiempo para ir a comprar por lo que casi siempre busca hacerlo por internet. Luis además es un tipo muy organizado. Maneja habitualmente listas de la compra y suele tener algunos tipos de alimentos que siempre suele comprar. No hay nada como atún de la marca Encarna o los fideos Bonduel. Aficiones: A Luis le gusta principalmente salir a correr. Es por ello que su dieta está basada principalmente en carbohidratos que tiene que comprar regularmente. Además, a este arquetipo podríamos añadirle fotos de cómo podría ser físicamente esta persona o como nos la imaginamos. También podríamos hablar de aficiones, hobbies, etc. El objetivo no es otro que tratar de empatizar aún más con los usuarios para los que estamos construyendo funcionalidad. De esta manera la anterior Historia de Usuario podría quedar utilizando el arquetipo de Luis Pérez: Como Luis Pérez Quiero poder cambiar mi dirección de correo electrónico Para facilitarme que en caso de que quiera introducir otra dirección pueda hacerlo La confirmación que necesita la Historia de usuario suele plasmarse a modo de Criterios de Aceptación. Existe también una plantilla ampliamente utilizada para escribir estos Criterios de Aceptación: Dado <contexto> Cuando <acción> Entonces <resultado> GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB Artefactos de scrum3 Pág. 16 Un ejemplo siguiendo con la Historia de Usuario anterior: Historia de Usuario Como Luis Pérez Quiero poder cambiar mi dirección de correo electrónico Para facilitarme que en caso de que quiera introducir otra dirección pueda hacerlo Criterios de Aceptación: 1. Cambio correcto Dado el email “luis@yo.com” Cuando modifico el email por “luisPerez@yo.com” Entonces el nuevo email es “luisPerez@yo.com” 2. Existencia de @ Dado el email “luis@yo.com” Cuando modifico el email por “luisPerezyo.com” Entonces se muestra el error “Tu email deben contener una @” 3. Existencia de dominio Dado el email “luis@yo.com” Cuando modifico el email por “luisPerezyo.c” Entonces se muestra el error “Tu email no pertenece a un dominio válido” Hemos elegido un caso muy sencillo con poco margen para la duda, pero según se vaya complicando. Podemos ver como los criterios de aceptación representan escenarios posibles dentro del cambio de email que le servirá a los desarrolladores para implementar estas funcionalidades. El criterio de aceptación nos debe servir como guía para revisar la Historia de Usuario en la Reunión de revisión o demo al final del Sprint. 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB 3Artefactos de scrum Pág.17 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 de Desarrollo 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB Reuniones de scrum4 Pág. 20 En la Guía de Scrum se indica: “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; y,  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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB 4Reuniones de scrum Pág.21 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. 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. 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB Reuniones de scrum4 Pág. 22 Reunión diaria 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. 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 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. 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB 5Roles de scrum Pág.25 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. En la sección de recursos adicionales puedes encontrar un artículo con las 42 tareas que debería realizar un Scrum Master. Equipo de construcción Equipo de construcción son los encargados de construir el producto. Si estamos hablando de equipos de construcción de software estará formado por desarrolladores, diseñadores, arquitectos, testers y cualquier persona que esté implicada de una u otra manera en la construcción del producto. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB Roles de scrum5 Pág. 26 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 auto-organizació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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB 6Estimación ágil Pág.27 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB Estimación ágil6 Pág. 30  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 repita 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB 7Kanban Pág.31 Breve historia Que es Kanban 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 software 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB Estimación ágil6 Pág. 32 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB 7Kanban Pág.35 Prácticas Bueno todo esto está muy bien, pero ¿cómo empiezo a trabajar con Kanban? Existen una serie de prácticas por las que empezar a trabajar con Kanban. Estas son:  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.  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.  Limita el trabajo en progreso Mide y gestiona el flujo  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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB Estimación ágil6 Pág. 36 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. Puedes ver en los recursos adicionales alguna referencia. 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. GESTIÓN DE PROYECTOS CON METODOLOGÍAS ÁGILES DHB 7Kanban Pág.37 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.