SCRUM: La historia de un equipo ágil

Scrum es una de las técnicas ágiles más utilizadas. No se trata de la codificación. En cambio, se centra en la organización y gestión de proyectos. Si tienes un momento, permíteme contarte sobre el equipo con el que trabajo y cómo adoptamos las técnicas Scrum.

Una pequeña historia

Las raíces de Scrum en realidad se extienden más allá de la era ágil.

Las raíces de Scrum en realidad se extienden más allá de la era ágil. La primera mención de esta técnica se puede encontrar en 1986, por Hirotaka Takeuchi e Ikujiro Nonaka, para el desarrollo de productos comerciales. El primer artículo oficial que define Scrum, escrito por Jeff Sutherland y Ken Schwaber, se presentó en 1995.

La popularidad de Scrum creció poco después de la publicación del Manifiesto Ágil en 2001, así como del libro Desarrollo ágil de Software con Scrum, coautor de Ken Schwaber y Mike Beedle.

Algunos hechos

Scrum define un conjunto de recomendaciones, que los equipos deben seguir. También define varios actores, o roles, si prefiere esa terminología, junto con un proceso iterativo de producción y planificación periódica. Hay varias herramientas, que se adaptan al proceso Scrum. Me referiré a algunos en este artículo, pero las herramientas más poderosas son la pizarra y las notas adhesivas.

No hay, y nunca habrá, una lista de "Mejores Prácticas de Scrum", porque el contexto del equipo y del proyecto supera todas las demás consideraciones. - Mike Cohn

Los roles

Todo comienza con el cerdo y el pollo. El pollo le pregunta al cerdo si está interesado en abrir conjuntamente un restaurante. El pollo dice que podrían llamarlo "jamón y huevos". El cerdo responde: "No, gracias. Estaría comprometido, ¡pero solo estarías involucrado!"

¡Eso es Scrum! Especifica un conjunto concreto de roles, que se dividen en dos grupos:

• Committed: Aquellos directamente responsables de la producción y entrega del producto final. Estas funciones incluyen el equipo en su conjunto, sus miembros, el scrum master y el propietario del producto.
• Involved: Representa a las otras personas interesadas en el proyecto, pero que no toman parte activa o directa en los procesos de producción y entrega. Estos roles suelen ser partes interesadas y gestores.

Así es como empezamos

Todo depende de la dedicación y la buena voluntad. Si deseas que tu equipo sea eficiente, productivo y entregue a tiempo, necesitas que alguien adopte alguna forma de técnicas ágiles. Scrum puede o no ser ideal para ti, pero seguramente es uno de los mejores lugares para comenzar. Encuentra a alguien en tu equipo que esté dispuesto a ayudar a los demás, o tú mismo, puedes asumir la responsabilidad de presentar Scrum.

Puedes preguntar por qué debería importarte cómo hace Scrum otro equipo, como el mío. Deberías preocuparte porque todos aprendemos cómo hacer Scrum mejor al escuchar historias de cómo lo han hecho otros, especialmente aquellos que lo están haciendo bien. - Mike Cohn

El talentoso equipo con el que trabajo ya sabía mucho sobre 'Agile'. Cambiamos del desarrollo de Waterfall a un proceso más ágil y lanzamos con bastante frecuencia. Logramos lanzar con éxito cada tres a seis meses, con un número decente de errores después de cada lanzamiento.

Pero, aún así, estábamos lejos de lo que podemos lograr hoy. Nos perdimos el proceso, o las reglas, que nos obligarían a cambiar nuestra perspectiva sobre el producto y el proceso. Ese fue el momento en que nuestro gerente de equipo nos presentó a Scrum, un término que, en ese momento, nunca habíamos escuchado.

Esta persona tomó el papel de Scrum Master.

El Scrum Master

Scrum Master es fácilmente uno de los roles más importantes. Esta persona es responsable de crear un puente entre el propietario del producto Product Owner (definido a continuación) y el equipo Team (también se define más adelante). Esta persona generalmente posee un fuerte conocimiento técnico y participa activamente en el proceso de desarrollo. Él o ella también se comunica con el Propietario del producto sobre las Historias de usuario 'Stories' y cómo organizar el Backlog.

El Scrum Master coordina los procesos de desarrollo, pero no realiza una microgestión (el equipo es autoorganizado). Sin embargo, al comienzo del proceso, el Scrum Master podría administrar la parte del equipo para micro-manejo, a fin de mejorar la interacción de su equipo y las técnicas de auto-organización.

