Que significa puntos de historia
- Detalles
- Publicado: Martes, 16 Junio 2009 00:00
- Escrito por Diego Gomez
Tradicionalmente los proyectos de software son estimados usando períodos de tiempo como unidad de medida. "Esta funcionalidad llevará 5 días para ser completada" o "Esta tarea me tomará 2 horas." Los procesos ágiles en general han adoptado otra forma de estimación de actividades y alguna confusión se ha creado en torno a esta cuestión.
Una de las estrategias más populares es el uso de Puntos de Historia como unidad de medida de las actividades. Pero, ¿qué son de hecho los Puntos de Historia? La respuesta clásica es "una unidad de medida creada para expresar el tamaño global de una actividad," Tenga en cuenta que usamos la palabra TAMAÑO, un error común es tratar sólo los a los puntos de historia como una medida de complejidad, cuando en realidad los puntos de historia son una combinación de cosas como:
¿Ven esta pila de dinero a la izquierda? Representa tan sólo una pequeña fracción de la cantidad de dinero que tu organización está desperdiciando por no poder gestionar correctamente el alcance de los proyectos. Y no me refiero a los retrasos ocasionados por requerimientos crecientes. Estoy hablando de algo completamente diferente. Algo mucho más fundamental y facil de obtener cuando una organización realmente se compromete con todo lo que Ágil tiene para ofrecer. Para mi éste es uno de los beneficios más importantes de la agilidad, pero hay muy pocas organizaciones que lo hacen bien.
La forma más común para que los equipos entreguen productos más rápido es reduciendo el alcance de cada producto. Sin embargo, esto no puede hacerse de manera arbitraria. Hay motivos de negocio reales para cada una de los requerimientos que se piden (¡o al menos eso esperamos!). 
Una característica clave de los equipos que hacen Programación en Parejas es que su nivel de comunicación es mucho más alto que los equipos que trabajan en forma individual. Y es ahí donde podremos encontrar el verdadero motivo en aplicar esta técnica.
Recientemente, 
Cuando las empresas están experimentando y examinando los métodos ágiles, la presión de la dirección es "muéstrame el dinero" cambiar la forma en que una gran empresa en entrega software es como tirar un tanque de petrolero -posible, pero necesitas tiempo y energía. La gerencia debe estar convencida de que el cambio promoverá el alcance de al menos uno de los dos objetivos estratégicos de toda organización: reducir costos o incrementar las ventas.
Navengado por ahí me encuentro con un excelente 
GTD (Getting Things Done - Terminar las cosas) es una idea originaria (en cuanto a lo de ponerle nombre) de David Allen. La idea principal detrás de todo esto es la de conseguir organizarse. Es una recopilación de métodos que ayudan a estar más organizado.
Recientemente, Buddha Buck 
No sé. A veces siento que algunas personas venden mal todas las excelentes ventajas del Desarrollo Guiado por Pruebas (TDD) y la Programación de a Pares (PP). Es que muchos agilistas exponen este argumento: al hacer TDD y PP se incrementa la calidad, así que aunque la productividad disminuya, tenemos la conciencia tranquila de que fuimos buenos ciudadanos del mundo del software.
Muchos equipos ágiles se enfrentan a un dilema cuando toman una nueva historia al final de un Sprint. Todavía existe tiempo restante, pero no lo suficiente para terminar esta nueva historia. Un interesante debate en el grupo Scrum Development intenta encontrar algunas soluciones a esta cuestión.