Dimensionamiento del trabajo pendiente: automatizado

Aspectos esenciales del dimensionamiento del backlog

Tamaño de la cartera de pedidos de softwareng y estimación A menudo se considera que los costos son derrochadores y consumen mucho tiempo. Las estimaciones también son más de lo que se esperaba.Estimaciones que, aunque ocasionalmente se utilizan incorrectamente, son confiables y esenciales para tomar decisiones de inversión acertadas y eficientes.Planificación eficaz.

ScopeMaster proporciona automáticamente una función estandarizadatodo intInterpretación y estimación del tamaño funcional en función del texto de cada historia de usuario.

Por qué el dimensionamiento automático > Dimensionamiento del equipo

Sco no sólopeMaster proporciona una estimación del tamaño razonable del backlog, pero puede hacerlo de manera instantánea y sin esfuerzo, e incluso dimensionar elementos del backlog que podrían faltar.

ScopeMaster automatiza el dimensionamiento de la cartera de proyectos de software

Estimación del tamaño de la cartera de proyectos de software (y, posteriormente, del costo y el cronograma)Es importante que los gerentes comprendan cuánto costará y cuánto tiempo llevará. ManaLos gerentes y ejecutivos se enfrentan constantemente a decisiones difíciles sobre el trabajo de software.Los proyectos, presupuestos y cronogramas se exceden con frecuencia, lo que genera considerables desperdicios e ineficiencias. Los gerentes Necesita saber el costo probable y la duración. Desarrollar software para que puedan planificar de acuerdo aSe espera que tomen decisiones confiables sobre prioridades y asignación de personal y, sin embargo, a menudo lo hacen sin una estimación confiable mediante software del tiempo y el esfuerzo necesarios.

La mayoría de los profesionales del software creen que es imposible estimar el trabajo de desarrollo de software o que siempre consumirá mucho tiempo, lo cual simplemente no es cierto.

¿Por qué las estimaciones de los desarrolladores no son fiables?

Los desarrolladores a menudo tienen problemas con las estimaciones. La estimación con técnicas como los puntos de historia o el tamaño de las camisetas es en realidad solo un indicador para aproximar (como adivinar) horas o incluso días de trabajo. Los equipos a menudo pueden argumentar lo contrario, pero es probable que se trate de un intento de ofuscar para promocionar. Cuando los desarrolladores proporcionan estimaciones para una parte del trabajo, pueden subestimar deliberadamente el trabajo para "ganar" el trabajo y protegerlo. su También pueden sobreestimar sus responsabilidades para evitar trabajos que no desean realizar.

Una vez que los desarrolladores han proporcionado a un gerente una estimación de una historia de usuario, un Sprintly de trabajo o incluso un backlog completo, el gerente puede usar esa estimación como un objetivo, una medida de control o incluso un compromiso, todos los cuales son usos inadecuados de una estimación.

Lamentablemente, los desarrolladores casi siempre subestiman el tiempo y el esfuerzo que realmente se requieren para la entrega de software. Es parte de la naturaleza humana hacerlo. Solo tienen en cuenta factores conocidos, pero con el software, a menudo hay desconocidos que causan demoras. Por esta razón, rara vez se permiten estas cuestiones en la estimación técnica.

Entonces, ¿cómo podemos estimar los atrasos de manera más confiable??

Decenas de factores pueden afectar el tiempo y el esfuerzo necesarios para desarrollar software (como la complejidad, el entorno de trabajo, el apoyo ejecutivo, la experiencia técnica y la volatilidad de los requisitos). El factor más importante a la hora de determinar el esfuerzo o el coste es el tamaño, específicamente el tamaño funcional. Una vez que conozca el tamaño funcional, Puede derivar rápidamente estimaciones válidas para otras dimensiones, como:

• dotación de personal
• tiempo de desarrollo
• costos
• pruebas necesarias para lograr la calidad adecuada
• …y mucho, mucho más

¿Qué es el tamaño funcional?