Los Scrum Masters tienen más responsabilidades, y las cubriré mientras discutimos este proceso.

Introduciendo el término "Sprint"

Personalmente, no tenemos ningún problema con los lanzamientos de tres a seis meses, pero originalmente no podía imaginar un programa de lanzamientos tan frecuente. Pensé que era demasiado rápido y no nos dio el tiempo necesario para integrar y depurar nuestros productos. Pero entonces, nuestro Scrum Master nos presentó el término, sprint.

Sprint: Una unidad básica de desarrollo en Scrum. Puede tomar entre una semana y un mes, y el producto se encuentra en un estado estable después de cada sprint.

¡Eso suena indignante! Estable todas las semanas > ¡Imposible! Pero, en realidad, es bastante posible. Primero, redujimos nuestros ciclos de producción de tres meses a un mes y medio y, finalmente, a un solo mes. Todo esto se logró sin cambiar nuestro estilo. Sin embargo, deberás introducir algunas reglas para un sprint de menos de treinta días. Aquí no hay reglas mágicas; Las reglas deben beneficiar a tu proyecto.

Si recuerdo correctamente, el primer cambio significativo en nuestro proceso de desarrollo se produjo con la introducción de la planificación del sprint.

Planificación del Sprint

Esta es una de las varias reuniones que recomienda Scrum. Antes de cada nuevo sprint, el equipo, el propietario del producto y el Scrum Master planifican el próximo sprint. Esta reunión puede durar un día entero, pero es probable que los sprints más cortos solo necesiten un par de horas.

Nuestro proceso consiste principalmente en revisar la acumulación de productos y decidir sobre un subconjunto de historias de usuario que se incluirán en el próximo sprint. Estas decisiones se toman mediante negociaciones directas entre el equipo, representado por el scrum master y el propietario del producto.

El propietario del producto o Product Owner

Establecer la dirección de un producto adivinando qué característica pequeña proporcionará el mayor valor puede ser la tarea más difícil.

Esta persona es responsable de definir las Historias de usuario y de mantener el Product Backlog. Él o ella también es un puente entre el equipo y la gerencia superior. El propietario del producto evalúa las solicitudes de las partes interesadas, la administración superior, los usuarios y otros comentarios (como informes de errores, encuestas de usuarios, etc.).

Él o ella prioriza este retraso, proporcionando el máximo valor a los interesados en el menor tiempo posible. El propietario del producto logra esto al planificar las historias de usuario más valiosas que se pueden completar de manera oportuna. Esto puede sonar sofisticado, ¡lo es! de hecho, establecer la dirección de un producto adivinando qué característica pequeña proporcionará el mayor valor puede ser la tarea más difícil de todo el proceso. Por otro lado, a veces es bastante fácil. Puedes tener mil usuarios que solicitan una característica específica. En estos casos, la elección correcta es obvia.

Si esos usuarios representan una gran parte de tu base de usuarios, siempre que esa característica específica aumente la lealtad.

Pero una vez más, esta es una elección difícil. ¿Qué pasaría si pudieras aumentar tu base de usuarios en un 100% implementando una función diferente? Por lo tanto, puedes aumentar la lealtad de tus usuarios actuales o aumentar la base de usuarios. ¿Cuál es la elección correcta? Todo depende de la dirección actual del negocio, y el propietario del producto debe decidir dónde llevar el producto.

En la empresa para la que trabajo, estas decisiones se propagan al equipo. No es un requisito del proceso Scrum, pero es especialmente útil con equipos nuevos. El intercambio de información ayuda a que todos comprendan por qué se toman algunas decisiones y por qué las características aparentemente obvias pueden retrasarse o eliminarse.

El tablero de planeación

Recuerdo la mañana en que sucedió: llegué a la oficina, solo para encontrar a nuestro Scrum Master preparando un tablero de planificación improvisado con papel A4 y cinta transparente. No tenía idea de lo que estaba haciendo. Como todas las mañanas, preparé una taza de café y esperé a ver.

Al terminar, se colocó una pizarra blanca en la pared. Tenía varias columnas, y se transformó en una forma rectangular. Varias notas adhesivas de colores salpicaban el "tablero". Eso fue hace dos años.

El tablero ahora se adapta al Proceso de Desarrollo Lean que usamos hoy. Recuerda, Agile tiene que ver con cambiar y adaptarse al cambio. Nunca sigas ciegamente las reglas.

Entonces, ¿qué hay en ese tablero?

Columnas para el proceso de desarrollo

Hay cuatro columnas principales:

