28 de marzo de 2012

Cuando estimas, te equivocas




Va otro dato que muestro en  mi presentación ¡No estimarás! para demostrar con algunos estudios serios como nos va cuando estimamos. En este caso es un estudio muy conocido, el Chaos Report, del Standish Group.

En este estudio sobre miles de líderes de TI en el mundo entero, hacen varias preguntas sobre proyectos de TI, y en particular sobre los resultados en termino de costos. No hay mucho para comentar sobre este numero del 41% de desvió promedio sobre el costo estimado, habla solo!

De toda forma me parece que con o sin estudios, todo el mundo sabe (aunque no lo reconoce) que siempre nos va mal con las estimaciones de desarrollos de software. Y a pesar de eso seguimos estimando y creyendo en números exactos.

Eso suele generar muchas malas practicas, como por ejemplo "te sumo un 25% para poder bajártelo despuès", u otras que encontré referenciadas en el excelente paper: Estimation Games.

Tenes otros números crujientes sobre el tema?

En otros posts (después de mis vacaciones) seguiré mi encrucijada contra las estimaciones, gran mal del sigo XXI...

Estimar afecta tu productividad


Les comparto otro estudio que muestro en  mi presentación ¡No estimarás! para demostrar con algunos estudios serios como nos va cuando estimamos. En este caso es un estudio que se menciona en el excelente libro Peopleware. Si bien tiene sus años, me parece muy interesante lo que demuestran.

Con una muestra relativamente grande de proyectos y utilizando un algoritmo de Barry Boehm para calcular la productividad de desarrollo, demuestran el impacto sobre la productividad según quien o quienes estiman el desarrollo.

El resultado que me parece fantástico es que la mejor productividad se alcanza cuando nadie estima el desarrollo. ¿Que les parece?

27 de marzo de 2012

Cuando estimas, sos influenciable


Aprovechando varias charlas que tuve últimamente sobre estimaciones con colegas, quiero mostrar con algunos estudios serios como nos va cuando estimamos.

En mi presentación ¡No estimarás! mostraba el slide reproducido acá, para explicitar que somos influenciables cuando estimamos proyectos de desarrollo de software. El estudio mencionado es muy interesante, y para resumir la metodología, se mandaron a un universo interesante de empresas unas especificaciones de sistemas a desarrollar pidiendo unas estimaciones de esfuerzo. En los pedidos se introducían algunas variaciones para estudiar su impacto promedio sobre las estimaciones de las empresas.

En la imagen pueden ver los resultados que más me impactaron, con variaciones de entre 10 y 31% en las estimaciones según la cantidad de paginas de las especificaciones, la información de esfuerzo para desarrollar el sistema a reemplazar, la expectativa explicita de esfuerzo o de duración.

En resumen, si queres que tus proveedores estimen menos horas, mandale una especificación corta, diciendo que el sistema a reemplazar se desarrollo con muy poco esfuerzo y tirandoles expectativas de esfuerzo y duración muy bajos ;o)

21 de marzo de 2012

Segunda Reunión de la Comunidad Agile de Neuquén, Argentina


Próxima Reunión de Comunidad Ágil de Neuquén

Cuándo: Miercoles 28 de Marzo 2012, a las 18h
Dónde: Salón Azul del la Biblioteca Central - Universidad Nacional del Comahue - Buenos Aires 1400, Neuquén 
Tema: Scrum

Scrum es un marco para la gestión ágil de proyectos que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo posible. Nos permite rápidamente y en frecuentes ocasiones inspeccionar software funcionando (cada dos semanas o un mes) para adaptarlo mejor a las necesidades cambiantes del negocio. Los equipos se auto-organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad, y reflexionan periódicamente sobre mejores forma de trabajar. Cada dos semanas o un mes, se puede ver el software funcionando y decidir si liberarlo o seguir mejorándolo en otra iteración. 

En esta reunión Thomas Wallet hará una presentación de Scrum, y con la ayuda de todos los que quieran aportar o preguntar, se debatirán los aspectos importantes de su implementación en una organización. 


La reunión es gratuita, solo hay que inscribirse a través del siguiente link.

13 de marzo de 2012

Lo importante...

"Lo importante no es el proceso, sino tu proceso para mejorar el proceso" - Henrick Knibberg

5 de marzo de 2012

8 otras maneras de definir el Valor de Negocio


El concepto de Valor de Negocio (Business Value) representa el beneficio al cual accede una empresa / institución / grupo de usuarios cuando se disponibiliza una nueva funcionalidad de software para su uso productivo.

