Modelo Agil
MODELO ÁGIL
Nombre: Kanban
Es un marco de trabajo que requiere una comunicación en tiempo real sobre la capacidad del equipo, utilizado para controlar el avance de trabajo en una línea de producción, con la intención de determinar los niveles de productividad en cada fase del proyecto.
Historia
Creado por Taiichi Ohno, ingeniero y empresario, que trabaja para Toyota en Japón. Su metodología está inspirada en los supermercados y como llenan sus estantes, su gestión de inventario surtiendo los productos de acuerdo a la demanda del consumidor. Un sistema que le permitiera igualar la cantidad de productos en el inventario con el material que realmente estaba utilizando en la manufactura de los coches.
En el desarrollo de software también lo utilizaban desde que David J Anderson lo hizo famoso con su libro, Kanban: una evolución exitosa para tu negocio de tecnología, explicando cómo los equipos se pueden adaptar a este método.
Actividades
Este método se organiza con un tablón grande dividido en columnas, el número de columnas pueden variar dependiendo del nivel de complejidad o fases del proceso. Algunas de sus actividades principales suelen ser:
Lista de tareas o “To-Do”: Aquí se coloca la lista de tareas pendientes.
En desarrollo o “Doing”: Aquí se sitúa una tarea hasta que se complete.
Pruebas: Se realizan comprobaciones para ver si la tarea se ha realizado con éxito.
Despliegue: Una vez validada el código se añaden a esta columna subida a producción en el sistema.
Terminado o “Done”: Aquí van las tareas que están finalizadas por completo.
Fases y etapas
El Service Request Manager tiene como responsabilidades:
Entender las necesidades y expectativas de los clientes y comunicarlas al equipo.
Ayudar a priorizar los ítems en la reunión de reposición.
Adicionalmente tiene mucha importancia ayudando a definir las políticas del sistema, de forma que estén alineadas con las expectativas de los clientes.
Estas políticas de servicio se referirán a aspectos como:
La evaluación de riesgos.
La definición de las clases de servicio.
La priorización, programación y secuenciación de los ítems pertenecientes a las diferentes.
Estas funciones frecuentemente las ejecutan otros roles como el responsable del equipo, el product of service manager, o bien una figura similar al product owner.
Roles
Dentro del modelo Kanban los roles no son sino un mecanismo para producir el cambio. Y aquí tenemos como guía los principios y valores de Kanban. En primer lugar, nos encontramos con el principio “Empezar con lo que se hace ahora”.
En segundo lugar están los valores del respeto -a los roles y procesos actuales- y la comprensión de los mismos, su importancia y papel.
Por eso en Kanban no se exigen roles, aunque sí que es importante que se ejecuten ciertas responsabilidades para el buen funcionamiento. No importa tanto el rol que los ejecuta mientras lo haga adecuadamente.
Pero al final en muchos hay dos roles que emergen en muchos equipos Kanban:
Service Request Manager.
El Service Request Manager tiene como responsabilidades:
Entender las necesidades y expectativas de los clientes y comunicarlas al equipo.
Ayudar a priorizar los ítems en la reunión de reposición.
Adicionalmente tiene mucha importancia ayudando a definir las políticas del sistema, de forma que estén alineadas con las expectativas de los clientes.
Estas políticas de servicio se referirán a aspectos como:
La evaluación de riesgos.
La definición de las clases de servicio.
La priorización, programación y secuenciación de los ítems pertenecientes a las diferentes.
Estas funciones frecuentemente las ejecutan otros roles como el responsable del equipo, el product of service manager, o bien una figura similar al product owner.
Service Delivery Manager
Mejorar la fluidez con la que se mueven las peticiones dentro del workflow es la misión del Service Delivery Manager. Debe vigilar que los servicios no queden detenidos por culpa de los obstáculos al flujo como dependencias,
El Service Delivery Manager, por su parte, tiene como responsabilidades:
Gestionar el workflow para asegurar que los ítems seleccionados fluyen y son entregados dentro de los niveles de servicio objetivo.
Facilitar las reuniones diarias (Kanban Meeting) y la planificación de la entrega (Delivery Planning).
Facilitar el cambio y las actividades de mejora continua.
Dentro de las funciones de facilitación del cambio y la mejora, el Service Delivery Manager:
Vigila que no hayan ítems bloqueados durante demasiado tiempo.
Ayuda en los desbloqueos de los ítems.
Asegura que se recojan métricas sobre la efectividad del sistema.
Se asegura de que se identifiquen los problemas y las causas.
Vigila que los errores no se repitan de forma sistemática.
Estas funciones frecuentemente las ejecutan otros roles como el Delivery manager o el jefe de equipo.
Nombre: Scrum
Historia
El término “scrum” originalmente surge de un tipo de formación que se realiza en rugby, en la cual los jugadores tienen que sacar la pelota sin tocarla con las manos.
Pero la historia de Scrum como método de trabajo empieza en 1986 en Japón. Ese año, Hirotaka Takeuchi e Ikujiro Nonaka introdujeron el término en un artículo. Hablaban de Scrum como una excelente forma de aumentar la velocidad y la flexibilidad en el desarrollo de productos comerciales. A partir de ahí, se empezó a usar cada vez más, recibiendo un gran impulso en Boston, donde lo empezaron a usar Ken Schwaber y Jeff Sutherland.
En la actualidad, Scrum se está utilizando en diferentes tipos de negocio y, especialmente, en el desarrollo de software. La Scrum Alliance es la organización sin ánimo de lucro que se encarga de difundir Scrum en este ámbito.
Actividades
Planeación del Sprint/Sprint Planning
Todos los involucrados en el equipo se reúnen para planificar el Sprint. Durante este evento se decide qué requerimientos o tareas se le asignará a cada uno de los elementos del equipo. Cada integrante deberá asignar el tiempo que crea prudente para llevar a cabo sus requerimientos. De esta manera se define el tiempo de duración del Sprint.
Reunión de equipo de Scrum/Scrum team meeting
A estas reuniones se les deberían dedicar máximo 15 minutos diarios, y deberían ser siempre en el mismo horario y lugar. En ellas, cada miembro del equipo deberá responder que hizo ayer, que hará hoy y que problemas tuvo, esto con el fin de ayudarse mutuamente
Refinamiento del Backlog/Backlog Refinement
El Product Owner revisa cada uno de los elementos dentro del Product Backlog con el fin de esclarecer cualquier duda que pueda surgir por parte del equipo de desarrolladores. También sirve para volver a estimar el tiempo y esfuerzo dedicado a cada uno de los requerimientos.
Revisión del Sprint/Sprint Review
Los miembros del equipo y los clientes se reúnen para mostrar el trabajo de desarrollo de software que se ha completado. Se hace una demostración de todos los requerimientos finalizados dentro del Sprint. En este punto no es necesario que todos los miembros del equipo hablen, pueden simplemente estar presentes, pero la presentación está a cargo del Scrum Master y el Product Owner.
Retrospectiva del Sprint/Retrospective
En este evento el Product Owner se reúne con todo su equipo de trabajo y su Scrum Master para hablar sobre lo ocurrido durante el Sprint. Los puntos principales a tratar en esta reunión son:
Qué se hizo mal durante el Sprint para poder mejorar el próximo.
Qué se hizo bien para seguir en la misma senda del éxito.
Qué inconvenientes se encontraron y no permitieron poder avanzar como se tenía planificado.
Etapas
Las fases de la metodología Scrum se reparten en 16 procesos o tareas, que a su vez se resumen en 5 pasos o etapas de implementación:
Inicio
La primera fase se encarga de estudiar y analizar el proyecto identificando las necesidades básicas del sprint.
Las preguntas a hacer en la fase de inicio son:
¿Qué quiero?
¿Cómo lo quiero?
¿Cuándo lo quiero?
La metodología Scrum da preferencia a la formación de equipos pequeños de mínimo 3 y máximo 5 personas, pues se facilita la fluidez de las ideas y se aporta creatividad al grupo.
Entre los primeros pasos de Scrum, tenemos 6 procesos:
Crear la visión del proyecto
Identificar a los Master Scrum o ScrumMaster y a los stakeholders.
Formar equipos Scrum
Desarrollar épicas
Crear backlogs o listas de requerimientos priorizando el producto
Planificar el lanzamiento
Planificación y estimación
La segunda fase de Scrum incluye normalmente los siguientes pasos:
Crear, estimar y comprometer historias de usuario.
Identificar y estimar tareas.
Crear el sprint backlog o iteración de tareas.
La clave para llevar una buena administración de los proyectos es hacer una planificación y estimación del sprint, lo que te ayudará a establecer metas fijas y a cumplir con los plazos.
Implementación
En esta fase se realiza una reunión para hablar del sprint y se explora cómo optimizar el trabajo de cada grupo Scrum para darle forma definitiva al proyecto.
En la implementación se cumple con los siguientes procesos:
Crear entregables.
Realizar daily stand-up.
Refinanciamiento del backlog priorizado del producto.
En la fase de implementación o desarrollo no deberían hacerse cambios innecesarios de última hora (se supone que para evitarlo existe una fase de planificación).
Revisión y retrospectiva
Una vez que ya todo está maquetado e implementado, deberás hacer la revisión del proceso, que no es más que la autocrítica o evaluación interna del grupo respecto a su propio trabajo.
Es importante sumar opiniones constructivas y aportar soluciones viables.
Entre los pasos más importantes para realizar en esta fase tenemos:
Demostrar y validar el sprint.
Retrospectiva del sprint.
Lanzamiento
La última de las fases del método Scrum es el lanzamiento.
Con esto nos referimos al desenlace del proyecto y entrega del producto, donde deberías cumplir con 2 únicas tareas que son:
Enviar entregables.
Enviar retrospectiva del proyecto.
Roles
El equipo de Scrum consiste en tres diferentes roles:
El Product Owner
Es la “voz del cliente” y el responsable de desarrollar, mantener y priorizar las tareas en el backlog.
El Scrum Master
Es responsable de asegurarse que el trabajo del equipo vaya bien siguiendo las bases de Scrum. Además, se encarga de remover cualquier obstáculo que pueda encontrar el equipo de desarrollo.
Los Development Team Members
Son los encargados de escribir y probar el código.
Nombre: Extreme Programming (XP)
El Extreme Programming (XP) es una metodología ágil de desarrollo de software con bases en la comunicación constante y la retroalimentación. Uno de sus fines principales es el de construir un producto que vaya en línea con los requerimientos del cliente.
Historia
La programación extrema fue inventada por Kent Beck mientras trabajaba en Chrysler Corporation en 1996, años antes de que se firmara el Manifiesto Ágil. El trabajo de Kent en este proyecto se hizo popular por haber tenido éxito en tan sólo un año y dos meses cuando un equipo de 30 personas había fracasado durante años.
Mientras Beck trabajaba en el proyecto comenzó a refinar la metodología y posteriormente escribió un libro sobre esta, el cual se publicó en octubre de 1999.
Pero a pesar del éxito que tenía su técnica, el proyecto terminó siendo cancelado en el año 2000, tras la compra de Chrysler por Daimler-Benz.
Actividades
Planificación: toma como referencia la identificación de la historia del usuario con pequeñas versiones que se irán revisando en periodos cortos con el fin de obtener un software funcional.
Diseño: trabaja el código orientado a objetivos y, sobre todo, usando los recursos necesarios para que funcione.
Codificación: se refiere al proceso de programación organizada en parejas, estandarizada y que resulte en un código universal entendible.
Pruebas: consiste en un testeo automático y continuo en el que el cliente tiene voz para validar y proponer. Es, en pocas palabras, la prueba de aceptación.
Etapas
Exploración
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.
Planificación de la Entrega
En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimación del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debería obtenerse en no más de tres meses. Esta fase dura unos pocos días.
Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración (para maximizar el valor de negocio). Al final de la última iteración el sistema estará listo para entrar en producción.
Producción
La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase.
Mantenimiento
Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente.
Muerte del Proyecto
Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.
Roles
Cliente
Los clientes son los responsables de definir los objetivos del proyecto, así como de conducir su gestión. Marcan las necesidades y las prioridades en el proyecto.
Programadores
Como especialistas en las actividades que ayudarán a cumplir los objetivos, los programadores serán los encargados de delimitar duraciones y estimar tiempos. Por lo que planificaron el proyecto, con respecto a los requisitos acordados con los clientes.
Testers
El Tester o encargado de pruebas amplía su marco de ejecución, pues su comunicación con el cliente será vital para alinear resultados con requisitos estimados.
Tracker
Su objetivo será que en todo momento haya un control y un por qué se realiza cada cosa. También la comunicación y relación constante con el cliente es clave. Definirá los hitos o puntos de control en la planificación, en función de los objetivos del cliente y las estimaciones de tiempos de ejecución de tareas del equipo de programadores.
Coach
Los Coach realizan una tarea fundamental: el asesoramiento y orientación continúo tanto para el equipo de trabajo como para los clientes. Son la guía del proyecto, para que todos sepan bien qué, cómo y cuándo hacerlo.
Gestor (BIG BOSS)
Es el vínculo entre el cliente y programadores. Experto en tecnología y labores de gestión. Construye el plantel del equipo, obtiene los recursos necesarios y maneja los problemas que se generan. Administra a su vez las reuniones (planes de iteración, agenda de compromisos, etc). Su labor fundamental es la coordinación.