Aspectos básicos del dimensionamiento del trabajo pendiente
Examina cada historia de usuario Y el conjunto
ScopeMaster proporciona automáticamente una estimación del tamaño basada en el texto de la historia del usuario.
Por qué el dimensionamiento automatizado con ScopeMaster es mejor que el dimensionamiento en equipo
ScopeMaster no solo proporciona una estimación razonable del tamaño del trabajo pendiente, sino que también puede hacerlo sin esfuerzo, al instante y puede dimensionar los elementos del trabajo pendiente que faltan.
Dimensionamiento del trabajo pendiente de software automatizado por ScopeMaster®
Dimensionamiento y estimación del trabajo pendiente de software normalmente son una pérdida de tiempo y se juegan. Sin embargo, las estimaciones fiables son esenciales para tomar decisiones de inversión acertadas y una planificación eficaz.
Estimar el tamaño del trabajo pendiente de software (y posteriormente el costo y el cronograma) es importante para que los gerentes comprendan cuánto costará y cuánto tiempo llevará. Los gerentes y ejecutivos se enfrentan constantemente a decisiones difíciles sobre el trabajo del software. En proyectos más grandes, con frecuencia se exceden los presupuestos y los cronogramas, lo que genera considerables desperdicios e ineficiencias. Gerentes Necesita saber el costo probable y la duración. desarrollar software para poder planificar en consecuencia. Se espera que tomen decisiones confiables sobre prioridades y asignación de personal y, sin embargo, a menudo lo hacen sin una estimación de software confiable del tiempo y esfuerzo necesarios.
La mayoría de los profesionales del software creen que es imposible estimar el trabajo de desarrollo de software o que requiere mucho tiempo. Esto no es así.
¿Por qué las estimaciones de los desarrolladores no son fiables?
Los desarrolladores suelen tener dificultades con las estimaciones. La estimación utilizando técnicas como los puntos de la historia o el tamaño de la camiseta es en realidad solo una aproximación para adivinar horas o días de trabajo. Los equipos argumentarán lo contrario, pero eso es más que nada una confusión para promover. Cuando los desarrolladores proporcionan estimaciones para una parte de un trabajo, pueden subestimar deliberadamente el trabajo, tal vez para "ganarlo" y proteger su trabajo. También pueden sobreestimar para evitar tener que hacer algún trabajo que no quieren hacer.
El uso indebido de las estimaciones de los desarrolladores es frecuente
Una vez que los desarrolladores han proporcionado a un gerente una estimación de una historia de usuario, un sprint de trabajo o incluso un trabajo pendiente completo, el gerente podría usar esa estimación como un objetivo, una medida de control o incluso un compromiso, todo lo cual Son usos inadecuados de la estimación del esfuerzo básico.
Subestimar es la naturaleza humana
Los desarrolladores casi siempre subestiman el tiempo y el esfuerzo realmente necesarios para entregar el software. Es la naturaleza humana hacerlo. Sólo consideran los factores que conocen y, sin embargo, con el software a menudo hay incógnitas que causan retrasos, tesis que rara vez se tienen en cuenta en la estimación técnica. Además, las propuestas iniciales de los desarrolladores suelen ser bajas para “ganar el trabajo”.
¿Cómo estimar la cartera de pedidos de productos de software de forma fiable?
Decenas de factores pueden afectar el tiempo y el esfuerzo para desarrollar software (como la complejidad, el ambiente de trabajo, el soporte ejecutivo, la experiencia técnica, la volatilidad de los requisitos). El El factor más importante para determinar el esfuerzo o el costo es el tamaño., específicamente tamaño funcional.
El tamaño funcional del software es la base de la estimación del backlog
Una vez que sepas el funcional tamaño, puede derivar rápidamente estimaciones válidas para otras dimensiones, como:
- dotación de personal
- tiempo para desarrollar
- costos
- pruebas necesarias para lograr la calidad adecuada
- y mucho más
¿Qué es el tamaño funcional?
El tamaño funcional surge de la Medición del Tamaño Funcional (FSM). Es una técnica estandarizada madura y probada para el dimensionamiento de software. Es un Práctica formal de ingeniería aprobada por los grupos de estándares ISO.. Es agnóstico de la tecnología y la metodología de desarrollo. El tamaño funcional es una medida universal que se aplica a todo tipo de software. Se considera desde el perspectiva de los usuarios. Es objetivo, válido y coherente. Dos personas que midan el tamaño funcional deberían obtener el mismo número cada vez. La unidad de medida es el punto de función, específicamente el punto de función COSMIC o CFP. La PPC se puede estimar o contar (exactamente) sólo a partir de los requisitos y especificaciones. El tamaño funcional es independiente del lenguaje de codificación utilizado para desarrollarlo. FSM existe desde hace muchos años y ha demostrado ser la medida más confiable del tamaño del software. FSM le permite estimar o medir el tamaño antes, durante y después de que se haya escrito el código.
Estimación innovadora de la cartera de productos
ScopeMaster es la primera y única herramienta que estima de manera confiable el tamaño funcional directa y automáticamente a partir de una acumulación de requisitos escritos. Sin embargo, no confíe sólo en nuestra palabra. Expertos y académicos de todo el mundo coinciden en que ScopeMaster® es una innovadora herramienta de dimensionamiento automatizado: Validación académica de ScopeMaster como herramienta de dimensionamiento automatizada.
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
Lo mejor de conocer el tamaño antes de codificar es que puedes asignar la cantidad correcta de tiempo y fondos para realizar el trabajo. Con solo conocer el tamaño, normalmente puedes ahorrar 10% o más en un proyecto de software más grande, a veces incluso más.
Estimación de software automatizada con ScopeMaster
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. “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”. Colin Hammond, fundador.
ScopeMaster interpreta la intención funcional de la historia del usuario o el requisito de software y, por lo tanto, es capaz de automatizar el dimensionamiento funcional, que luego se puede utilizar para más estimación del desarrollo de software.
ScopeMaster no sólo es mucho más rápido que medir manualmente (al menos 4 veces más rápido), sino que cuesta sustancialmente menos que el dimensionamiento manual, los contadores certificados son escasos y ScopeMaster elimina gran parte de la monotonía de realizar el trabajo. ScopeMaster "lee" los requisitos, interpreta la intención funcional y luego los dimensiona en consecuencia. Puede estimar el tamaño en aproximadamente 3 CFP por segundo. Se podría dimensionar un conjunto de requisitos de 1000 CFP (alrededor de $1m de software subcontratado) en aproximadamente 2 o 3 minutos. Luego podría revisar los resultados para a) corregir cualquier error en los requisitos y b) verificar el tamaño funcional de cada requisito. Una vez verificada por el analista, la estimación se convierte en un recuento/medición exacta, que incluso puede utilizarse para la subcontratación de 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. Sólo cinco han conseguido 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 allá por los años 1980. El Metodología de tamaño funcional COSMIC evolucionó a partir de metodologías anteriores, diseñadas específicamente para abordar sus deficiencias. Las ventajas clave que hacen que la metodología COSMIC Sizing sea más relevante para el software moderno son:
- Se basa en principios de software y trata elegantemente capas de software y arquitecturas de software interconectadas.
- Se pueden realizar estimaciones y mediciones antes de conocer todos los requisitos, lo que es muy adecuado para el desarrollo ágil.
- Ha sido automatizado y, por lo tanto, requiere un aprendizaje insignificante.
Los puntos de la historia prevalecen en todos los proyectos ágiles y son una medida indirecta del esfuerzo específica del equipo. Cada equipo tiene un entendimiento común de la magnitud de un punto de la historia; normalmente es del orden de unas pocas horas de esfuerzo, pero no existen reglas estrictas. Los puntos de historia no son una moneda universal. No son un estándar y no se pueden utilizar de manera confiable para comparar equipos o proyectos. Los puntos de la historia son un indicador interno útil del esfuerzo anticipado, si no hay otros medios de estimación disponibles. Sin embargo, los puntos de función son universales, estándar y altamente 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 de software
Una vez que conozca el tamaño funcional en los puntos de función COSMIC (CFP), podrá 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 los valores de conversión de la industria que asignan puntos de función al esfuerzo, el costo y el cronograma. 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 cartas de Fibonacci. Según nuestra experiencia, la estimación ágil se logra mejor mediante el dimensionamiento funcional con COSMIC FP.
¿Qué puedes estimar según el tamaño?
- 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?
Manualmente, un analista competente puede contar (medir) puntos de función a un ritmo de aproximadamente 100-500 FP por día (aproximadamente $100k – $500k de software). Esto depende de la calidad y claridad de los requisitos y especificaciones. La velocidad también depende de la experiencia y capacidad del analista. Con ScopeMaster puede esperar alcanzar estas reglas aproximadamente 4 veces más rápido.
Estimación mientras escribe historias de usuarios
Con ScopeMaster Story Analyzer para Jira, puede 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 funcional y el tamaño funcional.
El tamaño no es el único factor que determina los costos y el cronograma del software, pero es el más importante.
Problemas con los puntos de la historia y las camisetas.
- Inconsistente
- Se puede jugar
- No lineal
Los puntos de la historia son una opinión basada en equipo sobre la cantidad de esfuerzo que podría llevar crear algún software desde la perspectiva de un desarrollador. Los puntos de la historia son esencialmente un indicador de las estimaciones de esfuerzo; por ejemplo, un punto de la historia podría ser el equivalente a 1 día de una persona ideal. Son muy subjetivos y dependen de las opiniones del equipo. Varían de un equipo a otro e incluso con el tiempo dentro del mismo equipo. Su inconsistencia y capacidad de juego los hace poco prácticos como métrica de ingeniería confiable.
Para aquellos que consideran que la estimación es dañina, sin importancia o simplemente demasiado difícil, consulte el excelente artículo de Steve Mconnell sobre por qué La estimación es una habilidad importante y valiosa que los gerentes de proyectos necesitan..