El tamaño funcional surge de Medición del tamaño funcional (FSM)Es una técnica estandarizada madura y probada para dimensionar software, una práctica de ingeniería formal aprobada por los grupos de estándares ISO y agnóstica de la tecnología, la codificación y la metodología de desarrollo. Como medida universal que se aplica a todos los tipos de software, se considera desde el Perspectiva del usuario. Por encima de todo, el tamaño funcional es objetivo, válido y consistente; en otras palabras, dos personas que midan el tamaño funcional deberían obtener siempre el mismo número. La unidad de medida es el punto de función; para decirlo de forma más específica, es el punto de función COSMIC (o CFP), que se puede estimar o contar únicamente y con precisión a partir de los requisitos y especificaciones. FSM existe desde hace muchos años y ha demostrado ser la medida más fiable del tamaño del software, ya que permite estimar o medir el tamaño antes, durante y después del proceso de codificación.

ScopeMaster es la primera y única herramienta que permite estimar de manera fiable el tamaño funcional de forma directa y automática a partir de una lista de requisitos escritos. Sin embargo, no se fíe solo de nuestras palabras; expertos y académicos de todo el mundo coinciden en que ScopeMaster es una Herramienta innovadora de dimensionamiento automatizado.

Aporte certeza al trabajo de su software con la medición automatizada del tamaño funcional.

Para obtener más información sobre la medición del tamaño funcional COSMIC, visite https://www.cosmic-sizing.org.

Estimación automatizada de software con ScopeMaster

Rápido:Aproximadamente 10 veces más rápido que un experto en dimensionamiento.

Preciso: Dentro de 15% de un dimensionamiento manual.

Basado en estándares:Resultados en los principales estándares ISO para dimensionamiento de software.

Tres estándares líderes automatizados:

ScopeMaster fue concebido como una herramienta para automatizar el trabajo administrativo de medir el tamaño funcional del software a partir de los requisitos. En palabras de nuestro fundador, Colin Hammond, “La razón por la que me propuse escribir una herramienta para hacer esto es porque, como gerente de proyectos de software, descubrí que tamaño funcional “Es el factor más importante que necesito para gestionar un proyecto con éxito”.

ScopeMaster interpreta la intención funcional de la historia del usuario o el requisito del software y, por lo tanto, puede automatizar el dimensionamiento funcional, que luego se puede utilizar para más estimación del desarrollo de software.

ScopeMaster no solo es mucho más rápido que la medición manual, sino que cuesta sustancialmente menos que el dimensionamiento manual. Los contadores certificados son escasos y ScopeMaster elimina gran parte del trabajo pesado. ScopeMaster "lee" los requisitos, interpreta la intención funcional y luego los dimensiona en consecuencia. Puede estimar el tamaño en aproximadamente tres CFP por segundoPodría dimensionar un conjunto de requisitos de 1000 CFP (aproximadamente 1 TP4T1m de software subcontratado) en aproximadamente dos o tres minutosLuego, puede revisar los resultados para corregir cualquier error en los requisitos y verificar el tamaño funcional de cada requisito. Una vez verificado por el analista, la estimación se convierte en una medición exacta, que luego se puede utilizar para la subcontratación a precio fijo del trabajo de desarrollo de software.

Dimensionamiento funcional COSMIC

A lo largo de los años, se han creado varias variaciones de la métrica de tamaño funcional. Solo cinco han logrado el reconocimiento ISO (COSMIC, IFPUG, Mark II, NESMA y FiSMA). IFPUG, Mark II, NESMA y FiSMA son similares en el sentido de que se derivan del conjunto de reglas original creado por Allan Albrecht en IBM en la década de 1980. Metodología de tamaño funcional COSMIC Se trata de una evolución de metodologías anteriores, diseñadas específicamente para abordar sus deficiencias. Las principales ventajas que hacen que la metodología de dimensionamiento COSMIC sea más relevante para el software moderno son:

1. Se basa en principios de software y trata elegantemente capas de software y arquitecturas de software interconectadas.
2. Se pueden realizar estimaciones y mediciones antes de conocer todos los requisitos, lo que resulta muy adecuado para el desarrollo ágil.
3. Se ha automatizado y, por lo tanto, el aprendizaje requerido es insignificante.

