Documente Academic
Documente Profesional
Documente Cultură
C Perdida de confort
por fallas del
D Perdida de dinero
discrecional, es
decir del que
sistema
podemos disponer
E Perdida de dinero
esencial, es decir
dinero que
L De Life en inglés,
vida. Indica la
perdida de vidas
probablemente no por fallas del
es nuestro sistema
Propiedades de crystal
Entrega frecuente
Consiste en entregar software a los clientes con frecuencia, no solamente en compilar
el código. La frecuencia dependerá del proyecto, pero puede ser diaria, semanal o
mensual (2 semanas y no más de un mes).
Comunicación osmótica
Todos juntos en el mismo cuarto (cara a cara). La comunicación es más barata y mejor
cuanto más “cercana” sea.
Promueve prácticas como el uso de pizarrones, pizarras y espacios destinados a que
todos (miembros del equipo y visitas) puedan ver claramente el progreso del trabajo.
Mejora reflexiva
Tomarse un pequeño tiempo (unas pocas horas cada semana o una vez al mes) para
pensar bien qué se está haciendo, tomar notas, reflexionar, discutir.
Fácil acceso a usuarios expertos
Tener alguna comunicación con expertos desarrolladores.
Herramientas y Técnicas
• Catalogo simple
• Caso de uso
• Requisito de diseño no funcional
Herramientas • Arquitectura
• Prueba de casos
• Diseño de interfaz de usuario
• Entrevistas de proyectos
• Talleres de reflexión
• Planeamiento Blitz
Técnica • Estimación Delphi con estimaciones de pericia
• Encuentros diarios de pie
• Miniatura de procesos
• Gráficos de quemado
Técnicas
Entrevistas de proyectos
Se suele entrevistar a más de un responsable para tener visiones más ricas.
Talleres de reflexión
El equipo debe detenerse treinta minutos o una hora para reflexionar sobre sus
convenciones de trabajo, discutir inconvenientes y mejoras y planear para el
período siguiente.
Planeamiento Blitz
Se escriben las funciones del programa en tarjetas y los programadores estiman
tiempos para cada una de forma independiente entre las mismas.
Estimación Delphi con estimaciones de pericia
Los expertos se reúnen y definen el tamaño del proyecto, fecha de entrega, etc.
Técnicas
Encuentros diarios de pie
Cinco a diez minutos como máximo. No se trata de discutir problemas, sino de
identificarlos.
Miniatura de procesos
Una forma de presentar Crystal Clear puede consumir entre 90 minutos y un día.
La idea es que la gente pueda “degustar” la nueva metodología.
Gráficos de quemado
Son gráficas en las cuales se observan retrasos en las tareas, este gráfico sirve
para tener un control del proyecto y ver en que funciones deben tener mayor
prioridad.
Programación lado a lado
Establece proximidad, pero cada quien se enfoca a su trabajo asignado,
prestando un ojo a lo que hace su compañero, quien tiene su propia máquina.
Esta es una ampliación de la Comunicación Osmótica al contexto de la
programación.
Estrategias
Todas describen una forma de tomar ventaja del desarrollo incremental para
establecer valor desde el principio.
Estrategias
Ni las estrategias ni las técnicas son mandatorias para Crystal Clear. Pero es
bueno tener en cuenta algunas de ellas al momento de empezar a trabajar.
Desventajas
o Delimita el alcance del proyecto
con el cliente.
En resumen
La guía de trabajo que presenta Crystal Clear es altamente recomendable para
equipos pequeños. Da flexibilidad y prioriza la parte humana (como todas las
Metodologías Agiles), apuntando a lograr eficiencia, habitabilidad y confianza en
los miembros del equipo.
Presta especial importancia a la ubicación física del grupo, donde la
comunicación cumple el principal rol. La entrega frecuente de código confiable y
"funcionando" mantiene el foco y evita distracciones.
El equipo es el que elige qué técnicas aplicar según lo que consideren apropiado
en cada proyecto.
Conclusiones
o Cuantas más personas estén implicadas, más grande debe ser la metodología.
o Si el proyecto tiene mucha densidad, un error no detectado puede ser crítico.
o El aumento de tamaño o densidad añade un coste considerable al proyecto.
o La forma más eficaz de comunicación es la interactiva (cara a cara).
Bibliografía
o Hans Van Vliet, “Software Engineering. Principles and Practice” (Tercera
edición, 2002).
o Ian Sommerville, “Software Engineering” (Sexta Edición, 2001).
o Ivar Jacobson, Grady Booch y James Rumbaugh, “The Unified Software
Development Process” (1999).
o https://metodosdesarrolloagil.wikispaces.com/-+Crystal
INTEGRANTES:
DANIEL LAURA
Y E S S I C A S I LV E S T R E
M E L I S S A TA N TA C A L L E
KAREN ZALLES