Definición de las metodologías ágiles
Autores de las
metodologías ágiles:
1. Jeff Sutherland: Co-creador del marco de trabajo Scrum, una de las metodologías ágiles más populares.
2. Ken Schwaber: Junto con Jeff Sutherland, es uno de los fundadores de Scrum y ha contribuido significativamente al desarrollo de esta metodología.
3. Kent Beck: Desarrollador y autor conocido por su papel en la creación de Extreme Programming (XP).
Principios del Manifiesto ágil.
¿Que es el manifiesto ágil?
El Agile Manifestó, Manifiesto ágil o Manifiesto para el desarrollo de software ágil es una declaración de valores y principios sobre nuevas formas de desarrollar software que surgió en 2001, como reacción a los tradicionales métodos formales con los que se trabajaba entonces en la industria.
Los 4 Valores del Manifiesto Agile:
Primer Valor:
Valorar a los individuos y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.
Es conocido como el más importante, sin embargo esto no implica en lo absoluto que las herramientas y procesos no lo son, sino que de alguna manera por así decirlo, pasan a un segundo plano. Si establecemos una prioridad en nuestra gestión, las personas están en el primer puesto y luego siguen los demás elementos.
En las metodologías ágiles (MA) se valora a las personas y se consideran como la razón de éxito principal, lo que provoca una mayor garantía en la productividad. Lograr esto implica que sean los procesos quienes se adapten al equipo y no el equipo a dichos procesos.
Como ustedes bien saben y hemos escuchado muchas veces, la clave del éxito de una organización son las personas, esto puede tener un mayor peso cuando se trata de una empresa del ámbito tecnológico; por ello debemos promover la confianza en el equipo, el respeto por cada persona, el compromiso con los objetivos del equipo, el proyecto, la empresa y finalmente la transparencia en todo el proyecto.
Segundo Valor: Software funcionando por encima de la documentación extensiva
El manifiesto ágil no da por vana la documentación, sólo la trivial y redundante. Los documentos son soportes que nos permiten transferir conocimiento, registran datos relevantes en el tiempo, y en otros tipos de escenarios son obligatorios. Pero su envergadura debe ser mucho menor que el producto final, básicamente la documentación debe ser corta y limitarse a lo fundamental, priorizando el contenido más que a la presentación.
A través de la Documentación no generamos valor, al menos no el que conseguimos a través de una comunicación directa entre las personas, y a través de la interacción con los entregables del producto. Siempre que sea posible debemos reducir al mínimo necesario el uso de documentación, ya que requiere de un trabajo que no aporta un valor directo al producto. Así también evitamos la aparición de barreras de burocracia entre departamentos o entre personas.
La prioridad es obtener las funcionalidades de valor que espera el cliente con cada entregable. Con el fin de recibir la retroalimentación del cliente a la mayor brevedad posible y adherir las ideas o requerimientos resultantes de esta revisión al entregable final. De la misma manera, se deben identificar los errores lo antes posible, de forma que el cliente pueda obtener el producto que quiere.
Tercer Valor: Valorar más la colaboración con el cliente que la negociación contractual
Las prácticas ágiles son recomendadas cuando identificamos que los requerimientos son variables o inconsistentes, muchas veces debido a la rapidez con la que cambia el ambiente del cliente y el negocio.
El propósito de un proyecto ágil es aportar el mayor valor posible en el producto, no dominar una ejecución de acuerdo a los procesos y cumplimiento de planes.
Es más beneficioso y recomendable una colaboración activa y retroactiva entre el cliente y el equipo, que la limitación que se suele tener en un contrato por la acotación de responsabilidades de cada parte.
Por tal motivo para prevenir el desencanto por parte del cliente y del equipo y obtener respuesta positiva, el valor debe residir más en una colaboración continua con el cliente que en la elaboración del contrato, comprometiendo al cliente con el equipo de trabajo a través de una participación constante durante todo el trayecto del proyecto.
Cuarto Valor: Valorar más la respuesta ante el cambio que seguir un plan
.png)
En el mundo ágil, resulta más beneficioso y conveniente tener una rápida respuesta ante los cambios que seguir una planificación o plan ya establecido. Poder anticiparnos a los posibles cambios y tener la capacidad de adaptarnos a ellos de forma rápida y progresiva, esto hace que se diferencie bastante de la gestión de proyectos tradicional, donde lo usual es evitar las desviaciones ya que no es su fuerte el responder a los cambios.
Este valor, más que dar seguimiento a los planes, se base en la capacidad de respuesta. Todo esto se debe a la naturaleza cambiante de la de los proyectos de tecnología.
Principios del manifiesto ágil:
1. Satisfacer al cliente
Principio: nuestra principal prioridad es satisfacer al cliente mediante la entrega temprana y continuada de software con valor.
Con el propósito de fidelizar al cliente se busca satisfacerlo con el producto o servicio entregado, en este sentido nos enfocamos en dar valor desde el primer momento, tomando en cuenta sus necesidades, en cada una de las etapas del proyecto, mediante una oportuna comunicación
2. Estar abiertos al cambio
Principio: aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Por experiencia sabemos que los requisitos pueden ser modificados, independientemente que el proyecto este bastante avanzado, usar una metodología adaptativa conlleva a revisar y reaccionar de forma rápida ante los cambios; en ocasiones hasta el diseño inicial es modificado, la clave es aprovechar el cambio para proporcionar una ventaja competitiva a nuestro cliente.
3. Entregas frecuentes
Principio: entregamos software funcional frecuentemente, entre dos semanas y dos meses, dependiendo de los Sprint del proyecto, siempre es positivo tener más iteraciones en menos tiempo.
El proceso se ejecuta gradualmente, dividiendo el proyecto en pequeñas partes consiguiendo efectuar las entregas en pocas semanas, de este modo el cliente recibe paso a paso el código del software, pudiendo cerciorarse de su funcionalidad de manera continua
4. Trabajo colaborativo
Principio: Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto
En un entorno ágil se requiere que todos los involucrados interactúen diariamente, aunque las actividades se gestionen de forma independiente, además que cada quien este al tanto de sus labores, sin que una figura autoritaria dirija la gestión.
5. Motivar al equipo
Principio: los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
Aquí juega un papel importante la comunicación y la selección del equipo, en los entornos ágiles la información debe fluir de forma rápida y aunque todos los miembros del equipo se auto gestionen, las reuniones cortas pero frecuentes, servirán para conocer sus habilidades, escucharlos y motivarlos.
6. Comunicación abierta y directa
Principio: el método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
Los miembros del proyecto deben estar en continua comunicación por diferentes canales, sin embargo, algunas veces es necesaria la conversación cara a cara y aunque estén en diferentes departamentos, niveles en la organización o trabajen de forma remota se requiere tener un contacto de forma intermitente, por si surgen dudas o se necesitan comunicar alguna información.
7. Lenguaje sencillo
El software funcionando es la principal medida progreso.
Nos interesa que cliente esté involucrado en todas las fases del proyecto para que se sienta comprometido y satisfecho, evitando retrasos o el estancamiento del desarrollo, aquí es crucial el lenguaje, debemos expresarnos de forma sencilla, evitando detalles técnicos ya que en su mayoría no son informáticos.
8. Mantener un ritmo sostenible
Principio: los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
La metodología se basa en mantener un ritmo sostenido a lo largo del tiempo, donde el software o servicio se va desarrollando y en cada etapa se analiza con la finalidad de hacer mejoras, buscando un resultado excelente.
9. Buscar la excelencia
Principio: la atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
El diseño y a la excelencia técnica son importantes en los proyectos ágiles, por ello se revisa y ajusta en cada iteración, mientras el software se va desarrollando, se realizan mejoras increméntales para garantizar su correcta funcionalidad y alcanzar la excelencia.
10. Lo simple y lo breve
Principio: la simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
El cliente se sentirá satisfecho y cómodo si los entregable están en el tiempo planificado y son simples de analizar, trayendo como resultado que su colaboración sea activa y continua.
11. Equipos autónomos
Principio: las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
La idea fundamental es crear equipos auto organizados para que proyecto tenga éxito, donde el líder cumple la función de facilitador que distribuye las tareas y comparte la responsabilidad. En un entorno ágil todos los miembros del equipo son responsables del proyecto, cada integrante debe sentirse respetado y con libertad para decidir cómo es más cómodo realizar sus labores, sin olvidar que debe mantener el contacto, ya que ninguno puede trabajar de forma aislada.
12. Retroalimentación
Principio: a intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
La retroalimentación obtenida de los Stakeholders a lo largo del proceso de desarrollo es crucial porque siempre se buscar mejorar en cada iteración e implementar las mejoras, aunque en ocasiones pensemos que son pequeñas o no son lo suficientemente significativas, a veces estos ajustes marcan la diferencia.
Programación XP:
La programación extrema es una metodología de desarrollo de software que forma parte de lo que se conoce colectivamente como metodologías ágiles. XP se basa en valores, principios y prácticas, y su objetivo es permitir que equipos pequeños y medianos produzcan software de alta calidad y se adapten a los requisitos cambiantes y en evolución.
La Programación Extrema (Extreme Programming o XP) es una metodología de desarrollo de software ágil que se centra en mejorar la calidad del software y la satisfacción del cliente mediante prácticas específicas. Fue creada por Kent Beck a fines de la década de 1990 y ha sido utilizada con éxito en diversos proyectos de desarrollo de software. Se basa en principios y valores que buscan maximizar la flexibilidad
Ejemplo:
Al desarrollar un proyecto y cambiar algo que cambio el cliente en un momento donde el programa ya esta en una etapa avanzada.
Valores de XP:
Los valores de XP: comunicación, sencillez, retroalimentación, valor y respeto. Veamos cada uno de ellos con más detalle.
Xp Values And Principles
Image Src: Alexsoft.com
Comunicción: La falta de comunicación impide que los conocimientos fluyan dentro de un equipo. A menudo, cuando hay un problema, alguien ya sabe cómo resolverlo. Pero la falta de comunicación les impide conocer el problema o contribuir a su solución. Así, el problema acaba resolviéndose dos veces, generando residuos.
Simplicidad: La simplicidad dice que siempre hay que esforzarse por hacer lo más sencillo que funcione. A menudo se malinterpreta y se interpreta como lo más sencillo y punto, ignorando la parte de «que funciona».
También es crucial recordar que la simplicidad es muy contextual. Lo que es sencillo para un equipo, es complejo para otro, dependiendo totalmente de las habilidades, la experiencia y los conocimientos de cada equipo.
Retroalimentación: La retroalimentación en las metodologías de desarrollo de software más tradicionales, tipo cascada, a menudo es «demasiado pequeña, demasiado tarde».
XP, sin embargo, adopta el cambio y los equipos de XP se esfuerzan por recibir una retroalimentación temprana y constante. Si es n
ecesario corregir el rumbo, los XPers quieren saberlo lo antes posible.
Metodología ágil Kanban:
Kanban es una metodología ágil que se originó en el ámbito de la fabricación y la gestión de la cadena de suministro, pero que también ha sido aplicada con éxito en el desarrollo de software y otros contextos. La palabra "Kanban" es de origen japonés y significa "tarjeta visual" o "registro visual".
Ejemplo:
Un equipo de desarrollo de software que utiliza la metodología ágil Kanban para gestionar su trabajo
Cada tarea está representada por una tarjeta en el tablero Kanban.
El equipo tiene un límite de trabajo en proceso (WIP) de 2, lo que significa que no pueden tener más de dos tarjetas en la columna "En Proceso" al mismo tiempo. Esto ayuda a evitar la sobrecarga de trabajo y a mantener un flujo de trabajo constante.
Cómo funciona la metodología Kanban:
Hoy en día, los tableros Kanban son en su mayoría tableros virtuales con columnas que representan las etapas del trabajo (¡aunque aún se pueden dibujar tableros Kanban en pizarras blancas y dar seguimiento al trabajo con post-it!). En un tablero, una “tarjeta Kanban” representa una tarea, y esta tarjeta de tarea avanza a través de las etapas del trabajo a medida que se finaliza. Los equipos que usan un sistema Kanban tienden a colaborar en un único tablero Kanban, aunque las tareas generalmente se asignan a miembros individuales del equipo.
Los principios Kanban:
Existen cuatro principios básicos que te ayudarán a guiar a tu equipo al momento de implementar la metodología Kanban:
1. Empieza con lo que haces ahora
Puedes implementar el marco Kanban a cualquier proceso o flujo de trabajo actual. A diferencia de algunos procesos de gestión ágil más definidos como Scrum, el marco Kanban es lo suficientemente flexible como para adaptarse a las prácticas centrales de tu equipo de trabajo.
2. Comprométete a buscar e implementar cambios progresivos y evolutivos
Los grandes cambios pueden ser perjudiciales para tu equipo y, si intentas cambiar todo a la vez, es posible que el nuevo sistema no funcione como esperabas. Ese es el motivo por el cual el marco Kanban está diseñado para fomentar la mejora continua y el cambio progresivo. En lugar de cambiar todo de una vez, empieza por buscar cambios progresivos para lograr que los procesos de tu equipo realmente evolucionen con el tiempo.
3. Respeta los procesos, los roles y las responsabilidades actuales
A diferencia de otras metodologías Lean, Kanban no tiene roles integrados y puede funcionar con la estructura y los procesos actuales de tu equipo. Además, tu proceso actual podría tener elementos excelentes, que se perderían si intentaras modificar completamente tu sistema de trabajo de un momento a otro.
4. Impulsa el liderazgo en todos los niveles
Con el espíritu de mejora continua, el método Kanban reconoce que el cambio puede provenir de cualquier dirección y no solo “de arriba abajo”. Con Kanban, se alienta a los miembros del equipo a participar, proponer nuevas formas para lograr que los procesos evolucionen y emprender nuevas iniciativas de trabajo.
Las 6 prácticas de la metodología Kanban
Los principios básicos de Kanban te ayudan a guiar la mentalidad de tu equipo al momento de abordar un flujo de trabajo Kanban. Para implementar un proceso Kanban, sigue estas seis prácticas que usan las grandes empresas y que te permitirán ayudar a tu equipo a implementar una mentalidad de mejora continua y a lograr un crecimiento progresivo: los principios esenciales del marco Kanban.
1. Visualizar el trabajo
Una de las principales ventajas de Kanban es que puedes visualizar cómo el trabajo “avanza” a través de las etapas. Una tarjeta Kanban de tarea comenzará su viaje en el lado izquierdo de tu tablero y, a medida que tu equipo trabaja en ella, recorrerá lentamente las siguientes etapas hasta que aterrice en la columna Finalizadas. Esta práctica no solo te brinda una idea general de cómo el trabajo avanza a través de las etapas, sino que también te permite obtener información en tiempo real y apreciar de un vistazo el estado de los proyectos.
2. Limitar el trabajo en curso
Como metodología ágil, Kanban se centra en un principio de entrega temprana, lo que implica que las tareas deben moverse rápidamente de una columna a otra en lugar de estancarse en un estado ambiguo de “trabajo en progreso” (wip). Aunque no existe un requisito establecido sobre cuántas tareas deben estar “en progreso” en un momento dado, es importante establecer los límites del trabajo; por lo que anima a tu equipo a centrarse en finalizar tareas individuales y a evitar realizar varias tareas a la vez.
3. Gestionar el flujo de trabajo
La práctica n.° 2 recomienda limitar la cantidad de trabajo en curso, y la mejor manera de hacerlo es con la optimización del flujo de tareas dentro del tablero Kanban. Gestionar y mejorar el flujo de trabajo te permitirá controlar el tiempo predestinado para el trabajo y así poder reducir el tiempo de entrega (el tiempo que pasa entre el inicio de una tarea hasta que llega a la columna Finalizadas de tu tablero Kanban) y garantizar que estás entregando tareas o enviando nuevos productos mientras siguen siendo relevantes.
4. Implementar políticas de procesos explícitas
Debido a la rapidez con la que se mueven las tareas en Kanban, asegúrate de que tu equipo haya establecido y comunicado claramente las convenciones. Las políticas de tu proceso deben guiar a tu equipo en la implementación de la metodología Kanban. Además, se debe alentar a todos en el equipo a participar e innovar las políticas Kanban, tal como se establece en el cuarto principio básico de Kanban: Impulsar el liderazgo en todos los niveles.
5. Implementar ciclos de comentarios
En Kanban, necesitas recopilar comentarios de dos grupos distintos: tus clientes y tu equipo.
Recopila comentarios de tus clientes sobre la calidad y eficacia de la solución que produjo el equipo. ¿Fue el producto adecuado? ¿Hubo algún problema? En el caso de que haya surgido algún problema, como errores en un código o cualquier otro defecto del producto, revisa tu flujo Kanban y agrega más tiempo para la revisión, los ajustes y la evaluación.
Realiza consultas frecuentes con el equipo sobre el proceso de ejecución de un marco Kanban. ¿Cómo se sienten con los resultados? Aquí tienes otra oportunidad para fomentar el liderazgo en todos los niveles y mejorar las políticas de procesos del equipo.
6. Mejorar colaborando y evolucionar experimentando
En esencia, Kanban se trata de una mejora continua. Sin embargo, también significa que otros sistemas podrían funcionar bien junto con Kanban. Ya sea Scrum o alguna otra metodología, debes estar siempre dispuesto a colaborar, experimentar y desarrollar tus procesos si es necesario.
Metodología SCRUM:
¿Qué es SCRUM?:
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.
¿Por qué utilizar SCRUM?
Scrum permite a los equipos de desarrollo priorizar los módulos que aportan mayor valor al negocio y a la organización de una manera iterativa, recibiendo constante retroalimentación del área de negocio para adaptar la construcción del producto a las cambiantes necesidades del proyecto.
Así mismo se exponen los avances del equipo de desarrollo de forma regular al resto del equipo. Esta forma de trabajo propicia la construcción de productos de manera rápida, flexible y transparente, lo que asegurará una entrega del producto muy acercada a los deseos del cliente, habiendo optimizado tiempo, recursos y esfuerzos durante el desarrollo.
¿Cómo funciona la metodología Scrum?
La metodología Scrum se puede aplicar a todo tipo de trabajo en equipo, ya que ayuda a administrar y estructurar los proyectos de manera eficaz. Como en el juego de rugby, esta metodología para las empresas funciona juntando las cabezas de los miembros de un equipo para administrar el trabajo.
La manera en que funciona la metodología Scrum es muy sencilla: una vez que se han creado los equipos se reparten el trabajo en una lista de pequeños entregables con un orden de prioridad; los tiempos de entrega se dividen en ciclos conocidos como sprints, que por lo regular representan una semana.
Todos los integrantes colaboran en función de sus conocimientos individuales y el trabajo se optimiza a través de diferentes reuniones que se tienen al término de cada sprint.
El objetivo principal de la metodología Scrum es involucrarse con los clientes, el mercado y la tecnología a través de pequeñas acciones que ayuden a aumentar la productividad y la calidad de los productos y, sobre todo, lograr un mayor impacto comercial.
Características de la metodología Scrum
Reconoce la metodología Scrum por estas 6 características:
1. Inestabilidad
La mayoría de los métodos prefieren eliminar la incertidumbre; en cambio, la metodología Scrum señala el lugar a donde se quiere llegar sin establecer un proceso rígido, con lo que da más libertad creativa y fomenta las respuestas más novedosas.
2. Organización autónoma de los equipos
Imagina que un proyecto actúa como una startup y en lugar de traer demasiada información preconcebida, el equipo de desarrollo encuentra su propia forma de operar.
Los autores hacen énfasis en ciertos valores como la autonomía, la trascendencia y la influencia cruzada. Así cada equipo puede autodeterminar la manera en que trabaja y establece sus propias metas, que cada vez son más complejas y llevarán al «gran descubrimiento». Además tendrán la ventaja de contar con especialistas de diferentes áreas que contagien con su conocimiento y experiencia a otras áreas y que, a su vez, sean influidos por otros.
3. Fases de desarrollo simultáneas
Cada proyecto tiene una fecha límite de presentación ante el cliente, pero también las áreas tienen sus propios tiempos establecidos. Mientras que el área de producción podrá tener márgenes cortos, es probable que los diseñadores dispongan de lapsos mayores. Aun así, el proyecto deberá tener su propio pulso que se sincronizará, disminuirá o aumentará conforme pase el tiempo.
En una forma de trabajo tradicional, hay marcas de tiempo fijas y controles de calidad que reducen el riesgo; mientras que en un enfoque Scrum deberás asumir un margen de riesgo más amplio, ya que la integración y el debate entre varios puntos de vista darán lugar a respuestas extraordinarias.
4. Aprendizaje múltiple
Una de las ventajas clave es que un equipo dinámico podrá resolver las dificultades con flexibilidad. Es necesario que sus miembros estén inmersos en la investigación de su entorno, con lo que podrán responder ante los cambios en el mercado.
Este entorno potencia el aprendizaje individual y grupal ya que es un sistema multinivel. Esto quiere decir que el aporte de cada miembro puede darse en direcciones que no habían sido previstas, mientras que el grupo debe mantener un interés alto en fortalecer sus conocimientos teóricos y prácticos y así alentar al descubrimiento.
5. Control sutil
En lugar de pensar en controles de calidad demasiado estructurados, un proyecto Scrum incluirá puntos de inversión que ayudarán a reducir la ambigüedad y las tensiones, así como proveer estabilidad.
6. Transmisión organizacional del aprendizaje
Tras implementar la metodología Scrum en unas cuantas áreas de tu empresa, verás que toda la organización se contagiará del conocimiento adquirido. Scrum puede convertirse en una forma de trabajo general, sobre todo cuando se aprovechan los hallazgos de un proyecto anterior (aunque fuese fallido) para superar retos actuales.
Además, en un proyecto podrás encontrar ciertos individuos inusualmente capaces, como mencionó un ejecutivo de Honda a Takeuchi y Nonaka, y trasplantarlos en otros proyectos clave donde implementarán la metodología dentro de un nuevo grupo de personas.
Los roles dentro de la metodología Scrum
Dentro del marco de trabajo Scrum existen 4 roles básicos:
Propietario del producto (Product owner). Se trata de la persona que determina las prioridades del proyecto y representa a la empresa o los usuarios.
Equipo de desarrollo. Es el grupo de trabajo que llevará a la realidad el producto que necesita el propietario.
Facilitador de proyectos (Scrup master). Es la persona que gestiona dinámicas del equipo de trabajo y ayuda a llegar a la consecución del objetivo.
Interesados (Stakeholders). Son aquellos que tienen algún interés en el producto y observan su desarrollo, ya sea como clientes, patrocinadores, directivos de la compañía u otros actores externos.
Las 3 fases de la metodología Scrum
Fases de la metodología scrum
1. Preparación para el juego
Es el momento en que se establecen la visión y la planificación conforme a los objetivos específicos del proyecto. Deberás crear un esquema inicial para el trabajo sin olvidar que cambiará conforme avanza la ejecución.
El sprint es el momento clave dentro del juego de la metodología, así como esprintar es lo básico del scrum en el rugby. Cada sprint puede durar desde 1 hasta 6 semanas, aunque lo recomendable es que sea menor a un mes.
Consiste en el desarrollo que parte de una etapa anterior o de otro proyecto, y también de un producto o sistema desde cero. Requiere procesos de terminación intermedios, gracias a los cuales se pueda validar o corregir el avance.
3. Post-juego
Una vez que el producto está terminado, es necesario entregar toda la documentación que avale el proceso de trabajo y llevar a cabo las pruebas finales.
¿Qué es un flujo de trabajo Scrum?
Un flujo de trabajo Scrum implica un conjunto de ceremonias, roles y artefactos que ayudan a los equipos a organizar su trabajo y entregar resultados en ciclos cortos llamados sprints.
El flujo de trabajo se centra en Scrum, un marco dentro de la metodología Agile. Permite a los equipos realizar el trabajo en pequeños lotes en lugar de una sola vez. Mejora la responsabilidad, ofrece flexibilidad y ayuda a los equipos a mejorar continuamente sus productos y servicios.
Un flujo de trabajo Scrum (también conocido como un flujo de trabajo de sprint o un flujo de trabajo Agile) implica la incorporación de los principios de Scrum en sus procesos de negocio. Ayuda a los equipos a entregar un trabajo de alta calidad que proporciona el mayor valor posible a la empresa y al usuario final.
Vamos a utilizar el desarrollo de productos como ejemplo para mostrar cómo el marco de Scrum se puede aplicar a un flujo de trabajo empresarial.
Para incorporar Scrum en su proceso de desarrollo de productos, se empieza por dividir el proceso en iteraciones (conocidas como Sprints). Estas iteraciones incorporan todas las etapas de su flujo de trabajo de desarrollo de productos, que podrían incluir lo siguiente:
- Ideación
- Investigación
- Planificación
- Creación de prototipos
- Pruebas
- Cálculo de costes
- Creación
Cada iteración puede durar entre una y cuatro semanas. Al final de cada iteración, el equipo de desarrollo del producto revisa los éxitos y los fracasos, y crea un nuevo plan de acción para la siguiente iteración.
.png)
Comentarios
Publicar un comentario