Im el contexto de la programación de pares ... ¿cómo se estima? Una historia de 5 puntos ... dividida en 3 tareas ... cada tarea está llena de 2 miembros. ¿Significa que significa que es finalizable en la mitad del tiempo?estimación Agile/XP
Calcula el uso de puntos. El número de puntos alcanzables por un par se llama velocidad. Verifique esto: http://en.wikipedia.org/Planning_poker
Las metodologías más ágiles sugieren que debe estimar en puntos. Sin embargo, hay muchos equipos exitosos, incluidos varios equipos Kanban avanzados y altamente productivos, que calculan en horas. Los puntos vienen con sus propios juegos, incentivos perversos y problemas. YMMV. De todos modos ...
He escuchado cifras de un 25% más de horas de desarrollo para un par que completa una tarea. Por lo tanto, la tarea estaría terminada en el 62.5% del tiempo, utilizando dos desarrolladores en lugar de uno. Sin embargo, la calidad y el intercambio de conocimientos a menudo también aumentan. Como los errores = la repetición y la repetición del trabajo tardan más que hacerlo de la manera correcta la primera vez, la programación de pares generalmente se paga sola. Esto difiere para diferentes tareas y niveles de habilidad, por ejemplo: correcciones de errores simples, programadores principiantes, etc.
En mi experiencia 2/3 de las veces es una figura de estadio bastante buena. Es más de 1/2 pero menos de lo que sería con solo 1 persona.
Sallyann Freudenberg es un buen nombre para buscar en la investigación de programación de pares. También podría retirar las referencias en la página Wikipedia: http://en.wikipedia.org/wiki/Pair_programming
La figura está mayormente confirmada por los datos de este informe por Alistair Cockburn y Laurie Williams: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
Par calcula cuánto tiempo se va a tomarlos. Cualquier estimación se basa en la experiencia: cuanto más tiempo tenga el equipo de experiencia con el proyecto, con tecnología y trabajando juntos en pares, mejores serán las estimaciones. Cualquier porcentaje arbitrario, como agregar un 25% para los pares, etc., son útiles solo al principio (con un nuevo proyecto y un nuevo equipo con nueva tecnología) en los que no tiene nada más para basar la estimación. Tan pronto como la experiencia comience a desarrollarse, las estimaciones mejorarán.
recordar, sin embargo, de que son sólo esta - estimaciones, esa es nuestra mejor conjetura del futuro con la ayuda derivada de la experiencia y el conocimiento de nuestro entendimiento de la presente. Es como el pronóstico del tiempo: cuantos más datos tengamos, más pronosticadores de experiencia tendrán, mejor será, pero es solo una predicción, no una realidad.
Por eso los puntos son tan geniales, porque te ayudan a estimar un parámetro: las tareas a realizar son "grandes".
Siempre enfatizo tamaño de la historia sobre la estimación. Si puede minimizar la variación de tamaño entre las historias, entonces las estimaciones se vuelven mucho menos interesantes. Es decir, las actividades de estimación pierden su valor cuando la diferencia de tamaño entre dos historias es pequeña, lo que ayuda a los equipos rápidos a recuperar el costo de la estimación y a llevarlo a algo productivo (como la creación de productos).
Teniendo esto en cuenta, sugeriría que proactivamente reduzca la acumulación de trabajo y dividir historias de cinco puntos en otras más pequeñas (aún rebanadas verticales delgadas) siempre que sea posible. Hasta que su equipo tenga experiencia, le sugiero que continúe contando con partes de estimación, pero solicite una estimación predeterminada de 1 punto para cada tarjeta, con una rápida consulta de consenso o una discusión sobre por qué justifica un aumento a 2 o 3.Para cualquier cosa que sea claramente más grande que un 3, sugeriría desafiar que uno de los dos problemas está presente: el valor de referencia de "1" es demasiado pequeño o la historia debe dividirse (ya sea más específica o rastreada como una épica).
A medida que el equipo establece una velocidad decente, la actividad puede cambiar su forma de pensar de la estimación a la mera investigación de historias. Es decir, la pregunta durante la planificación de "¿cuán grande es esta historia?" se convierte en "¿esta historia es anormal?" La última pregunta toma mucho menos tiempo para responder.
Esto es solo una expansión del comentario de Amber (* En general, experiencia *) pero muestra cómo llegar allí. +1 – APC
1) Una manera simple y concreta de pensar en estimar unidades es el número de registros que se necesitarían para completar la historia.
Si está haciendo TDD, integración y refactorización continuas, estará trabajando en pequeñas cantidades de trabajo, manteniendo la construcción verde y controlando regularmente, de modo que bajo esas condiciones los registros individuales pueden ser una unidad significativa de estimación .
2) O bien, piense en bloques de tiempo de vinculación ininterrumpido en un día, p. después de la pausa para tomar café, después del café para almorzar, después del almuerzo hasta el descanso de media tarde, a media tarde para ir a casa, digamos 4 períodos al día ... así que decir 4 unidades es un solo día. Eso le da un límite en lo que podría esperar hacer en una interacción ...
Personalmente voy por el número de check-in, porque puedo bosquejar más o menos las tareas involucradas y tener una idea del check-in números.
La gran cosa sobre el número de registros de entrada es que no importa si usted está emparejamiento o no - sólo realiza un seguimiento de lo que puede hacer.
En general ... experiencia. – Amber