El Valor de Negocio suele usarse en las prácticas ágiles, entre otros factores, para priorizar un conjunto de funcionalidades, features o ítems en el desarrollo de un software. Priorización que a su vez permite balancear el alcance de un proyecto frente a las restricciones de tiempo, presupuesto, recursos y calidad.

Existen múltiples mecanismos para definir el Valor de Negocio, algunos muy conocidos y usados, pero también variaciones menos difundidas que pueden ser muy interesantes...


Los mecanismos más comunes para expresar el Valor de Negocio son en primer lugar mecanismos basado en un Conjunto Discreto de Valores, donde se asigna a cada ítem a priorizar un valor de negocio dentro de un conjunto de valores posibles. La escala más utilizada es la tradicional Alta/Media/Baja, con su variación MoSCoW (Must/Should/Could/Wont). A veces he visto usar el rango de enteros de 1 a 5, de 1 a 10, de 1 a 100, o sea generalizando un Rango de 1 a N.

Luego en algunos casos más aislados he visto el uso de un Ranking por Valor, donde por ejemplo lo más común es calcular para cada ítem algún indicador que compara el costo y beneficio del ítem, como por ejemplo el Return On Investment (ROI).

Finalmente en varios lugares pude ver como usaban un Ranking por Comparación, donde se define el valor de negocio de cada ítem en forma relativa, comparando con los otros ítems. La forma más conocida es cuando una persona o grupo de persona ordena en una secuencia única un conjunto de ítems por Valor de Negocio, tratando de comparar cada ítem con los otros para identificar su lugar en esta secuencia con criterios más o menos explícitos.

He podido experimentar con otros mecanismos o escuchar de otras formas de expresar el Valor de Negocio. Sin pretensión de establecer una lista exhaustiva, quiero compartir estos 8 otros mecanismos que me parecen interesantes o divertidos:

1. Valor de Negocio de los Conquistadores (variación de Conjunto Discreto de Valores)
Se usa el rango de valores: Oro, Plata, Bronce y Espejitos de Colores (!) para identificar el Valor de Negocio.

2. Priorizando con Naipes (variación de Conjunto Discreto de Valores)
Se prioriza un conjunto de ítems con una baraja de naipes, asignando una carta a cada ítem: el As tiene más Valor de Negocio que el Rey, que a su vez tiene más Valor de Negocio que la Reina, etc. La gracia es que hay una cantidad limitada de Ases, Reyes, etc.

3. Priorizando con Billetes (variación de Ranking por Valor)
Se determina el Valor de Negocio de un conjunto de ítems con billetes. Los participantes tienen una cierta suma en billetes (por ejemplo de Monopoly) y tienen que decidir cuántos billetes quieren poner para que se desarrolle cada ítem. Luego se ordenan los ítems por mayor monto. 

4. Ponderando Criterios (variación de Ranking por Valor)
Se identifican distintos aspectos críticos del Valor de Negocio, que se pueden evaluar con un valor numérico y que luego se ponderan.  Por ejemplo un cliente usa para cada ítem un formulario de preguntas para establecer el Valor de Negocio considerando por ejemplo aspectos de coherencia con la visión del producto, impacto en usuarios/clientes, madurez del pedido, etc. Cada respuesta arroja un valore numérico, que luego es ponderado para calcular finalmente un Valor de Negocio para el ítem. 

5. Alineándose a la Estrategia (variación de Ranking por Valor) 
Se trata de valorizar cada ítem en función de su aporte a los distintos objetivos estratégicos de la empresa. Participe en la definición del mecanismo para una institución bancaria: estos objetivos estaban armados en dos niveles: en el primer nivel se encontraban 8 objetivos estratégicos como orientación al cliente o cumplimiento regulatorio, con un segundo nivel con 19 objetivos como integración multi-canal o servicio de alta calidad. Para cada ítem se valoraba el aporte a los 19 objetivos segundarios entre 0 y 1, lo que luego permitía calcular un indicador de alineamiento a la estrategia (mediante una ponderación de los 19 objetivos de segundo nivel y 8 de primer nivel). Este indicador se usaba como Valor de Negocio. 

6. Costo del Atraso (variación de Ranking por Valor y Ranking por Comparación) 
En su post Prioritizing Features, Dean Leffingwell profundiza el concepto de priorización basada en el Costo del Atraso, del libro The Principles of Product Development Flow: Second Generation Lean Product Development. En particular propone calcular el Costo de Atraso estimando tres valores:

