Lidiar con expectativas de rendimiento poco realistas [cerrado]

¿Qué hechos y fuentes puedo usar para convencer a un gerente con el que estoy trabajando actualmente de que reescribir un proyecto de ~20 000 líneas de código en un mes es un plan completamente irreal y que escribir ~5000 líneas de código funcional en 3 semanas es realmente un buen resultado?

¿Qué tal comenzar con cómo llegaste a tus propias estimaciones? ¿Dónde están sus datos de apoyo para eso?
@CodeGnome, solo mi experiencia subjetiva. Es por eso que estoy pidiendo hechos y fuentes.
Ninguno de ustedes tiene datos de respaldo, ambas cifras son esencialmente inventadas. Pregunte si puede ver cuánto puede entregar en una semana y luego extrapolar.
@Nathan Cooper, entonces dame esos datos. No me importa si se demuestra que estoy equivocado, con hechos.
@XenoMind, el punto era crear sus propios datos, porque los datos de cualquier otro equipo no son su equipo y no reflejarán la realidad para usted .
@XenoMind y esa realidad es que no hay dos equipos que hagan el mismo trabajo en la misma cantidad de tiempo.
@RubberDuck, y no hay dos autos que puedan cubrir la misma distancia con 1 litro de gasolina...

Respuestas (3)

Una respuesta anterior que escribí aquí en Project Management Stack Exchange proporciona valores altos/bajos/nominales para las líneas de código fuente escritas según el tipo de proyecto por mes de personal. Los datos más específicos siempre son mejores: sería más relevante usar datos históricos de sus experiencias pasadas o proyectos anteriores en su empresa de tamaño y alcance similares. Como puede ver en esos datos, incluso 5000 SLOC/mes-personal está muy por fuera de los rangos nominales para cada tipo y tamaño de aplicación.

Hay más para estimar/evaluar un proyecto que solo las líneas de código que necesitan ser (o fueron) creadas/modificadas. Tamaño y naturaleza de la modificación/adición, complejidad del código, reutilización del código, lenguaje de programación, verbosidad del código (puede hacer que una línea haga exactamente lo mismo que cinco líneas, y esto puede ser bueno o malo dependiendo de situación y opinión) y uso de paquetes externos, por nombrar algunos. Y muchos de estos cambiarán, no solo de equipo a equipo, sino de proyecto a proyecto .

Las únicas personas que están realmente equipadas para dar algún tipo de estimación razonable y realista, dados todos estos factores, son las personas que realmente hacen el trabajo.Si un gerente trata de estimar qué es "realista", su estimación se verá afectada por otros factores, como los plazos y otras limitaciones, que falsearían dichas estimaciones, incluso si el gerente tuviera la capacidad de estimar adecuadamente el trabajo.

Un sistema más efectivo es que los desarrolladores hagan la estimación, el gerente confíe en la capacidad del desarrollador para hacer estimaciones (si el gerente no lo hace, ese es un problema aparte que debe abordarse), y luego el gerente debe tomar una decisión sobre si el valor agregado por el trabajo vale la pena el esfuerzo estimado invertido para lograrlo.

Dado que está hablando de líneas de código, puede consultar los gráficos de proyectos populares de github para ver cuántas líneas se han comprometido en períodos de tiempo similares.

https://github.com/Microsoft/dotnet/graphs/contributors

1. El desarrollo de código abierto sucede a borbotones. 2. Hizo referencia a Microsoft, ¿ Microsoft como punto de referencia? Estoy dispuesto a apostar que muy pocas empresas pueden igualar la tasa de abandono de MS.
1. puede verificar los colaboradores individuales que trabajan en el proyecto continuamente durante un período de tiempo 2. nuevamente, verifique los contribuyentes individuales para cancelar el efecto de las empresas que tienen más desarrolladores
Lidiar con expectativas de rendimiento poco realistas [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v