Kleer

SINOPSIS

Técnicas para la realización de Retrospectivas

Se abordan 29 técnicas usadas en diferentes partes de la estructura de “retrospectivas” en el desarrollo de proyectos tomando un cuadro-matriz como referencia, donde entre otras cosas se presenta el patrón/técnica, el alcance de su aplicabilidad, algunos comentarios/relaciones/prerrequisitos, etc. Se presenta a la empresa y su autor.

Introducción a la Agilidad y Scrum

Se introduce el concepto de “desarrollo de software” y tres de sus principales elementos: lenguajes de modelado, herramientas, y unas tardías “metodologías de desarrollo”.

Se menciona la adopción del “Modelo Secuencial de Procesos”, “Waterfall Model” ó “Modelo en Cascada” como el desarrollo metodológico más utilizado en la industria del software debido a la carencia de procesos metodológicos en este ámbito, y los orígenes de este modelo metodológico.

Se describen las fases de “Waterfall Model” y se presenta el estudio de Standish Group en 1994 conocido como el “CHAOS Report” que reflejaba imprtantes índices del éxito y proceso de proyectos de desarrollo de software, así como algunas conclusiones, y las nuevas metodologías emergentes en el contexto de esta realidad estudiada y reflejada en el reporte.

A continuación se presentan las “Metodologías Ágiles”, su orígen, el “Manifiesto Ágil”, los 4 valores y 12 principios, así como una presentación y descripción de nueve metodologías ágiles existentes.

Después se entra a describir con mayor detalle “Scrum” como marco del trabajo para aplicar un enfoque de metodología ágil; se presenta una definición general de Scrum, sus tres principios sólidos y largamente respetados, sus dos mecanismos, la concepción de cambio organizacional, los tres roles de Scrum, los dos principales elementos utilizados en Scrum, algunas formas de “priorización” que es responsabilidad del rol “Product Owner”, la dinámica (flujo de trabajo) compuesta principalmente por los Sprints (iteraciones) y los diferentes tipos de reuniones utilizadas. Finalmente una nota sobre la empresa y el autor.

Análisis, Estimación y Planificación Ágil

El documento aplica técnicas de construcción de software y estimación de proyectos para la planificación de un “sistema de gestión de cursos de capacitación” como modelo/ejemplo.

Se introduce la técnica de desarrollo evolutivo/incremental y conceptos como MMF y Visual Story Mapping. Usando técnicas y procesos ágiles se definen los roles de usuario. A continuación aplicando Visual Story Mapping se continúa el proceso de análisis y planificación del “sistema de gestión de cursos de capacitación” con los pasos de identificación de funcionalidades del software (herramientas), identificación de MMF y posteriores releases.

Con la información arrojada por el análisis anterior se introducen las Historias de Usuario, orígen, concepto, elementos componentes (las 3 C’s), redacción, características INVEST, criterios de Listo/Terminado, y las historias de usuario del sistema ejemplo.

Con base en las historias de usuario resultantes se introducen conceptos básicos de estimación ágil y algunas técnicas, para dar paso a las estimaciones de los releases del sistema ejemplo.

Finalmente se presentan el “Release Burn Down Chart” y el “Backlog Burn Down Chart” y un costo tentativo del proyecto.

El documento cierra con la presentación de la empresa y autor.

CITAS

Aprender de la experiencia y darnos un tiempo para pensar en el futuro no es una idea novedosa.

Existe un balance delicado entre el mirar hacia lo que pasó y planear los futuros pasos: queremos aprender del pasado, pero si nos quedamos en el análisis y no lo traducimos en acción, no sirve.

lograr que las acciones y mejoras sean priorizables y medibles, no sólo buenas intenciones.

Mantener el foco en qué hacer en el futuro, no en juzgar lo que se acaba de realizar.

ambientes físicos altamente rígidos donde los cambios se vuelven prohibitivos desde el punto de vista de los costos, sino prácticamente imposibles.

Una vez que se encuentra completa se procede a un “sign-off” (firma/aprobación) que congela dichos requerimientos, y es recién aquí cuando se inicia la fase de diseño del software,

Bajo esta nueva realidad, las metodologías Waterfall resultaron muy “pesadas” y prohibitivas para responder satisfactoriamente a los cambios de negocio.

Las conclusiones de la investigación sugieren que el involucramiento del usuario y el empleo de periodos de tiempo más cortos son claves para incrementar las tasas de proyectos exitosos

Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por la rigidez y dominados por la documentación.

Por el contrario, Scrum propone crear el equipo y que éste construya su propio entorno y procesos en base a sus necesidades.

Medir avance en función de resultados intermedios se convierte en una simple “ilusión de progreso”.

Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo.

Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.

La manera más eficiente y efectiva de compartir la información dentro de un equipo de desarrollo es la conversación cara a cara.

El software funcionando es la principal métrica de progreso.

equipos auto-organizados

A intervalos regulares, el equipo reflexiona acerca de cómo convertirse en más efectivos, luego mejora y ajusta su comportamiento adecuadamente.

mantenimiento evolutivo y/o correctivo

La programación extrema se diferencia de las metodologías tradicionales, al igual que las metodologías ágiles en general, por ser un enfoque basado en la adaptabilidad más que en la previsibilidad.