• Backlog de lanzamiento: Donde residen todas las historias para el lanzamiento actual. Sí, el producto está listo para su lanzamiento después de cada sprint, pero eso no significa necesariamente que realmente lo liberemos. Normalmente tenemos sprints de cinco días.
• Sprint Backlog: Cuando planificamos, negociamos lo que el propietario del producto quiere completar en el sprint. ¿Cómo decidimos lo que podemos y no podemos completar? Estimando la dificultad de cada historia (ver más abajo - Estimación de historias). El resultado final es un conjunto de historias movidas desde el retraso de la publicación al registro de sprint. El equipo se concentra en terminar esas historias en la próxima semana.
• Trabajando en - Esta es simple. Cuando los miembros del equipo toman una historia, la agregan a esta columna para mostrar a todos en qué están trabajando. Esto es para el control de los empleados, sino para comunicarse con los miembros del equipo. Todos deben saber siempre en qué están trabajando sus compañeros. En la imagen de arriba, los marcadores pequeños pegados en las notas adhesivas contienen los nombres de los miembros de mi equipo.
• Hecho - ¡Completa todas las cosas! Sí, aquí es donde van las historias completas. Sin embargo, es importante definir "lo que se hace". Al final de un sprint ideal, todas las historias y errores de la acumulación de sprint deben estar dentro de esta columna.

La definición de 'Hecho'

¿Qué es 'hecho'? ¿Cuándo puedes decir con confianza que una historia está completa? ¿Cómo lo sabes?

"Hecho" debe definirse de manera clara y precisa, para que todos sepan cuándo se completa una historia. La definición "hecho" puede diferir de un equipo a otro, e incluso de un proyecto a otro. No hay una regla exacta. Recomiendo que plantees este problema en una reunión de equipo y decidas qué determina una historia completa. Aquí hay algunas ideas que tal vez quieras considerar:

• Crear un diseño minimalista.
• Crear un boceto de GUI.
• Usar TDD o asegurarse de que hay pruebas unitarias.
• Escribir el código.
• Dejar que otro miembro del equipo pruebe tu historia manualmente.
• Todo el sistema se puede construir y compilar con el nuevo código.
• Las pruebas funcionales o de aceptación pasan como se espera, una vez que el nuevo código se integra en el sistema.

Existen múltiples ideas que se pueden incluir en la definición de 'hecho'. Toma lo que consideres necesario para tu equipo y úsalo. Además, no olvides adaptar esta definición a lo largo del tiempo. Si observas que tu definición se está volviendo obsoleta, puedes considerar eliminar algunos elementos o agregar ideas necesarias, pero frecuentemente olvidadas.

En la imagen de arriba, las notas adhesivas verdes describen lo que consideramos que se debe hacer, para cada parte del proceso.

Poblando el tablero

Esa fue la pregunta que nos hicimos. Hasta este punto, no usamos notas adhesivas para la planificación. Utilizamos software para realizar un seguimiento de las historias de usuario y los errores, pero, aparte de eso, no utilizamos nada. Después del almuerzo, nuestro scrum master nos presentó una montaña de notas adhesivas de colores. Después de preparar una docena de notas, nos las explicó.

Las historias de usuario

Una historia de usuario es una definición corta en una oración de una característica o funcionalidad.

Estas representan las principales características que queremos implementar. Una historia de usuario es una definición corta en una oración de una característica o funcionalidad. Se conoce como una historia de usuario, porque se presenta desde la perspectiva de un usuario. Naturalmente, el término usuario es la persona que utiliza nuestra aplicación. Esta persona puede pertenecer a una o más categorías diferentes: administrador del sistema, usuario restringido, administrador, etc.

Un ejemplo de tal historia puede sonar algo como: "Como usuario, quiero compartir una carpeta con mis compañeros de equipo".

En ese momento, no teníamos un propietario del producto definido, por lo que nuestro scrum master inventó estas historias. Esto es aceptable al principio, pero te recomiendo que separes estos dos roles. De lo contrario, ¿cómo puede el scrum master negociar la acumulación de sprint con el propietario del producto?

Puedes pensar: "¿Por qué negociar? ¿No es mejor para una sola persona decidir qué hacer y cuándo?" No exactamente. Los dos roles serían influenciados por las opiniones de una sola persona del sistema o proyecto. Dos personas, por otro lado, tienen una mejor oportunidad de proporcionar un camino más objetivo para el equipo, asegurando que se logre la meta final (mejor software valioso).

El propietario del producto debe definir historias de usuario; el equipo debe negociar su ejecución y el scrum master los representa.

