Metodología Agile
¿Qué es Agile?
El desarrollo de software Agile se basa en un enfoque incremental e iterativo. En lugar de planificar en profundidad al comienzo del proyecto, las metodologías Agile están abiertas a cambiar los requisitos a lo largo del tiempo y fomentan los comentarios constantes de los usuarios finales. Los equipos multifuncionales trabajan en iteraciones de un producto durante un período de tiempo, y este trabajo se organiza en un backlog que se prioriza en función del valor del negocio o del cliente. El objetivo de cada iteración es producir un producto que funcione.
En las metodologías Agile, el liderazgo fomenta el trabajo en equipo, la responsabilidad y la comunicación cara a cara. Grupos de interés empresariales y desarrolladores deben trabajar juntos para alinear el producto con las necesidades de los clientes y los objetivos de la empresa.
Agile se refiere a cualquier proceso que se alinee con los conceptos del Manifiesto Agile. En febrero de 2001, 17 desarrolladores de software se reunieron en Utah para debatir sobre métodos de desarrollo ligeros. Publicaron el Manifiesto para el desarrollo de software Agile, en el que se explicaba cómo encontraron "mejores formas de desarrollar software haciéndolo y ayudando a otros" e incluyeron cuatro valores y 12 principios. El Manifiesto Agile es un contraste dramático con el texto tradicional Una guía para el cuerpo de conocimientos de gestión de proyectos (Guía PMBOK®) y los estándares.
Guía para la gestión de proyectos
Su ventanilla única para todo tipo de gestión de proyectos
¿Está listo para sacar más provecho de sus esfuerzos de gestión de proyectos? Visite nuestra guía completa de gestión de proyectos para obtener consejos, prácticas recomendadas y recursos gratuitos para gestionar su trabajo de manera más efectiva.
12 principios de la metodología Agile
El Manifiesto Agile menciona 12 principios que guían a los equipos sobre cómo trabajar con agilidad. Estos son los principios:
- Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso.
- Los cambios en los requisitos son bienvenidos, incluso en una etapa avanzada del desarrollo. Los procesos Agile aprovechan el cambio para obtener la ventaja competitiva del cliente.
- Entregue software funcional con frecuencia, de un par de semanas a un par de meses, con preferencia a la escala de tiempo más corta.
- Negocios personas y desarrolladores deben trabajar juntos a diario a lo largo del proyecto.
- Desarrolle proyectos en torno a personas motivadas. Deles el entorno y el apoyo que necesitan, y confíe en ellos para realizar el trabajo.
- El método más eficiente y eficaz para transmitir información a un equipo de desarrollo y dentro de él es la conversación cara a cara.
- El software funcional es la medida principal del progreso.
- Los procesos Agile promueven un desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante de forma indefinida.
- La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
- La simplicidad, el arte de maximizar la cantidad de trabajo que no se hace, es esencial.
- Las mejores arquitecturas, requisitos y diseños surgen de los equipos autoorganizados.
- A intervalos regulares, el equipo reflexiona sobre cómo volverse más efectivo, luego sintoniza y ajusta su comportamiento en consecuencia.
Ventajas de la metodología Agile
Agile evolucionó a partir de diferentes enfoques de software ligeros en la década de 1990 y es una respuesta a la aversión de algunos gerentes de proyectos a la metodología en cascada rígida y lineal. Se centra en la flexibilidad, la mejora continua y la velocidad.
A continuación, le mostramos algunas de las principales ventajas de Agile:
- El cambio es bienvenido: Con ciclos de planificación más cortos, es fácil adaptarse y aceptar cambios en cualquier momento durante el proyecto. Siempre existe la oportunidad de refinar y volver a priorizar los pendientes, lo que permite a los equipos introducir cambios en el proyecto en cuestión de semanas.
- El objetivo final puede ser desconocido: La metodología Agile es muy beneficiosa para proyectos en los que el objetivo final no está definido claramente. A medida que el proyecto avanza, los objetivos saldrán a la luz y el desarrollo se puede adaptar fácilmente a estos requisitos cambiantes.
- Entrega más rápida y de alta calidad: Dividir el proyecto en iteraciones (unidades manejables) permite que el equipo se centre en el desarrollo, las pruebas y la colaboración de alta calidad. Realizar pruebas durante cada iteración significa que los errores se identifican y resuelven con mayor rapidez. Y este software de alta calidad se puede entregar más rápido con iteraciones sucesivas y coherentes.
- Sólida interacción del equipo: Agile destaca la importancia de las comunicaciones frecuentes y las interacciones cara a cara. Los equipos trabajan juntos y las personas pueden asumir la responsabilidad y ser propietarios de partes de los proyectos.
- Los clientes son escuchados: Los clientes tienen muchas oportunidades para ver cómo se entrega el trabajo, compartir sus comentarios y tener un impacto real en el producto final. Pueden obtener una sensación de propiedad al trabajar tan estrechamente con el equipo del proyecto.
- Mejora continua: Los proyectos Agile fomentan los comentarios de usuarios y miembros del equipo a lo largo de todo el proyecto, por lo que las lecciones aprendidas se utilizan para mejorar futuras iteraciones.
Consejos y prácticas recomendadas para su próximo proyecto utilizando la metodología Agile.
Desventajas de la metodología Agile
Si bien el nivel de flexibilidad en Agile suele ser positivo, también incluye algunos sacrificios. Puede ser difícil establecer una fecha de entrega sólida, se puede descuidar la documentación o el producto final puede ser muy diferente de lo previsto originalmente.
A continuación, le mostramos algunas de las desventajas de Agile:
- La planificación puede ser menos concreta: A veces, puede ser difícil definir una fecha de entrega sólida. Dado que Agile se basa en la entrega programada y los gerentes de proyectos a menudo están reprogramando las tareas, es posible que algunos elementos programados originalmente para la entrega no estén finalizados a tiempo. Además, se pueden agregar sprints adicionales en cualquier momento del proyecto, lo que se añade al cronograma general.
- El equipo debe ser experimentado: Los equipos Agile suelen ser pequeños, por lo que los miembros del equipo deben ser altamente calificados en una variedad de áreas. También deben entender y sentirse cómodos con la metodología Agile elegida.
- Compromiso de tiempo de los desarrolladores: La metodología Agile tiene más éxito cuando el equipo de desarrollo está completamente dedicado al proyecto. La participación activa y la colaboración son necesarias a lo largo del proceso Agile, que requiere más tiempo que un enfoque tradicional. También significa que los desarrolladores deben comprometerse con toda la duración del proyecto.
- La documentación puede descuidarse: El Manifiesto Agile prefiere el software de trabajo más que la documentación completa, por lo que algunos miembros del equipo pueden sentir que es menos importante centrarse en la documentación. Si bien la documentación completa por sí sola no conduce al éxito del proyecto, los equipos Agile deben encontrar el equilibrio adecuado entre la documentación y el debate.
- El producto final puede ser muy diferente: Es posible que el proyecto Agile inicial no tenga un plan definitivo, por lo que el producto final puede parecer muy diferente de lo que se había previsto inicialmente. Dado que Agile es tan flexible, se pueden agregar iteraciones nuevas en función de la evolución de los comentarios de los clientes, lo que puede conducir a una entrega final muy diferente.
El ciclo de desarrollo Agile
A continuación, le mostramos las fases del ciclo de desarrollo Agile. Es importante tener en cuenta que estas fases no deberían ocurrir en sucesión; son flexibles y evolucionan siempre. Muchas de estas fases se llevan a cabo en paralelo.
- Planificación: Una vez que una idea se considera viable y factible, el equipo del proyecto se reúne y trabaja para identificar las funciones. El objetivo de esta fase es dividir la idea en piezas de trabajo más pequeñas (las funciones) y luego priorizar cada función y asignarla a una iteración.
- Análisis de requisitos: Esta fase involucra muchas reuniones con gerentes, grupos de interés y usuarios para identificar los requisitos del negocio. El equipo debe recopilar información como quién utilizará el producto y cómo lo utilizará. Estos requisitos deben ser cuantificables, relevantes y detallados.
- Diseño: El diseño del sistema y del software se prepara a partir de los requisitos identificados en la fase anterior. El equipo debe pensar en cómo será el producto o la solución. El equipo de pruebas también tiene una estrategia de prueba o un plan para proceder.
- Implementación, codificación o desarrollo: Esta fase consiste en crear y probar funciones, y programar iteraciones para la implementación (siguiendo el enfoque de desarrollo iterativo e incremental [DII]). La fase de desarrollo comienza con la iteración 0, porque no se entregan funciones. Esta iteración sienta las bases del desarrollo, con tareas como la finalización de contratos, la preparación de los entornos y la financiación.
- Pruebas: Una vez que se ha desarrollado el código, se prueba según los requisitos para asegurarse de que el producto realmente resuelve las necesidades de los clientes y coincide con las historias de usuario. Durante esta fase, se realizan pruebas unitarias, pruebas de integración, pruebas del sistema y pruebas de aceptación.
- Implementación: Después de las pruebas, el producto se entrega a los clientes para que los utilicen. Sin embargo, la implementación no es el final del proyecto. Una vez que los clientes comienzan a usar el producto, pueden enfrentarse a problemas nuevos que el equipo del proyecto tendrá que abordar.
Metodologías que se utilizan para implementar metodologías Agile
Agile es un marco de trabajo y existe una serie de métodos específicos dentro del movimiento Agile. Puede pensar en ellos como diferentes sabores de Agile:
- Programación extrema (XP): También conocida como XP, la programación extrema es un tipo de desarrollo de software destinado a mejorar la calidad y la capacidad de respuesta a los requisitos cambiantes de los clientes. Los principios de XP incluyen comentarios, asumir la simplicidad y aceptar el cambio.
- Desarrollo basado en funciones (FDD): Este proceso de desarrollo de software iterativo e incremental combina las mejores prácticas del sector en un solo enfoque. Hay cinco actividades básicas en el FDD: desarrollar el modelo general, crear una lista de funciones, planificar por función, diseñar por función y compilar por función.
- Desarrollo de sistemas adaptativos (ASD): El desarrollo de sistemas adaptativos representa la idea de que los proyectos siempre deben estar en un estado de adaptación continua. El ASD tiene un ciclo de tres series repeticiones: especular, colaborar y aprender.
- Método de desarrollo de sistemas dinámicos (DSDM): Este marco de entrega de proyectos Agile se utiliza para desarrollar soluciones de software y no de TI. Aborda los errores comunes de los proyectos de TI, como superar el presupuesto, no cumplir con los plazos y la falta de participación de los usuarios. Los ocho principios del DSDM son: centrarse en las necesidades de la empresa, entregar a tiempo, colaborar, no comprometer nunca la calidad, desarrollar de forma incremental a partir de bases firmes, desarrollar de forma iterativa, comunicar de forma continua y clara, y demostrar control.
- Desarrollo de software lean (LSD): El desarrollo de software lean adopta los principios de fabricación Lean y TI Lean, y los aplica al desarrollo de software. Puede caracterizarse por siete principios: eliminar lo que no sirve, ampliar el aprendizaje, decidir lo más tarde posible, entregar lo más rápido posible, empoderar al equipo, desarrollar la integridad y ver el todo.
- Kanban: Kanban, que significa "signo visual" o "tarjeta" en japonés, es un marco visual para implementar Agile. Promueve cambios pequeños y continuos en su sistema actual. Sus principios incluyen: visualizar el flujo de trabajo, limitar el trabajo en curso, gestionar y mejorar el flujo, hacer que las políticas sean explícitas y mejorar continuamente.
- Crystal Clear: Crystal Clear es parte de la familia de metodologías Crystal. Se puede usar con equipos de seis a ocho desarrolladores y se centra en las personas, no en los procesos o artefactos. Crystal Clear requiere lo siguiente: entrega frecuente de código utilizable a los usuarios, mejora reflexiva y comunicación osmótica preferiblemente al ser co-localizado.
- Scrum: Scrum es una de las formas más populares de implementar Agile. Es un modelo de software iterativo que sigue un conjunto de roles, responsabilidades y reuniones que nunca cambian. Los sprints, que suelen durar de una a dos semanas, permiten al equipo entregar software con regularidad.
Otras prácticas en la metodología Agile
Existen muchas otras prácticas y marcos relacionados con Agile. Incluyen:
- Modelado Agile (AM): El modelado Agile se utiliza para modelar y documentar sistemas de software y es un complemento a otras metodologías ágiles como Scrum, Programación Extrema (XP) y Proceso Unificado Racional (RUP). AM no es un proceso de software completo por sí mismo. Puede ayudar a mejorar los modelos con código, pero no incluye las actividades de programación.
- Proceso Unificado Racional (RUP): Creado por Rational Software Corporation, una división de IBM, RUP es un marco iterativo y adaptativo para el desarrollo de software. Según Rational, RUP es como un mentor en línea que proporciona pautas, plantillas y ejemplos para el desarrollo de programas. Los aspectos clave de la RUP incluyen un proceso basado en el riesgo, un desarrollo centrado en los casos de uso y un diseño centrado en la arquitectura.
- Lean vs Agile: El desarrollo Lean se centra en eliminar y reducir lo que no sirve (actividades que no aportan ningún valor). El desarrollo Lean toma los principios de la fabricación Lean y los aplica al desarrollo de software. Estos principios son muy similares a Agile, sin embargo Lean lo lleva un paso más allá. En la fase de desarrollo, selecciona, planifica, desarrolla, prueba e implementa solo una función antes de repetir el proceso para la siguiente función.
- Desarrollo basado en pruebas (TDD): El desarrollo basado en pruebas se basa en ciclos de desarrollo repetitivos y cortos. En primer lugar, un desarrollador escribe un caso de prueba automatizado (inicialmente fallido) para una nueva función y agrega rápidamente una prueba con la cantidad mínima de código para pasar esa prueba. Luego, refactoriza el nuevo código a estándares aceptables.
- Scaled Agile Framework (logotipo de marca comercial SAFe): Scaled Agile Framework es un método muy estructurado que ayuda a las grandes empresas a empezar a adoptar Agile. SAFe se basa en los principios Lean y Agile, y aborda problemas difíciles en las grandes organizaciones, como la arquitectura, la integración, la financiación y las funciones a escala. SAFe tiene tres niveles: equipo, programa y cartera.
- Desarrollo rápido de aplicaciones (RAD): El enfoque RAD para el desarrollo de software pone más énfasis en el desarrollo que en la planificación de las tareas. Sigue un modelo incremental, donde cada componente se desarrolla en paralelo. Las fases de RAD son: el modelado de negocios, el modelado de datos, el modelado de procesos, la generación de aplicaciones y las pruebas y la rotación.
- Método de control empírico: Con el desarrollo de software Agile, puede usar un método de control empírico, lo que significa que puede tomar decisiones en función de las realidades que observa en el proyecto real. El modelo empírico de control de procesos tiene tres partes: visibilidad, inspección y adaptación.
Cómo estimar presupuestos en Agile
Sin una planificación por adelantado y en profundidad, muchos gerentes de proyectos no están seguros de cómo calcular el costo y el presupuesto de un proyecto Agile.
Estimar el costo antes de que comience el proyecto puede ser todo un desafío, independientemente de la metodología del proyecto que utilice. Sin embargo, en un proyecto Agile, puede vincular la cantidad de tiempo que tomará el proyecto con su costo total.
Primero, cree un gráfico burndown y use la tasa de burndown para estimar cuántos sprints habrá en su proyecto y cuándo terminará el proyecto. Luego, calcule cuánto costará el equipo en función de sus honorarios por hora. Multiplique el honorario de cada persona por la cantidad de horas de trabajo por semana, luego multiplique eso por la cantidad de semanas en un sprint. Una vez que calcule el presupuesto inicial de su equipo, puede agregar cualquier otro costo, como tecnología, viaje o equipo.
También puede dividir cada historia de usuario en tareas. Una vez que tenga una idea de cuántas horas llevará completar cada tarea, puede estimar el presupuesto del proyecto.
Por último, puede usar el póker de planificación para estimar el esfuerzo necesario para los objetivos de desarrollo. El póker de planificación es una técnica gamificada basada en el consenso para estimar el esfuerzo de los objetivos de desarrollo. Cada miembro del equipo hace estimaciones jugando cartas numeradas boca abajo sobre la mesa, en lugar de decirlo en voz alta. Luego, se revelan las tarjetas y se analizan las estimaciones con todo el equipo.
Programación Agile y Emparejada
La programación de pares (también conocida como "emparejamiento") forma parte de las prácticas de programación extrema (XP). Es cuando dos programadores comparten una sola estación de trabajo, lo que incluye compartir una pantalla, un teclado y un mouse. El propósito de esta técnica es fomentar una mejor comunicación, aclaración del problema y comprensión de la solución. El emparejamiento a menudo se usa en proyectos Agile para entregar rápidamente productos de alta calidad, ¿pero siempre es necesario?
La respuesta depende de los programadores, la empresa y los objetivos. En algunos proyectos y programadores, el emparejamiento puede mejorar la productividad. Sin embargo, puede que no siempre sea apropiado para cada proyecto. Lo mejor que puede hacer es experimentar y ver si le funciona.
Cómo aborda Agile los requisitos de software
Agile ayuda a los equipos de desarrollo a centrarse en los requisitos más importantes de los clientes lo más rápido posible. Con comentarios continuos e interacciones frecuentes cara a cara, el equipo del proyecto y los grupos de interés entienden y priorizan los requisitos adecuados.
Los equipos Agile utilizan backlogs con historias de usuario para gestionar los requisitos. Antes de que comience una iteración, el equipo acuerda qué requisitos deben cumplir con la próxima entrega. Este enfoque colaborativo garantiza que se prioricen las funciones más importantes. Además, los requisitos se actualizan continuamente a lo largo del proyecto a medida que surgen nuevas informaciones.
¿Puede usar Agile para proyectos fuera del desarrollo de software?
Si bien Agile tradicionalmente se creó para el desarrollo de software, también se puede usar en muchos otros proyectos e industrias.
Es importante recordar que el desarrollo de software Agile nace de los principios de la fabricación Lean y del aprendizaje organizativo. Estas ideas no se basaban en un software para empezar. Además, muchas prácticas de Agile, como las reuniones de actualización y la gestión visual, son muy comunes y pueden aplicarse a cualquier sector.
No hay muchos casos de casos de equipos que usan Agile para cosas fuera del software, pero hay algunas. Por ejemplo, Kate Sullivan, abogada corporativa del equipo legal de The Lonely Planet, ha transformado la prestación de servicios de asuntos legales con Agile. El equipo utiliza pizarras y tarjetas, reuniones de actualización matutinas, priorización, iteraciones semanales y retrospectivas regulares.
La metodología Agile definitivamente se puede aplicar a proyectos fuera del desarrollo de software, solo tiene que encontrar el método y enfoque adecuados para sus necesidades. Puede empezar con tableros y tarjetas, una lista de pendientes de trabajo, reuniones de actualización o iteraciones (reuniones de planificación semanales) para ver cómo responde su equipo.
Cómo empezar a trabajar con Agile
Una forma sencilla de empezar con Agile es incorporar reuniones diarias de actualización en su proyecto. Las reuniones diarias de actualización son fáciles de incorporar a cualquier otra metodología de proyecto que ya esté utilizando (incluso en el método de cascada) y no requieren capacitación o transferencia de conocimientos. Reúnase en el mismo lugar todos los días durante unos diez minutos y pida a todos que hablen de lo que trabajaron el día anterior, de lo que trabajarán hoy y de cualquier obstáculo.
Si quiere hacer que el cambio completo a Agile ocurra de una vez, es posible que quiera empezar por comprender por qué el equipo y la organización quieren hacer este cambio. ¿Qué es y qué no funciona? ¿Qué buscan mejorar? Luego, podría realizar una evaluación Agile y obtener una vista completa de las personas, las habilidades y las tecnologías utilizadas.
Cualquiera que sea la ruta que elija, recuerde que Agile es flexible en su propia naturaleza. No hay una forma incorrecta o correcta de empezar con Agile. Haga lo que funcione para usted y su equipo.
La vista más reciente de Smartsheet, vista de tarjeta, ofrece a los equipos agiles una forma más visual de trabajar, comunicarse y colaborar en Smartsheet. La vista de tarjeta le permite centrar la atención con tarjetas enriquecidas, dar perspectiva con vistas flexibles y priorizar y ajustar el trabajo de manera más visual. Centre la atención con tarjetas visuales: muestre información en las tarjetas (campos personalizados, imágenes y codificaciones de color) para llamar la atención de su equipo. Categorice las tarjetas en carriles para organizar su trabajo de manera más visual.
Más información acerca de Smartsheet para el desarrollo de software
Metodología Scrum
Ventajas de Scrum
Scrum es un marco altamente prescriptivo con roles y ceremonias específicos. Si bien puede ser muchas información por aprender, estas reglas tienen muchas ventajas. Los beneficios de Scrum incluyen:
- Más transparencia y visibilidad del proyecto: Con las reuniones diarias de actualización, todo el equipo sabe quién está haciendo qué, eliminando muchos malentendidos y confusiones. Los problemas se identifican con anticipación, lo que permite al equipo resolverlos antes de que se salgan de control.
- Mayor responsabilidad del equipo: No hay ningún gerente de proyectos que le diga al Equipo Scrum qué hacer y cuándo. En cambio, el equipo decide colectivamente qué trabajo puede realizar en cada sprint. Todos trabajan juntos y se ayudan entre sí, mejorando la colaboración y empoderando a cada miembro del equipo para que sea independiente.
- Fácil de adaptarse a los cambios: Con sprints cortos y comentarios constantes, es más fácil hacer frente a los cambios y adaptarse a ellos. Por ejemplo, si el equipo descubre una nueva historia de usuario durante un sprint, puede agregar fácilmente esa función al siguiente sprint durante la reunión de refinamiento del backlog.
- Mayor ahorro de costos: La comunicación constante garantiza que el equipo sea consciente de todos los problemas y cambios en cuanto surjan, lo que ayuda a reducir los gastos y aumentar la calidad. Al codificar y probar funciones en fragmentos más pequeños, hay comentarios continuos y los errores se pueden corregir desde el principio, antes de que sean demasiado costosos para corregirlos.
Desventajas de Scrum
Si bien Scrum ofrece algunos beneficios concretos, también tiene algunas desventajas. Scrum requiere un alto nivel de experiencia y compromiso del equipo, y los proyectos pueden estar en riesgo de desviación del alcance.
A continuación, le mostramos las desventajas de Scrum:
- Riesgo de desviación del alcance: Algunos proyectos de Scrum pueden experimentar desviación del alcance debido a la falta de fecha de finalización específica. Sin fecha de finalización, los grupos de interés pueden sentirse tentados a seguir solicitando funcionalidad adicional.
- El equipo requiere experiencia y compromiso: Con roles y responsabilidades definidos, el equipo debe estar familiarizado con los principios de Scrum para tener éxito. Debido a que no hay roles definidos en el Equipo Scrum (todos lo hacen todo), se requiere de miembros del equipo con experiencia técnica. El equipo también debe comprometerse con las reuniones diarias de Scrum y mantenerse en el equipo durante la duración del proyecto.
- El Scrum Master equivocado puede arruinarlo todo: El Scrum Master es muy diferente a un gerente de proyectos. El Scrum Master no tiene autoridad sobre el equipo; tiene que confiar en el equipo que gestiona y nunca decirle qué hacer. Si el Scrum Master intenta controlar al equipo, el proyecto fallará.
- Las tareas mal definidas pueden derivar en imprecisiones: Los costos y cronogramas del proyecto no serán precisos si las tareas no están bien definidas. Si los objetivos iniciales no son claros, la planificación se vuelve difícil y los sprints pueden llevar más tiempo del estimado originalmente.
Funciones en Scrum
En Scrum hay tres roles específicos. Estos son:
- Dueño del Producto: El Dueño del Producto del scrum tiene la visión de lo que quiere construir y transmite esa visión al equipo. El Dueño del Producto se centra en los requisitos del negocio y del mercado, priorizando todo el trabajo que debe realizarse. Crea y gestiona el backlog, proporciona instrucciones sobre qué funciones enviar a continuación e interactúa con el equipo y otras partes interesadas para asegurarse de que todos entiendan los elementos del backlog del producto. El Dueño del Producto no es gerente de proyectos. En lugar de gestionar el estado y el avance, su trabajo es motivar al equipo con un objetivo y una visión.
- Scrum Master: A menudo considerado el entrenador del equipo, el Scrum Master ayuda al equipo a hacer su mejor trabajo posible. Esto significa organizar reuniones, lidiar con obstáculos y desafíos, y trabajar con el Dueño del Producto para garantizar que el backlog del producto esté listo para el próximo sprint. El Scrum Master también se asegura de que el equipo siga el proceso Scrum. No tiene autoridad sobre los miembros del equipo, pero sí tiene autoridad sobre el proceso. Por ejemplo, el Scrum Master no puede decirle a alguien qué hacer, pero puede proponer una nueva cadencia de sprint.
- Equipo Scrum: El Equipo Scrum está compuesto por cinco a siete miembros. Todos los miembros del proyecto trabajan juntos, se ayudan entre sí y comparten una profunda sensación de camaradería. A diferencia de los equipos de desarrollo tradicionales, no hay roles distintos como programador, diseñador o evaluador. Todos completan el conjunto de trabajo juntos. El Equipo Scrum es el propietario del plan para cada sprint; anticipan cuánto trabajo pueden realizar en cada iteración.
Pasos en el proceso Scrum
Existe un conjunto específico e inmutable de pasos en el flujo Scrum. Incluyen:
- Backlog del producto: El Dueño del Producto y el Equipo Scrum se reúnen para priorizar los elementos del backlog del producto (el trabajo en el backlog del producto proviene de historias de usuario y requisitos). El backlog del producto no es una lista de cosas que se deben completar, sino que es una lista de todas las funciones deseadas para el producto. Luego, el equipo de desarrollo saca el trabajo del backlog del producto para completarlo durante cada sprint.
- Planificación de sprints: Antes de cada sprint, el Dueño del Producto presenta los elementos principales del backlog al equipo en una reunión de planificación de sprints. Luego, el equipo elige qué trabajo puede realizar durante el sprint y mueve el trabajo del backlog del producto al backlog del sprint (que es una lista de tareas que se deben completar en el sprint).
- Perfeccionamiento/limpieza del backlog: Al final de un sprint, el equipo y Dueño del Producto se reúnen para asegurarse de que el backlog esté listo para el próximo sprint. El equipo puede eliminar historias de usuario que no sean relevantes, crear nuevas historias, reevaluar la prioridad de las historias o dividir historias de usuario en tareas más pequeñas. El propósito de esta reunión de "limpieza" es garantizar que el backlog solo contenga elementos relevantes y detallados, y que cumplan con los objetivos del proyecto.
- Reuniones diarias de Scrum: El Scrum diario es una reunión de actualización de 15 minutos en la que cada miembro del equipo habla sobre sus objetivos y cualquier problema que se haya venido planteando. El Scrum diario se realiza todos los días durante el sprint y ayuda a mantener al equipo encaminado.
- Reunión de revisión de sprints: Al final de cada sprint, el equipo presenta el trabajo que ha completado en una reunión de revisión del sprint. Esta reunión debe incluir una demostración en vivo, no un informe o una presentación de PowerPoint.
- Reunión de retrospectiva de sprints: También al final de cada sprint, el equipo reflexiona sobre lo bien que Scrum está trabajando para ellos y habla de los cambios que deben realizarse en el próximo sprint. El equipo puede hablar de lo que salió bien durante el sprint, de lo que salió mal y de lo que podría hacer de otra manera.
Herramientas, artefactos y métodos en Scrum
Además de las funciones y ceremonias, los proyectos Scrum también incluyen ciertas herramientas y artefactos. Por ejemplo, el equipo utiliza un tablero Scrum para visualizar el backlog o un gráfico burndown para mostrar el trabajo pendiente. Los artefactos y métodos más comunes son:
- Tablero Scrum: Puede visualizar el backlog de su sprint con un tablero de tareas Scrum. El tablero puede tener diferentes formas; tradicionalmente incluye tarjetas de índice, notas adhesivas o una pizarra. El tablero Scrum generalmente se divide en tres categorías: pendientes, trabajo en curso y hecho. El Equipo Scrum debe actualizar el tablero durante todo el sprint. Por ejemplo, si alguien tiene una tarea nueva, escribiría una tarjeta nueva y la colocaría en la columna correspondiente.
- Historias del usuario: Una historia de usuario describe una función de software desde la perspectiva del cliente. Incluye el tipo de usuario, lo que quiere y por qué lo quiere. Estas historias cortas siguen una estructura similar: como un
, quiero para que pueda El equipo de desarrollo utiliza estas historias para crear código que cumpla con los requisitos de las historias.
- Gráfico burndown: Un gráfico burndown representa todo el trabajo pendiente. El backlog suele estar en el eje vertical, con el tiempo a lo largo del eje horizontal. El trabajo restante puede estar representado por puntos de historia, días ideales, días del equipo u otras métricas. Un gráfico burndown puede alertar al equipo si las cosas no van según lo planeado y ayuda a mostrar el impacto de las decisiones.
- Scrum de gran escala (LeSS): Si quiere escalar elementos de Scrum a cientos de desarrolladores, el marco Scrum de gran escala (LeSS) ayuda a extender las reglas y las directrices sin perder lo principal del Scrum. Los principios se toman directamente de Scrum, sin embargo, se centra en escalar sin agregar sobrecarga adicional (como agregar más roles, artefactos o procesos).
- Timeboxing: Un timebox es un período establecido durante el cual un equipo trabaja para alcanzar un objetivo. En lugar de dejar que un equipo trabaje hasta que se alcance el objetivo, el enfoque del timebox deja de funcionar cuando se alcanza el límite de tiempo. Las iteraciones con timebox a menudo se utilizan en Scrum y Programación Extrema.
- Icebox: Las historias de usuario que se registran pero no se trasladan al desarrollo se almacenan en el icebox.
El término "icebox" fue creado por Pivotal Tracker, una herramienta de gestión de proyectos Agile.
- Scrum vs RUP: Si bien tanto Scrum como Rational Unified Process (RUP) siguen el marco Agile, RUP involucra una definición más formal del alcance, los logros más importantes y las fechas específicas (Scrum utiliza un backlog del proyecto en lugar del alcance). Además, RUP incluye cuatro fases principales del ciclo de vida del proyecto (inicio, elaboración, construcción y transición), mientras que Scrum dicta que todo el "ciclo de vida tradicional" se adapta a una iteración.
- Lean vs Scrum: Scrum es un marco de desarrollo de software, mientras que Lean ayuda a optimizar ese proceso. El objetivo principal de Scrum está en las personas, mientras que Lean se centra en el proceso. Ambos se consideran técnicas Agile, sin embargo Lean introduce dos conceptos principales: eliminar lo que no sirve y mejorar el flujo.
Cómo empezar a trabajar con Scrum
Trabajar con Scrum a menudo significa cambiar los hábitos del equipo. Necesitan asumir más responsabilidades, aumentar la calidad del código e impulsar la velocidad de entrega. Este nivel de compromiso actúa como agente de cambio; a medida que los equipos se comprometen con los objetivos del sprint, están cada vez más motivados para mejorar y entregar un producto de calidad más rápido.
Un buen lugar para empezar con Scrum es hablar sobre las funciones. Cada proyecto debe tener un Scrum Master, Dueño del Producto y Equipo Scrum. Tal vez quiera hablar sobre quién debería ser el Scrum Master y Dueño del Producto, o si estas funciones ya están asignadas, es posible que quiera aclarar sus roles y responsabilidades.
Dependiendo de lo familiarizado que esté su equipo con Scrum, es posible que también quiera optar por sesiones de capacitación. Los coaches y capacitadores certificados de Scrum y los proveedores de educación registrados de Scrum Alliance pueden ayudar a su equipo a aprender y adoptar Scrum.
La vista más reciente de Smartsheet, vista de tarjeta, ofrece a los equipos agiles una forma más visual de trabajar, comunicarse y colaborar en Smartsheet. La vista de tarjeta le permite centrar la atención con tarjetas enriquecidas, dar perspectiva con vistas flexibles y priorizar y ajustar el trabajo de manera más visual. Centre la atención con tarjetas visuales: muestre información en las tarjetas (campos personalizados, imágenes y codificaciones de color) para llamar la atención de su equipo. Categorice las tarjetas en carriles para organizar su trabajo de manera más visual.
Utilice la vista de tarjeta de Smartsheet durante su próxima reunión de Scrum.
Más información acerca de Smartsheet para el desarrollo de software
Metodología de cascada (Waterfall)
¿Qué es el modelo de cascada?
La metodología en cascada sigue un proceso secuencial y lineal y es la versión más popular del ciclo de vida de desarrollo de sistemas (SDLC) para ingeniería de software y proyectos de TI. A veces, se planifica utilizando un diagrama de Gantt, un tipo de diagrama de barras que muestra las fechas de inicio y finalización de cada tarea. Una vez finalizada una de las ocho etapas, el equipo de desarrollo pasa al siguiente paso. El equipo no puede volver a una etapa anterior sin iniciar todo el proceso desde el principio. Y, antes de que el equipo pueda pasar a la siguiente etapa, es posible que el cliente deba revisar y aprobar los requisitos.
El modelo en cascada se originó en las industrias de fabricación y construcción, tanto en un entorno altamente estructurado en el que los cambios pueden ser demasiado costosos o a veces imposibles. La primera descripción formal del modelo de cascada se le atribuye a Winston W. Royce en un artículo de 1970 en el que describió un modelo de software deficiente.
Ventajas del modelo de cascada
El modelo de cascada se utiliza mejor para proyectos simples e inmutables. Su naturaleza lineal y rígida hace que sea fácil de usar y permite una documentación en profundidad.
Las ventajas del modelo de cascada incluyen:
- Fácil de usar y aprender: Dado que el modelo de cascada sigue el mismo patrón secuencial para cada proyecto, es fácil de usar y entender. El equipo no necesita ningún conocimiento o capacitación previo antes de trabajar en un proyecto en cascada. La cascada también es un modelo rígido; cada fase tiene entregas y revisiones específicas, por lo que es fácil de administrar y controlar.
- La disciplina es reforzada: Cada fase del modelo de cascada tiene un punto de inicio y de finalización, y es fácil compartir el progreso con los grupos de interés y los clientes. Al centrarse en los requisitos y el diseño antes de escribir el código, el equipo puede reducir el riesgo de que no se cumpla el plazo.
- Requiere un enfoque bien documentado: El modelo de cascada requiere documentación para cada fase, lo que resulta en una mejor comprensión de la lógica detrás del código y las pruebas. También deja un rastro de papel para cualquier proyecto futuro o si los grupos de interés necesitan ver más detalles sobre una fase determinada.
Desventajas del modelo de cascada
El mayor inconveniente del modelo de cascada es cómo gestiona el cambio. Dado que el modelo de cascada es lineal y secuencial, no puede rebotar entre fases, incluso si se producen cambios inesperados. Una vez que haya terminado con una fase, eso es todo.
A continuación, le mostremos más información sobre las desventajas del modelo de cascada:
- Los cambios no pueden adaptarse fácilmente: Una vez que el equipo finaliza una fase, no puede volver atrás. Si llegan a la fase de pruebas y se dan cuenta de que faltaba una función de la fase de requisitos, es muy difícil y costoso volver atrás y corregirla.
- El software no se entrega hasta muy avanzado: El proyecto debe completar de dos a cuatro fases antes de que comience la codificación. Como resultado, los grupos de interés no verán el software en funcionamiento sino hasta finales del ciclo de vida.
- Reunir requisitos precisos puede ser un desafío: Una de las primeras fases de un proyecto en cascada es hablar con los clientes y grupos de interés e identificar sus requisitos. Sin embargo, puede ser difícil identificar exactamente lo que quieren hacer al principio del proyecto. A menudo, los clientes no saben lo que quieren desde el principio y, en cambio, aprenden e identifican los requisitos a medida que avanza el proyecto.
Etapas del modelo de cascada
Hay ocho etapas del modelo de cascada y todas deben suceder en orden secuencial. Por ejemplo, el equipo de desarrollo no puede volver a la fase de análisis si se encuentra en la fase de pruebas.
- Concepción: Esta fase comienza con una idea. La fase de concepto involucra una evaluación aproximada del proyecto, por qué es beneficioso y analiza las estimaciones iniciales de costos.
- Inicio: Una vez que se forma la idea, debe contratar al equipo del proyecto y definir los objetivos, el alcance, el propósito y los entregables.
- Recopilación y análisis de requisitos: Los requisitos se reúnen y analizan para ver si el proyecto es realmente viable. Toda esta información se documenta en un documento de especificación de requisitos.
- Diseño: Las especificaciones de diseño creadas en esta fase se utilizan en la fase de codificación para escribir realmente el código. Los requisitos se estudian y evalúan, y se prepara el diseño del sistema. El objetivo del equipo es entender qué acciones deben tomarse y cómo deben ser.
- Implementación/codificación: Comienza la codificación real del software. Todos los diagramas de flujo o algoritmos creados en la fase de diseño se convierten en un lenguaje de programación.
- Evaluación: Una vez que el código está completo, el software debe probarse para detectar cualquier error. Cuando finalizan las pruebas, el software se entrega al cliente. Algunos equipos pueden optar por incluir pruebas de aceptación de usuarios (UAT), en las que los usuarios prueban el software antes de implementarlo al público en general.
- Mantenimiento: Una vez que los clientes han estado utilizando el software en el mundo real, pueden encontrar problemas adicionales. El equipo de desarrollo deberá resolver, cambiar o modificar el software para seguir siendo efectivo.
Desarrollo iterativo en cascada
En el modelo tradicional en cascada, el equipo pasa por cada fase de todo el proyecto. Por ejemplo, hacen el análisis para todo el proyecto, luego hacen el diseño para todo el proyecto, etc.
En un modelo en cascada iterativo, todavía se requiere mucha planificación inicial. Una vez que el plan está implementado, el equipo sigue el mismo patrón que la cascada tradicional, pero lo hace para cada historia. Hacen el análisis de una historia, luego todo el diseño de una historia, luego toda la codificación y las pruebas de una historia. Luego repiten el proceso para otra historia. El trabajo se divide en fragmentos que benefician al equipo de desarrollo.
Cómo el modelo de cascada se ocupa de los requisitos de software
Los proyectos en cascada definen todos los requisitos de software por adelantado. El proyecto no puede proceder a menos que se hayan identificado y documentado estos requisitos.
Algunos proyectos en cascada pueden tener un equipo dedicado para capturar, recopilar y reunir estos requisitos. Pueden usar cuestionarios, entrevistas cara a cara o telefónicas, tableros blancos y herramientas de modelado para captar los requisitos de los grupos de interés y los clientes.
Una vez definidos los requisitos iniciales, el equipo debe elaborar un documento de especificación de requisitos (a veces pueden crear más de uno). Este documento define lo que se debe entregar para que todos entiendan el alcance del proyecto.
Kanban
¿Qué es Kanban?
Kanban es una palabra japonesa que significa "signo visual" o "tarjeta". Es un marco visual que se usa para implementar Agile que muestra qué producir, cuándo producirlo y cuánto producir. Fomenta cambios pequeños e incrementales en el sistema actual y no requiere una configuración o procedimiento determinados (lo que significa que puede superponer Kanban sobre otros flujos de trabajo existentes).
Kanban se inspiró en el sistema de producción de Toyota y en la fabricación Lean. En la década de 1940, Toyota mejoró su proceso de ingeniería tomando como modelo la forma en que los supermercados abastecen sus estanterías. El ingeniero Taiichi Ohno notó que los supermercados abastecen el producto suficiente para satisfacer la demanda, optimizando el flujo entre el supermercado y el cliente. El inventario solo se reabastecía cuando había espacio vacío en el estante (una señal visual). Y como el inventario coincidía con el consumo, el supermercado mejoró la eficiencia en la gestión de inventarios.
Toyota llevó estos mismos principios a sus plantas de fabricación. Diferentes equipos crearían una tarjeta (o Kanban) para comunicar que tenían capacidad extra y estaban listos para extraer más materiales. Debido a que todas las solicitudes de piezas se extrajo del orden, Kanban a veces se denomina "sistema de extracción.”
Estas mismas ideas se aplican hoy en día a los equipos de software y a los proyectos de TI. En este contexto, el trabajo en curso (WIP) ocupa el lugar del inventario y el trabajo nuevo solo se puede agregar cuando hay un "espacio vacío" en el tablero kanban visual del equipo. Kanban hace coincidir la cantidad de WIP con la capacidad del equipo, lo que mejora la flexibilidad, la transparencia y la producción.
Según el blog Kanban, "Kanban es una técnica para gestionar un proceso de desarrollo de software de una manera altamente eficiente. Kanban respalda el sistema de productos "just-in-time" (JIT) de Toyota. Aunque la producción de software es una actividad creativa y, por lo tanto, diferente a los coches que producen en masa, el mecanismo subyacente para gestionar la línea de producción todavía puede aplicarse.”
Al comparar Kanban con Agile, es importante recordar que Kanban es una variedad de Agile. Es uno de los muchos marcos que se utilizan para implementar el desarrollo de software Agile.
Acerca del tablero Kanban
Un tablero Kanban es una herramienta para implementar el método Kanban para proyectos. Tradicionalmente, esta herramienta ha sido un tablero físico, con imanes, chips de plástico o notas adhesivas en una pizarra para representar elementos de trabajo. Sin embargo, en los últimos años, cada vez más herramientas de software de gestión de proyectos han creado tableros Kanban en línea.
Un tablero Kanban, ya sea físico o en línea, se compone de diferentes carriles de natación o columnas. Los tableros más simples tienen tres columnas: pendientes, trabajo en curso y hecho. Las columnas de un proyecto de desarrollo de software pueden consistir en columnas backlog, listo, codificación, pruebas, aprobación y hecho.
Las tarjetas kanban (como las notas adhesivas) representan el trabajo y cada tarjeta se coloca en el tablero en el carril que representa el estado de ese trabajo. Estas tarjetas comunican el estado de un vistazo. También puede usar diferentes tarjetas de colores para representar diferentes detalles. Por ejemplo, las tarjetas verdes podrían representar una función y las tarjetas naranjas podrían representar una tarea.
Ventajas de Kanban
La naturaleza visual de Kanban ofrece una ventaja única al implementar Agile. El tablero Kanban es fácil de aprender y entender, mejora el flujo de trabajo y minimiza el tiempo del ciclo.
Las ventajas de Kanban incluyen:
- Aumenta la flexibilidad: Kanban es un modelo fluido y evolutivo. No hay duraciones de fase establecidas y las prioridades se reevaluan a medida que entra en juego la información nueva.
- Reduce lo que no sirve: Kanban gira en torno a reducir lo que no sirve, garantizar que los equipos no dediquen tiempo a hacer un trabajo que no sea necesario o a realizar un tipo de trabajo equivocado.
- Fácil de entender: La naturaleza visual de Kanban ayuda a que sea increíblemente intuitivo y fácil de aprender. El equipo no necesita aprender una metodología completamente nueva, y Kanban se puede implementar fácilmente como complemento de otros sistemas implementados.
- Mejora el flujo de entrega: Los equipos Kanban optimizan el flujo de trabajo hacia los clientes. Al igual que la entrega continua (CD), Kanban se centra en la entrega justo a tiempo del valor y la entrega del trabajo a los clientes en una cadencia regular.
- Minimiza el tiempo de ciclo: El tiempo de ciclo es la cantidad de tiempo que se necesita para que el trabajo pase por el flujo de trabajo del equipo. En los proyectos Kanban, todo el equipo ayuda a garantizar que el trabajo avance de manera rápida y exitosa a lo largo del proceso.
Desventajas de Kanban
Muchas de las desventajas asociadas con Kanban vienen con un uso indebido o una mala administración del tablero Kanban. Un tablero desactualizado o demasiado complicado puede derivar en confusión, imprecisiones o falta de comunicación.
A continuación, le mostraremos más sobre las desventajas de Kanban:
- Un tablero desactualizado puede generar problemas: El equipo debe comprometerse a mantener actualizado el tablero Kanban, de lo contrario, trabajará con información inexacta. Y una vez que el trabajo se finaliza en función de un tablero obsoleto, puede ser difícil volver a poner las cosas en marcha.
- Los equipos pueden sobrecargar el tablero: El tablero Kanban debe mantenerse claro y fácil de leer; sin embargo, algunos miembros del equipo pueden aprender "nuevos trucos" que pueden aplicar a su tablero. Agregar este tipo de cosas superfluas al tablero Kanban solo oculta la información importante.
- Falta de señalización del tiempo: Una queja frecuente sobre Kanban es que no se sabe cuándo se harán las cosas. Las columnas del tablero Kanban solo están marcadas por fases (pendientes, en curso, completadas), no hay plazos asociados a cada fase, por lo que realmente no sabes cuánto tiempo podría durar la fase de pendientes.
Prácticas y principios básicos de Kanban
Cada proyecto Kanban debe seguir estos principios básicos:
- Visualizar el flujo de trabajo: Una representación visual de su trabajo le permite comprender el panorama general y ver cómo avanza el flujo de trabajo. Al hacer visible todo el trabajo, incluidos los obstáculos y las colas, puede identificar los problemas desde el principio y mejorar la colaboración.
- Limitar el trabajo en curso (WIP): Los límites de trabajo en curso (límites de WIP) determinan la cantidad mínima y máxima de trabajo para cada columna del tablero o para cada flujo de trabajo. Al poner un límite de WIP, puede aumentar la velocidad y la flexibilidad, y reducir la necesidad de priorizar las tareas.
- Administrar y mejorar el flujo: El flujo de trabajo (el movimiento del trabajo) en todo el tablero Kanban debe supervisarse y mejorarse. Idealmente, quiere un flujo rápido y fluido, lo que demuestra que el equipo está creando valor rápidamente. El equipo debe analizar los problemas del flujo e implementar cambios.
- Hacer que las políticas de procesos sean explícitas: Para que se produzca un cambio colaborativo en el sistema Kanban, los procesos deben ser explícitos. Todo el mundo tiene que entender cómo funcionan las cosas o qué significa realmente "completado". Puede modificar el tablero para que estos procesos sean más claros; por ejemplo, podría rediseñarlo para especificar cómo debería fluir el trabajo.
- Mejora continua: El método Kanban fomenta cambios pequeños y continuos que se mantienen. Una vez que se haya implementado el sistema Kanban, el equipo podrá identificar y comprender los problemas y sugerir mejoras. Los equipos miden su efectividad mediante el seguimiento del flujo, la medición del tiempo del ciclo y el aumento de la calidad del trabajo.
Preguntas frecuentes sobre Kanban
P: ¿Cómo organiza las reuniones y mantiene la concentración sin un Scrum Master?
Alguien del equipo debe tomar la iniciativa de poner la reunión en el calendario y garantizar que la conversación se mantenga en curso. Incluso sin un Scrum Master, normalmente no es un problema demasiado grande.
El tablero Kanban ayuda a mantener el enfoque durante la reunión. Durante la reunión, puede pasar por el tablero de izquierda a derecha y buscar historias que no se hayan movido desde la última reunión. En lugar de hablar de logros, puede simplemente mirar las tarjetas del tablero. La única pregunta que debe hacer durante una reunión es sobre los obstáculos o los desafíos para terminar un elemento.
También podría probar una reunión kaizen, en la que solo invita a las personas que están involucradas en la tarea en cuestión. Cada persona analiza los problemas y desafíos, y cómo su trabajo podría hacerse de manera más eficiente. Luego, todo el grupo habla sobre soluciones a esos problemas.
Kaizen también puede incluir a un facilitador kaizen, quien alienta al equipo a hablar abiertamente sobre cuestiones críticas.
P: ¿Cómo puede Kanban satisfacer el deseo de la gerencia de una entrega predecible?
En cierta medida, Kanban cambia la previsibilidad por la eficiencia. No hay restricciones ni planificación en el timebox, sin embargo, una vez que un equipo ha optimizado el flujo de trabajo y puede tener una idea de cuánto tiempo tardan ciertas tareas, habrá algún nivel de previsibilidad.
Si la gestión todavía necesita una previsibilidad más definida (que no es el enfoque Kanban), es posible que deba intentar gestionar las expectativas. En un modelo tradicional, tiene una fecha de entrega predecible, pero en realidad, nadie va a entregar un producto para esa fecha si no está completo. La gestión siempre va a esperar a que el producto esté completo, independientemente de la fecha original establecida. En el modelo Kanban, las expectativas deben ajustarse para centrarse en la entrega del producto cuando esté listo y finalizado.
P: ¿Cómo se usa Kanban cuando se tiene una fecha límite?
Hay un par de formas diferentes de gestionar los plazos en un modelo Kanban. Simplemente puede escribir los plazos en las tarjetas Kanban, asegurándose de que estos plazos actúen más como pautas en lugar de fechas de vencimiento duras y rápidas (en Kanban, no se debe sacrificar la calidad por el tiempo).
También podría cambiar la forma en que usted y su equipo abordan los plazos. En la forma más verdadera de Kanban, esto no es necesario. El sistema Kanban se asegurará de que todas las tareas se finalicen lo antes posible, por lo que ya no es necesario tener una fecha límite.
P: ¿Se puede usar Kanban para otros proyectos además del desarrollo de software?
Sí, Kanban puede mejorar los resultados de los procesos, reducir los tiempos de producción y ayudar a gestionar el flujo de trabajo en casi cualquier sector. Por ejemplo, en el sector del desarrollo de juegos, Kanban ayuda a acortar el cronograma del proceso de video y a reducir lo que no sirve. En bienes raíces, aporta más eficiencia al dar seguimiento a los contratos, las perspectivas y las listas en varios tableros. Y en finanzas, Kanban puede identificar rápidamente los cuellos de botella y aumentar la velocidad de comercialización.
P: ¿EL WIP está impulsado por la disponibilidad de recursos?
Sí. Al establecer límites de WIP, debe ver cuántas personas tiene en su equipo y cuántas tareas quiere que trabajen al mismo tiempo.
P: ¿Cómo se sabe si el límite de WIP es correcto?
No existe ninguna fórmula para establecer los límites de WIP adecuados. Es muy común que los límites se equivoquen al principio, pero solo tiene que ajustarlos a medida que avanza el proyecto. Un buen lugar para empezar es asignar 1,5 para los recursos disponibles, pero siempre debe reevaluar este número y hacer cambios según sea necesario.
Agile vs Scrum
Diferencias y similitudes entre Agile y Scrum
Si bien Agile y Scrum siguen el mismo sistema, hay algunas diferencias al comparar Scrum con Agile. Agile describe un conjunto de principios en el Manifiesto Agile para crear software a través del desarrollo iterativo. Por otro lado, Scrum es un conjunto específico de reglas a seguir a la hora de practicar el desarrollo de software Agile. La metodología Agile es la filosofía y Scrum es la metodología para implementar esa filosofía.
Dado que Scrum es una forma de implementar Agile, ambos comparten muchas similitudes. Ambos se centran en entregar software temprano y a menudo, son procesos iterativos y se adaptan al cambio. También fomentan la transparencia y la mejora continua.
¿Cómo encaja Scrum con Agile?
Scrum es uno de los muchos marcos que se utilizan para implementar un proceso Agile. Agile es un término general que incluye otros procesos, como Programación Extrema, Kanban, Crystal y Scrum. Scrum es Agile, pero Agile no es Scrum.
Cuándo usar Scrum
Recomendamos usar Scrum si:
- Los requisitos del proyecto cambiarán y evolucionarán
- Se requiere retroalimentación continua
- Tiene que averiguar cómo hacer una gran parte del trabajo porque no lo ha hecho antes
- No es necesario que se comprometas con una fecha de lanzamiento fija
- El equipo del proyecto quiere autonomía
- Es necesario entregar software de manera regular
Scrum funciona bien para proyectos que tienen muchas incógnitas o que evolucionan con el tiempo. Scrum se ocupa de estos cambios de manera muy efectiva, para que pueda acomodar fácilmente nueva información o funciones a lo largo del proceso.
Cuándo usar Agile
La línea entre cuándo usar Agile y cuándo usar Scrum es borrosa. Scrum es un marco en el proceso Agile, por lo que ambos tienen mucho en común. Un buen lugar para empezar es comprender primero si debe usar Agile en general. Luego, si una metodología Agile parece que funcionaría para usted, podría elegir qué marco de metodología Agile usar (Scrum es un marco de trabajo).
Recomendamos usar Agile si:
- El producto final no está claramente definido
- Los clientes/grupos de interés necesitan poder cambiar el alcance
- Los cambios deben implementarse durante todo el proceso
- Los desarrolladores son adaptables y pueden pensar de manera independiente
- Es necesario optimizar para una implementación rápida
Enfoque híbrido
Si un enfoque Scrum puro no funciona para su proyecto, también puede probar un modelo híbrido. Hay varias metodologías que combinan los principios de Agile o Scrum y adaptan el marco para escalarlo de manera más efectiva.
Por ejemplo, la Entrega Agile Disciplinada (DAD) se basa en las prácticas de Agile, Scrum y Lean para proporcionar una base sólida a partir de la cual escalar. DAD se desarrolló para proporcionar un enfoque más coherente con la metodología ágil, tomando estrategias de Scrum, Kanban, Programación Extrema, entre otras. En lugar de tomarse el tiempo necesario para aprender uno de estos marcos existentes y arrejuntarlos según sea necesario, DAD ya combina todas las técnicas relevantes.
Otros métodos híbridos incluyen Scrum de gran escala (LeSS), que amplía Scrum con reglas y directrices de escalamiento, y Scaled Agile Framework (SaFE), basado en principios Lean y Agile subyacentes.
Kanban vs Scrum
Diferencias y similitudes: Scrum vs Kanban
Scrum y Kanban son variantes de Agile, pero tienen algunas diferencias.
- Scrum requiere funciones específicas, mientras que Kanban no.
- Scrum se basa en iteraciones con timeboxes, que combinan la planificación, la mejora de procesos y la publicación. En Kanban, puede optar por realizar estas actividades con una cadencia regular o cuando sea necesario.
- Scrum limita el trabajo en curso (WIP) en cada iteración, mientras que Kanban limita el WIP en cada flujo de trabajo.
- Scrum se resiste al cambio, mientras que Kanban se adapta y adopta fácilmente el cambio. En Scrum, una vez que el equipo ha comprometido historias en un sprint, no puede agregar más historias más adelante. En Kanban, puede agregar o cambiar historias según lo desee, suponiendo que esté dentro de los límites de WIP.
- Un tablero Scrum se restablece después de cada sprint. El tablero Kanban se utiliza continuamente.
- Un equipo Scrum es multifuncional y un equipo es el propietario del tablero Scrum. En Kanban, los equipos no necesitan ser multifuncionales y cualquiera puede ser el propietario del tablero Kanban.
- Los equipos Scrum requieren estimación, mientras que Kanban no.
Ahora, Scrum y Kanban también tienen algunas similitudes:
- Son empíricos. Tiene que experimentar con el proceso para ver lo que funciona para usted.
- Ambos permiten que los miembros del equipo trabajen en varios productos a la vez.
- Son Lean y Agile.
- Ambos limitan el WIP (aunque la forma en que cada uno limita el WIP es diferente)
- Utilizan la programación tipo pull
- Se centran en entregar software anticipadamente y a menudo
- Ambos utilizan la transparencia para mejorar los procesos
¿Cómo se relacionan Kanban y Scrum entre sí?
Kanban y Scrum son ambos marcos de trabajo para el desarrollo de software Agile. Ambos toman tareas grandes y complejas y las dividen en fragmentos más pequeños. Kanban y Scrum también trabajan para mejorar y optimizar continuamente el proceso, y quieren mantener el trabajo altamente visible.
Si bien tanto Kanban como Scrum son muy adaptativos, Scrum es más rígido que Kanban. Scrum tiene más restricciones, mientras que Kanban es más flexible.
Cuándo usar Kanban
Recomendamos usar Kanban si:
- Necesita añadir historias o cambiar sprints sobre la marcha
- No necesita iteraciones
- La estimación no es necesaria
- Quiere la capacidad de hacer lanzamientos en cualquier momento
- La mejora continua ya está enfatizada
- Su equipo no responde bien a los grandes cambios
- Quiere mejorar el flujo de entrega
- El sistema debe ser fácil de entender
Scrum puede ser menos flexible que Kanban. El cronograma gira en torno a los sprints, y cada sprint tiene una duración de dos a cuatro semanas. En cada sprint, el equipo tiene funciones específicas y sigue ceremonias específicas.
¿Qué es Scrumban?
Scrumban combina los principios de Scrum y Kanban en un sistema basado en extracciones. El equipo planifica el trabajo que se estableció durante el inicio y limpia continuamente el backlog. Las mismas reuniones de Scrum deben tener lugar, pero la frecuencia puede cambiar según el contexto y la necesidad. La parte más importante de Scrumban es asegurarse de que se cumplan los límites de trabajo en curso (límites de WIP).
Scrumban toma partes tanto de Scrum como de Kanban. Por ejemplo, incluye las funciones definidas, el scrum diario y otras reuniones de Scrum. Y de Kanban, toma el tablero Kanban, el flujo continuo y la capacidad de agregar cambios según sea necesario al tablero.
Scrumban puede parecerse más a Scrum a nivel técnico, pero a nivel cultural, se parecerá más a Kanban. En lugar de grandes cambios a la vez, Scrumban fomenta cambios incrementales. Si su equipo quiere migrar de Scrum a Kanban, Scrumban puede ser una opción para una transición suave.
¿Cuál es mejor? Kanban vs Scrum
Cuando se compara Kanban con Scrum, no hay un ganador definitivo. El mejor marco depende de su proyecto, equipo y sus objetivos. Dado que tanto Kanban como Scrum son metodologías Agile flexibles, puede tomar fácilmente los principios de cada una y aplicarlos según lo considere necesario.
Es importante recordar que el verdadero Scrum es un cambio mucho más grande que el Kanban. El equipo tendrá que aprender sobre las ceremonias, las funciones específicas y las iteraciones. Por otro lado, Kanban fomenta mejoras incrementales. Puede aplicar los principios kanban a cualquier proceso que ya haya implementado, incluso a Scrum. Nada tiene que cambiar significativamente para empezar con Kanban.
Como regla general, si su equipo u organización está realmente atascado y necesita un gran cambio, Scrum puede ser más apropiado. Si ya tiene un proceso con el que está contento, pero quiere implementar algunos cambios pequeños, Kanban puede ser una mejor opción.
Agile vs Cascada
Cuándo debe usar método de cascada y cuándo la metodología Agile
Recomendamos usar el método de cascada si:
- No espera cambios en el alcance y está trabajando con contratos de precio fijo
- El proyecto es muy simple o lo ha hecho muchas veces antes
- Los requisitos son muy conocidos y fijos
- Los clientes saben exactamente lo que quieren con anticipación
- Está trabajando con proyectos ordenados y predecibles
Y debería usar Agile si:
- El producto final no está claramente definido
- Los clientes/grupos de interés necesitan la capacidad de modificar el alcance
- Anticipa cualquier tipo de cambio durante el proyecto
- El objetivo es la implementación rápida
Al decidir entre Agile frente al método de cascada, todo puede reducirse a esto: si anticipa o espera algún cambio a lo largo del proyecto, elija Agile. Si sabe que el proyecto es fijo, inmutable y predecible, el método de cascada puede ser una mejor opción.
¿Cuál es mejor? Agile vs Cascada
La metodología Agile y el método de cascada son tan opuestos que es difícil decir cuál es mejor. Realmente depende del proyecto, del nivel de claridad en torno a los requisitos y de la flexibilidad que pueda tener.
Si tiene una imagen clara de cuál debería ser el producto final, tiene requisitos fijos que no cambiarán y está trabajando en un proyecto relativamente simple, algunos argumentan que el método de cascada es una mejor opción que Agile. Si no espera lidiar con cambios, el método de cascada es un proceso sencillo y eficiente. Los problemas con el método de cascada vienen cuando tiene que adaptarse a los cambios.
Si no tiene una imagen clara del producto final, anticipa cambios y está trabajando en un proyecto complejo, Agile es superior. Agile está diseñado para adaptarse a los requisitos nuevos y cambiantes en cualquier momento durante el proyecto, mientras que el método de cascada no permite volver a una fase finalizada y realizar cambios.
Híbrido: Agifall o WAgile
Si todavía tiene preguntas sobre el modelo cascada comparado con Agile, siempre podría combinar los principios de ambos y usar un modelo híbrido.
Agifall, por ejemplo, aumenta la velocidad y la calidad al agregar metodologías Agile al proceso en cascada. En un proyecto Agifall, desglosaría las fases de investigación, estrategia y planificación en tareas y procedería con sprints para completarlas. La fase de desarrollo sería igual que cualquier otro proyecto Agile, con más información por adelantado. Tampoco es necesario esperar a que finalice una fase para comenzar la siguiente, que es tradicional en un método de cascada puro. Con Agifall, cuando el proyecto puede comenzar, debe comenzar.
Wagile tiene una connotación más negativa que Agifall. La definición de Wagile en Wikipedia es, "un grupo de metodologías de desarrollo de software que resultan de caer de Agile de vuelta a la cascada, hacer muchas cascadas cortas y pensar que es Agile, modelo en cascada disfrazado de desarrollo de software Agile".
Wagile adopta prácticas de Agile como iteraciones breves, reuniones rápidas diarias o integración continua en la parte superior del modelo en cascada, sin cambiar realmente el modelo tradicional en cascada.
Kanban vs Agile
Diferencias y similitudes: Agile vs Kanban
Si bien Kanban es una forma visual de implementar Agile, tienen muchas diferencias:
- Kanban defiende el flujo continuo, mientras que Agile trabaja en iteraciones.
- Kanban puede funcionar igual de bien para cualquier tipo de trabajo, mientras que Agile puede ser más adecuado para algunos proyectos que para otros.
- Cualquier persona puede seguir la metodología Kanban, pero algunas metodologías Agile requieren conocimientos o capacitación.
- Kanban requiere una representación visual del flujo de trabajo, mientras que Agile no.
- Algunos proyectos Agile requieren equipos multifuncionales, mientras que Kanban no.
- La metodología Agile es una filosofía, mientras que Kanban es un método.
Ahora, Agile y Kanban también tienen similitudes:
- Ambas dividen los proyectos en fragmentos más pequeños.
- Hacen hincapié en la mejora continua.
- Aportan un gran valor a la transparencia.
- Ninguna de ellas requiere mucha planificación inicial.
- Trabajan para lograr una entrega más rápida.
Cuándo debe usar Kanban y cuándo usar Agile
Recomendamos usar Kanban si:
- Su proyecto no requiere iteraciones
- Quiere la capacidad de hacer lanzamientos en cualquier momento
- Su equipo prefiere el cambio incremental
- Su equipo trabaja bien con los elementos visuales
- Quiere mejorar el flujo de entrega
- Está buscando un sistema fácil de entender
Y recomendamos usar Agile si:
- El producto final no está claramente definido
- Los cambios deben implementarse durante todo el proceso
- Los desarrolladores son adaptables y pueden pensar de manera independiente
- Está buscando hacer un cambio sustancial
¿Cuál es mejor? Agile vs Kanban
Al igual que con cualquier metodología de gestión de proyectos, no hay un marco que sea mejor el 100 % de las veces. Puede elegir Kanban para algunos proyectos, pero querrá implementar Agile para otros.
Considere qué nivel de cambio quiere presentar a su equipo. Si desea agregar algo como complemento de un marco existente con cambios pequeños e incrementales, Kanban es una mejor opción. Si está buscando hacer un cambio de procesos más grande, implementar Agile (como Scrum) sería mejor.
Y, si quiere que el equipo de su proyecto comience de inmediato con un nuevo método, Kanban es más fácil de entender. No se requiere capacitación y se puede usar como complemento de cualquier proceso existente. Por otro lado, algunos métodos Agile requieren más conocimiento del equipo. Por ejemplo, es posible que necesiten aprender roles, ceremonias y terminología específicos.
Recursos y publicaciones relacionadas
Descargue una plantilla gratuita de diagrama de cascada de Excel o aprenda a crear un diagrama de cascada desde cero. También compartiremos cuándo usar un diagrama de cascada y las funciones de un diagrama de cascada en Excel.
Encuentre ocho plantillas de gestión de proyectos Agile en Excel, que van desde la plantilla de backlog de productos Agile hasta la plantilla de estatuto de proyectos Agile. También aprenderá a usar plantillas Agile en Smartsheet
Cursos:
- Profesional Certificado en Agile de PMI (PMI ACP): Esta certificación, ofrecida por el Project Management Institute (PMI), abarca los diversos enfoques de Agile, como Scrum, Kanban, Lean, Programación extrema (XP) y Desarrollo basado en pruebas (TDD). Los requisitos previos incluyen 2000 horas de experiencia general en proyectos trabajando en un equipo, 1500 horas trabajando en equipos de proyectos Agile y 21 horas de capacitación en prácticas Agile.
- ScrumMaster certificado (CSM): Esta certificación de Scrum Alliance ayuda a los equipos a usar Scrum correctamente, comprender sus valores y proteger al equipo de las distracciones. Como CSM, podrá ocupar el puesto de Scrum Master o miembro del equipo Scrum. Para obtener su certificado CSM, debe tomar un curso CSM de un capacitador autorizado de Scrum Alliance y demostrar el progreso con una prueba en línea.
- Dueño del Producto de Scrum Certificado (CSPO): Un Dueño del Producto de Scrum Certificado aprende terminología, prácticas y principios de Scrum para cumplir con el rol de Dueño del Producto en un equipo Scrum. Está más cerca de la parte empresarial del proyecto, mantiene el backlog del producto y se asegura de que todos conozcan las prioridades. Para obtener esta certificación de Scrum Alliance, debe asistir a un curso de CSPO en persona y de dos días impartido por un capacitador de Scrum certificado.
- Profesional Certificado en Scrum (CSP): Los profesionales certificados de Scrum desafían a sus equipos de Scrum a mejorar la forma en que se implementa Scrum para cada proyecto. Para solicitar un CSP, actualmente debe tener una credencial CSM, CSPO o CSD, tener un mínimo de 36 meses de experiencia con Agile/Scrum, y reunir y enviar 70 unidades educativas scrum de los últimos tres años.
- Profesional Kanban Acreditado (AKP): Los profesionales Kanban acreditados son profesionales que tienen conocimientos y experiencia comprobados en la implementación de Kanban para el desarrollo de software. La certificación la ofrece Agile Certification Institute, Inc. y requiere que tenga una capacitación previa en prácticas Agile y que apruebe un examen de certificación de AKP.
Administre cualquier proyecto a su manera con Smartsheet
Empodere a sus empleados para que vayan más allá gracias a una plataforma flexible, diseñada para satisfacer las necesidades de su equipo y capaz de adaptarse cuando esas necesidades cambien. La plataforma Smartsheet facilita la planificación, la captura, la gestión y la creación de informes sobre el trabajo, desde cualquier lugar, lo que ayuda a su equipo a ser más eficiente y lograr más. Cree informes sobre las métricas claves y obtenga visibilidad en tiempo real acerca del trabajo en curso gracias a informes, paneles y flujos de trabajo automatizados diseñados para ayudar a su equipo a mantenerse conectado e informado. Cuando los equipos tienen claridad sobre el trabajo en curso, pueden lograr mucho más en el mismo tiempo. Pruebe Smartsheet gratis hoy mismo.
Recursos y publicaciones relacionadas
Cómo crear un diagrama de cascada en Excel
Descargue una plantilla gratuita de diagrama de cascada de Excel o aprenda a crear un diagrama de cascada desde cero. También compartiremos cuándo usar un diagrama de cascada y las funciones de un diagrama de cascada en Excel.
Las mejores plantillas de Excel para la gestión de proyectos Agile
Encuentre ocho plantillas de gestión de proyectos Agile en Excel, que van desde la plantilla de backlog de productos Agile hasta la plantilla de estatuto de proyectos Agile. También aprenderá a usar plantillas Agile en Smartsheet
Planificación Agile: Mejores prácticas para gerentes de proyectos
Recursos Agile de gestión de proyectos integrales
Cursos:
- Profesional Certificado en Agile de PMI (PMI ACP): Esta certificación, ofrecida por el Project Management Institute (PMI), abarca los diversos enfoques de Agile, como Scrum, Kanban, Lean, Programación extrema (XP) y Desarrollo basado en pruebas (TDD). Los requisitos previos incluyen 2000 horas de experiencia general en proyectos trabajando en un equipo, 1500 horas trabajando en equipos de proyectos Agile y 21 horas de capacitación en prácticas Agile.
- ScrumMaster certificado (CSM): Esta certificación de Scrum Alliance ayuda a los equipos a usar Scrum correctamente, comprender sus valores y proteger al equipo de las distracciones. Como CSM, podrá ocupar el puesto de Scrum Master o miembro del equipo Scrum. Para obtener su certificado CSM, debe tomar un curso CSM de un capacitador autorizado de Scrum Alliance y demostrar el progreso con una prueba en línea.
- Dueño del Producto de Scrum Certificado (CSPO): Un Dueño del Producto de Scrum Certificado aprende terminología, prácticas y principios de Scrum para cumplir con el rol de Dueño del Producto en un equipo Scrum. Está más cerca de la parte empresarial del proyecto, mantiene el backlog del producto y se asegura de que todos conozcan las prioridades. Para obtener esta certificación de Scrum Alliance, debe asistir a un curso de CSPO en persona y de dos días impartido por un capacitador de Scrum certificado.
- Desarrollador de Scrum Certificado (CSD): Los desarrolladores de Scrum certificados aprenden habilidades de ingeniería ágil especializadas y demuestran sus conocimientos a través de una capacitación formal y una evaluación de habilidades técnicas. El curso de CSD está orientado a desarrolladores de software que trabajan en un entorno Scrum. Para obtener un CSD de Scrum Alliance, debe tener cinco días de capacitación formal impartidos por un proveedor de educación registrado de Scrum Alliance y un instructor autorizado de Scrum Alliance.
- Profesional Certificado en Scrum (CSP): Los profesionales certificados de Scrum desafían a sus equipos de Scrum a mejorar la forma en que se implementa Scrum para cada proyecto. Para solicitar un CSP, actualmente debe tener una credencial CSM, CSPO o CSD, tener un mínimo de 36 meses de experiencia con Agile/Scrum, y reunir y enviar 70 unidades educativas scrum de los últimos tres años.
- Profesional Kanban Acreditado (AKP): Los profesionales Kanban acreditados son profesionales que tienen conocimientos y experiencia comprobados en la implementación de Kanban para el desarrollo de software. La certificación la ofrece Agile Certification Institute, Inc. y requiere que tenga una capacitación previa en prácticas Agile y que apruebe un examen de certificación de AKP.
Administre cualquier proyecto a su manera con Smartsheet
Empodere a sus empleados para que vayan más allá gracias a una plataforma flexible, diseñada para satisfacer las necesidades de su equipo y capaz de adaptarse cuando esas necesidades cambien. La plataforma Smartsheet facilita la planificación, la captura, la gestión y la creación de informes sobre el trabajo, desde cualquier lugar, lo que ayuda a su equipo a ser más eficiente y lograr más. Cree informes sobre las métricas claves y obtenga visibilidad en tiempo real acerca del trabajo en curso gracias a informes, paneles y flujos de trabajo automatizados diseñados para ayudar a su equipo a mantenerse conectado e informado. Cuando los equipos tienen claridad sobre el trabajo en curso, pueden lograr mucho más en el mismo tiempo. Pruebe Smartsheet gratis hoy mismo.