Independientemente de la metodología de desarrollo de software utilizada, las estimaciones deben ser una de las principales actividades de planeación de software, “No se puede controlar aquello que no se puede medir” afirmaba Peter Drucker. Ósea, un desconocimiento cuantitativo puede llevar al completo caos y a que el proyecto no alcance el éxito deseado.
Un estudio de la empresa Quantitative Software Management (QSM) sobre el desempeño ágil mostró consistentemente que es la buena estimación y planificación lo que define el éxito en el desarrollo de software, y no la metodología utilizada.
Muchos especialistas de las metodologías ágiles son seguidores del movimiento #NoEstimate, pues creen que no existe valor en estimar al trabajar en pequeños incrementos de software en sprints cortos. Sin embargo algunas investigaciones, como una realizada por CA Technologies, muestran que las entregas realizadas por equipos que tienen el hábito de realizar estimaciones, son más rápidas que las entregas de los equipos que no realizan ninguna estimación.
Realizar estimaciones de forma colaborativa entre todos los miembros del equipo es muy válido para aumentar el comportamiento en la entrega, aclarar dudas, intercambiar ideas, esclarecer requisitos y percibir riesgos que usted no percibiría solo. Así, se evita la tendencia de las personas y organizaciones al subestimar el tiempo que va a necesitar para completar una tarea, mismo cuando tiene experiencia en las tareas similares.
Inscribete en el curso de Estimación de proyectos de software.
Cohn (2005), afirma que un día ideal corresponde a cantidades de trabajo que un profesional de nivel senior con influencia en las tecnologías y herramientas involucradas consigue realizar en un día de trabajo sin interrupciones. Se trata de una estimación empírica, ejecutada por expertos para el desarrollo con base en una exploración adaptable (ALVES; FONSECA, 2008).
La velocidad es calculada a partir del número de horas que el equipo gasta para implementar un trabajo equivalente a un día ideal.
En caso el ítem pase un día de trabajo, es sugerido descomponer ese ítem en ítems menores que se consiga implementar en apenas un día.
Es más indicada para equipos que todavía no poseen experiencia en realizar estimaciones, pues es fácil de entender y aplicar.
Mientras tanto, al medir el tamaño de una actividad en días ideales, todavía estamos asociando la noción del tiempo, lo que no siempre es una buena estrategia. Diversos factores pueden influenciar ese tipo de estimación como: evolución de la experiencia del tiempo, conocimiento adquiridos, cambios de frameworks, entre otros. El mismo equipo ahora puede entender que una funcionalidad similar a una anterior puede ser concluida en menos días. La base de la estimación muda es así como el histórico es perjudicado.
El objetivo del planning game es maximizar el valor agregado y minimizar el costo del sistema a ser desarrollado. Esa técnica, propuesta por la eXtreme Programming, presupone que el cliente es conocedor del negocio, sabiendo relacionar y priorizar los requisitos del sistema de acuerdo con su valor agregado. Por otro lado, el programador es conocedor de las cuestiones técnicas sabiendo estimar el costo de la implementación de esos requisitos (SHORE; WADEN, 2008). Sus 2 reglas básicas son: (i) o cliente prioriza y (ii) o programador estima.
El juego comienza con el cliente relacionando los requisitos en cartas. En seguida, esas cartas son colocados en orden, de acuerdo con el valor agregado observado por el cliente. Por fin el programador debe estimar el costo de la implementación de cada requisito priorizado. Esos pasos son repetidos hasta que todos los requisitos hayan sido priorizados y estimados.
Durante el proceso, desarrolladores y clientes interactúan para resolver dudas sobre prioridades y estimaciones. Inicialmente, esta técnica fue utilizada para evaluar el trabajo en una iteración, pero también puede ser usada para realizar una planeación de una entrega (Release) completa.
Nuevamente la mayor ventaja está en la colaboración e interacción, en ese caso entre el cliente y el desarrollo. Con todo el cliente puede presentar varias partes interesadas, que pueden poseer diferentes intereses y así puede no ser tan fácil llegar a un acuerdo con relación al valor agregado de un determinado requisito, de esa misma manera, el conjunto de programadores puede diferir en la estimación de costo de los requisitos y en esos casos ellos deben llegar a un consenso.
Las métricas de tamaño tienen el objetivo de estimar esfuerzo y plazos asociados al desarrollo de software (PUTMAN, 1992). Es una de las primeras y principales actividades relacionadas a las estimaciones de software. Y de acuerdo con las investigaciones realizadas por Usman; Mendes y Borstler (2015), El story points o el punto de función es la métricas de tamaño más utilizadas en proyectos ágiles.
El story point es una medida relativa donde el equipo decide cuánto vale un punto y basado en ese tamaño determina cuantos putos cada actividad posee.
Los Puntos de función ofrecen una medida estandarizada del tamaño funcional de los requisitos del usuario, independientemente de cualquier aspecto de implementación de estos en el software.
Aunque la técnica de puntos de función haya surgido mucho antes de los story points, ambos pueden ser utilizados de manera similar en proyectos ágiles. Se puede estimar las historias de usuarios, los sprint y el product backlog en puntos de función. La idea de velocidad (o productividad) también puede ser derivada: PF/sprint. Con esa información se puede entonces definir el número de sprints de un reléase.
La velocidad inicial se puede obtener más fácilmente con los puntos de función, pues es una medida estándar entre los proyectos.
La técnica de puntos de función provee una medida objetiva e incomparable, y así permite una visión táctica y estratégica sobre el desarrollo de software, análisis de viabilidad, benchmarking y puede ayudar a entender las variaciones de productividad y crecimientos del alcance entre proyectos. Es más adecuada cuando se necesita un factor de normalización para comparación de software y para medir la funcionalidad solicitada por el usuario, antes de los proyectos de software, de forma a estimar su tamaño y su costo.
Los proyectos de desarrollo están siendo más grandes y más complejos, desafiando los equipos a conocer y a determinar plazos de entrega realistas. Así, es imprescindible que los equipos realizan estimaciones que los permitan prever esfuerzo, plazos y costos de sus proyectos.
Es importante decir que las estimaciones no deben ser difíciles, costosas o ineficientes. Hechas de manera correcta pueden ser muy efectivas y ayudar a entregar valor a sus organizaciones. Métodos y métricas para estimaciones en su mayoría son aplicadas a un determinado contexto de desarrollo ágil con adaptaciones a fin de que se adecuaran a un proyecto en cuestión. Ósea, deben sufrir adaptaciones para que se adecuen al contexto de su proyecto, pues cada uno de ellos tiene características propias que pueden influenciar en el resultado de las estimaciones.
¿Trabajas con metodologías ágiles y realizas estimados de software? ¿Cuál método de estimación y medición de software utilizas en tu organización?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia informática y gestión de proyectos?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
ALVES, F.; FONSECA, M. Ideal day e priorização: Métodos Ágeis no planejamento. Engenharia de Software, Rio de Janeiro, 2008.
COHN, M. Agile Estimating and Planning, Prentice Hall, 1ª edição, 2005
HIGHSMITH, J. Agile Project Management: Creating Innovative Products. [S.l.:s.n.], 2009.
Muhammad Usman, Emilia Mendes, and Jürgen Börstler. 2015. Effort estimation in agile software development: a survey on the state of the practice. In Proceedings of the 19th International Conference on Evaluation and Assessment in Software Engineering (EASE '15). ACM, New York, NY, USA
PUTMAN, L. H.;WARE M. Measures for Excellence: Reliable Software On Equipo, Within Budget, Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 1992.
SHORE, J.; WADEN, S. The Art of Agile Development. [S.l.: s.n.], 2008.
Este artículo es cortesía de Fatto, Empresa de Consultoría y sistemas, en el te presentamos 4 técnicas de estimación de software que puedes aplicar en tus proyectos ágiles.
Estimar o no estimar
Muchos especialistas de las metodologías ágiles son seguidores del movimiento #NoEstimate, pues creen que no existe valor en estimar al trabajar en pequeños incrementos de software en sprints cortos. Sin embargo algunas investigaciones, como una realizada por CA Technologies, muestran que las entregas realizadas por equipos que tienen el hábito de realizar estimaciones, son más rápidas que las entregas de los equipos que no realizan ninguna estimación.
#NoEstimates puede ser una solución en algunos casos, por ejemplo, si su equipo ya es trabajar con pequeñas tareas con un equipo box establecido (2,3 días), o en el contexto de las estimaciones operacionales con ventanas de 2 a 4 semanas. Pero no puede ser aplicado de forma absoluta, en cualquier caso.
Las metodologías ágiles proponen un conjunto grande de técnicas para estimar y planear proyectos, principalmente en términos de modelos no basado en algoritmos, La mayoría de las técnicas de estimaciones ágiles se concentran en el uso de Historias de Usuarios.
Es importante recordar que no existe una mejor técnica, existe la que puede ser más adecuada a su propósito, o a su equipo o al proyecto/producto que usted está trabajando. Solo debemos estimar si eso fuera necesario para algo que traiga valor, y debemos siempre asociar las estimaciones a un propósito.
Dentro de las técnicas de estimaciones ágiles más conocidas tenemos el Planning Poker, Día ideal, The Planning Game y Métricas de tamaño, a continuación describimos cada una:
Es una variación de la técnica Delphi, que estima el esfuerzo exigido para concluir tareas y no proyectos interiores. Cohn (2005) y Highsmith (2009) proponen esa técnica para realizar estimaciones en el nivel del proyecto. funciona de la siguiente manera:
Las metodologías ágiles proponen un conjunto grande de técnicas para estimar y planear proyectos, principalmente en términos de modelos no basado en algoritmos, La mayoría de las técnicas de estimaciones ágiles se concentran en el uso de Historias de Usuarios.
Es importante recordar que no existe una mejor técnica, existe la que puede ser más adecuada a su propósito, o a su equipo o al proyecto/producto que usted está trabajando. Solo debemos estimar si eso fuera necesario para algo que traiga valor, y debemos siempre asociar las estimaciones a un propósito.
Dentro de las técnicas de estimaciones ágiles más conocidas tenemos el Planning Poker, Día ideal, The Planning Game y Métricas de tamaño, a continuación describimos cada una:
1.- Planning Poker
Es una variación de la técnica Delphi, que estima el esfuerzo exigido para concluir tareas y no proyectos interiores. Cohn (2005) y Highsmith (2009) proponen esa técnica para realizar estimaciones en el nivel del proyecto. funciona de la siguiente manera:
- Cada miembro del equipo tiene una baraja de cartas basada en una secuencia de Fibonacci modificada con algunas cartas adicionales, representando los puntos a ser atribuidos a cada historia de usuario.
- Uno a uno, el representante del cliente explica los requisitos descritos en la historia de usuario. Una vez que la historia es descrita, los miembros del equipo pueden hacer algunas preguntas para esclarecer su alcance.
- Después de eso, cada miembro, al mismo tiempo, muestra una carta de su conjunto con una estimación en puntos. Si estas son todas iguales, la historia recibe las estimaciones, si no, lo miembros que proponen la estimación más alta y las más baja explican sus puntos de vista y nuevas rodadas son jugadas hasta llegar a un consenso.
- Entonces, el equipo prevé la velocidad, que es el número de puntos que estos pueden entregar en una interacción. El cual puede ser obtenido por medio de datos históricos, una iteración de prueba o apenas una suposición. Con ese dato se puede establecer la longitud de la iteración. El numero de la iteraciones es obtenido por la división del número total de puntos por la velocidad. De esa forma, la duración de los proyectos es calculada multiplicando el número de iteraciones por el tamaño de la iteración.
Realizar estimaciones de forma colaborativa entre todos los miembros del equipo es muy válido para aumentar el comportamiento en la entrega, aclarar dudas, intercambiar ideas, esclarecer requisitos y percibir riesgos que usted no percibiría solo. Así, se evita la tendencia de las personas y organizaciones al subestimar el tiempo que va a necesitar para completar una tarea, mismo cuando tiene experiencia en las tareas similares.
Curso de Estimación de proyectos de software
¿Problemas para determinar las jornadas / horas para desarrollar requerimientos de software?
Inscribete en el curso de Estimación de proyectos de software.
Técnicas para medir y estimar el tamaño del software a partir de la complejidad de sus funcionalidades.
2.- Dia Ideal
Cohn (2005), afirma que un día ideal corresponde a cantidades de trabajo que un profesional de nivel senior con influencia en las tecnologías y herramientas involucradas consigue realizar en un día de trabajo sin interrupciones. Se trata de una estimación empírica, ejecutada por expertos para el desarrollo con base en una exploración adaptable (ALVES; FONSECA, 2008).
La velocidad es calculada a partir del número de horas que el equipo gasta para implementar un trabajo equivalente a un día ideal.
En caso el ítem pase un día de trabajo, es sugerido descomponer ese ítem en ítems menores que se consiga implementar en apenas un día.
Es más indicada para equipos que todavía no poseen experiencia en realizar estimaciones, pues es fácil de entender y aplicar.
Mientras tanto, al medir el tamaño de una actividad en días ideales, todavía estamos asociando la noción del tiempo, lo que no siempre es una buena estrategia. Diversos factores pueden influenciar ese tipo de estimación como: evolución de la experiencia del tiempo, conocimiento adquiridos, cambios de frameworks, entre otros. El mismo equipo ahora puede entender que una funcionalidad similar a una anterior puede ser concluida en menos días. La base de la estimación muda es así como el histórico es perjudicado.
3.- The planning game
El objetivo del planning game es maximizar el valor agregado y minimizar el costo del sistema a ser desarrollado. Esa técnica, propuesta por la eXtreme Programming, presupone que el cliente es conocedor del negocio, sabiendo relacionar y priorizar los requisitos del sistema de acuerdo con su valor agregado. Por otro lado, el programador es conocedor de las cuestiones técnicas sabiendo estimar el costo de la implementación de esos requisitos (SHORE; WADEN, 2008). Sus 2 reglas básicas son: (i) o cliente prioriza y (ii) o programador estima.
El juego comienza con el cliente relacionando los requisitos en cartas. En seguida, esas cartas son colocados en orden, de acuerdo con el valor agregado observado por el cliente. Por fin el programador debe estimar el costo de la implementación de cada requisito priorizado. Esos pasos son repetidos hasta que todos los requisitos hayan sido priorizados y estimados.
Durante el proceso, desarrolladores y clientes interactúan para resolver dudas sobre prioridades y estimaciones. Inicialmente, esta técnica fue utilizada para evaluar el trabajo en una iteración, pero también puede ser usada para realizar una planeación de una entrega (Release) completa.
Nuevamente la mayor ventaja está en la colaboración e interacción, en ese caso entre el cliente y el desarrollo. Con todo el cliente puede presentar varias partes interesadas, que pueden poseer diferentes intereses y así puede no ser tan fácil llegar a un acuerdo con relación al valor agregado de un determinado requisito, de esa misma manera, el conjunto de programadores puede diferir en la estimación de costo de los requisitos y en esos casos ellos deben llegar a un consenso.
4.- Métricas de Tamaño
Las métricas de tamaño tienen el objetivo de estimar esfuerzo y plazos asociados al desarrollo de software (PUTMAN, 1992). Es una de las primeras y principales actividades relacionadas a las estimaciones de software. Y de acuerdo con las investigaciones realizadas por Usman; Mendes y Borstler (2015), El story points o el punto de función es la métricas de tamaño más utilizadas en proyectos ágiles.
El story point es una medida relativa donde el equipo decide cuánto vale un punto y basado en ese tamaño determina cuantos putos cada actividad posee.
Los Puntos de función ofrecen una medida estandarizada del tamaño funcional de los requisitos del usuario, independientemente de cualquier aspecto de implementación de estos en el software.
Aunque la técnica de puntos de función haya surgido mucho antes de los story points, ambos pueden ser utilizados de manera similar en proyectos ágiles. Se puede estimar las historias de usuarios, los sprint y el product backlog en puntos de función. La idea de velocidad (o productividad) también puede ser derivada: PF/sprint. Con esa información se puede entonces definir el número de sprints de un reléase.
La velocidad inicial se puede obtener más fácilmente con los puntos de función, pues es una medida estándar entre los proyectos.
La técnica de puntos de función provee una medida objetiva e incomparable, y así permite una visión táctica y estratégica sobre el desarrollo de software, análisis de viabilidad, benchmarking y puede ayudar a entender las variaciones de productividad y crecimientos del alcance entre proyectos. Es más adecuada cuando se necesita un factor de normalización para comparación de software y para medir la funcionalidad solicitada por el usuario, antes de los proyectos de software, de forma a estimar su tamaño y su costo.
En Conclusión
Los proyectos de desarrollo están siendo más grandes y más complejos, desafiando los equipos a conocer y a determinar plazos de entrega realistas. Así, es imprescindible que los equipos realizan estimaciones que los permitan prever esfuerzo, plazos y costos de sus proyectos.
Es importante decir que las estimaciones no deben ser difíciles, costosas o ineficientes. Hechas de manera correcta pueden ser muy efectivas y ayudar a entregar valor a sus organizaciones. Métodos y métricas para estimaciones en su mayoría son aplicadas a un determinado contexto de desarrollo ágil con adaptaciones a fin de que se adecuaran a un proyecto en cuestión. Ósea, deben sufrir adaptaciones para que se adecuen al contexto de su proyecto, pues cada uno de ellos tiene características propias que pueden influenciar en el resultado de las estimaciones.
¿Y qué opinas tú?
¿Trabajas con metodologías ágiles y realizas estimados de software? ¿Cuál método de estimación y medición de software utilizas en tu organización?
¿Buscas más información de gerencia informática y proyectos?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia informática y gestión de proyectos?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Referencias
ALVES, F.; FONSECA, M. Ideal day e priorização: Métodos Ágeis no planejamento. Engenharia de Software, Rio de Janeiro, 2008.
COHN, M. Agile Estimating and Planning, Prentice Hall, 1ª edição, 2005
HIGHSMITH, J. Agile Project Management: Creating Innovative Products. [S.l.:s.n.], 2009.
Muhammad Usman, Emilia Mendes, and Jürgen Börstler. 2015. Effort estimation in agile software development: a survey on the state of the practice. In Proceedings of the 19th International Conference on Evaluation and Assessment in Software Engineering (EASE '15). ACM, New York, NY, USA
PUTMAN, L. H.;WARE M. Measures for Excellence: Reliable Software On Equipo, Within Budget, Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 1992.
SHORE, J.; WADEN, S. The Art of Agile Development. [S.l.: s.n.], 2008.
Doug Putman; Good Planning – Not Development Methodology – Is the Key to Successful Project Delivery , 2018.
No hay comentarios :
Publicar un comentario