Las historias de usuario definen todo lo nuevo que se necesita hacer; están representados por notas adhesivas amarillas en nuestro tablero.

Bugs, Bugs, Bugs

El seguimiento de tus errores es increíblemente importante.

También listamos errores en el tablero. ¿Ves esas notas adhesivas rojas? Esos son los errores que debemos corregir para la próxima versión.

Diferentes equipos tratan a los bugs (errores) de diferentes maneras. Nuestro equipo mezcla los errores con las historias, pero siempre comenzamos un sprint al corregirlos.

Sé de otros equipos que acumulan errores durante un período de tres sprints, y pasan cada cuarto sprint corrigiéndolos. Otros dividen los sprints en 25/75 por errores/historias. Además, otros equipos pueden trabajar en las historias por la mañana y los bugs después del almuerzo; simplemente depende de la empresa.

Depende de ti encontrar la mejor solución para tu equipo y, por supuesto, realizar un seguimiento de los errores. Escríbelas en notas adhesivas para poder rastrear los problemas de tu sistema y las soluciones para esos problemas. El seguimiento de tus errores es increíblemente importante.

Tareas o Sub-Historias

Las tareas se escriben como oraciones simples desde el punto de vista del desarrollador.

Idealmente, cada historia debe ser lo suficientemente corta como para completarse con relativa facilidad, pero dividir las historias en otras historias puede resultar difícil. Algunos proyectos simplemente no pueden permitirse esta posibilidad. Aún así, encontrarás historias grandes en las que varios miembros del equipo pueden trabajar. Es importante dividir grandes cantidades de trabajo en piezas más pequeñas y fáciles de manejar.

Un enfoque divide las grandes historias en Tareas. Las tareas se escriben como oraciones simples desde el punto de vista del desarrollador. Por ejemplo, la historia anterior de uso compartido de carpetas se puede dividir en varias tareas, tales como: "Crear IU para compartir", "Implementar un mecanismo de uso compartido público", "Implementar la funcionalidad de control de acceso", "Agregar casillas de verificación de control de acceso a la IU" y así. El punto es que tienes que pensar más en la historia cada vez que la divides en tareas más pequeñas. Tu equipo tendrá mucho mayor control sobre una historia, cuando analices cada pieza.

Usamos notas adhesivas de color azul claro para tareas en nuestro tablero. Busca en la última columna (la columna "Hecho") y encontrarás nuestras tareas en las notas adhesivas de la historia del usuario. Esa historia particular fue dividida en alrededor de cuatro tareas.

Tareas Técnicas

Ciertas actividades deben completarse para terminar una tarea, historia o el sprint como un todo. Estas tareas suelen estar relacionadas con la infraestructura, pero es posible que las tareas requieran cambios en el sistema. Este proceso puede o no ser parte de una historia. Por ejemplo, puedes encontrar que se debe instalar una aplicación de terceros para implementar la capacidad de uso compartido de la aplicación. ¿Es esta parte de nuestra historia de usuario? Posiblemente, pero tal vez no.

Determinamos que estas tareas deben separarse de la historia real. Esto nos ayudó a rastrear mejor estas tareas adicionales. En nuestro tablero, puedes encontrar estas tareas en notas adhesivas verdes. Hay uno en el registro de sprint, y unos tres en las pruebas.

El Backlog Técnico

Para un equipo joven con poca experiencia con Agile y Scrum, es útil resaltar estas tareas con un mini-backlog.

Este trabajo acumulado es para tareas de infraestructura, como la actualización del sistema de prueba automatizada, la configuración de un nuevo servidor y otras cosas que facilitan nuestro trabajo de desarrollo diario. Estas son cosas que deben completarse en algún momento, pero que no están directamente relacionadas con el desarrollo.

No tienes que colocar estos elementos en un registro separado. De hecho, sé de equipos que no los separan. Nuestro equipo eliminó nuestro atraso técnico hace unos meses; decidimos que las tareas de infraestructura son tan importantes como otras tareas. Sin embargo, para un equipo joven con poca experiencia en Agile y Scrum, es útil resaltar estas tareas con un mini-backlog. Por lo tanto, te recomiendo que lo pruebes. Puede funcionar para ti, y, de no ser así, simplemente coloca Tareas de infraestructura en tu tablero de planificación, posiblemente con un color diferente.

El gran desafío: la estimación

Durante una reunión de planificación, decidimos qué historias de usuario y errores del backlog (o la publicación del backlog en nuestro caso) se incluirán en el próximo sprint. Esto puede parecer simple, pero, en realidad, es bastante complicado.

