¿Qué puedo hacer para mejorar la estimación del tiempo que tomarán los proyectos? [duplicar]

Debe pedir algo de tiempo antes de devolver una respuesta a la administración. Regresa y estudia la tarea:

• Escriba un enfoque general
• Tal vez haga una exploración del código durante unas pocas horas
• Desglose la tarea en pasos en un Excel (sugeriría Microsoft Project, pero eso puede ser una exageración)
• En contra de cada tarea, intente asignar su mejor estimación de estimación
• Agréguelos, agregue un búfer de 20-30 por ciento y entréguelo a la Administración

Con el tiempo, mejorarás.

Actualización:

Bueno, no tiene que ser 2 días. Básicamente no das una respuesta de inmediato. No hay forma de que puedas saber (a excepción de las tareas más triviales) cuánto esfuerzo te costará de inmediato. Si es una tarea grande (quizás de 3 a 4 semanas) le tomará un par de días estimarla, pero si es una tarea de 3 a 4 días, solo le tomará de 3 a 4 horas romperla. subir y estimar.

Esta pregunta tiene una respuesta larga y una respuesta un poco menos larga (pero no una respuesta corta).

La respuesta larga tiene 255 páginas (y algunos apéndices) y se llama " Estimación del software: Desmitificando el Arte Negro "por Steve McConnell. Es muy recomendable.

La respuesta un poco menos larga es en realidad solo un conjunto de heurísticas / consejos:

1. Divida la tarea en elementos pequeños, preferiblemente 1-3 días cada uno
2. Intente encontrar una tarea similar, en el mismo dominio o que involucre tecnologías similares. Casi nunca es el caso de que estes estimando una tarea que has hecho antes (porque ya está hecho ...). Ejemplo: si su tarea es "mejorar SharePoint en modo X", tal vez haya realizado una tarea que involucró la integración con SharePoint y / u otro producto de Office y / o otro "sistema de administración de contenido"
3. Indique su estimación como un rango en lugar de una estimación de un solo punto
4. Comprenda sus márgenes: si está estimando algo completamente nuevo, es posible que deba tomar un factor del 100% o incluso del 400% (es decir, si su estimación es de 2 días y el factor es del 400%, podría tomar entre .5 a día a 8 días). A mayor incertidumbre, mayor es el factor.
5. Comprenda que a medida que avanza en la tarea, debe volver a revisar y refinar su estimación
6. ¡Comunícate, comunícate, comunícate! Asegúrese de que la administración esté al tanto de cuán confiable es (o no lo es) una estimación específica.
7. Proporcione estimaciones en escalas y números que reflejen la precisión (por ejemplo, estimar en horas implica más precisión que dar la misma estimación en días; estimar que tomaría 3.75 días hace que las personas asuman automáticamente que su estimación es más precisa que si una estimación de 4 se habrían dado)
8. Reconozca el "Cono de incertidumbre" (consulte más detalles a continuación)
9. Al dar una estimación, digamos "3 días", piense en la siguiente pregunta: "¿Puede tomar menos de 3 días?". Si la respuesta es No, entonces esta es una estimación optimista, ya que tomaría 3 días si y solo si nada sale mal ...

Varias notas más:

• Las inexactitudes pueden ir en ambos sentidos, ya sea hacia arriba o hacia abajo (aunque los proyectos de software son conocidos por subestimaciones en lugar de sobreestimaciones)
• Tenga en cuenta que los efectos de la subestimación suelen ser más perjudiciales para el proyecto que la sobreestimación (esto también se discute en la primera parte del libro mencionado anteriormente).

El cono de la incertidumbre:

La idea de "el cono" es comenzar un proyecto con estimaciones de alto nivel / baja precisión y su confianza y precisión aumentan a medida que avanza en el proyecto. Por ejemplo:

• En el momento de la recopilación de requisitos, sus estimaciones son mucho menos precisas que una vez que el diseño de alto nivel está listo
• Lo que es mucho menos preciso que después de que se realizó el diseño detallado
• Lo que es menos preciso que la mitad de la codificación.

