Software de estimación de velocidad y precisión

Question

Digamos que usted tiene un proyecto que implicará dos aplicaciones web (que compartirá / DAO / asambleas DAL BO y algunas bibliotecas OSS):

• una aplicación de gestión complejo semi que utiliza Windows Live ID para la autenticación y también es capaz de comunicarse con diversos servicios notificador (correo electrónico, SMS, gorjeo etc.), notificadores dirigida que está en aproximadamente el 10% de la funcionalidad
• mínima de aplicación de usuario complejo semi con menos funcionalidad pero más robustez que también utiliza Windows Live ID para la autenticación

Hay dos de nosotros con capacidades de estimación media y que no serán capaces de hacerlo en dos días, incluso si queríamos / que hacerlo. Al menos sería un lejos estimación.

Preguntas

1. ¿Cuánto tiempo / toma normalmente le llevará a realizar una estimación fiable / valioso?
2. ¿Qué le sugeriría para acelerar la estimación sin sacrificar la precisión?
3. ¿Cuánto floja (en términos de coste / hora) añadirías dependiendo de la velocidad de estimación (cuando se podría decir: Me podría estimar que sea un poco más, porque creo que es todavía bastante fuera )

Answer 1

Es una pregunta interesante. Me temo que la respuesta es "depende realmente!" Yo sé que no es terriblemente útil (aunque es cierto) así que aquí están algunos factores:

1) La calidad e integridad de los requisitos y su especificación. Esto es, para mí, lo más a menudo el asesino de proyecto de presupuesto. Si usted no tiene requisitos de calidad, que no tienen ninguna base razonable para una estimación. Utilizamos un estilo "RUP-lite" del desarrollo del producto aquí, así como el director de ingeniería no voy a dar nada más que la estimación grosera de grano hasta que hayamos completado nuestra fase de "preparación" y conseguido el cierre de sesión de gestión de productos que el núcleo 80% de las características del producto son de hecho cubierto con precisión.

2) El alcance y la naturaleza del producto. Más grande / más caro / más complicado = sustancialmente más largo de estimar. He pasado años trabajando en la tierra de telecomunicaciones portador de la entrega de soluciones que tienen los requisitos normales de transporte robusta ( "5 de 9" del tiempo de funcionamiento requerido por SLA significa que realmente debe hacer un buen trabajo de diseño de la solución y la recuperación de errores!). En ese tipo de entorno con todas las partes en movimiento a través de las áreas funcionales de la empresa, la estimación de trabajo va a depender de conseguir el cuadro completo ... específicamente, las dependencias entre funciones y dependencias externas pueden ser un verdadero asesino aquí. Dicho esto, también me he construido una gran cantidad de encogimiento envuelto y software de la empresa, también. En esos entornos es mucho más fácil ya que el alcance es típicamente sustancialmente menor, por lo tanto, más fácil de calcular.

3) ¿Cómo "nuevo" es este proyecto? ¿Cómo "nuevo" es el equipo a este producto o la tecnología set? El nuevo producto o equipo, el más largo y más memoria intermedia debe asignar.

4) ¿Cómo específica qué necesitamos ser? Si se trata de un "cálculo aproximado" entonces voy a apoyo en mi ingeniería conduce a proporcionar una estimación conservadora, entonces voy a la almohadilla de eso. Si necesitamos una estimación "real" (por ejemplo, uno que es utilizado por mi jefe y el que va a ser responsable de golpear), que iba a necesitar la entrada de un número de diferentes administradores y miembros del equipo, que va a necesitar tiempo para analizar los requisitos y confieren entre sí.

Esto puede tomar tan poco como un par de días, o weeks..it todo depende del tamaño. "Dos o tres días" es, francamente, no lo suficiente como para dimensionar otra cosa que el más trivial de los proyectos.

Lo mejor que puede hacer para mejorar la calidad de las estimaciones a mejorar la calidad de sus necesidades, y ser implacable en la identificación de las dependencias ocultas.

Una última cosa:. Fwiw, he estado haciendo esto desde el '81 y considero la estimación precisa de un proyecto de duración / coste como el único más difícil / plagado de parte peligro de gestión de ingeniería

Answer 2

Debido a que utilizamos métodos ágiles (Scrum, específicamente) que nos lleva alrededor de una hora más de lo que tardan los usuarios a priorizar.

Más tiempo no conduce a una mayor precisión.

La parte difícil, entonces, es conseguir que los usuarios priorizar. Oímos esta discusión todo el tiempo "si todo el asunto no se termine a tiempo, todo es inútil." "Excepto por el componente XYZZY, que tiene algo de valor." Ese argumento puede prolongarse durante horas, hasta que se resuelva que XYZZY debe ser en primer lugar.

En general, tratamos de crear 4 semanas sprints. Los primeros son complicados, porque siempre hay algo nuevo. Después de los primeros dos (o tres) que parecen establecer un ritmo constante.

Cada caso de uso tiene una valoración relativamente simple, subjetiva de cómo el esfuerzo que se necesita para terminarlo. Algo más de una carrera llena de duración tiene que ser descompuesto. La mayoría de las veces unos pocos casos de uso se encuentran agrupados en una sola carrera de velocidad.

