Ejercicio 3

Métodos Ágiles
Trabajo Práctico Nº1
Crystal Clear - Fabrica Textil
Integrantes:
Antognetti, Germán
Crego, Facundo
Gini, Daniel
Jeanne, Federico
Llano, Anibal
Perez, Alejandro
Pucheta, Nestor
Ejercicios 1 y 2
Hemos decidido dar la respuesta a los dos incisos como uno solo, ya
que se hace más sencillo explicar cada una de las actividades
propuestas por Crystal Clear a medida que se van introduciendo. Al
momento de presentar cada “ciclo”, se presenta un workflow para el
mismo si se considera que es demasiado complejo.
CICLO DEL PROYECTO
A pesar de que un proyecto se ve
como una actividad única, en
realidad luego formará parte de un
proyecto más grande y conviene
verlo como un ciclo. El ciclo del
proyecto en CC consta de tres partes:
1. Una actividad de diagramación.
2. Una serie de dos o más
entregas.
3. Una conclusión del proyecto.
Diagramación
Esta actividad lleva desde algunos días hasta algunas semanas.
Consiste en cuatro pasos:
1. Construir la base del equipo.
2. Realizar el exploratory 360º (que puede dar lugar a cancelar el
proyecto).
3. Formar y ajustar las convenciones de la metodología.
4. Construir el plan inicial del proyecto.
1. Construir la base del equipo: normalmente se empieza con un
sponsor ejecutivo, un diseñador líder y eventualmente un usuario
clave.
Luego, se agregan de 2 a 5 personas con distintos niveles de
habilidades y experiencias: novatos o programadores junior, o más
gente experimentada. Mientras más gente inexperta haya en el
equipo, más difícil se hace avanzar y capacitar al personal
paralelamente. Debe haber al menos una persona experimentada por
cada dos o tres juniors.
2. Realizar el exploratory 360º: En un punto temprano del proyecto,
el equipo, incluido el sponsor ejecutivo, hace un chequeo de las
cuestiones claves. Esto es el equivalente, a la fase de Inception
del RUP. En este chequeo, se cercioran de que el proyecto no se
base en:
• El valor de negocio
• Los requisitos
• El modelo del dominio
• La tecnología que se utilizará
• El plan del proyecto
• La conformación del equipo
• La metodología o las convenciones que se utilizarán
En esta fase, el sponsor se asegura de que el equipo, la
tecnología y la metodología puedan dar el valor de negocio
intencionado para este proyecto. El sponsor puede cancelar el proyecto
en esta etapa (mejor ahora que más tarde).
3. Formar y ajustar las convenciones de la metodología: esta
actividad no debería llevar más de una semana. Puede hacerse
usando las técnicas de ajuste de metodologías, los casos de
desarrollo de RUP, o similares.
No es más que un conjunto de convenciones que el equipo acuerda
adoptar. Lo más rápido es empezar con el conjunto de reglas mejor
pensado por el equipo, así las adaptaciones no tendrán que ser tan
drásticas. Las reglas se adaptan dos veces por iteración o por ciclo
de entrega.
4. Construir el plan inicial del proyecto: Hay varias maneras dentro
de los límites de tolerancia del CC de construir un plan inicial del
proyecto.
• La técnica de blitz planning.
• Un método más riguroso y más cuidadoso: DSDM . Implica
un sistema de chequeos de los objetivos del proyecto con el
sponsor ejecutivo, seguidos por la construcción de un plan
de entrega y de una serie de time-boxes, cada uno de tres
meses de largo.
• El método Scrum, fija los time-boxes a un mes de duración.
• En el juego del planeamiento de XP el equipo, incluyendo su
“cliente,” escribe un conjunto de tarjetas para los requisitos
funcionales y clasifica esas tarjetas en time-boxes de tres
semanas. El equipo discute con el sponsor de la frecuencia
apropiada de la entrega a los usuarios reales, y después
agrupa las iteraciones en los períodos de entrega, a menudo
cerca de tres meses de largo.
Cada una de estas técnicas está dentro de las tolerancias de
la metodología CC. Cada una proporciona un plan inicial del
proyecto, y es suficientemente rápida como para ser
utilizada sobre una base regular para detectar cambios en
la situación del proyecto y para actualizar el plan.
Reflexión de la Diagramación
El objetivo es que el grupo conozca de manera temprana hacia
donde va dirigido el proyecto, la tecnología que usa, las metas y su
valor de negocio. Todo esto fortalece al equipo.
Los resultados de la actividad de diagramación son:
• Un voto para seguir o no con el proyecto.
• Un grupo de gente con un diagrama y una idea de lo que están
haciendo.
CICLO DE ENTREGA
El ciclo de la entrega tiene tres o
cuatro partes:
1. Una recalibración del plan de
entrega.
2. Una o más iteraciones, cada
una dando por resultado
código integrado, probado.
3. Entrega a los usuarios reales.
4. Un ritual de la terminación,
incluyendo la reflexión sobre
el producto que es creado y
las convenciones que son
utilizadas.
1. Recalibración: A esta altura el equipo aprendió que tan rápido
trabajan, que errores cometen, y que tan erradas estaban sus
estimaciones iniciales.
Deben elegir entre apegarse al plan original y simplemente
actualizarlo, o reveer ambos los requerimientos y el plan.
Crystal Clear no decide por ninguna opción, deja en manos del
sponsor del proyecto. Si este decide que el proyecto está llevando
demasiado tiempo, puede optar entre las siguientes tres
alternativas:
• Reemplazar el equipo.
• Ajustar el alcance del proyecto y los tiempos de entrega.
• Plantear nuevas estrategias para realizar el proyecto con el
equipo y tiempo disponibles.
2. Iteraciones: Ver sección de iteración.
3. Delivery: a la hora de realizar la entrega se cuenta con dos
opciones:
•
Hacer una entrega extensiva, con manuales y práctica para
el usuario, lo cual es más costoso.
• Encontrar un usuario amigable, que aprenda rápido, y que
lo haga como una cortesía para el equipo.
Uno trata de usar la primera opción, pero para que se haga de
manera más eficiente se deben hacer entregas en periodos de 3
meses. Si tarda menos se hacen muy costosas cada una de las
entregas, y si tardan más el equipo no puede mantener en mente
todo lo que realizaron.
4. Ritual de terminación: En esta fase se hace mucho hincapié en la
relajación del equipo, luego la reflexión sobre la metodología y,
en menor medida, cómo funciona el software.
El principal objetivo es lograr que los integrantes del equipo se
“desenchufen” del proyecto durante un tiempo (2 días),
realizando actividades sociales (caminatas, charlas, etc.), ya sea
entre el equipo o cada uno por separado. De esta manera al
momento de regresar al trabajo, el equipo viene con fuerzas
renovadas.
En la parte de la reflexión el equipo se pregunta: “¿Qué nos gustó
y debe permanecer así?”, “¿Qué debemos cambiar? ”.
Por último, para observar el uso del sistema, se pueden grabar e
incluso contratar a terceros para que observen a los usuarios en
interacción con el mismo.
CICLO DE ITERACION
El largo y formato de las
iteraciones varían según el equipo
de desarrollo. Hay 2 posibles tipos
de iteraciones: iteración de una
semana; iteración de 2 meses. Se
busca un tiempo intermedio entre
estos extremos.
Una iteración comprende 3 partes:
1 – Planeamiento de la iteración.
2 – Actividades diarias y ciclos de
integraciones.
3 – Reflection Workshop y
ceremonia.
Con el desarrollo de las
iteraciones, el equipo buscara
agregar requerimientos,
extendiendo, de esta manera, la
infraestructura del sistema, sumando funcionalidad con su
correspondiente testeo y mostrando el sistema al usuario.
Iteración de una semana:
Como una semana no es mucho tiempo, el equipo deberá dividir su
trabajo en pequeñas partes para garantizar que pueden ser
desarrolladas, testeadas e integradas.
A primera hora de cada día, el equipo se reunirá unos pocos minutos,
para planificar los puntos a tratar durante la jornada, resolver
problemas que pueden ser relevantes y que cada integrante tenga un
conocimiento general de la tarea de los demás.
Durante la semana se desarrollan las actividades normalmente. Los
episodios consisten en tomar el trabajo asignado, desarrollarlo y
chequearlo. También se desarrolla una integración y el testeo del
sistema.
El riesgo de las iteraciones cortas es que se olvidan de traer usuarios
reales.
Finalización:
Para una iteración de una semana, la ceremonia de cierre es algo
“emocional”, más que otra cosa. Algunos equipos van anotando
sugerencias durante las reuniones diarias, para permitir ser tratadas al
comienzo del siguiente día. De esta manera, al final de la semana,
permitirá evaluar puntos a favor y en contra de su hábito de trabajo.
Iteración de 2 meses:
El planear una iteración de esta longitud, puede tomar hasta un día
completo, dependiendo de la práctica que tenga el quipo en las técnicas
usadas.
Durante la iteración, el transcurso de las actividades diarias es igual a
las iteraciones de una semana. Una de las diferencia es que se debe
realizar un reflection workshop a mitad de iteración (al mes), aunque
más simple que el workshop final. El objetivo de esto, es descubrir
cosas que deben ser resueltas antes de terminar con dicha iteración.
Finalización
El reflection workshop puede llevar desde una hora hasta medio día, ya
que deberán revisar todos los aspectos de su trabajo, donde se
comentan convenciones de codificación y técnicas aprendidas, por
ejemplo.
Luego de la primera iteración o entrega, los equipos van adquiriendo
experiencia logrando que los tiempos tiendan a disminuir.
CICLO DE INTEGRACIÓN
Un ciclo de integración, puede durar
desde media hora a muchos días,
dependiendo de la práctica del
equipo. Algunos equipos utilizan
maquinas que corren script
automáticos, mientras que otros
hacen integración cada día o 3 veces
a la semana. Crystal Clear no
determina una duración para la
integración.
EL DIA
Comienza con la reunión diaria, y
consiste en diseñar uno o más
episodios. Algunos equipos integran
episodios de múltiples días, y otros
realizan en un día, varias
integraciones de varios episodios
cada una.
DESARROLLO DE UN EPISODIO
Es la unidad básica del trabajo del programador en un desarrollo ágil.
Durante un episodio, una persona toma una pequeña parte del diseño
que le fue asignada, la programa hasta completarla, esto incluye el
testeo, y lo verifica con las reglas de negocio.
En el Crystal Clear, no existen 2 roles diferentes entre diseñador y
programador, por eso, hay un único rol Diseñador-Programador, lo que
facilita poder sentarse a programar, pudiendo diseñar y viceversa.
Ejercicio 3
a) Enumere las ventajas y desventajas que ve de no tener un proceso definido
b) Tome las 3 prácticas de Crystal que le parecen más interesantes y desarrolle
un ejemplo donde considere que serían beneficiosas.
c) Cuáles son las 2 características que determinan la complejidad de un proyecto
según crystal?
d) Realice un Process Miniature de manera tal de poder realizar el ejercicio 4, y
presente las notas resultados del mismo, para presentar a la cátedra y a sus
compañeros de la materia
a) Las ventajas de no tener un proceso definido en la metodología
Crystal Clear, son:
1. El proceso se adapta fácilmente a cambios. Por ejemplo:
a. Cambio de requerimientos funcionales.
b. Anticipación en los tiempos de entrega.
2. Los integrantes del proyecto se sienten conformes, ya que todos
se encuentran prácticamente al mismo nivel, lo cual genera
motivación.
Las desventajas de no tener un proceso definido en la metodología
Crystal Clear, son:
1. Debido a la falta de documentación, la perdida de un empleado
genera un fuerte impacto ya que se lleva consigo todo su
conocimiento sobre el proyecto.
2. Los integrantes del grupo deben ser gente con experiencia.
3. La cantidad de integrantes del proyecto debe mantenerse baja.
4. No es posible aplicar la metodología a proyectos críticos
b)
Enumeraremos en un principio las tres prácticas de Crystal más
importantes:
Frequent Delivery
* Los usuario y los clientes consiguen retroalimentación en el
progreso del equipo
* Los clientes pueden verificar que sus necesidades fueron
interpretadas correctamente
* Los Desarrolladores pueden mantener el foco, y rompen “Tiempos
ociosos por indecisión”
* Las realizaciones frecuentes levantan la moral del grupo.
Las metodologías Crystal consideran que la entrega frecuente es la
característica más importante de las siete características, para
cualquier proyecto, sin importar su tamaño. Esta entrega de la
aplicación, y del código probado se debe efectuar, típicamente, cada
dos meses, y no más que cada cuatro meses. Si el proyecto es
particularmente pequeño, estas entregas deben ser más frecuentes. La
prueba de los verdaderos usuarios expertos es una característica
esencial de estas entregas.
Estas entregas dan a clientes la retroalimentación en cómo está
progresando el equipo. También permite al equipo y los clientes
verificar que el equipo han interpretado correctamente sus
necesidades, y proveer al equipo retroalimentación.
La entrega frecuente puede también ayudar al foco y a la moral de un
equipo. El equipo consigue la retroalimentación actualizada en las
decisiones del diseño. Pues el equipo puede eliminar errores y
desplegar productos con frecuencia, pueden obtener un alza de la
moral con estas realizaciones frecuentes.
Reflective Improvement
Reflective Improvement es otra característica esencial de los proyectos
Crystal Clear. Simplemente significa que los equipos deben reflejar en
lo que están haciendo y, basado en esta reflexión, buscar mejoras
potenciales. En una sesión de revisión, el equipo o individuo mira en lo
que creen que en el programa está funcionando, y qué podría
posiblemente funcionar mejor. Pueden entonces incorporar mejoras
potenciales en la iteración o la entrega siguiente. En la sesión siguiente
de la revisión, la eficiencia de estas mejoras puede ser evaluada.
Las reflexiones y las mejoras repetidas dejan a equipo constantemente
mejorar. Si qué se parecía como una mejora era realmente perjudicial,
esto puede ser detectada en la revisión siguiente, y ser invertida. Los
equipos no necesitan pasar una cantidad grande de tiempo en la mejora
reflexiva. Una hora cada pocas semanas pasaron el pensamiento de qué
trabaja, y las áreas para la mejora son generalmente suficientes.
Comunicación por ósmosis
La comunicación por ósmosis es una característica crucial en Crystal
Clear. En el entorno de trabajo, la información útil debe fluir libremente
en el ambiente que oyen los miembros del equipo. Esto permite que los
miembros tomen la información relevante, como si fuera por ósmosis.
Similarmente, si un miembro del equipo oye por casualidad una
pregunta o la discusión a la que sienten puede contribuir entonces
pueden hacer un comentario útil, y después vuelven a su trabajo. Por la
comunicación por ósmosis, los miembros del equipo pueden, casi
subconscientemente participar en conversaciones circundantes con
impacto mínimo a su trabajo.
El entorno de trabajo debe facilitar la comunicación osmótica. Lo más
importante para esto es tener el equipo entero trabajando en el mismo
cuarto - el “cuarto de guerra”. Esto permite que los miembros lo
adapten siempre que alguien haga una pregunta. Los miembros pueden
también tomar la información oyendo por casualidad discusiones
relevantes entre otros miembros.
Otros aspectos del ambiente pueden ayudar a la comunicación
osmótica. Los escritorios y las sillas se deben colocar para la
obstrucción mínima a las discusiones. También, los pizarrones son
útiles para compartir la información, pues pueden ser vistos por todos
los miembros, durante y después de la discusión. Si el equipo tiene
acceso a pizarrones imprimibles, esta información se puede almacenar
para una referencia posterior.
3 b) Un ejemplo donde la utilización de éstas prácticas de Crystal Clear pueden
ser beneficiosas sería en el caso de una pequeña empresa compuesta por un
grupo de desarrollo de 3 personas que se dedican al diseño e implementación de
sistemas Web. Las tres personas poseen conocimientos avanzados en la
tecnología utilizada, comparten un mismo espacio físico donde trabajan juntos y
poseen un pizarrón donde pueden expresar sus ideas.
Los tiempos de las “entregas frecuentes” se adaptan al tamaño del sistema Web
que se esta implementando.
3 c) Las 2 características que determinan la complejidad de un proyecto según
crystal son:
Numero de personas: Numero de personas que están involucradas en el
proyecto.
Criticidad: Se refiere en qué impactarán las fallas del sistema.(Comfort, Dinero,
Vidas).
En el siguiente gráfico se puede apreciar como dependiendo de éstas dos
características se puede seleccionar un determinado tipo de metodología dentro
de la familia Crystal (Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red)
Process Miniature:
Crear un pequeño proyecto de (90’ a un día) para permitir al grupo de
desarrollo para probar la metodología.
- Les permite aprender la metodología rápidamente.
- Les ayuda a identificar deficiencias en el proceso.
3 d) Para el Process miniature se seleccionó una parte pequeña del
proyecto que corresponde al login del sistema web utilizando una
pequeña base de datos. De esta forma el equipo puede comenzar a
poner en práctica las técnicas y estrategias de la metodología.
De esta forma logramos:
- Integración del grupo.
- Conocimiento de habilidades en el grupo.
- Definición de la ceremonia.
- Uso de las herramientas de documentación (pizarra).
Ejercicio 4
Tailoring
Debido a que en el método Crystal Clear se le da más importancia a los
recursos humanos que al proceso en sí, primero se realizará el tailoring
del ambiente de trabajo, la conformación del equipo, las técnicas,
estrategias, propiedades y por último el proceso.
Ambiente y conformación del equipo
El equipo de desarrollo se encuentra trabajando en el mismo lugar
físico, el cual cuenta con buena iluminación y ventilación.
Adicionalmente existe otro ambiente con muebles confortables y un
pizarrón donde los integrantes del equipo desarrollan las reuniones y
eventualmente distenderse. En ambos ambientes existen plantas y las
paredes se encuentran pintadas con colores armoniosos para permitir
un lugar saludable de trabajo.
La disposición de las computadoras y los integrantes del equipo es la
siguiente:
En este esquema se puede apreciar la disposición de los integrantes del
equipo y de los muebles que se encuentran en el lugar de trabajo.
Adicionalmente se aprecian las plantas, los colores tenues y los
pizarrones en las paredes. La disposición de los escritorios facilita la
utilización de la técnica Side-by-Side Programming y el contacto visual
entre las cuatro personas. Debido a la diferencia de habilidades entre
los miembros del equipo se sugiere que en una de las mesas se sienten
el Programador Senior y el Junior juntos y en la otra los dos
programadores Semi-Senior.
Como resultado de este ambiente de trabajo también se logra la
Comunicación Osmótica tan importante en esta metodología.
Otro aspecto importante para todo proyecto es la motivación de las
personas. Este grupo se encuentra motivado ya que habían trabajado
juntos, conocen la tecnología y se encuentran en un ambiente
agradable. Adicionalmente, el vínculo con el cliente es fuerte, debido a
que se cuenta con dos sponsors que avalan políticamente el proyecto y
transmiten seguridad al equipo.
Técnicas
Methodology shaping: como el equipo tiene experiencia previa en
desarrollos similares, no es necesaria una puesta en común con la
terminología que se va a usar, los integrantes se conocen y saben de lo
que se habla.
Reflection workshop: al final de cada iteración, el equipo se reúne en
la sala en el otro ambiente para discutir sobre cómo está trabajando el
equipo, cómo se relacionan los integrantes, incluso convenciones de
código. Luego identifican problemas y explican cómo los solucionaron y
cómo podrían evitar que vuelvan a aparecer.
Daily stand ups: los integrantes del equipo, se juntan 5 a 10 minutos a
primera hora de cada día para informarse sobre las tareas que
realizarán los demás.
Process Miniature: como se menciono anteriormente, se utilizo una
funcionalidad simple del sistema para familiarizarse con la metodología.
Delphi Estimation: vemos que esta técnica fue utilizada, ya que la
estimación del costo del proyecto fue realizada estimando con respecto
a horas de trabajo y comparando con proyectos análogos previos.
Estrategias:
Information radiators: como se mostró anteriormente, los radiadores
de información son los pizarrones ubicados en las paredes laterales del
ambiente de trabajo.
Walking Skeleton: Para el presente proyecto el Walking Skeleton
consistirá en una interface Web sencilla, la integración con la Base de
datos y permitirá cargar los datos básicos de los operarios. Dado que el
desarrollo debe ser implementado utilizando Open Source, las
tecnologías a utilizar son PHP, PostgreSQL y Eclipse.
Propiedades:
Frequent Delivery: Debido a las características del proyecto, se
utilizará un tiempo de entrega de dos semanas. Cada entrega estará
compuesta por más de una iteración.
Iteraciones: Las iteraciones pueden variar de una a dos semanas
dependiendo la funcionalidad abordada.
Automated Test: El sistema será testeado automáticamente 3 veces
por semana, en horario no laboral. El más importante de estos tests es
uno creado específicamente para realizar una gran cantidad de
consultas y verificar que ninguna de éstas exceda los 3 segundos en
devolver el resultado.
Ejercicio 5
Cuestionamientos a la metodología
-
-
El programador junior puede no contar con la experiencia
necesaria para hacer un uso correcto de las libertades que
brinda esta tecnología. Puede estar mucho tiempo ocioso o no
saber comunicarse con los demás integrantes del grupo.
La metodología no deja bien en claro cuales y que cantidad de
artefactos deben ser generados.
Es necesario que la empresa tenga la infraestructura necesaria
para que todos los integrantes ocupen un mismo lugar físico.