El propietario del producto se presenta con un conjunto de historias para trabajar. Esta lista normalmente contiene más trabajo del que se puede lograr en el sprint. El scrum master, junto con el equipo, tiene que convencer al propietario del producto de lo que se puede hacer durante un sprint. Con el tiempo, este proceso se vuelve más fácil, ya que el propietario del producto aprende la velocidad aproximada del equipo. Entonces, nuevamente, el equipo puede ser más productivo con cada sprint, permitiendo así que se terminen más historias. ¡El truco es tener un equipo que realmente quiera superar las expectativas!

Ahora, el propietario del producto quiere completar más historias de las que podemos hacer en un sprint. Necesitamos estimar la cantidad de trabajo que podemos hacer en relación con las historias enviadas por el propietario del producto, y podemos hacerlo de varias maneras.

Puntos de historia

Los Puntos de historia son uno de los métodos más comunes para estimar historias, errores o tareas. No son necesariamente el mejor enfoque, pero aún así son una buena manera de comenzar.

Entonces, ¿qué es un punto de historia? Al comienzo del proceso, el equipo busca la historia más simple que puede encontrar en la pizarra. No importa lo difícil que sea, o el tiempo que demore en completarse. Cuando encuentran esa historia, la establecen como la historia teniendo un punto de referencia. En algunos proyectos, tal historia puede ser tan simple como arreglar elementos de la interfaz de usuario en diez minutos; mientras que, la historia más simple para sistemas más complejos puede tomar dos horas para que la completen tres personas. Ahora que tienes una línea de base, evalúa las otras historias y los errores y asígnales puntos.

Esto puede ser más difícil de lo que parece, y existen varias técnicas de puntos para ayudar a estimar historias. Aquí hay dos de ellos:

• Usa los números de Fobinacci - 1,2,3,5,8 (y quizás 13, pero una historia de 13 tamaños me huele demasiado grande).
• Usa potencias de 2 - 1,2,4,8 (y quizás 16, pero este número debe evitarse).

Eres libre de elegir lo que te resulte más cómodo. ¡Se ágil! Tal vez desees utilizar incrementos de dos puntos, porque tus tareas se estiman mejor de esa manera. ¡Bravo por ti!

Semáforos

Los números son geniales, y mucha gente técnica los ama. Sin embargo, puedes encontrar que, en algún momento, los programadores comienzan a asociar los puntos de historia con el tiempo. Pensarán: "Me lleva dos días hacer esto. Vamos a darle cinco puntos". Esto está mal. Las estimaciones van de mal en peor cuando esto sucede. Los puntos de la historia nunca deben relacionarse con el tiempo.

El uso de colores de semáforo puede ayudar a aliviar este problema. En lugar de asignar números a las historias, el equipo puede asociar esas historias con colores. Nuestro equipo hizo este cambio hace unos meses y ayudó mucho a cambiar nuestro punto de vista.

Naturalmente, cada color tiene un significado diferente.

• Verde significa una tarea fácil que se puede completar en el próximo sprint.
• Amarillo se refiere a una tarea más difícil, una que requiere más esfuerzo de parte de varios miembros del equipo. También tiene una alta probabilidad de completarse en el próximo sprint.
• Las etiquetas rojas se asignan a las historias, que son extremadamente difíciles y no se pueden terminar en un solo sprint. Debería haber pocas o ninguna de estas historias, pero si adoptas sprints de una semana, cinco días es poco tiempo.

Tallas de camiseta

Los números pueden ser feos para ti, los colores son demasiado artísticos. ¡Es hora de tallas de camiseta! Esta técnica sugiere renunciar a comparar la complejidad de la historia con el tiempo de finalización. En pocas palabras, en lugar de números, usas tamaños como S, M, L, XL, XXL para tus historias.

Personalmente, nunca me sentí atraído por este tipo de estimación, pero algunos creen que es la mejor manera de hacerlo. Pruébalo, si te sientes cómodo con la idea.

El propietario del producto, las partes interesadas y los gerentes deben saber qué esperar del final de un sprint. Deben decidir si las historias en las que se trabajó deben publicarse y deben saber cuándo están listas las características. No es una buena solución lanzar todas las funciones nuevas al final del ciclo de desarrollo de un producto; liberar las funciones más valiosas de manera más frecuente es una forma considerablemente mejor de hacerlo. Para lograr esto, deben saber qué estará disponible en el corto plazo, y su información debe provenir del equipo. Por lo tanto, el equipo debe estimar, de la mejor manera posible, el trabajo que pueden hacer en un sprint.