Este es un hecho de la vida, y en lugar de luchar contra él, esta comprensión debe estar incorporada en su plan. Esto es más importante cuando se estima un proyecto completo o una tarea grande (es decir, más de 2 semanas), ya que dividirlo en elementos de grano fino como sugerí en el artículo 1 no es realmente factible (o rentable).

Pruebe programación basada en evidencia .

  

Durante el último año, más o menos, en Fog Creek hemos estado desarrollando un sistema que es tan fácil que incluso nuestros desarrolladores más gruñones están dispuestos a aceptar. Y por lo que podemos decir, produce horarios extremadamente confiables. Se llama programación basada en evidencia, o EBS. Recopila evidencias , principalmente de datos históricos de la hoja de tiempo, que retroalimenta en sus programaciones. Lo que obtiene no es solo una fecha de envío: se obtiene una curva de distribución de confianza, que muestra la probabilidad de que se enviará en una fecha determinada. Se parece a esto:

     

     

Cuanto más pronunciada sea la curva, más confiado está de que la fecha de envío es real.

     

Así es como lo haces ...

Puedes intentar leer estos dos libros, ambos son geniales (los leí más de una vez)

• Estimación de software
• Desarrollo rápido

Y también tratan el aspecto humano en la construcción de software (lo que parece puede ser útil para usted)

haga una estimación rápida, vuelva a realizar la estimación regularmente y, lo que es más importante, mantenga la administración actualizada.

Se trata de gestionar las expectativas, así que asegúrese de que entiendan las limitaciones de su estimación, esto es clave, especialmente para los gerentes de proyectos no técnicos.

A pesar de su advertencia de que ahora está obsoleto, el artículo de Joel sobre Programas de software sin dolor es extremadamente útil si está Nuevo en el concepto.

  

Entonces, tienes que hacer un horario. Esto es algo que casi ningún programador quiere hacer. En mi experiencia, la gran mayoría solo trata de salirse con la suya sin hacer un horario en absoluto. De los pocos que hacen un cronograma, la mayoría solo lo hacen porque su jefe los obligó a hacerlo, a medias, y nadie realmente cree el cronograma, excepto la alta gerencia, que a su vez cree que "no hay ningún proyecto de software". siempre a tiempo "y en la existencia de ovnis ...

     

Aquí hay una forma sencilla e indolora de hacer calendarios que son realmente correctos ...

Esto puede sonar glib, pero en realidad ayuda. A lo largo de los años, he tenido un par de clientes internos que irrumpieron en mi oficina con una nueva idea. "¿Cuánto tiempo tomaría escribir una nueva característica para nuestro gran programa que hace [una descripción extremadamente vaga]?" Descubrí que pedir más detalles a menudo era inútil. "Solo dame una estimación aproximada", él o ella exigiría.

Así que buscaría en el cajón de mi escritorio y sacaría un dado de seis caras. Lo sacudía en mi mano y lo arrojaba sobre el escritorio. "Cuatro semanas", diría yo.

"Vamos, sea serio", se quejaría el cliente.

En ese punto, explicaría que sin al menos una idea coherente de cómo funcionaría esta nueva característica, no tenía absolutamente ninguna idea, y tirar el dado era tan bueno como cualquier otro método de estimación. En última instancia, todos tienen la pista. La mayoría de las ideas se fueron a morir. Con el resto, mi cliente volvería con algo con lo que podría trabajar.

En pocas palabras, lo que estaba haciendo era ilustrar lo absurdo de tratar de llegar a una estimación prácticamente sin información. Una imagen vale más que mil palabras, como dicen.

Hay bastante buen material escrito sobre el tema de la estimación. Los libros de Steve McConnell (mencionados anteriormente aquí) son excelentes, y también recomendaría Estimación y planificación ágiles de Mike Cohn.

Estudié este libro antes de planear y estimar un proyecto grande con mi equipo hace 18 meses, y fue tremendamente útil. Sin embargo, los enfoques y técnicas del libro no son solo para grandes proyectos, sino que son útiles para cualquier tamaño de tarea.

Estimar es difícil. Trabajar con estimaciones NO es un sueño imposible. Así que es una especie de maldad necesaria.

