INTEGRANTES YANETH ISAMAR AVILÉS SORIANO. KERIN ERNESTO APARICIO LOZANO. GILSON DIRCEO CARRANZA AYALA. JOSÉ LUIS RODRÍGUEZ PALACIOS. JOEL NEHEMIAS GOMEZ CHAVES
Metodología Scrum ¿Qué es? Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua, adaptación, auto-gestión e innovación.
¿Cuándo se utiliza? Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada
nueva
iteración
sin
ningún
problema.
Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar sus capacidades.
Beneficios
Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le aporta cada requisito / historia del proyecto, el equipo los estima y con esta información el Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al equipo.
Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodología está diseñada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.
Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más importantes del proyecto antes de que esté finalizado por completo.
Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.
Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos para organizarse.
Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de inversión.
Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el Backlog.
Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada.
Proceso y Roles de Scrum
El proceso
El desarrollo se realiza de forma iterativa e incremental. Cada iteración, denominada Sprint, tiene una duración preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versión del software con nuevas prestaciones listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya construida y se añaden nuevas prestaciones priorizándose siempre aquellas que aporten mayor valor de negocio.
Product Backlog: Conjunto de requisitos denominados historias descritos en un lenguaje no técnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversión considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.
Sprint Planning: Reunión durante la cual el Product Owner presenta las historias del backlog por orden de prioridad. El equipo determina la cantidad de historias
que puede comprometerse a completar en ese sprint, para en una segunda parte de la reunión, decidir y organizar cómo lo va a conseguir.
Sprint: Iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product Backlog a las que se ha comprometido, en una nueva versión del software totalmente operativo.
Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint.
Daily sprint meeting: Reunión diaria de cómo máximo 15 min. en la que el equipo se sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el día anterior, que hará hoy y si hay impedimentos.
Demo y retrospectiva: Reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstración del producto. Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien, qué procesos serían mejorables y discute acerca de cómo perfeccionarlos. Roles
En Scrum, el equipo se focaliza en construir software de calidad. La gestión de un proyecto Scrum se centra en definir cuáles son las características que debe tener el producto a construir (qué construir, qué no y en qué orden) y en vencer cualquier obstáculo que pudiera entorpecer la tarea del equipo de desarrollo. El equipo Scrum está formado por los siguientes roles:
Scrum master: Persona que lidera al equipo guiándolo para que cumpla las reglas y procesos de la metodología. Gestiona la reducción de impedimentos del proyecto y trabaja con el Product Owner para maximizar el ROI.
Product owner (PO): Representante de lso accionistas y clientes que usan el software. Se focaliza en la parte de negocio y él es responsable del ROI del proyecto (entregar un valor superior al dinero invertido). Traslada la visión del proyecto al equipo, formaliza las prestaciones en historias a incorporar en el Product Backlog y las re prioriza de forma regular.
Team: Grupo de profesionales con los conocimientos técnicos necesarios y que desarrollan el proyecto de manera conjunta llevando a cabo las historias a las que se comprometen al inicio de cada sprint.
Ventajas y Desventajas Las principales ventajas que Scrum presume de aportar son las siguientes, propias de las metodologías ágiles en general:
Buena respuesta frente a cambios: Scrum acepta que se produzcan cambios en el producto durante el desarrollo del mismo. Al trabajar en ciclos de aproximadamente un mes de duración, cualquier nueva característica o modificación es bienvenida al inicio de cada ciclo.
Aumenta la visibilidad: Las reuniones mensuales y diarias permiten identificar y corregir problemas casi de inmediato.
Entrega el mayor valor primero: Al trabajar sobre una lista priorizada, nos aseguramos de que entregamos primero las características de mayor valor. Y al entregar un producto terminado al final de cada ciclo, no nos arriesgamos a que el proyecto fracase porque no haya dado tiempo a terminarlo.
Mejora las estimaciones: Al trabajar en ciclos de duración fija, se aprende rápidamente como de productivo es el equipo y cuántas tareas es capaz de terminar en un tiempo dado.
Elimina el síndrome del estudiante: En vez de trabajar de forma relajada al principio del proyecto y acumular estrés los últimos meses, con Scrum el estrés se distribuye al final de los múltiples ciclos de un mes que componen el desarrollo del producto.
Sin embargo, hay circunstancias donde no suele ser conveniente usarlo, por ejemplo:
Cuando los equipos de trabajos son muy grandes.
Cuando las estructura del equipo sea muy complicadas.
Cuando el equipo esté distribuido geográficamente.
Ante aplicaciones críticas.
Gente con muy poca experiencia.
Ciclo de producción
En Scrum, un proyecto se realiza en bloques temporales cortos y fijos (iteraciones de entre dos semanas y un mes). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite. El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos, balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de inversión mediante la re planificación de objetivos que realiza al inicio de cada iteración. Planificación de la iteración Al inicio del ciclo sprint, que se produce cada 15 o 30 días, se lleva a cabo una reunión de planificación del sprint, en el que las principales actividades que se van a realizar son, seleccionar que trabajo se va a realizar, preparar el Sprint Backlog,
que es donde se detalla el tiempo que se va a tomar para realizar el trabajo, e identificar y comunicar que parte del trabajo se debe realizar en la iteración actual. En esta reunión podemos diferenciar dos partes.
Selección de requisitos: No durará más de cuatro horas, en ella el cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita.
Planificación de la iteración: En un máximo de cuatro horas, el equipo elabora la lista de tareas de la iteración necesarias para desarrollar los requisitos a que se ha comprometido. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se auto asignan las tareas.
Al final del ciclo se llevarán a cabo las reuniones de revisión del sprint y de retrospectiva del sprint. Ejecución de la iteración Cada día de un sprint se realiza la reunión de sincronización sobre el estado de un proyecto. Esto se llama Daily Stand up. Cada miembro del equipo inspecciona el trabajo que están realizando el resto (dependencias entre tareas, progreso hacia el objetivo, problemas que se están encontrando…) para poder hacer los cambios necesarios que permitan cumplir con el compromiso adquirido. El scrum tiene unas guías específicas:
La reunión comienza puntualmente a su hora. A menudo hay castigos acordados por el equipo para quien llegue.
Todos son bienvenidos, pero sólo los cerdos pueden hablar.
La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
Todos los asistentes deben mantenerse de pie con el fin de que la reunión no se alargue.
La reunión debe ocurrir en el mismo lugar y hora todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas:
¿Qué has hecho desde ayer?
¿Qué vas a hacer a partir de este momento?
¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?
Durante la iteración el Scrum Master se encarga de que el equipo pueda cumplir con su compromiso y de que no se reduzca su productividad. Para ello:
Elimina los obstáculos que el equipo no puede resolver por sí mismo.
Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.
Después de esta reunión, se realizará lo que se conoce como Scrum de Scrum, que son reuniones que permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración. Normalmente asiste una persona asignada por cada equipo. La agenda será similar a la del Daily Stand up. Los miembros que asisten a esta reunión se realizarán cuatro preguntas:
¿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?
Inspección y adaptación El último día de la iteración se realiza la reunión de revisión del sprint (Sprint Review Meeting). No puede durar más de cuatro horas. En esta reunión se revisa el trabajo para ver que parte ha sido completada y cual no. Luego el equipo presenta al cliente el trabajo que se ha finalizado en la iteración en forma de incremento del producto. En función de los resultados mostrados y de los cambios que se hayan realizado
en el proyecto, el cliente realiza los cambios necesarios de manera objetiva, replanificando el proyecto. Después de cada iteración se realiza la Retrospectiva de la iteración o Sprint Retrospective, en ésta, todos los miembros del equipo analizan como ha sido su manera de trabajar, cuáles han sido los problemas que han observado y dan sus impresiones sobre la iteración que se acaba de finalizar. El Scrum Master es el encargado de ir eliminando los obstáculos. El objetivo de esta retrospectiva es lograr una mejora continua del proceso. Esta reunión no debe durar más de cuatro horas.
Scrum Manager y Scrum Master, ¿quién es quién?
Los Scrum Manager son participantes clave en organizaciones ágiles. La importancia de su rol radica en lo estratégico de su responsabilidad, que se orienta a la preservación de la calidad del producto, desde la arquitectura de código hasta el usuario final de calidad. Su involucración permite garantizar que el desarrollo cumple con los objetivos planteados a corto y largo plazo. Además, su influencia es determinante al encontrarse cerca del equipo de desarrollo y actuar como intermediarios, representando los intereses de este área frente a la alta dirección. Esta proximidad con el proceso y el producto protege a los equipos de las distracciones externas, la adopción de patrones o enfoques de trabajo
improductivos, la irrupción de funciones cruzadas o la aparición de proyectos secundarios que puedan alejar a los desarrolladores de los objetivos del equipo. La función del Scrum Manager Pese a la similitud de ambos términos, Scrum Master y Scrum Manager no se ocupan de lo mismo en un entorno de
desarrollo. Los Scrum Master son
responsables de los proyectos en un equipo ágil y se centran en la optimización del rendimiento, trabajando entre el propietario del producto y el equipo, para asegurar la consistencia de las acciones que se lleven a cabo. A diferencia de esta figura, el Scrum Manager es el encargado de:
Crear el equipo, por lo que su labor comienza con la contratación de desarrolladores. Esta tarea lleva mucho tiempo y, si el Scrum Master se ocupase de ella, terminaría distrayendo al desarrollo.
Reducir algunos de los efectos de la incorporación a medida que cada nueva persona se integra en el equipo, para permitir que el equipo pueda centrarse de lleno en el producto.
Actuar como un socio y mentor, ya que son expertos en los fundamentos de la gestión y por eso deben responsabilizarse de mantener las reuniones que sean precisas con los miembros de los equipos, dar retroalimentación y coaching.
En algunos casos, también pueden apoyar la labor del Scrum Master y aportar ideas, código, pruebas y cultura de empresa.
Está claro que, la de Scrum Manager, es una posición de gerencia, por lo que su implicación tendrá mucho que ver con la toma de decisiones estratégicas, especialmente en lo que respecta a la determinación de plazos, para la que habrá de actuar como negociador entre las partes, tratando de lograr un acuerdo. Sin embargo, su aportación más importante al desarrollo es la que tiene que ver con la generación de valor. Desde su experiencia y conocimiento, del medio y del
equipo, a través de preguntas e hipótesis, puede conseguir orientar al equipo en la dirección correcta. El planteamiento de antecedentes, la revisión de los principios más importantes el enfoque ágil y su colaboración activa con el Scrum Master lograrán que, sin coartar la autonomía de los profesionales del desarrollo, se resuelvan problemas, se aumente la eficiencia y cada miembro del equipo consiga crecer y aprender.
Prácticas ágiles que puedes aplicar en proyectos no ágiles
No hace mucho leí un post en el que se hablaba de prácticas ágiles que todo desarrollador de software debería aplicar. El problema (y esto es una opinión) que le veo al agile (o agilísimo) es esa sensación de que son demasiadas cosas que debes aprender, de que el camino está lleno de dificultades, ese valle de la desesperación, esa sensación de no dominar nunca la ‘técnica’. En resumen darte cuenta de los años malgastados aprendiendo cosas que no te han llevado a construir mejor software y la necesidad de desaprender todo eso.
Donde trabajo no somos ágiles y no lo somos por muchos motivos que no voy a contar aquí. Y el hecho de que no seamos estrictamente ágiles no quiere decir tampoco que seamos unos patanes, peores que nadie, que nuestros proyectos fracasen o que no apliquemos prácticas ágiles a proyectos que no son ágiles.
Bien, aun así, en mi lucha por encontrar la manera de agilizar proyectos que son una mole y en definitiva, trabajar más a gusto, esta semana he recapitulado 7 buenas prácticas ágiles que no implican desmontar la empresa entera, “vender” que eres lo más ágil del mundo o pasarte meses intentando aplicar TDD sin ser productivo.
¿Qué prácticas ágiles puedes aplicar en proyectos no ágiles sin desmontar tu empresa? Se me ocurren estas siete buenas prácticas ágiles que se pueden aplicar en cualquier proyecto de software y muchas de ellas, en cualquier proyecto de cualquier ámbito (ni siquiera hace falta que sean de ingeniería)
Reunión diaria La típica reunión o sprint diario de Scrum en el que el equipo habla de: Qué hice ayer, qué voy a hacer hoy y problemas que he tenido. Esto es algo que se puede hacer en cualquier proyecto del mundo mundial, sea de software o no. Y tampoco hace falta ‘institucionalizarlo’, es decir, reunirse de pie con un sombrero de copa y unas pipas. Se puede hacer tranquilamente, al llegar cada mañana en 5 minutos, cada uno desde su silla. El objetivo: que el equipo sepa el estado actual de las tareas y atacar problemas cuanto antes.
Cuánto queda Esta es la pregunta que todos los que alguna vez hemos dirigido un proyecto, más veces hacemos: ¿Cuándo va a estar esto terminado? Estimar cuánto te falta para terminar una tarea cuesta menos cuanto más tiempo llevas trabajando en ella, así que no veo el motivo por el cual no apuntarlo en algún sitio. Y si ya haces un gráfico Burn Down y lo haces durante la reunión diaria, entonces no sé qué haces leyendo esto.
Define terminado Esto es algo que me ha pasado hoy con un compañero. Trabaja muy bien y lo hace todo muy rápido, pero cuando he hurgado un poco he visto que tareas, incluso historias que ya habíamos dado por ‘terminadas’ realmente no lo estaban. Pequeñas tareas transversales a todas las historias como gestión de permisos, internacionalizar cadenas, pequeños parámetros de configuración, no estaban. La respuesta: ‘No, es que eso lo dejo para el final porque así no pierdo tiempo’. ¿El final? ¿Y cuándo es el final? ¿El día de antes de desplegar? No tiene sentido… hay que definir cuándo algo lo damos por terminado porque si no, todo está a medias.
Tu proyecto debe compilar siempre Esto es algo que lo he vivido en mis propias carnes y en las de otros. Llega tu jefe, te pide que le enseñes en lo que estás trabajando y justo media hora antes, la acabas de liar parda y has entrado en un ciclo de re factor que te va a llevar todo el día y tu proyecto no va a compilar ni de lejos. ¡Error! Y error muy grande. Uno de los objetivos de hacer TDD es que tu proyecto pase el menor tiempo posible sin poder ser construido. Y bien, ¿si no has hecho test y necesitas re factorizar? Búscate la vida pero no rompas tu proyecto. En el proyecto en el que trabajo ahora no tengo test y tengo que migrar media aplicación a otro framework. ¿Cómo lo he resuelto? Adaptando el actual y poco a poco ir migrando funcionalidad, ¡pero el proyecto siempre construye! (Y tengo la suerte de que es Javascript :))
Automatiza dentro de tus posibilidades Otra situación que he vivido en mi empresa. Llega tu jefe y quiere probar no sé qué cosa. Tu proyecto no compila en local, pero es que además ni siquiera tienes una versión ‘estable’ en ningún servidor de desarrollo o pre. Otro craso error. O peor aún, todo funciona, pero desplegar te cuesta 3 horas. No seas perro y automatiza como mínimo tus despliegues.
Trabaja en equipo pero juntos Esto es algo que nunca entenderé… ¿Por qué en una oficina pequeña las personas que trabajan en el mismo proyecto, están cada una en una esquina? ¿O
de espaldas? Para hablar tienen que levantarse o peor aún, hablar por Skype. Nadie sabe lo que está haciendo el otro, pasan días y cada uno va a su bola… Hace unas semanas decidí cambiarme de sitio en mi oficina cerca de mis actuales compañeros de proyecto, lo que implica irme a otra zona de la oficina lejos de los compañeros que he tenido alrededor los últimos 5 años y con los que he trabajado muy ocasionalmente. Las personas que trabajan en un proyecto trabajan mejor juntas y si además son un equipo que se mantiene a lo largo de diferentes proyectos, ¡mucho mejor! Y si además se llevan bien ya ni te cuento.
Desarrolla en parejas Esto es algo que sin ‘formalizarlo’ hago muy a menudo. Diseñar una base de datos por parejas, resolver un bug, construir un proyecto… Muchas de estas cosas en ocasiones cuestan menos de hacer por parejas y cuando uno de los dos sabe menos del tema sirve para que el otro no se coma siempre los marrones o haya una dependencia fuerte.
¿Es posible Scrum ignorando las buenas prácticas?
La relación que existe entre las metodologías y las buenas prácticas ha hecho correr ríos de tinta. Es una cuestión candente que Luis Fraile o Ángel Medinilla (ver la lista de Agile Spain) en la lengua de Cervantes y Martin Fowler en la de Shakespeare, entre otros muchos ‘agilitas’, han tratado con diferentes posturas. El mismo debate ha surgido en la lista de correo de Agile Spain y seguro que resurgirá en el futuro. Así que no me he podido resistir a escribir sobre el tema. Mi visión sobre esta cuestión es clara. No me importan las metodologías con M mayúscula, me importa la metodología con m minúscula. Esta distinción la hacen los autores de Peopleware para marcar la diferencia entre ‘tener una metodología’ y ‘trabajar metódicamente’. A menudo nos encontramos con organizaciones que alardean de metodología e ignoran todo método en su trabajo diario. La diferencia entre ambas situaciones está en un único aspecto: las buenas prácticas de ingeniería del software que los equipos de desarrollo utilizan en el día a día. Tampoco faltan los gestores que pretenden que la gestión de proyectos es un puro problema organizativo, en el que las buenas prácticas de ingeniería del software tienen un papel secundario. Este perfil de gestor es en mi opinión menos útil que el gestor que tiene una visión técnica fundamentada en las mejores prácticas de la
ingeniería del software, de los problemas que surgen durante el desarrollo del proyecto. Lógicamente siempre manteniendo el equilibrio. Desde el punto de vista del espectro metodológico hay dos vertientes claras, metodologías que son prescriptivas en lo que a ciertas buenas prácticas se refiere, como XP o MSF Agile y metodologías que no prescriben buenas prácticas como parte de su receta, como Scrum o CMMI. Scrum es totalmente agnóstico respecto a las buenas prácticas. Siguiendo la premisa de que el equipo es en Scrum auto organizado y auto gestionado, este es soberano a la hora de decidir cómo implementar las historias comprometidas para un sprint. Scrum no exige, en principio, el uso de ninguna buena práctica. Yo soy partidario de las buenas prácticas por encima de las metodologías. Pero ese no es el tema de hoy. El tema de hoy es contestar la pregunta ¿es posible hacer Scrum sin utilizar buenas prácticas? Dicho esto veamos qué ocurre si un equipo de Scrum decide ignorar las buenas prácticas. Voy a tratar de demostrar, mediante reducción al absurdo, que no es posible, en proyectos de desarrollo de software, cumplir algunas reglas de Scrum sin utilizar buenas prácticas de ingeniería del software. El punto es que si ignorando algunas buenas prácticas llegamos a la conclusión de que no podemos cumplir alguna de las reglas de Scrum directamente se deriva que no estamos utilizando Scrum. Esto supone asumir también que Scrum solo es Scrum si se respetan sus reglas. Es fácil saber si estás usando Scrum o no, comprobando si estás siguiendo las reglas o no. Voy a hablar de las tres buenas prácticas utilizadas por los equipos de desarrollo ágil: Automatización de las pruebas, construcciones automatizadas y gestión de la configuración. Un equipo ágil podría elegir no utilizar pruebas automatizadas. El precio que pagaría por esa decisión sería no poder detectar regresiones en el software de manera rápida y no poder asegura que las historias están hechas de manera inequívoca. Sin la posibilidad de detectar regresiones de manera rápida, lo que ocurriría, es que cuando el final del sprint se acercase, el equipo tendría que
congelar el desarrollo de funcionalidad, dedicar un tiempo considerable a asegurar la ausencia de regresiones y a asegurar que las funcionalidades están completas, pruebas incluidas. Una de las reglas de Scrum especifica que se debe minimizar el tiempo que se dedica a la preparación del Sprint Review. La conclusión es clara: Sin automatización del testeo es imposible dedicar poco tiempo a la preparación del Sprint Review. Luego sin pruebas automatizadas, no es posible Scrum. Un equipo ágil podría decidir no usar construcciones automatizadas. El precio que pagaría sería que no podría construir una versión lista para el despliegue con suficiente velocidad y asegurando la ausencia de errores derivados de un proceso de construcción manual. Una de las reglas de Scrum dice que el Producto Owner puede decir tras cualquier Sprint Review poner el software en producción. Sin construcciones automáticas, esta puesta en producción se demoraría y el equipo habría fallado al entregar un incremento de funcionalidad potencialmente entregable, aspecto clave en Scrum. Por lo tanto la conclusión es simple: sin construcciones automatizadas, no es posible Scrum. Un equipo ágil, podría elegir no usar una política de gestión de la configuración adecuada. El precio que pagaría sería que no podría asegurar que el software entregado solo contiene historias completas. Recordemos que una de las reglas de Scrum dice que el equipo solo puede demostrar características completas y que nada que no se haya demostrado debe ser entregado. De esta premisa se deriva que si nuestra política de gestión de la configuración no es adecuada, no es posible Scrum. De lo anteriormente expuesto, es simple de concluir que como la automatización de las pruebas, las construcciones automatizadas y la gestión de la configuración adecuadas, son buenas prácticas y sin ellas no hay Scrum, sin buenas prácticas, no hay Scrum. Es más diría que sin buenas prácticas no hay agilidad, pero eso ya no soy capaz de demostrarlo formalmente. Ya lo decía mi abuelo: quien no siembra
no recoge.
Scrum: Los 3 grandes beneficios
Los desarrollos Agile precisan de organizaciones que reaccionen a la nueva información y a las nuevas ideas que se den en cualquier punto del proceso de desarrollo Scrum es un marco organizativo para el desarrollo de equipo de alto rendimiento que combina de manera muy eficiente elementos y buenas prácticas de liderazgo. Puede ser desplegado para conseguir finalizar mucho más eficientemente el trabajo, donde “trabajo” va desde la ejecución de estrategias de venta, entregar mejores campañas de marketing, o construir mejores características y funcionalidades de productos y servicios. Scrum, como metodología de desarrollo Agile, está muy contrastada en los entornos de desarrollo de software ayudando a los equipos de desarrollo en la consecución de mejores proyectos de software, pero ello no implica que sus beneficios estén limitados solamente al desarrollo de software. Por ello cabe la siguiente pregunta, ¿por qué elegir Scrum para el desarrollo de productos y servicios? A mi modo de entender, existen tres beneficios importantes que una organización no debería ignorar:
1)
Satisfacer a los Clientes
Construyendo de manera iterativa e incremental, las organizaciones están mejor preparadas para entregar a sus clientes los productos y servicios que realmente necesitan de manera más rápida y eficiente. Con Scrum, puedes recibir e incorporar el “feedback” del cliente al final de cada sprint, lo que significa que los resultados obtenidos estarán mejor alineados con las necesidades reales, no por las propias asunciones. Esto hace mucho más fácil mantener una relación más estrecha con los clientes y demás partes (stakeholders), involucrados y corresponsables en dicho proceso. 2)
Reducción de los Costes del Producto/Servicio
Scrum también mejora el ROI (Return of Investment) mediante la reducción de costes: la velocidad a la que hacemos las cosas, la eliminación de mermas del proceso, de manera que se evitan trabajos no esenciales, repeticiones, errores… que no son esenciales para nuestro mínimo producto viable (Minimum Viable Product). Esto hace que los equipos trabajen más rápido, más seguro, a menor coste, de manera fácil y asumible. 3)
Un equipo más feliz y productivo
Como dice Kenny Rubin “no existe un técnico que yo conozca que quiera participar en el desarrollo de cualquier cosa que nunca verá la luz del día”. Con Scrum, tus desarrolladores podrán desarrollar rápidamente aquellos elementos que la gente necesita utilizar, que es realmente lo que motiva a los ingenieros y técnicos.
¿Scrum es agilidad?
Mi percepción es que hay empresas que escuchan hablar de agilidad, metodologías ágiles y lo primero que se les viene a la cabeza es Scrum, porque es de lo que más se habla. Después, lo implementan en su empresa y piensan que así ya son ágiles. En estos casos es muy probable que mejore su situación con respecto a cómo estaban antes, pero tarde o temprano, acaban decepcionándose porque eso no era lo que les habían prometido por agilidad. ¿Sabes por qué pasa eso? Porque Scrum, por sí solo, es una forma de gestionar proyectos, nada más. Puedes implantar Scrum sin ser ágil, y por ello, implantar Scrum no implica volverse ágil. No obstante sí que es cierto que puedes utilizar Scrum, junto con otras técnicas y prácticas de Ingeniería del Software, para lograr llevar a tu día a día los principios y valores ágiles. Por ejemplo, un valor ágil es la importancia de las personas e interacciones entre ellas. Scrum se preocupa de ello al darle mucha importancia al equipo, a que sea
multifuncional y colaborativo, pero para ser realmente ágil, hay que cuidar cómo son las interacciones con otros roles, coordinar bien al equipo, que esté motivado… Muchas cosas que Scrum por sí solo no tiene en cuenta, y vienen más del lado de la cultura de empresa. Otro valor es la mejora continua, que Scrum lo lleva implícito en las reuniones de retrospectivas. O la idea de colaborar con el cliente, teniendo la figura del Product Owner. Pero la herramienta no lo es todo. Por eso escucharás que es imposible implantar un Scrum teórico en todas las empresas, y que hay que adaptarlo. Hay que adaptarlo a tu empresa, cumpliendo los valores ágiles. Tener una pizarra con post-it, gráficos burndowns etc. no te vuelve ágil. En las empresas realmente ágiles, esto es la superficie de una cultura de empresa tremendamente fuerte y centrada en las personas. Para mí, lo más productivo es centrarse primero en que la cultura de empresa sea ágil, y que Scrum sea una herramienta que ayude a adoptar ciertos valores ágiles. Y por lo general, no se suele empezar por esta parte. Ejemplos de que has implantado Scrum, pero no eres ágil. En muchas empresas en las que solo se implanta Scrum (y que quieren ser ágiles), se dan casos como estos: – No hay colaboración entre el cliente y el equipo. El cliente siempre pide cosas para ayer, todo es importante e impone fechas inamovibles e imposibles de entrega, todo por el mismo precio y negociando cada punto y coma del contrato. Todo eso se impone al equipo de desarrollo, haciendo las horas extra necesarias para conseguirlo. Esto podría ser un engendro de Scrum, ya que aquí tienes roles definidos y a un representante del negocio en el equipo. Pero no es ágil. Estás incumpliendo el valor de colaboración entre los clientes y el equipo.
La agilidad implica un cambio en la forma de contratación. El cliente y el proveedor deben colaborar entre sí. Por ejemplo, el equipo se compromete a entregar pequeños incrementos del producto que quiere el cliente cada semana y acepta que no tenga del todo claro qué es lo que quiere. Digamos que la empresa es flexible a la hora de gestionar los cambios y aceptar la incertidumbre. A cambio, el cliente irá priorizando en cada caso lo que va queriendo, y si hay que rectificar, se puede llegar a actualizar el contrato, el precio, etc. – No se valora a las personas. Esto es un clásico. Tenemos los roles de Scrum, pero los equipos están desmotivados y no se les deja actuar con creatividad, ya que hay una actitud de management tradicional de mandar y controlar, de que cuanto más tiempo pases sentado en la silla más productivo eres, etc. – El equipo no es maduro. Hay ciertas prácticas ágiles que necesitan que el equipo sea profesional y maduro. Mob programming es un buen ejemplo de ello. Es una técnica muy efectiva, pero un arma de doble filo si el equipo no se toma las cosas en serio; si lo haces mal con las personas equivocadas, puedes llegar a tener a 5 personas viendo vídeos de gatitos en Youtube. – Hay falta de liderazgo. Esto es otro clásico y un síntoma de no entender bien qué es un equipo ágil, multifuncional y autoorganizado. Tener un equipo multifuncional no es sencillo. Puedes tener suerte y que todo surja por sí solo, pero en la mayoría de los casos, no es algo que surge solo, y mucho más si el equipo está formado por gente acostumbrada a trabajar de la forma tradicional. Es completamente normal. Por eso, en muchos casos necesitas un facilitador, alguien que fomente buenas prácticas, resuelva conflictos y promueva actitudes que finalmente harán que el equipo sea multifuncional (pair programming, etc.). -Falta de empatía entre distintos roles de la empresa. Otro clásico. En una fábrica, la gente que está en la cadena de montaje puede estar separada de la gente de negocio y de la gente de calidad y no llegar a entenderse. Esta visión, de que el desarrollo software es parecido a la construcción de cosas físicas es algo que se extendió al mundo del software.
Pero el mundo del software no es así (Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas (1/2)). El manifiesto ágil recalca la importancia de la colaboración y empatía entre las personas (desarrolladores, testers, Product Owners, negocio, etc.). Al final, todos los roles son importantes y la empresa es un equipo que debe lograr el mismo objetivo: crear un buen producto que satisfaga al cliente. Un síntoma de implantar mal la agilidad es que cada rol no sepa lo que hacen otras personas de la misma empresa, otros equipos, que no haya comunicación y que se menosprecie el trabajo de los demás. Personalmente, esto lo noto muchísimo cuando se menosprecia la función del testing y de la calidad del software en general.
Webgrafia
i2btech. (s.f.). Obtenido de http://www.i2btech.com/blog-i2b/tech-deployment/para-que-sirve-elscrum-en-la-metogologia-agil/ obs. (s.f.). Obtenido de https://www.obs-edu.com/int/blog-project-management/scrum/scrummanager-y-scrum-master-quien-es-quien softeng. (s.f.). Obtenido de https://www.softeng.es/es-es/empresa/metodologias-detrabajo/metodologia-scrum/proceso-roles-de-scrum.html Softeng. (s.f.). Obtenido de https://www.softeng.es/es-es/empresa/metodologias-detrabajo/metodologia-scrum.html ub. (s.f.). Obtenido de http://www.il3.ub.edu/blog/scrum-beneficios-agile-methodologies/ Wiki. (s.f.). Obtenido de http://wikis.uca.es/wikiCE/index.php/Scrum