Medición de la velocidad de desarrollo

¿Quieres ver qué tan bien te desempeñas en el sprint actual? Un método de uso frecuente es el gráfico de quemado:

En esta tabla, tenemos un sprint de cinco días y asumimos que podríamos completar diez puntos en el sprint. Cada punto de valor representa los puntos de historia restantes al final de cada día. La línea verde revela el camino ideal: unos dos puntos constantes por día. La línea roja muestra nuestro rendimiento real, o la verdadera velocidad de desarrollo.

No está en la imagen del tablero de planificación, pero mi equipo solía tener una hoja de papel A4 colocada sobre el tablero de planificación, con la tabla de quemados para cada sprint. Al final de cada día, uno de los miembros del equipo era responsable de calcular los puntos completados para ese día. Es simple: si los programadores mueven las historias de columna a columna a medida que trabajan, es fácil encontrar las historias pendientes que quedan.

No hay historias a medio hacer. Si se hace una historia, se hace. Si no está completo, entonces no se cuenta en el gráfico de quemado.

Por supuesto, fallarás - ¡GRAN TIEMPO - en la estimación! Esto es especialmente cierto al principio. Lamentablemente, no hay forma de evitar esto. No hay forma de saber cuántos puntos puedes entregar. Tu primer gráfico puede verse muy bien como:

Nuestro primer gráfico seguramente se parecía a eso. Creo que ni siquiera completamos la mitad de lo que nos comprometimos. ¿Por qué? Bueno, porque la estimación es difícil. Independientemente de lo que hagas o de lo bueno que seas, cuando alguien te pregunte qué tan complicado es algo que nunca has hecho antes, tendrás dificultades para proporcionar una estimación precisa. ¡No te asustes! Haz tu mejor esfuerzo. Con el tiempo, estas cosas se vuelven más fáciles. Es posible que puedas estimar con un 70% de precisión en algún momento para los sprints cortos. Si los sprints son más largos, tu precisión probablemente será menor, porque habrá más historias para estimar y más variables que pueden salir mal.

Cuando esto sucede, te ajustas. Para el próximo sprint, toma cuatro puntos. Me gusta esto:

Esto es malo otra vez. Eras demasiado conservador, y terminaste temprano. Es una reacción natural para que el equipo se ajuste, basado en el fracaso de la estimación previa. Aún así, esto es un fracaso de nuevo, pero en el otro lado de la carretera.

¿El problema? ¿Qué haces después de que hayas terminado lo que estabas planeando? ¿Otra historia? ¿Cómo pones eso en la tabla? No se puede volver a dibujar la línea original.

Cuando se trabaja con tablas de reducción, se recomienda hacer siempre un promedio de las últimas 3-5 tablas, para especificar los puntos para el próximo sprint. Por supuesto, al principio, no tienes esa información disponible, por lo que no serás tan preciso como en el futuro. Esta bien.

Después de algún tiempo, tus gráficos comenzarán a parecerse más y más al primer ejemplo. La mayoría de las veces, terminarás todas las historias y tendrás una velocidad sostenida.

¿Velocidad?

Este término se refiere a tu velocidad de desarrollo. Se relaciona con cuánto puedes hacer en un sprint. Uno de los conceptos más importantes en Agile es tener una velocidad constante. Haz que el equipo entregue a un ritmo constante. Con la gestión tradicional de proyectos, la velocidad disminuye a medida que el proyecto envejece. La complejidad y la rigidez reducen la velocidad de desarrollo.

Metodologías y técnicas ágiles destinadas a mantener un ritmo constante. Entregan rápido ahora, y entregan más rápido más tarde. ¿Cómo lo hicieron? Scrum es uno de los elementos del puzzle. Otras piezas importantes incluyen las técnicas que los programadores pueden utilizar para mejorar su código y proceso de desarrollo. Por ejemplo, XP (eXtreme Programming), Pair Programming, TDD (Test Driven Development), etc. Todos estos, juntos, pueden hacer que un equipo sea realmente genial.

Así que medimos esta velocidad, pero ¿qué hacemos realmente con ella?

Usa la velocidad para saber lo que tu equipo puede hacer. Usa la velocidad para saber qué esperar. Usa la velocidad para hacer que tu equipo quiera más y sea mejor. Nunca uses la velocidad para juzgar a tu equipo o evaluar la productividad de tus programadores.

Siempre mira hacia atrás y mejora