• Comience por dejar en claro que las estimaciones iniciales están muy lejos, por lo que si llega a una estimación de X Unit, dé un rango de 0.6X a 1.6X.
• Luego está el truco de duplicar la estimación (sin embargo, decir que un año ~ 2 tomará 4 años podría ser un problema)
• (Hay uno más que implica escalar la magnitud y golpear a la siguiente unidad superior. Necesito consultar mi libro para esta).

Luego viene la parte de cómo alcanzo esa estimación para poder duplicar / multiplicar. No hay respuesta fácil.

• Las tendencias históricas tienen sentido si haces el mismo tipo de proyecto con el mismo nivel de habilidades de equipo.
• El siguiente es el 'Déjame dirigir la nave para 2-3 iteraciones' y luego volveré con una mejor estimación.
• Finalmente viene el "Dime cuánto costará ... Hasta que nadie trabaje en esto". En este caso, no tienes un ángel de la guarda. Siéntese y divídalo y luego aplique conjeturas poco a poco hasta que tenga una estimación acumulativa. Luego haz el doble n-golpe.

En mis 5 años de vivir en las trincheras ... Lo único que he visto es "adivinar por el asiento de tu pantalón" ... Sin FP ... Sin proceso ... ayuda en las restricciones del mundo real. Aún así, las cosas pueden mejorar. Por lo tanto, sugiero obtener el libro de Mike Cohn 'Estimación y planificación ágiles'; ese es el libro que más se acerca a nosotros a los programadores pecaminosos y la realidad. El resto son predicadores en sus caballos altos ... ¿Caper Jones, en qué planeta está tu morada?

Buena pregunta ... sigo preguntando esto cuando comienza cada proyecto y luego una vez por semana hago el GRIND. Todavía no hay respuesta de las voces en mi cabeza.

Además, dado que parece que no trabajas en una compañía de software, ten en cuenta que en ningún momento el 100% del tiempo del desarrollador se dedica a la codificación. Asegúrese de poner tiempo para la planificación, documentación, investigación, pruebas. Estos suelen ser los pasos que a la administración le gustaría eliminar del proceso, pero no estarán contentos con los resultados si lo hacen. Si obtiene una reacción negativa, debe recordarles que A) Terminará dedicando tiempo a esos elementos de todas formas, ya sea que estén presupuestados, no B) Terminará dedicando más tiempo a mantener y corregir errores sin la planificación adecuada. Si no ha leído "El mes del hombre mítico" por Frederick Brooks, lo recomendaría encarecidamente. Tiene muchos buenos conceptos y probablemente se relacionará más que un poco con algunos de los escenarios. Algunos de los artículos están un poco anticuados, pero hay mucha información buena y deberías poder obtener uno a bajo precio.

No estimar. En su lugar, utilice una técnica de gestión de proyectos que no dependa de la estimación. Scrum, por ejemplo, hace hincapié en hacer trabajo en lugar de hablar de hacer trabajo (es decir, estimaciones).

Si pasas un día o dos o 5 o lo que sea una estimación, ¿no sería mejor que hubieras codificado, diseñado o probado en esos días, en lugar de pasar el tiempo "estimando"?

Recuerda la Ley de Hofstadter:

  

Siempre lleva más tiempo que tú   esperar, incluso cuando se toma en   Cuenta la ley de Hofstadter.

Es divertido y todo, pero en realidad generalmente hago estimaciones razonables, luego pongo un poco (al menos) 10% encima y luego lo redondeo todo. En ocasiones no se me permitió hacerlo, lamento decir que terminé fallando miserablemente en mi agenda.

Doble tu estimación inicial.

Sin embargo, en serio, intente dividir la tarea en bits más pequeños y estimables. Y luego doblarlo.

Sobre todo es solo una cuestión de práctica.

Aquí hay algunas cosas importantes que debe recordar cuando realice una estimación:

1. Usa algún método para hacer un seguimiento de cuánto tiempo pensaste que iba a durar en comparación con el tiempo que realmente tomó.
2. Asegúrese de dividir sus tareas en los pasos más pequeños posibles antes de llegar a su estimación.
3. No olvide incluir el tiempo de prueba / corrección de errores en su estimación.
4. No permitas que las personas te obliguen a horarios artificiales.