El son maneras formales de la puntuación de cada caso de uso para manejar mejor los problemas de costo y horario. Nosotros no usamos porque el esfuerzo extra no ayuda.

Después de las dos primeras carreras,

1. Hay nuevo y diferente funcionalidad,

2. Las prioridades han cambiado,

3. Los detalles de cada caso de uso se han revisado de forma espectacular.

¿Qué significa "precisión" significa cuando lo que está tratando de estimar los cambios al final de cada sprint?

---

Una de las lecciones aprendidas. Partes de mi compañía pasan un los tiempo totalmente la definición de exactamente lo que va a ser entregado, y midiendo después de que se están dando exactamente lo que quieren.

Los clientes lo notan, y uno dijo que "pasamos mucho tiempo de la entrega de lo que dice el contrato, pero no es lo que necesitábamos."

El problema con firmes estimaciones iniciales es que adquieren una vida propia. Cuanto más se "invierte" en la estimación, más las estimaciones parecen ser un entregable útil. Ellos no son útiles porque son generalmente totalmente equivocado. Se basan en suposiciones iniciales que son totalmente equivocado.

Es una mala política para invertir más en la estimación de tiempo. Las respuestas "precisas" no son más precisos, pero son más atesorados por todas las capas de gestión. A medida que usted y el cliente aprende, se invalidan numerosas suposiciones y es absolutamente necesario volver a estimar constantemente.

No lo haga por adelantado. Si su contrato le obliga a hacerlo por adelantado, a continuación, asegúrese de que tiene una disposición de control de cambios y decirle al cliente que absolutamente va a hacer cambios a medida que avanza hacia adelante. Como ambos y el cliente aprende, tanto debe hacer cambios.

Answer 3

Para realizar una estimación fiable que realmente se necesita para crear una lista de tareas a realizar. Dividirlo en historias / tareas (incluso si no se utiliza ágil) y evaluarlos. Esto puede tomar mucho tiempo ya - en especial la cantidad de investigación (para buscar bibliotecas para hacer estas cosas notificador para reducir el costo). Me gustaría tener al menos 3 días - sin embargo 1-2 semana (s) suena más razonable para mí. Esto no parece ser un pequeño proyecto.

No me atrevería a acelerar el proceso de estimación de si queríamos ofrecer algo resultados razonables. Las estimaciones no son exactos y usted acaba de empeorar las cosas.

Una opción sería hacer una suposición totalmente en bruto dentro de unas horas y luego empezar a trabajar en él ya (para una semana o algo así). Al final de la semana que podría ser capaz de dar una mejor estimación sobre la base de su progreso actual. Sin embargo, es importante crear un buen prototipo (que se ve como una mierda, pero tiene un poco de código en todas las regiones).

Answer 4

Bueno, una cita común es "El precio será de entre el 50% y el 400% de nuestras estimaciones iniciales". La razón de que esta cita ha crecido tan grande es que es verdad. precisión de la estimación depende en gran medida de su dominio en el conocimiento. Si este es el momento 100a que vendió un tipo dado de Blog-motor que estás bastante seguro acerca de las estimaciones. Sin embargo, más a menudo que no, usted no tiene que el conocimiento profundo del dominio (si la aplicación ya existe, ¿por qué crear una nueva?).

El desarrollo ágil se ha hecho popular porque la gente reconoce ampliamente que el tipo tradicional de "cascada" de pensar simplemente no funciona para la mayoría de los proyectos del mundo real. Debe aplicar la misma forma de pensar para sus estimaciones. Obviamente, se necesita algún tipo de punto de venta, pero asegúrese de decirle a sus clientes de que esta información es muy vago (y que no importa lo que cualquier competidor les dirá, sus estimaciones son vagos también).

Si usted quiere vender iteraciones, y por lo tanto también estiman iteraciones. Estoy seguro de que algunos de marketing-individuo en cualquier empresa sabrá cómo manejar el papeleo y las cosas legales para ello, por lo que no debería ser tan grande de oferta.

Considere un proyecto de 5 iteraciones:

• Comience a cabo mediante la colocación de hitos. Estos están sujetos a cambios, pero proporcionarán sus primeras estimaciones vargue para el producto final.
• Plan de iteración # 1.
• Estimación iteración # 1, ajustar las estimaciones totales en consecuencia.
• Haga iteración # 1
• Enjuague / repetición hasta la iteración # 5
• que haya terminado:)
• Reflexionar sobre su proyecto. ¿Cómo evolucionaron sus estimaciones? ¿Razones? Aprender haciendo:)

La mayoría de los clientes prefieren tener estimaciones parciales y parciales de liberaciones que un objetivo poco realista que algunos traje de las vendió:)

Answer 5

Apartarse ligeramente de su pregunta original, pero también es importante aprender de las estimaciones que se han producido en el pasado por mantener la información acerca de cuánto tiempo realmente tuvo que hacer las cosas que usted estima.

Hemos estimado de 5 días para producir estas páginas, en realidad se tomó 10 días, y etc.

En la información a largo plazo como esta voluntad (¡ojalá!) Le permiten producir estimaciones más precisas.