a. User Value (valor para el usuario) : es el valor potencial de una funcionalidad desde el punto de vista de sus usuarios. Leffingwell propone usar una estimación relativa para ordenar los items entre si para determinar el User Value. 

b. Time Value (valor en el tiempo): tambien se usa una estimación relativa para esta valor, que se basa en como el valor de una funcionalidad para sus usuarios disminuye con el tiempo. Leefingwell explica: 
"Muchas funcionalidades proporcionan un mayor valor cuando se entregan tempranamente y se diferencian en el mercado, que cuando ya se convirtieron en commodities." 
En particular la entrega de una funcionalidad puede perder todo su valor pasada una cierta fecha (por ejemplo una funcionalidad especial requerida para un promoción del día de la madre).

c. Information Discovery (descubrimiento de información): usando una estimación relativa se trata de ordenar items en función de como nos ayudarán a entender mejor el contexto, mitigar riesgos y/o prepararnos para explotar oportunidades en el futuro. 

Finalmente Leefingwell explica como sumar estos tres parámetros para calcular el Costo del Atraso, que nos puede servir como Valor de Negocio. Recomiendo leer el post completo, ya que tiene explicaciones más detalladas con buenos ejemplos.


7.
Beneficio & Penalidad
 (variación de Ranking por Valor y Ranking por Comparación)
Esta técnica propuesta por Karl Wiegers en First Things First: Prioritizing Requirements propone definir el Valor de Negocio de un conjunto de ítems por comparación teniendo en cuenta dos valores: el Beneficio relativo que aporta una funcionalidad a sus usuarios y la Penalidad relativa que sufre el usuario o negocio si no se incluye esta funcionalidad. Wiegers explica la necesidad de tener en cuenta ambos aspectos para priorizar, que no siempre van de la mano. Por ejemplo, no cumplir con una regulación podría generar una multa importante aún cuando el beneficio de la funcionalidad correspondiente es bajo. 

En el ejemplo que presenta Wiegers, se define el orden relativo de 10 funcionalidades para el Beneficio, y luego de nuevo para la Penalidad. Con una ponderación de 2 para el Beneficio y 1 para la Penalidad, se ve en la tabla siguiente la definición del Valor de Negocio (columna "Value %"):





8. Post-Its Silenciosos (variación de Ranking por Comparación) 
Esta variación puede servir cuando un grupo de personas tiene que ordenar un conjunto de ítems por Valor de Negocio por comparación entre los distintos ítems. La idea es escribir el titulo de un ítem por post-it y dejar que el grupo ordene los post-its en una única secuencia de Valor de Negocio. Es muy interesante observar el poder visual y manual de los post-its en este tipo de actividad. En particular que cada uno pueda visualizar (sin herramienta de por medio) el conjunto de post-its entero ayuda mucho en la priorización, y por otro lado mover manualmente un post-it arriba de otro también es un gesto muy comunicativo en un grupo. Si el grupo empieza a discutir mucho y no se pone de acuerdo, se puede recurrir a la consigna de no hablar durante el ejercicio. Y los resultados que vi en varias oportunidades son increíblemente eficientes, ya que  se suele lograr un consenso en muy poco tiempo. 



No estoy seguro de saber exactamente el origen de cada uno de estos mecanismos, pero quiero agradecer a Ariel Meter, Alejandro Nuñez García, Ilse Dierricks, Damián Famiglietti y Alan Cyment por habermelos comentado o enseñado.

Para cerrar, tengo un par de recomendaciones en cuanto al Valor de Negocio:
  • Me parece útil encontrar un buen balance entre el costo de la definición del Valor de Negocio y sus beneficios: un método muy complejo quizás sea imposible de implementar, y en el otro extremo una priorización muy liviana quizás no permita tener las justificaciones necesarias
  • Veo muy enriquecedor probar y combinar varios mecanismos. 
  • Me parece fundamental conseguir espacios donde experimentar y aprender a definir el Valor de Negocio. Por ejemplo el Business Value Game es un muy buen juego para trabajar los mecanismos de definición del valor de Negocio. 
¿Y en tu equipo, que mecanismo usan? ¿Conocer otros?

2 de marzo de 2012

Primera Reunión de la Comunidad Ágil de Neuquen, Argentina

El 1/3/2012 fue la primera reunión de la Comunidad Ágil de Neuquén.

Participaron 20 estudiantes y profesionales de distintos horizontes, todos con mucho entusiasmo.

Más información en este link.

Esperemos que siga por mucho tiempo esta comunidad!