El artículo de Joel que menciones es una gran expansión de estas ideas.

No creo que haya una receta paso a paso universal.

Cada proyecto es diferente. Si conoce su código y conoce sus procesos, entonces sabe lo suficiente como para hacer una estimación seria. Solo piense en todos los pasos, todos los componentes y sea realista. No seas demasiado optimista. Construir en contingencias para todos los lugares donde existe un riesgo potencial. Es mucho mejor ser preciso que ser rápido.

Al igual que con cualquier otra cosa: mejoras en la estimación al hacerlo mucho. Cuanto más te obligues (o te obligues) a hacer estimaciones, mejor podrás hacerlo.

Para mejorar las estimaciones, debe comparar sus estimaciones anteriores con el tiempo real que tomó y luego buscar patrones en la diferencia.

Como otros lo han sugerido, el primer paso es dividir el proyecto tan lejos como puedas para que estés trabajando con tareas discretas manejables. Registre sus estimaciones para cada tarea y luego, al hacer el trabajo, registre el tiempo real que toma (incluido el tiempo para todos los bits que olvidó al realizar la estimación; a menudo son los principales problemas).

Al final del proyecto, compare sus dos conjuntos de cifras para ver dónde se equivocó (porque, incluso después de años de experiencia, todos nos equivocamos en algún lugar). A continuación, puede buscar mejorar de dos maneras:

• Trate de identificar dónde está subestimando u olvidando las tareas constantemente y luego continúe con su aprendizaje a su próxima estimación, es decir, intente mejorar la precisión con la que estima cada tarea. Cuanto más trabaje en proyectos similares cada vez, más fácil será hacerlo.

• También busque un patrón general en la diferencia entre la estimación total y el tiempo real tomado. Si constantemente toma, digamos, un 50% más de lo que estimó para cada proyecto, tiene una guía para aumentar sus estimaciones futuras. Por lo tanto, incluso si la precisión de las estimaciones de sus tareas individuales no mejora, debería tener un sentido general más realista.

Puede beneficiarse del primer enfoque después de un proyecto; el segundo enfoque se vuelve más efectivo a medida que tiene más cifras para comparar.

También encuentro que el segundo enfoque es más útil si necesita estimar el tiempo que tomarán otros desarrolladores. Me resulta difícil estimar en nombre de otro desarrollador en un equipo, pero sé que ciertas personas siempre toman más o menos tiempo que yo en determinados tipos de tareas. Entonces, en lugar de tratar de calcular cuánto tiempo tomarán, calculo cuánto tiempo tomaría y luego aplico un multiplicador general basado en proyectos anteriores. (Por supuesto, lo ideal sería que hicieran sus propios cálculos, pero esto no siempre es posible).

Pregúntele a su jefe qué decisiones tomará basándose en la estimación que proporcione.

Las estimaciones son soporte de decisión. Lo que la mayoría de la gente realmente quiere son mejores decisiones.

Tal vez podamos obtener eso al mejorar nuestras estimaciones (y se han dado muchas buenas sugerencias) pero, seamos sinceros, las estimaciones nunca serán tan precisas como lo quiere el PM promedio, ni tan bajas como el promedio El vendedor quiere.

Todas las estimaciones son rangos y probabilidades (incluso cuando nos vemos obligados a dar un solo número), y puede brindar un mejor apoyo a la toma de decisiones si sabe para qué se utilizará la estimación.

Hay mucho más que decir acerca de esto, pero quería tener la perspectiva como nadie más lo ha mencionado.

George, he pasado la mayor parte de mi carrera como equipo de un solo hombre, así que sé de lo que estás hablando.

Alguien sugirió que obtuvieras MS Project, si tienes mucha experiencia con Project, eso podría estar bien. Pero si no, en mi humilde opinión, solo hará las cosas más complicadas.

Mi primera visión real de las estimaciones provino de Programas de software indoloros por Joel Spolsky. Joel ahora sugiere que utilice Programación basada en evidencia , que creo que está en su software de seguimiento de errores < a href="http://www.fogcreek.com/FogBugz/"> FogBugz . No lo he usado, pero estoy seguro de que es mucho mejor que lo que voy a decirte ... pero si quieres ir por el camino del bricolaje:

