se supone que esa es una de las cosas que quieren conseguir las metodologias agiles...
segun estas metodologias, los desarrolladores somos bastante buenos en estimar "dias perfectos", es decir, 8 horas de trabajo, concentrados, sin distracciones ni problemas importantes (y por supuesto nada de reuniones chorras y demas)
a esa unidad le quitan el significado (lo de "dias") y lo dejan solo en un numero, que se asigna a las diferentes tareas ("historias")
otra de las caracteristicas de estas metodologias son las iteraciones, en general cada mes o algo asi, al llegar el final de la iteracion se mira cuantas unidades se han completado (y se toman en consideracion tareas TOTALMENTE completas, es decir, programadas, probadas y aprobadas por el cliente), se suman todas las unidades de esas tareas y ese es el numero de unidades que se asignan para la siguiente iteracion.
las tareas incompletas no se parten, es decir, si una tarea se estimo en 3 unidades y esta terminada al 50%, no se queda en 1.5 unidades, sino que sigue valiendo 3.
con esto lo que se consigue, mes a mes (iteracion a iteracion, mejor dicho) es precisamente eso, llegar a una media de unidades de trabajo realizadas por iteracion para un grupo de trabajo especifico y, con eso, hacer estimaciones mas realistas.
desde mi experiencia (me he tirado unos cuantos anios trabajando con estas metodologias), tiene dos problemas, el primero que el resultado solo se ve en proyectos largos (en mi caso no fue un problema, era software bancario en que cada nueva version, cada anio aprox, eran tanto nuevas funcionalidades como correcciones) y que el grupo tiene que permanecer basicamente igual durante el tiempo de proyecto (las mismas personas), cosa que en espania, con la vision de muchas empresas de "los tecnicos son prescindibles", es imposible
en mi caso especifico, ademas, con cada entrega importante se hacian varias reuniones de "lecciones aprendidas" donde se hablaba precisamente de eso: imprevistos, cosas que no habian salido como se planeaba y como evitarlas o reducir su impacto, procesos que se podian mejorar, etc, etc.
--
Dale fuego a un hombre y estara caliente un dia, prendele fuego y estara caliente el resto de su vida.
Re:Siempre falta algo
(Puntos:2)( http://barrapunto.com/ | Última bitácora: Lunes, 24 Febrero de 2014, 10:03h )
segun estas metodologias, los desarrolladores somos bastante buenos en estimar "dias perfectos", es decir, 8 horas de trabajo, concentrados, sin distracciones ni problemas importantes (y por supuesto nada de reuniones chorras y demas)
a esa unidad le quitan el significado (lo de "dias") y lo dejan solo en un numero, que se asigna a las diferentes tareas ("historias")
otra de las caracteristicas de estas metodologias son las iteraciones, en general cada mes o algo asi, al llegar el final de la iteracion se mira cuantas unidades se han completado (y se toman en consideracion tareas TOTALMENTE completas, es decir, programadas, probadas y aprobadas por el cliente), se suman todas las unidades de esas tareas y ese es el numero de unidades que se asignan para la siguiente iteracion.
las tareas incompletas no se parten, es decir, si una tarea se estimo en 3 unidades y esta terminada al 50%, no se queda en 1.5 unidades, sino que sigue valiendo 3.
con esto lo que se consigue, mes a mes (iteracion a iteracion, mejor dicho) es precisamente eso, llegar a una media de unidades de trabajo realizadas por iteracion para un grupo de trabajo especifico y, con eso, hacer estimaciones mas realistas.
desde mi experiencia (me he tirado unos cuantos anios trabajando con estas metodologias), tiene dos problemas, el primero que el resultado solo se ve en proyectos largos (en mi caso no fue un problema, era software bancario en que cada nueva version, cada anio aprox, eran tanto nuevas funcionalidades como correcciones) y que el grupo tiene que permanecer basicamente igual durante el tiempo de proyecto (las mismas personas), cosa que en espania, con la vision de muchas empresas de "los tecnicos son prescindibles", es imposible
en mi caso especifico, ademas, con cada entrega importante se hacian varias reuniones de "lecciones aprendidas" donde se hablaba precisamente de eso: imprevistos, cosas que no habian salido como se planeaba y como evitarlas o reducir su impacto, procesos que se podian mejorar, etc, etc.
Dale fuego a un hombre y estara caliente un dia, prendele fuego y estara caliente el resto de su vida.