Los puntos de historia son comunes en todos los proyectos ágiles; son una medida indirecta del esfuerzo de cada equipo. Cada equipo tiene una comprensión común de la magnitud de un punto de historia (normalmente, del orden de unas pocas horas de esfuerzo), aunque no existen reglas estrictas. Los puntos de historia no son una moneda universal; no son un estándar y no se pueden utilizar de forma fiable para comparar equipos o proyectos. Los puntos de historia son un indicador interno útil del esfuerzo previsto cuando no hay otros medios de estimación disponibles. Sin embargo, los puntos de función son universales, estándar y muy aplicables al desarrollo ágil tanto como a cualquier otra metodología de desarrollo. Haga clic aquí para leer más sobre los méritos de CFP frente a Story Points.

El tamaño es la piedra angular de la estimación del software

Una vez que conoce el tamaño funcional en puntos de función COSMIC (CFP), puede establecer rápidamente otras métricas que están directamente relacionadas con el tamaño, como el costo, el esfuerzo y el cronograma. Una vez que se establece el tamaño en CFP, puede utilizar valores de conversión de la industria que asignan puntos de función a estas métricas. En lugar de utilizar conversiones de la industria, puede utilizar sus propios datos históricos del proyecto para establecer sus propios puntos de referencia de velocidad.

Estimación ágil

En lugar de perder el tiempo discutiendo puntos de la historia o jugando con las cartas de Fibonacci, creemos que la estimación ágil se logra idealmente a través del dimensionamiento funcional con COSMIC FP. Eso significa que puede estimar mejor:

• Velocidad (promedio de CFP entregados por semana)
• Cronograma (número de semanas necesarias para la entrega)
• Costo (coste total de diseño, desarrollo, prueba y entrega)
• Esfuerzo (esfuerzo necesario para diseñar, desarrollar, probar y entregar)
• Calidad (potenciales de defecto para cada componente de la entrega)

¿Qué tan rápido se pueden derivar estimaciones?

De forma manual, un analista competente puede medir puntos de función a un ritmo de varios cientos de puntos de función por día (lo que se traduce en un software que vale cientos de miles de dólares), aunque depende de la calidad y claridad de los requisitos y especificaciones. La velocidad también depende de la experiencia y la capacidad del analista. Con ScopeMaster, puede esperar alcanzar estas reglas sobre cuatro veces más rápido.

Estimación a medida que escribes historias de usuario en Jira

Usando el Analizador de historias ScopeMaster para JiraPuede estimar el tamaño funcional de sus historias sin siquiera salir de Jira. El potente motor de lenguaje de ScopeMaster analiza el texto de su historia de usuario para detectar la intención y el tamaño funcionales.

El tamaño no es el único factor que determina los costos y el cronograma del software, peroEs el más significativo. Descubra el valorObtenga más información sobre el dimensionamiento funcional automatizado a través de nuestro folleto:

Para aquellos que consideran que la estimación es perjudicial, poco importante o simplemente demasiado difícil, consulte el excelente artículo de Steve McConnell sobre por qué La estimación es una habilidad importante y valiosa que los gerentes de proyectos necesitan..

Problemas con los puntos de la historia y las camisetas.

• Inconsistente
• Jugable
• No lineal

Los puntos de historia son una opinión basada en el equipo sobre la cantidad de esfuerzo que podría requerirse para crear software desde la perspectiva de un desarrollador. Los puntos de historia son esencialmente un indicador de las estimaciones de esfuerzo, por ejemplo, un punto de historia podría ser el equivalente a un empleado ideal trabajando durante un día ideal. Son altamente subjetivos y dependen de las opiniones del equipo. Además, varían de un equipo a otro, e incluso dentro del mismo equipo a lo largo del tiempo. Su inconsistencia y su capacidad de adaptación los hacen poco prácticos como una métrica de ingeniería confiable.