Lo que necesita es una forma sencilla de administrar una lista de tareas. Personalmente, agregué 4 campos personalizados a mi software de control de errores (uso BugTracker.NET ), mínimo, máximo, probable y real estimar tiempos. Agrego todas las tareas y funciones a bugtracker junto con min, max, & estimaciones probables Cuando termino cada tarea, actualizo la hora real. A medida que avanzo mis tareas, puedo ver en mi historial que, en promedio, mis estimaciones "probables" están un X% (para mí, es un 26%), así que puedo tomar mi tiempo total y proyectar todas las tareas restantes con mi min, max, y tiempo probable ajustado. Luego, en futuras tareas o proyectos, puedo revisar mi historial de tareas similares y sus tiempos reales, y formar mis estimaciones a partir de ellas. Tener el historial también ayudará a evitar tareas faltantes.

Si haces esto, también puedes encontrarte con un BS político. Cuando comencé esto, le di acceso a mi gerente, le mostré cómo funciona y cómo podía establecer mis prioridades y averiguar el progreso de los proyectos. Sin embargo, como el software es una herramienta de seguimiento de errores, creo que todas las funciones, mejoras y tareas se están reportando como errores. Esto es algo que desearía poder deshacer.

Y el libro Steve McConnell es fantástico.

Algo que yo uso es COCOMO. Es una técnica que proporciona modelos probabilísticos para la estimación de costos de software. Es algo con lo que tus PM (si están formalmente capacitados) probablemente estarán familiarizados. En lugar de preocuparse por las horas, simplemente calcula la SLOC (líneas de código fuente) que espera escribir. Eso justo allí debería activar algunas alarmas, pero es solo una parte de la técnica. Luego, introduzca estas estimaciones en un modelo y ajuste las métricas para un ajuste fino.

• Número de desarrolladores
• Capacidad de cada desarrollador
• Su calendario de trabajo (horas por semana, por recurso)
• Idioma (s) de desarrollo y amp; porcentajes (si usa más de uno)
• Familiaridad con el dominio (¿alguien ha escrito este tipo de aplicación antes)?
• estilo de gestión
• Proceso de desarrollo (Agile, waterfall, RUP, ...)
• etc.

Lo que hace todo este proceso es permitirte concentrarte en lo que eres bueno para estimar: el código. La estimación del tiempo es resumida y encapsulada por el propio modelo. Cada modelo ha sido construido analizando cientos de proyectos del mundo real. Incluso puedes sintonizarlos tú mismo, conectando tus propios datos.

He tenido mucha resistencia a este método, especialmente cuando me olvido de redondear. "Oh, cierto. Esto tomará 29.02 horas". Con todo, ha sido el método más preciso para mí. Mis colegas pueden estar en desacuerdo con el uso de SLOC todo lo que quieran, pero no pueden debatir la ciencia que creó esta técnica.

Como desarrollador exclusivo, lo he usado, pero al principio tuve problemas con mi ego. No quería reconocer que mis habilidades en C ++ eran más débiles de lo que pensaba en ese momento. Me hizo subestimar. Después de que conecté mis niveles de habilidad reales, todo se alineaba. Lección aprendida.

Otra técnica que coloco en la parte superior (algunas herramientas lo hacen por usted), es la técnica de estimación de tres, que es ampliamente aplicable en todos los lugares. Tomas tu peor caso, el mejor caso y el caso esperado y luego los promedias juntos. Pon tu peso esperado por un factor de cuatro. Así que ... "(peor + mejor + esperado * 4) / 6" Es una ayuda moderada para el riesgo, pero en realidad es un truco psicológico para obtener estimaciones precisas más rápidamente ... a favor de tu instinto.

Sobreestime y divida el proyecto en múltiples tareas pequeñas que se pueden dividir en 15 minutos, 30 minutos, 1 hora, 2 horas, 4 horas u 8 horas; Si no cabe en 8 horas, vuelve a dividir la tarea. Esto debería dar una idea clara de cuánto tiempo debería tomar.

La estimación de proyectos de software es un tiro en la oscuridad. No dejes que nadie te diga lo contrario. Los gerentes de proyecto, especialmente los gerentes de proyecto no técnicos, a menudo no se dan cuenta de esto.

