Respuesta corta: porque cada producto, grupo tecnológico, equipo de desarrollo, necesidades organizativas, modelo de ingresos y muchos otros factores son únicos en cada caso. Especialmente cuando necesita agilidad, tiene sentido tener estimaciones basadas en el esfuerzo para iterar y adaptarse. Esto es especialmente importante en productos digitales basados en la web.
Respuesta larga sobre cómo abordar la estimación basada en el esfuerzo con puntos ágiles:
Nosotros (en el camino escalable ) nos enfocamos en procesos para desarrollar productos digitales de manera efectiva y eficiente. Uno de nuestros procesos es usar el desarrollo ágil ( o desarrollar con agilidad ), que incluye el uso de puntos ágiles para asignar una definición común al esfuerzo requerido para completar las tareas. En esta publicación nos centraremos en la secuencia de Fibonacci modificada: 0, 1, 2, 3, 5, 8, 13, 21, etc., como una escala de complejidad exponencial. Esta definición de complejidad debe ser compartida por todo un equipo, desde desarrolladores, propietarios de productos, ejecutivos, hasta cualquier otra persona que desee comprender los matices y complejidades de desarrollar productos digitales dentro de este marco. El marco le permite a usted y a la organización tener visibilidad de los plazos, la complejidad, el presupuesto y la dotación de personal.
- ¿Qué marco PHP es mejor para CRM? Codeigniter o Laravel?
- ¿Cuál es la pila tecnológica detrás de YouTube?
- ¿Hay alguna posibilidad de tomar un sitio de redes sociales como una startup?
- ¿Cuál es la forma de hacer un sitio web de preguntas y respuestas como Quora? Soy un programador de 13 años. Necesito un tutorial.
- ¿Cómo cambio el texto y el estilo de un elemento de entrada del archivo de carga HTML?
Así es como interpretamos los puntos ágiles en nuestros proyectos y el esfuerzo de desvinculación de horas.
PUNTOS Y SIGNIFICADO
0 – MUY RÁPIDO PARA ENTREGAR Y SIN COMPLEJIDAD; POR ORDEN DE MINUTOS
- Uno debería poder entregar muchos 0 en un día
- Sé exactamente lo que hay que hacer, y me llevará muy poco tiempo.
- Ejemplo: cambiar el color en CSS, corregir una consulta simple
1 – RÁPIDO PARA ENTREGAR Y COMPLEJIDAD MÍNIMA; EN EL PEDIDO DE UNA HORA +
- Uno debería poder entregar un puñado de 1 en un día
- Sé exactamente lo que hay que hacer, y me llevará poco tiempo
- Ejemplo: agregar campo a un formulario
2 – RÁPIDO PARA ENTREGAR Y ALGUNA COMPLEJIDAD; EN EL PEDIDO DE HORAS MÚLTIPLES / MEDIO DÍA +
- Uno debería poder entregar uno 2 cómodamente en un día
- Principalmente sé lo que hay que hacer, dónde se deben implementar las mejoras / cambios, y me llevará algún tiempo
- Ejemplo: Agregar parámetro al formulario, validación, almacenamiento
3 – TIEMPO MODERADO PARA ENTREGAR, COMPLEJIDAD MODERADA Y POSIBLEMENTE ALGUNA INCERTIDUMBRE / DESCONOCIMIENTOS
- En el pedido de aproximadamente un día o más para entregar
- Tengo una buena idea de lo que hay que hacer, y me llevará un poco de tiempo.
- Ejemplo: migrar CSS estático algo complejo a un preprocesador CSS
5 – MÁS TIEMPO PARA ENTREGAR, ALTA COMPLEJIDAD Y PROBABLEMENTE DESCONOCIMIENTOS
- En el pedido de aproximadamente una semana o más para entregar
- Sé lo que hay que hacer a un alto nivel, pero hay una buena cantidad de trabajo debido a la complejidad / cantidad de desarrollo, y hay grandes incógnitas que descubriremos a medida que nos adentramos en el trabajo.
- Ejemplo: integrarse con API de terceros para empujar / extraer datos y vincular a perfiles de usuario en la plataforma
8 – LARGO TIEMPO PARA ENTREGAR, ALTA COMPLEJIDAD, DESCONOCIMIENTOS CRÍTICOS
- En el orden de un par de semanas +
- Entiendo el concepto y los objetivos, pero me llevará un tiempo entregarlo debido a la cantidad de trabajo, la complejidad y las incógnitas.
- Si tenemos un 8, deberíamos dividirlos en tareas / problemas más pequeños con valores de puntos más pequeños y minimizar la complejidad
- Esto podría requerir un Spike para diseñar / eliminar la incertidumbre, o crearse como una epopeya con historias más granulares dentro de ella.
- Ejemplo: revisar el diseño / HTML / CSS / JS de una aplicación web
13 – MUCHO TIEMPO DE ENTREGA, ALTA COMPLEJIDAD, MUCHAS DESCONOCIMIENTOS CRÍTICOS
- En el orden de muchas semanas / mes
- Similar a un 8; Esto definitivamente debería ser épico, y requiere discusiones sobre cómo lograr
- Ejemplo: migre la aplicación del almacén de datos obsoleto a la nueva tecnología DB y ORM
21 – ESTÁS HACIENDO ESTO MAL … 
PENSAMIENTOS FINALES
Como puede ver, esto no es claro y deja mucho espacio para la interpretación. Es difícil estimar el desarrollo de software, y hay muchos factores a considerar, incluida la complejidad para desarrollar dada la arquitectura existente, la disponibilidad del equipo, las prioridades comerciales, la complejidad imprevista de terceros, el uso de CD (entrega continua) / pruebas automatizadas, etc. Lo que los equipos deben esforzarse Lo que hay que hacer es construir una cultura en la que haya un buen conocimiento de la solución, y todos estén de acuerdo en las definiciones del nivel de esfuerzo requerido para entregar cada pieza de funcionalidad, tarea, corrección de errores, etc.
Hay muchos temas que no están cubiertos en esta publicación, como discutir picos, el propósito de los sprints en entornos de CD y mucho más. Muchos desarrolladores digitales también utilizan la metodología de cascada en lugar del desarrollo ágil. Waterfall Methodology se relega a proyectos muy específicos donde el lujo de iterar y adaptarse rápidamente no está disponible: piense en construir un avión (o software de vuelo donde los errores son del tipo mortal). El objetivo principal de esta publicación es comenzar a implementar puntos ágiles en sus proyectos; investigue, aprenda, repita y descubra qué funciona mejor para su (s) equipo (s) y organización (es).
OTROS RECURSOS:
- Desarrollo Ágil de Software
- Historia del usuario
- Ejecución de programas ágiles (sin perder la cabeza) | El entrenador ágil
- Una breve introducción a Scrum: proceso y roles de Scrum | El entrenador ágil
- Qué significa ágil para el desarrollador diario | El entrenador ágil
Publicado originalmente en el Blog de la ruta escalable