Después de los primeros sprints, nuestro scrum master reunió a todo el equipo. Comenzó a preguntarnos sobre las cosas buenas y malas de la semana pasada. Esto puede ser incómodo al principio, pero aún así es increíblemente importante. Describir lo que sintió que salió mal la semana pasada creará conciencia. Y, por supuesto, también es útil resaltar lo que salió bien.

Estas reuniones suelen denominarse retrospectivas. Ofrecen el alcance para resaltar lo que era bueno y lo que salió mal. Aquí hay algunos ejemplos de mis propias retrospectivas.

Cosas malas

• Los miembros del equipo estaban peleando demasiado
• El miembro del equipo X o Y no colaboró cuando se programó el par
• Perdimos demasiado tiempo con cosas pequeñas, como X o Y
• No hicimos un par de programas todo el tiempo.
• No escribimos pruebas unitarias para el módulo M

Cuando discutas problemas, trata de dejar de lado tus sentimientos personales; habla sobre lo que te molesta. Esta es la única forma en que el equipo puede resolver el problema. Lo más importante es proponer inmediatamente una solución para cada problema. No dejes simplemente que la lista se escriba y te olvides de ella; quédate unos minutos y pide a todo el equipo que piense qué se puede hacer para evitarlos la próxima semana.

Cosas buenas

• Terminamos a tiempo
• Pudimos hablar sin pelear.
• Algunos de nosotros nos volvimos más receptivos a las sugerencias e ideas.
• Escribimos todo el código con TDD.

Nuevamente, resalta tantas cosas buenas como sea posible, especialmente al principio o con programadores junior. Por ejemplo, tener todo el código escrito con TDD puede ser un gran logro para un equipo junior. Haz que se sientan realmente bien al respecto, haz que quieran hacerlo más y más. Lo mismo es cierto para un equipo senior; simplemente tienen otras cosas para resaltar (TDD se hace por reflejo).

Quiero ver lo que hiciste este Sprint

La demo es para mostrar a los interesados (y al propietario del producto) el progreso del proyecto.

Este encabezado viene de las palabras de mi scrum master. En ese punto, él también era el dueño del producto. Antes del final de un sprint, nos pedía que le presentáramos lo que hemos logrado. Preparamos una demo, o un ejemplo de trabajo en un entorno controlado.

Scrum propone estas demostraciones al final de cada sprint. Esto debe hacerse antes de la reunión retrospectiva que discutimos anteriormente. El equipo debe preparar un entorno especial y asegurarse de que el producto sea capaz de mostrar las características realizadas en este sprint. La demostración es para mostrar a los interesados (y al propietario del producto) el progreso del proyecto.

Puedes preguntarte por qué mencioné un entorno controlado, cuando nuestro producto debería estar listo para la producción al final de cada sprint. Sí, el producto debería estar lo más cerca posible para la producción, pero eso no significa que la función, en sí misma, esté lista. A menudo, habrá características que son demasiado grandes para caber dentro de un solo sprint. El producto permanecerá estable, pero la función no estará lista. Cuando las partes interesadas ven la demostración, quieren revisar la función y lo que puede hacer. En muchos casos, para mostrar algunas funcionalidades de las funciones sin terminar, primero se deben preparar entornos especiales.

Además, en función de estas demostraciones, el propietario del producto puede determinar que una característica más grande es lo suficientemente buena, y una nueva versión del producto debe publicarse y enviarse a los usuarios. La mayoría de las veces, incluso si una función no está del todo completa, una versión ayudará al proyecto a obtener valiosos comentarios de los usuarios y concentrará la finalización de la función de manera que satisfaga a la mayor cantidad de usuarios posible.

Bueno, esto suena bastante simple. Eres un equipo ágil, mantienes tus pruebas siempre en verde y tu producto se encuentra en un estado estable. ¿Qué tan difícil puede ser preparar una demo rápida? ¡Es más difícil de lo que piensas!

Nuestro equipo necesitaba, si recuerdo correctamente, más de cinco intentos antes de que pudiéramos preparar correctamente la demo. Por suerte para nosotros, ¡las partes interesadas no se incluyeron en estas primeras demostraciones fallidas!

Aún así, necesitamos más orientación

En estas reuniones, cada miembro del equipo debe responder a tres preguntas.

Fue el momento en que nuestro scrum master propuso hacer una reunión cada día. ¡Sí! Todos los días, todas las mañanas, ¡a una hora exacta!