Aunque hay muchas pautas y fórmulas por ahí, nunca he encontrado una manera mejor que simplemente tomar un proyecto anterior, aplicar algún tipo de factor de escala y usarlo como una línea de base. Por ejemplo, mi último proyecto duró 6 meses y el siguiente tiene reglas más simples pero mucha más migración de datos más otra interfaz externa, por lo que creo que es aproximadamente un 50% más difícil = 9 meses.

Algunos consejos:

Hay muchas buenas sugerencias sobre cómo hacer la estimación, pero todas llevan tiempo. Para obtener el tiempo para hacer una estimación correctamente, utilizo esta táctica.

Cuando me piden una estimación sin tener tiempo para averiguar cuánto tiempo tomará el proyecto, siempre volveré y daré una estimación que sé que a la administración no le gustará. Digamos que usted piensa que un proyecto tomará aproximadamente 3 meses. Diré algo así como de 6 meses a un año. Por lo general, me miran mal y les digo: "Bueno, si me dejan hacer una estimación real, probablemente pueda darle una mejor estimación".

Además, ¡NUNCA digas que un proyecto tomará de 2 a 3 meses! Está pensando que el proyecto tomará 3 meses y su gerente solo escuchará 2 meses.

llego tarde al juego para esta pregunta, pero su comentario tocó un acorde: a menudo se le piden estimaciones en el lugar : no hay tiempo para investigar, detallar, planear, consultar con el equipo, etc. Solo un número ir-con-tu-gut - y probablemente un número que volverá para atormentarte.

Esto sucede con frecuencia. El truco es confiar en tus instintos pero también compensar tus errores .

En otras palabras, haga su mejor estimación y multiplique por algún factor que ayude a cancelar la falta de información, el tiempo para realizar un análisis adecuado y la arrogancia eterna y el optimismo.

Por ejemplo, si sus últimas 3 estimaciones fueron:

• 1 día
• 2 semanas
• 3 meses

y el tiempo real fue:

• 4 días
• 2 meses
• 1 año

entonces claramente su "coeficiente de optimismo" es 4.

A medida que mejore la estimación (o evite estimar, según sea el caso), este coeficiente debería tender a la baja. Pero puede volver a activarse por un tiempo si empiezas a trabajar en un dominio o tecnología diferente, etc. Por lo tanto, es importante realizar un seguimiento siempre, al menos mentalmente.

Para un área completamente nueva con poca información y tecnología desconocida en circunstancias extremas, como reparar el hiperimpulsor en un crucero de batalla Hutt en medio de un tiroteo cuando no puedes leer huttés, es mejor emplear la Regla Scotty : dos veces y agrega algunos ^*

[ ^* un amigo mío insiste en que la verdadera Regla de estimación de Montgomery Scott es tomar su mejor estimación, redondear, multiplicarla por 10 y cambiar al siguiente orden superior de unidades. Entonces, si cree que una tarea tomará 2.5 horas, redondeará hasta 3 horas, multiplicar por 10 para obtener 30 horas y cambiar las unidades de horas a días para obtener la estimación final de 30 días.]

Recomendaría dividir la tarea tanto como sea posible antes de realizar cualquier evaluación, este ejercicio solo lo forzará a tener una comprensión profunda de lo que tiene que hacer y cómo planea hacerlo. Una vez hecho esto, aumentas tus posibilidades de comparar la subtarea con algo que ya has hecho y tienes algo más cercano a la realidad. Si la especificación de lo que tienes que hacer no está clara, también lo descubrirás en este momento, lo que es bueno.

Las tareas de más de 40 horas difícilmente se pueden evaluar con precisión, si su gerente de proyecto es bueno, ¡lo sabrá! Está bien estar equivocado, la experiencia es la única cosa real que marcará una diferencia real en tus evaluaciones (y al final, solo te ayudará a estar más cerca de una respuesta correcta, no a ser perfecta).

También tuve una experiencia muy agradable con la planificación del póquer. Cuanto más lo usa mi equipo, mejores son sus evaluaciones (¡además de que es divertido!) pero se necesita más de 1 persona, lo que no puede ayudarte mucho.

