¿Y qué pasa con los casos de uso en los proyectos Ágiles?
- Detalles
- Publicado: Miércoles, 18 Febrero 2009 09:12
- Escrito por Leonardo De Seta
Dean Leffingwell, autor de Scaling Software Agility, nos explica que los Casos de Uso son una herramienta valiosa para modelar requerimientos en proyectos Lean/Ágiles de gran envergadura. No es común encontrar casos de uso en los proyectos Lean/Ágil (especialmente en XP y Scrum), en donde se suele utilizar historias de usuario para recolectar los requerimientos.
En 
Hace poco vimos el concepto de 
Un objetivo común en Sistemas es poder determinar la productividad de varias técnicas, herramientas y personas como parte del esfuerzo total para mejorar dicha productividad. Si podemos medir la productividad de manera simple, vamos a poder identificar lo que está funcionando bien en determinadas situaciones, o lo que no está funcionando, y realizar los ajustes necesarios.
Hace algún tiempo, 
El Desarrollo de Software Lean tiene sus inicios en el Sistema de Producción de Toyota (TPS) y ayuda a las organizaciones de software a optimizar sus procesos y sus métodos de producción de manera de poder entregar sus productos al mercado de manera más rápida y con mejor calidad. El movimiento Lean puede considerarse como un nuevo método de desarrollo que intenta identificar y erradicar todos los problemas y "desventajas" de metodologías antiguas, como Cascada.
Los equipos de Scrum suelen comprometerse a realizar historias, las cuales luego las descomponen en tareas. Estas tareas son estimadas y re-estimadas a diario para actualizar el gráfico de Burndown. Pero no todo es tan bonito y simple. Muchas veces, crear estas tareas es algo que simplemente apesta. ¿Hay alternativas?
El Patrick Kua publicó en su blog algunos consejos interesantes que usa cuando está trabajando en pareja.
La Programación en parejas y las Revisiones de código son prácticas que aumentan la calidad del software, así como promover la difusión del conocimiento. Si bien los debates 
Al comienzo de cada sprint, el equipo de Scrum y el Dueño del Producto negocian el alcance del sprint. Tienen una cantidad limitada de tiempo para discutir y acordar el backlog del sprint. El Dueño del Producto quiere que la funcionalidad se implemente adecuadamente e invertir el dinero de forma inteligente. El equipo quiere un acuerdo que pueda cumplir. ¡Y todos quieren que la reunión termine a tiempo!