Considero que esto es algo muy bueno para los nuevos equipos, para las personas que aún no se sienten cómodas entre sí o con el proyecto. Estas reuniones diarias, llamadas Daily Scrum, se mantienen con el equipo, a una hora específica todos los días. Esto debe mantenerse antes de que se realice cualquier trabajo para el día correspondiente. En mi equipo, establecimos la hora a las 10 de la mañana cada mañana, lo que fue difícil de hacer. Sin embargo, fue la decisión correcta.

El scrum diario es una reunión breve y simple (no más de quince minutos). El objetivo es ayudar a los miembros del equipo a ver quién está haciendo qué, y determinar dónde están los problemas y los cuellos de botella en el desarrollo del proyecto.

En estas reuniones, cada miembro del equipo debe responder a tres preguntas:

• ¿Qué hiciste ayer? - Se espera una respuesta corta - max 2-3 oraciones.
• ¿Qué planeas hacer hoy? - El mismo tipo de respuesta corta, como "Trabajaré en esta historia hoy".
• ¿Hay algún problema con tu proceso? Si es así, ¿qué? ¿Se pueden resolver rápidamente? Esta debería ser una respuesta que resalte los problemas y las soluciones, si se conoce. No se deben tomar discusiones detalladas, mientras que esta reunión continúa. El scrum master debe tomar nota del problema y trabajar para resolverlo junto con el equipo, después de que se levante la sesión.

Resolver los problemas e impedimentos en el camino de los desarrolladores debe ser una alta prioridad para el equipo, para que puedan continuar con su desarrollo tan pronto como sea posible. A menudo, la persona que tuvo el problema es capaz de resolverlo de manera oportuna. Otras veces, él o ella requiere la ayuda de un compañero de equipo. Y otras veces, el problema puede ser tan serio que el equipo tendrá que detener el desarrollo y concentrarse exclusivamente en resolver lo que les impide continuar con su trabajo.

Recuerdo que mi equipo se encontró con estos enormes bloques de carreteras en varias ocasiones. Hubo tareas e historias, que parecían ser bastante obvias en el primer sitio, pero, después de que un par o un solo programador tuvieron la oportunidad de investigar el problema, lo obvio se volvió confuso e incorrecto. Descubrimos varias veces que una biblioteca de terceros no podía proporcionarnos la funcionalidad necesaria y terminamos concentrando todos nuestros esfuerzos en encontrar otra biblioteca más capaz, o incluso implementando una solución nosotros mismos.

La mayoría de nuestro proyecto está escrito en PHP. En algún momento, tuvimos que conectar nuestro proyecto con VMWare. Revisamos las bibliotecas oficiales para la API de VMWare y encontramos que hay versiones de Java y Perl. También hay una opción no oficial de Ruby. Estábamos seguros de que podríamos usar uno de ellos, y simplemente hacer algunas llamadas exec() de PHP para capturar la salida como un String. Como pensamos, el análisis desde allí debería ser pan comido.

Resultó que esto era casi imposible. Ninguna de las dos bibliotecas funcionó como esperábamos. Algunos estaban abandonados o incompletos, y era casi imposible analizar los resultados. En última instancia, nos vimos obligados a hacer algo que nadie había hecho antes: implementar una biblioteca API de VMWare en PHP. Desafortunadamente, no había otra forma razonablemente aceptable de hacerlo.

Este problema era masivo; ¡retrasó los planes iniciales por semanas! Por supuesto, el propietario de nuestro producto fue notificado inmediatamente y, junto con él, planeamos un nuevo programa y desarrollamos nuevas historias, que incluían la creación de esta biblioteca API.

Más a menudo que no, tus problemas serán mucho más pequeños. Las personas pueden quedarse estancadas con una lógica más sofisticada, pero, muchas veces, a la mañana siguiente, ya tienen ideas y soluciones. Otras veces, simplemente irán por el camino equivocado, y un compañero de equipo tendrá que ayudarlo a volver a encarrilarse. Estos representan tus problemas típicos.

Conclusión

Aquí estamos en la conclusión. Al menos, así es como mi equipo comenzó con Scrum. Algunas reglas fueron muy útiles; otras no tanto. Además, algunas reglas solo fueron útiles por un corto tiempo, mientras que otras aún son respetadas religiosamente por nuestro equipo.

Solo puedo recomendar que aceptes el proceso ágil, pruebes Scrum y formes tus propias conclusiones. Estoy seguro de que encontrarás trozos y piezas para adoptar para tu equipo. Sé ágil, adáptalo a tu estilo de trabajo, a tus proyectos y personalidades, y no tengas miedo de agregar tus propias reglas personalizadas.

Después de todo, Agile se refiere a la adaptación, ¡no a ciegas siguiendo un conjunto de reglas predeterminadas!