La metodología Scrum para el desarrollo de proyectos ágiles

Fundamentos de la metodología SCRUM Agile

Como decía A. Einstein: «Si buscas resultados distintos, no hagas siempre lo mismo». Ante el desarrollo de una idea donde interviene algo nuevo (algo que no existe en el mercado: sea un producto o un software) jamás podremos lograr algo verdaderamente «nuevo» si se priorizan los procesos o las herramientas, al conocimiento colectivo de individuos creativos que interactúan entre si y tiene experiencias que comparten entre ellos, con el objetivo de lograr resultado desconocidos, distintos y sorprendentes que en transcurso del tiempo irán aportando valor al producto final.

Este principio resulta fundamental, ya que es totalmente opuesto a otras metodologías de trabajo tradicionales (o convencional), donde el proceso o la herramienta es el valor más importante de la compañía y por ello, de algún modo, estas limitarán y definirán parte del resultado o producto final.

El modelo Scrum hace mucho más ágil el trabajo en este punto, pues al priorizar al individuo y sus interacciones, se podrá usar la creatividad individual y colectiva, para resolver problemas con mayor rapidez y con resultados más valiosos. (pues no serán dependientes de nada, excepto de la creatividad. En cambio, cuando se priorizan los procesos o las herramientas, no se puede desarrollar una idea realmente nueva, inexistente en el mercado, porque no encontraremos con constantes «esto no se puede hacer» y limitaciones que harán inviable el proyecto.

1.2 Valorar más el producto que funciona (o “software”, en el caso de empresas puramente tecnológicas), que la documentación exhaustiva y milimétrica.

Durante el desarrollo de un producto (mediante métodos de trabajo convencionales) se genera gran cantidad de documentación que explica la funcionalidad o el uso del mismo, temas legales, además de cientos de aspectos que definen el producto o resultado soñado (o a alcanzar). Para ello se dedica mucho tiempo, y aunque es un proceso importantísimo, no es algo a priorizar según las metodologías ágiles.

En Scrum se prioriza el desarrollo del producto tangible, ya que partimos de la base que estamos creando algo nuevo, no se debe perder el tiempo, en primera instancia, en documentar algo difuso como si fuera nítido, pues es más importante dedicar el esfuerzo en crear el prototipo que funciona (algo real, tangible) y estudiar su interacción con los individuos. Ya sea en el desarrollo de software o en el desarrollo de nuevos productos, poder tocar, poder oler, poder usar, poder interactuar con el producto, nos desvelará mucha más información importante y relevante, que la que traducen unas simples palabras escritas en un documento que posteriormente puede cambiar. En este punto Scrum ayuda a sentir la viveza tangible, de algo intangible siguiendo otras metodologías, por lo que hace más ágil el proceso de desarrollo. Otra vez, anteponiendo lo tangible, el software real, a la documentación exhaustiva nos estamos liberando de limitaciones, y estamos solo creando, con la única intención de crear, por lo que parece más lógico lograr satisfacer las necesidades con resultados más reales y objetivos.

El cliente, en un proyecto convencional, pone el dinero, define los objetivos, los plazos y se desentiende prácticamente hasta el día de la entrega (pues ha descrito al detalle lo que quiere y como lo quiere. Los profesionales que contrata tienen una meta fija y nítida y esta es inamovible).

Las metodologías ágiles se usan en proyectos onde el cliente no puede, o no quiere definir, algo que es difuso en los principios del proyecto, de modo, que este no se ve limitado por contratos que determinan quién hace qué y cuándo o cómo lo hace. Todo se calcula en base a está metodología y sus practicas. El cliente es un miembro activo más del equipo, que se integra y colabora en el grupo. (Un modelo de contrato por obra no es compatible con este tipo de metodologías) El cliente le dedica el mismo tiempo al proyecto que el resto de los integrantes.

De algún modo, otra vez en este tipo de metodologías es aquí donde reside el existo de un proyecto. El diseñador, el desarrollador, el cliente, y demás roles que participan en el desarrollo de un producto se sienten un equipo que lucha por conseguir algo en conjunto. Existe una empatía y un objetivo común. Desaparece la idea de jefe, que es quién manda,, y aparecen roles que desempeñan diferentes funciones durante todo el proceso de desarrollo del producto.

Lo más interesante es que gracias a estos métodos y prácticas ágiles, el trabajo puede ser auto-gestionado por los propios individuos sin la necesidad de una jerarquía de jefe tradicional.

1.4 Valorar más la respuesta al cambio, que el seguimiento de un plan.

En un proyecto convencional, las ideas se pactan en un contrato tradicional, y los cambios son considerados como inconvenientes o barreras que impiden alcanzar una meta real fijada en un plan de desarrollo estricto.

En proyectos donde las ideas son intangibles, o difusas, y las realidades son inestables y susceptibles a cambios, la metodología Scrum hace más ágil el desarrollo del proyecto, pues trata el cambio como algo natural y valora por ello la capacidad de anticipación y adaptación, ante la mera premisa de seguir un plan trazado y exactamente documentado. Los proyectos basados en el desarrollo de algo desconocido y nuevo (tecnológico o no), que tratan el cambio como un hándicap, son proyectos destinados al fracaso, pues como dijo Darwin: «No es la especie más fuerte la que sobrevive, ni la más inteligente, sino la que mejor se adapta a los cambios».

De estos 4 premisas fundamentales se derivan muchas otras, entre ellas las siguientes, descritas por profesionales que usan Scrum. (No es una una metodología estricta, o que siga pautas fijadas en un libro. Las empresas adaptan está metodología/filosofía y aparecen variables de desarrollo que solo funcionan para nuestra idea o desarrollo de un producto determinado)

• La principal prioridad es satisfacer al cliente a través de la entrega temprana de un producto real o prototipo usable, con el cual lograr una interacción entre los individuos y el producto (siempre se irá implementado el valor del producto a medida que se vaya desarrollando las distintas fases del proyecto),

• Son bienvenidos los cambios en cualquier fase del desarrollo. Los procesos ágiles trasforman el cambio (un hándicap, en metodologías convencionales) en una ventaja competitiva para el cliente. Solo se pueden implementar cambios tras el Sprint.

• Entregar con frecuencia implementaciones del producto que funcione (software o no), en periodos de un par de semanas hasta un par de meses (con preferencia de periodos cortos para el desarrollo de software)

• Todas las personas que integran el negocio deben trabajar juntos de forma cotidiana a través del proyecto. Todos los roles tiene la misma importancia y juegan un papel fundamental. Nadie es más importante que el resto. Todos tiene mágia que aportar.

• Se desarrollan proyectos en torno a individuos motivados y creativos, a los que se les brinda la oportunidad y el respaldo que necesitan para que realicen la tarea que les atañe.

• La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara. Los documentos limitan el desarrollo y hacen hacen perder mucho tiempo en el camino.

• El producto que funciona es la principal medida del progreso.

• Se reduce el Time to Market. El cliente puede empezar a utilizar las características más importantes del producto antes de que esté completamente terminado. Puede comenzarse la explotación del producto mucho antes que con una metodología tradicional donde solo se puede lanzar el producto cuando está finalmente acabado, tal y como se pactó en el acuerdo contractual.

• Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida. La integración por parte de los individuos que trabajan en el desarrollo es total.

• Se logra maximizar de forma sencilla la cantidad de trabajo que no se hace. Se identifica claramente lo que queda pendiente y lo que está acabado.

• Las mejores arquitecturas, requisitos y diseños nacen de equipos que se auto-organizan el trabajo sin la figura del jefe que manda pero desconoce en que fase del desarrollo se encuentra el proyecto. Cada individuo conoce su rol en el proceso de desarrollo y es capaz de autogestinarse para lograr los objetivos marcados. Sin jefes¡

• En intervalos regulares el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

LOS ROLES en la metodología SCRUM 

• Product Owner. Es la figura del cliente (o de alquién que juega el Rol de cliente y representa y vela por los intereses del proyecto desde la perspectiva del mismo). Es el responsable de la visión estratégica. En las metodologías ágiles, el Cliente se involucra en el proyecto como uno más, estando presente en todas las reuniones de grupo, y demás procesos de esta metodología. Es el encargado de identificar las características del producto. Tiene el poder de decidir sobre las fechas de lanzamiento y contenidos. Es el principal responsable de la rentabilidad del producto (ROI), por ello se encarga de priorizar las tareas necesarias para llegar al producto final, según el valor de mercado. Ajusta las características y prioridades por iteración, según sea necesario. Es un buen conocedor del sector al que se dirige el producto y tiene la capacidad de aceptar o rechazar resultados del trabajo.

• Scrum Manager: Este rol juega un papel primario y es el de eliminar los obstáculos que impiden que el equipo de desarrollo alcance los objetivo fijados en el tiempo concreto. El ScrumMaster no es el líder del equipo (ya que el equipo es auto-organizado), sino que actúa como “facilitador” entre el equipo y cualquier influencia que le distraiga. El ScrumMaster es una especie de arbitro que hace que las reglas de la metodología se cumplan. Se le conoce como el facilitador y está trabaja íntimamente relacionado con el equipo de desarrollo y el Cliente o Product Owner.

• Development Team: El equipo de desarrollo suele ser un equipo de trabajo formado por 3 a 9 integrantes y tienen la responsabilidad de entregar el producto en la fecha acordada. Son individuos creativos trabajando de manera auto-organizada y en equipo, con las habilidades necesarias para realizar el trabajo: análisis, diseño, desarrollo, pruebas, documentación, etc. Personal cualificado, altamente motivado y muy bien valorado por la compañía. Son apasionados del sector y no les mueve el dinero, sino el mero hecho de participar y hacer ideas realidad.

2.2 ROLES auxiliares

Para la metodología Scrum hay roles de individuos que interviene de forma auxiliar en los «equipos». No tienen un rol formal y no se involucran frecuentemente en el «proceso», sin embargo deben ser tomados en cuenta para obtener datos reales y objetivos acerca del proyecto. De este modo se intenta involucrar en el proceso a los usuarios, expertos del negocio y otros interesados («stakeholders») ya que ofrecen una visión distinta y valiosa acerca de diversos detalles del desarrollo.

• Rol Stakeholders: Clientes, Proveedores, Vendedores. Son personas que hacen viable el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su desarrollo. Participan (solo) directamente durante las revisiones del «sprint».

• Rol Managers: Es un Rol auxiliar de administrador (no siempre se hace uso de él). Se encarga básicamente de establecer el mejor y más rentable entorno para el desarrollo del proyecto.

Las reuniones en la metodología Scrum Agile

3.1 «Daily Scrum»: Son las reuniones diarias que permiten discutir el trabajo, enfocándose especialmente en áreas de solapamiento e integración. Cada día tiene lugar una reunión (todos de pie) de no más de 15 minutos. En este espacio de tiempo se hacen algunas preguntas y se responden sin la intención de buscar soluciones a problemas, sino que se trata de hablar sobre hechos.

• ¿Qué ha hecho tu equipo desde nuestra última reunión?

• ¿Qué hará tu equipo antes que nos volvamos a reunir?

• ¿Hay algo que demora o estorba a tu equipo?

• ¿Estás a punto de poner algo en el camino del otro equipo?

   

• Seleccionar qué trabajo se hará dependiendo de las prioridades.

• Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que llevará hacer el trabajo.

• Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint.

• Revisar el trabajo: completado y pendiente.

• Presentar el trabajo completado a los interesados.

• El trabajo incompleto no puede ser demostrado.

Ventajas competitivas de trabajar con Metodologías ágiles

Algunos de los beneficios de implantar metodologías ágiles para la gestión y desarrollo de proyectos son:

• Flexibilidad a cambios a lo largo de la vida de desarrollo de un producto.

• Reducción del Time to Market.

• Se ofrece una mayor calidad del producto.

• Se mejora la productividad.

• Se maximiza el retorno de la inversión (ROI).

• Resulta más simple la predicciones de tiempos.

• Se reducen ampliamente los riesgos de desarrollo.

Los Artefactos en la metodología Scrum Agile

• Product backlog

• Sprint backlog

• Burn down chart

Glosario básico de la metodología SCRUM Agile

Algunos términos normalmente usados en la metodología ágil Scrum son:

• Tribu: Grupo de personas que comparten pasiones y temas de interés.

• Scrum: Marco de trabajo para gestionar proyectos en equipo.

• IT = Information technology: Tecnología de la información.

• Iteración (Ciclo). Proceso que se repite. Período de tiempo. Ciclo

• Desarrollo iterativo e incremental. Desarrollar un producto, dividiendo el proyecto en períodos de tiempo (iteraciones), donde en cada ciclo se entrega un producto, y se busca incrementar el valor del producto entregado en el ciclo anterior.

• Equipo / Team. Es un grupo auto-organizado de individuos que enfocado sus esfuerzos en un objetivo común.

• ROI: El retorno sobre la inversión (return on investment) es una razón financiera que compara el beneficio o la utilidad obtenida en relación a la inversión realizada. Este termino representa una herramienta para analizar el rendimiento que la empresa tiene desde el punto de vista financiero.

• Spike: Un spike sirve para incluir en un sprint tareas que no implican el desarrollo de una historia de usuario. Son tareas que no implican un incremento directo al producto que se está desarrollando. Son tareas como: Documentar, estudiar, hacer pruebas… Normalmente la duración de un spike debe ser como máximo la duración de un sprint, y debe servir para desbloquear alguna tarea pendientes, o adquirir nuevos conocimiento necesario para poder planificar y enfrentarse al sprint siguiente. Este tipo de tareas se proponen y planifican durante la reunión “Planificación del Sprint”.

• Definition of done (DoD) / Definición de hecho: Se debe definir que significa el termino “Hecho” para que todo el equipo o equipos que trabajan en el proyecto sepan y entiendan este concepto del mismo modo. Hecho hecho, es hecho, y no “casi” hecho. Dejando claro este termino, se puede determinar si un elemento o tarea de la pila de producto (backlog) esta completo (hecho).

• Impedimento: Cualquier cosa que impide que un miembro del equipo realice sus tareas de la manera más eficiente posible.

• Velocidad: Es el esfuerzo total que un equipo es capaz de hacer en un sprint. Su valor numerico se deriva de la evaluación de los trabajos completado a partir de elementos del backlog en el último Sprint. Los datos de velocidad histórica es una guía para ayudar al Team a comprender la cantidad de trabajo que pueden hacer en un sprint próximo.

Más documentación interesante sobre Scrum si te gusta leer:

1. ¿Qué es Scrum? por Proyectos ágiles
2. The home of Scrum por Scrum.org
3. Scrum por Scrum alliance

Metodologías SCRUM Agile y los procesos de desarrollo

Creación de historias de usuario según la metodología Scrum

Experiencias páctica. Uso de la metodología Scrum