design - thinking - ¿Cómo calificas un proyecto ágil por adelantado?
design thinking y agile (6)
Big Upfront Estimation es solo Big Upfront Design con $$$ adjunto
No, eso iría completamente en contra de todo el paradigma de ágil.
Agile puede ser sobre Costos fijos
Lo que puede hacer es establecer una fecha y luego trabajarla en iteraciones / sprints y dejar que los propietarios del producto decidan qué es importante hacer para esa fecha. De esta forma, un Sprint de 1 o 2 semanas es un Costo Fijo, de la misma manera que lo sería en un Big Up Front Design , es solo un costo fijo más pequeño.
Toda la premisa detrás de las metodologías ágiles es eliminar los plazos arbitrarios y la marcha de la muerte en que se convierten porque el cambio no se contabiliza en los contratos y las fechas límite. SCRUM funciona, es un gran punto de partida para construir una metodología, leer sobre ella y hacer lo que dice, al menos como punto de partida.
Sprints cortos con comentarios y aprobaciones de los clientes
Brinde un punto de partida para refinar sus estimaciones futuras y ayúdelo a obtener confianza del propietario y del cliente del producto muy rápidamente, porque ellos ven sus inquietudes más importantes entregadas en un corto período de tiempo.
Cuando trabajo en proyectos de desarrollo de software de precio fijo, frecuentemente me encuentro teniendo que estimar el número total de horas que un proyecto tomará una vez que se establezca el precio, pero antes de que se inicie el trabajo (o MUY temprano en el desarrollo). Desafortunadamente, este tipo de proyectos se desarrollan mejor utilizando un método iterativo / ágil, lo que significa que no hacemos (y realmente no podemos) un diseño completo por adelantado.
En un escenario típico, tendríamos un contrato que tiene características X y dólares en Y. Después de la contratación, el departamento de ingeniería necesitaría estimar el número de horas requeridas para completar las características de X. Hay varias razones posibles para necesitar esta información por adelantado, que incluye:
• Los dólares en Y se traducen en Z horas disponibles, por lo que debemos asegurarnos de que el tiempo (X) <= Z, quizás reduciendo el alcance de X.
• La fecha de entrega está establecida, por lo que debemos asignar los recursos adecuados para cumplir con esa fecha.
Kelly Waters tiene una opinión interesante sobre la estimación de ágil aquí: http://www.agile-software-development.com/2009/04/agile-estimating.html Lamentablemente, estas son estimaciones de dificultad, utilizando un sistema de puntos, y no traducir a horas
Me parece que debemos poder hacer una de estas dos cosas:
• Obtenga contratos que tengan una gran cantidad de flexibilidad en ellos para adaptarse a un proceso de desarrollo ágil.
• Averigüe cómo proporcionar estimaciones anticipadas razonablemente precisas para las características que aún no se han diseñado.
La primera opción, por supuesto, no es una opción en la mayoría de los casos. ¿Alguien tiene algún consejo u orientación sobre cómo generar estimaciones iniciales en un escenario de desarrollo ágil?
Alternativamente, ¿alguien ve otra opción para resolver nuestro problema a través de algún otro cambio de proceso?
"no, eso iría completamente en contra de todo el paradigma de ágil": creo que esto es bastante incorrecto. Agile está basado en el sentido común y nadie invertiría en el proyecto si no tuviera idea de cuánto costaría aproximadamente: entienden que tendrán que reducir el alcance para cumplir con los plazos o aumentar el presupuesto y / o extender los plazos para entregar todo el alcance. En los proyectos de mi compañía, estimamos proyectos comparando su tamaño y también estamos calculando épicas utilizando la planificación del póker. Usando el cono de la incertidumbre, y sin cambiar la calidad, estamos a un máximo de 50% de descuento en nuestras estimaciones antes de comenzar el primer sprint en comparación con la realidad. Y mejoraremos a medida que desarrollemos nuestra experiencia ágil (en precisión y tiempo para obtener las primeras estimaciones). No puede esperar que el marketing patrocine proyectos para 3 sprints (hasta 3 meses) para tener una idea de cuánto costaría.
Creo que cada cliente quiere tener al menos una estimación de cuánto le costará la implementación de una determinada cantidad de funciones. No estoy de acuerdo con las personas que dicen que si estás usando ágilmente no puedes hacer esto. Agile se puede adaptar al mundo real donde los clientes quieren saber cuánto dinero van a gastar en un proyecto, o al menos tener una idea aproximada.
Por lo tanto, hay al menos dos formas documentadas de hacerlo y ambas se describen en el libro "Estimación y planificación ágil" de Mike Cohn que recomiendo encarecidamente a todos que lean.
Antes incluso de que su proyecto comience, haga el ejercicio de desglosar sus historias en tareas y calcule cada hogar en horas. Haz el presupuesto matemático con esas estimaciones. Tenga en cuenta que estas estimaciones solo se utilizarán para alcanzar el tiempo / presupuesto estimado. Cuando se inicia el proyecto, el equipo debe ser responsable de estimar y crear las tareas de forma normal.
Usa datos históricos. Si el mismo equipo ha trabajado anteriormente en un proyecto con tecnología similar, entonces puede usar la velocidad del equipo anterior para estimar el costo del proyecto.
Nuevamente, para más detalles sobre cómo hacer esto, lea el libro al que se hace referencia.
El precio fijo en Agile le brinda una cantidad de iteraciones que puede ejecutar para un tamaño de equipo determinado. El objetivo de Agile es maximizar el valor que puede obtener durante estas iteraciones. Agile tiene que ver con la administración del alcance.
Entonces, en realidad no deberías hacer estimaciones iniciales. Esto significa un alcance fijo que es justo lo contrario de Agile o anti-Agile, si lo prefiere.
Agile no funciona así, necesita un nuevo tipo de contrato, como se señala en otra respuesta. Ver por ejemplo 10 Contratos Ágiles y / o google .
En lugar de apuntar a un contrato para el proyecto "completo", debe crear un contrato que se ejecute durante uno o dos meses.
Establezca objetivos muy bajos, tal vez solo dos o tres características.
Explique al cliente que esta es una fase de descubrimiento del proyecto. Sin esta fase, no puede darles una estimación de todo el alcance. A nadie le interesaría darles una estimación inexacta.
El cliente se beneficia de las siguientes maneras:
- Menor costo inicial (solo una fracción del precio total). Si las cosas van mal, existe un límite en su exposición financiera (sensato dado que la mayoría de los proyectos de software fallan).
- Tenga un software en funcionamiento dentro de un par de meses que pueda resolver de inmediato algunos de sus problemas
- Tener un software que funcione para provocar pensamientos / conversaciones sobre los requisitos
- El cliente descubrirá más acerca de lo que realmente quiere
- El cliente puede ver qué tan bien trabaja. Si no les gusta, pueden buscar en otro lado.
Si estima los elementos atrasados en los puntos de la historia (que se analizan en el artículo de Kelly Waters al que se vincula), entonces la pregunta es cuántos puntos de historia espera que su equipo ofrezca en un sprint. Si su equipo ha estado trabajando juntos anteriormente, entonces debería poder adivinar esto (quizás con límites superiores e inferiores para indicar un rango de confianza).
Si el equipo no ha trabajado antes, entonces puede tomar algunas historias bien entendidas y dividirlas en tareas detalladas. Esto le dará un número de horas-hombre y puede comparar esto con las estimaciones de puntos de su historia para tratar de predecir su velocidad. Nuevamente, un rango de confianza de valores superiores e inferiores es probablemente apropiado.
Supongamos que sus historias de usuarios suman 150 puntos, y usted predice que su equipo puede entregar 15-20 puntos por mes, luego el trabajo demorará entre 7.5 y 10 meses (a través de una división simple).
La ventaja de este enfoque es que puede medir la velocidad real del equipo y compararla con el plan. Reconsiderar tus cronogramas también debería ser bastante fácil, por ejemplo, si descubres después de un par de sprints que la velocidad del equipo es de solo 10 puntos por mes, entonces puedes predecir fácilmente cuáles serán tus cronogramas revisados.
Tenga en cuenta que la velocidad del equipo fluctúa por varias razones. Por lo general, es más bajo al inicio de un proyecto cuando el equipo aún se está formando. Además, es probable que el equipo se concentre en las inquietudes de infraestructura en este punto en lugar de ofrecer funcionalidad.