“el arte de maximizar la cantidad de trabajo no realizado”

Hay que ser valiente para confiar en que la programación por parejas beneficia la calidad del código sin repercutir negativamente en la productividad.

(micromanagement, gestión sobrante)

Mediante la refactorización se intenta mantener la sencillez, la claridad y la cantidad mínima de funcionalidades en el código.

integración continua

“Piensa en grande, actúa en pequeño, equivócate rápido; aprende con rapidez”.

“una manera simple de manejar problemas complejos”

Scrum es un estado de la mente;

La auto-organización funciona cuando hay objetivos y límites claros.

Un timebox no se puede achicar o agrandar, esto es, la entrega del resultado no se debe adelantar ni retrasar. La variable de ajuste es el alcance del producto comprometido en un determinado timebox.

El equipo de desarrollo es auto-organizado. Esto significa que no existe un líder externo que asigne las tareas ni que determine la forma en la que serán resueltos los problemas. Es el mismo equipo quien determina la forma en que realizará el trabajo y cómo resolverá cada problemática que se presente.

Esta característica se conoce como multi-funcionalidad y significa que dentro del equipo de desarrollo no existen especialistas exclusivos, sino más bien individuos generalistas con capacidades especiales.

El equipo de desarrollo tiene tres responsabilidades tan fundamentales como indelegabes.

problemas y conflictos interpersonales

por ello mientras lo hagan no existe una forma “errónea” de trabajar.

“Scrum es fácil, hacer Scrum es difícil 24 ”

Emprender este camino significa adoptar una filosofía de liderazgo servil por sobre el comando y control.

Las responsabilidades del ScrumMaster deberían cubrir la totalidad de su tiempo.

Esta prioridad es responsabilidad exclusiva del Product Owner

Podemos entender el valor de negocio como la relevancia que un ítem tiene para el cumplimiento del objetivo de negocio que estamos buscando.

principios de ritmo sostenible, entrega frecuente de software valioso y adaptación constante

aprendizaje, inspección y adaptación.

En estos casos, la regla del “timeboxing” no nos permitirá modificar (adelantar o postergar) la fecha de entrega o finalización del Sprint. La variable de ajuste en estos casos será el alcance del Sprint, esto es, en el caso de adelantarnos deberemos incrementar el alcance del Sprint agregando nuevos PBIs y reducirlo en el caso de retrasarnos.

Como se ha visto, hemos hablado en potencial: el equipo de desarrollo “podría”, esto “determinaría”.

la retrospección del equipo es el corazón de la mejora continua.

Mientras que la reunión de revisión se destina a revisar el producto (el “qué”), la retrospectiva se centra en el proceso (el “cómo”).

Valiéndose de técnicas de facilitación y análisis de causas raíces, se buscan tanto fortalezas como oportunidades de mejora.

También dicta entrenamientos sobre Scrum, tanto desde una perspectiva de gestión y liderazgo como de un punto de vista de ingeniería y desarrollo de software.

lo que significa segmentar el desarrollo de forma transversal a dichas funcionalidades con el fin de proveer una pequeña porción de cada una en cada entrega, formando un producto utilizable:

Todas las metodologías ágiles coinciden en que un producto debe construirse de forma evolutiva en pequeñas entregas.

MMF: Minimum Marketable Features

“el conjunto más pequeño posible de funcionalidad que, por si misma, tiene valor en el mercado”

Uniendo entonces el concepto de MMF y de nivel de confort, deberíamos pensar la construcción del software de forma evolutiva, naciendo desde lo mínimo posible (MMF) e ir escalando en los niveles de confort de las funcionalidades iteración tras iteración,

Falta de conocimiento técnico.

1) un time-box conocido como “spike” que le permita investigar la solución y proveer una estimación más certera

como lo son los cambios producidos en el contexto de negocio, los cambios tecnológicos y aquellos surgidos por la mera existencia del producto construido

las metodologías ágiles proponen comenzar a trabajar en un proyecto sin la necesidad de tener una estimación precisa basada en supuestos y siendo conscientes de que la estimación inicial es de un orden de magnitud probable,

Esta situación da origen a dos modelos de planificación de Sprint: la planificación basada en velocidad (velocity-based planning) donde el Equipo se compromete a realizar tantos User Stories de modo que sumen una estimación en Puntos de Historia igual a la velocidad del Equipo, por un lado, y la planificación basada en compromisos (commitment-based planning) donde sin importar la velocidad, el Equipo revalúa las Historias de Usuario y se compromete en función de la estimación de cada una de ellas, por el otro.

creemos en una forma de trabajo clara, centrada en las personas y orientada hacia las necesidades

tanto desde una perspectiva de gestión y liderazgo como de un punto de vista de ingeniería y desarrollo de software.

TÉRMINOS

kaizen, retrospectiva, introspección, acotado, acotar, cota, priorizable, priorizar, prioridad, medible, medir, medición, refactorización, refactorizar, equipos auto-organizados, micromanagement, integración continua, marco de trabajo, ScrumMaster, PorductOwner, Sprints, auto-organizado, multi-funcionalidad, valor de negocio, rédito, potencial, criteriosa, criterio, spike, think tank.

REFERENCIAS