Comencé a trabajar en mi trabajo actual como desarrollador de Android justo después de graduarme (hace 1,5 meses), mi primera tarea fue crear una aplicación de quejas que incluye las siguientes características:
Completé la tarea en alrededor de 3 a 4 semanas y pude entregar la versión beta de la aplicación. Creo que parte del código es "débil" principalmente debido a la presión sobre los plazos, pero nada que cause problemas graves de rendimiento.
Ahora, me piden que comience un nuevo proyecto y después de que me pidan una estimación (que proporcioné después de leer artículos sobre la estimación del tiempo de desarrollo), pero todavía no tengo una idea clara de cómo estimar el tiempo necesario para el desarrollo. , ahora me enfrento a expectativas y plazos poco realistas.
¿Cómo puedo dar estimaciones más precisas cuando me dan los requisitos de una aplicación (específicamente Android) para poder explicar por qué se necesita ese tiempo y cómo puedo lidiar con plazos y expectativas poco realistas establecidos por el gerente o el líder del equipo?
La respuesta corta es nunca dar una estimación de tiempo fijo, siempre dar un rango. Y luego documente esto claramente en correos electrónicos o en el plan del proyecto (escrito).
Respuesta larga: Cincuenta y tantos años de desarrollo de software han demostrado de manera bastante concluyente que estimar un proyecto completo, antes de que se realice cualquier trabajo, tiene una tasa de éxito de alrededor del 20 % o menos (según las encuestas de la industria, el 80 % de los proyectos de TI fallan).
Desafortunadamente, parece que estás trabajando para una empresa que aún no ha descubierto esta realidad. Cuando una empresa no está dispuesta a enfrentarse a la realidad, a menudo no hay nada que puedas hacer. Es una cuestión de percepción y tratar de cambiar la percepción es como tratar de cambiar las mareas.
Lo que recomiendo es documentar claramente sus estimaciones y advertencias actuales. Deje en claro que su estimación es una estimación basada en los datos disponibles y sin continuar con el trabajo, no puede obtener más detalles. En la gestión de proyectos tradicional, esto se denomina "Estimación del orden de magnitud". Donde al comienzo del proyecto se consideró que una estimación era aproximadamente un 20% precisa. A medida que avanzaba en el proyecto, la estimación se volvería más y más precisa. Piense en ello como un embudo que se vuelve más estrecho cuanto más se acerca al lanzamiento. Entonces, para un proyecto de dos años, la fecha de lanzamiento inicial es un rango de medio año (2H 2018). Seis meses después del proyecto, la estimación se mueve a un rango de un cuarto (3T 2018). Un año después del proyecto obtienes un mes (octubre de 2018) y 18 meses después del proyecto obtienes una semana (tercera semana de octubre de 2018).
Debe documentar lo que sabe, en qué se basa su estimación y establecer claramente que es una estimación e intentar asignarle algún tipo de variación. Parte de esto es no dar una estimación fija, sino dar una estimación de rango. Usted dice: "Creo que esto podría demorar entre 4 y 8 semanas en completarse. En dos semanas, después de que comience la codificación, probablemente pueda reducirlo a un rango de una semana".
Esto lo lleva al concepto de estimación en ágil. Empiezas con muchas incógnitas y descubres lo que puedes hacer en función de lo que has hecho.
Fecha alternativa fija, flujo de características Algo a lo que Scrum se adapta en gran medida es establecer una fecha fija para el lanzamiento y mantener el alcance en flujo. Entonces, en lugar de decir "Terminaré en 4 a 8 semanas", dice "Me comprometo a realizar el envío el 17 de marzo. En este momento puedo comprometerme con 4 de las doce características de la lista. En dos semanas, Podré refinar el alcance y hacerle saber el alcance final con el que me puedo comprometer".
Si bien la respuesta de Joel es buena, la realidad a la que nos enfrentamos en este negocio es que tenemos que hacer compromisos, tenemos que fijar el precio de nuestra propuesta, no un rango de precios posibles.
Las estimaciones siempre deben ser un rango; sin embargo, también debe proporcionar un objetivo, algo dentro de ese rango. Y además de esto, el negocio puede dictar otro objetivo... un objetivo que representa el precio para ganar, que es muy probable que sea mucho más bajo que lo que usted quiere como objetivo. En algunos casos, incluso fuera de su rango.
La mejor manera de ayudar a mantener este objetivo en un rango realista es con la historia. Debe capturar los resultados de su proyecto y almacenarlos para que pueda hacer referencia a lo que sucedió en el pasado e incorporarlo a su pensamiento. Utilice la información de la industria si puede obtenerla. Lo segundo mejor es incluir tantos expertos reales... reales... para ayudar a estimar el trabajo. Y finalmente, cree una tonelada de reservas de contingencia sobre muchos de sus proyectos para que pueda financiar aquellos objetivos que se establecieron demasiado bajos.
Hussain Al Derry