Utilicé muchos, pero tal vez valga la pena ver algo como la herramienta de estimación de 3 puntos.

Herramienta de estimación de 3 puntos

Con esto, tomas el Optimista (si todo fue según lo planeado), Mayormente Probable (cuánto tiempo crees que tomará el proyecto) y el Pesimista (más largo que crees que podría tomar)

Luego, puede calcular una Media y agregar un promedio ponderado a las partes si es necesario. Cuanto más se divida su proyecto, mejor será el resultado que pueda obtener.

Como inicio rápido, podría tener algo así como sus encabezados principales, con cualquier cantidad de tareas, con calificaciones optimistas, más probables y pesimistas

• Investigación
• Especificación de la función
• Especificación de diseño
• codificación
• Pruebas
• Implementación

Por supuesto, es posible que desee expandir un título o agregar su propio título.

Por lo general, aquí hay una función de penalización asimétrica, para el gerente y el equipo de desarrollo. Eso es en realidad parte de la lógica del relleno.

Tarde: si la gente le dice a sus jefes que esperen a Tsched, y en lugar de eso, es más largo que Tsched, entonces los horarios se interponen y se critica a la gente por varias cosas y, en el peor de los casos, las ventas se pierden o los clientes desaparecen o los proyectos se reinician. Organizado o en la papelera.

Temprano: si la T verdadera es menor que Tsched, entonces, oye, dale una palmada al equipo de desarrollo en la espalda y mantente ocupado en el próximo proyecto. O, Dios no lo quiera, refactorice y mejore la calidad del código (no, no haga eso ... haga el próximo proyecto. Trabajo).

Debería escuchar el podcast de stackoverflow y escuchar el proceso de estimación de Jeff Atwood para este sitio en el que se encuentra en este momento. Era un poco demasiado agresivo y Joel lo llamó.

Estos son buenos puntos a considerar, pero deberá eliminar las cosas que no funcionan o no se aplican. Revise las sugerencias después de hacer más estimaciones y vea si algo sobresale como más aplicable después de usar estas sugerencias.

Hacer un seguimiento de lo que estimaste y luego cuánto tiempo realmente tomó es una GRAN idea, y con demasiada frecuencia no se sigue, porque debes pasar al siguiente "fuego". Sin embargo, solo puede mejorar la estimación si dedica tiempo a determinar cómo estaba mal su estimación y determinar qué cambiar para la próxima vez.

También mencionó que está trabajando con el código existente. A medida que realice más cambios en esto, sugeriría aumentar el tiempo necesario para realizar la prueba. Debe asegurarse de que el cambio funcione y de que la otra funcionalidad del código aún funcione. Si sus pruebas son de alguna manera automatizadas, entonces es posible que deba cambiarlas para probar este cambio en el software. Si sus pruebas son manuales, debe asegurarse de probar lo que cambió (agregar o cambiar la forma en que lo hizo anteriormente).

Buena suerte.

Puedes intentar dividirlo en tareas más pequeñas y estimar cada tarea. Por ejemplo, podría dividirlo en algo como:

1. instalar SharePoint
2. Crear un elemento web de prueba de concepto.
3. Implementar código personalizado en SharePoint.

Estas son tareas para las que deberías poder encontrar tutoriales y, al leerlas, puedes comprender cuánto tiempo tomará (sugerencia: ¡instalar SharePoint es largo!).

Además de esto, estoy de acuerdo en que es difícil estimar tareas que no has hecho antes, así que trata de dividirte en tareas que sean pequeñas y comparables (en el alcance) con las cosas que has hecho en el pasado.

Si alguien más en la compañía ha hecho cosas similares, grita sobre la pared del cubo y mira lo que piensan. Compare esto con el tiempo que realmente le lleva, luego, cuando obtenga otra tarea, pregunte al mismo desarrollador cuánto tiempo les tomará. Multiplica ese resultado por la diferencia que obtuviste haciendo la tarea inicial. Realmente no hay una buena manera de estimar nuevas tareas sin una línea de base histórica, pero al menos de esta manera demostrará que hizo un esfuerzo para basar su estimación en algún tipo de hecho.