Feed de Edgaragg

Artículos relacionados

Facebook Share

Share on facebook

Designed by:
SiteGround web hosting Joomla Templates
Estimando el valor del negocio PDF Imprimir E-mail
Escrito por edgaragg   
Sábado, 11 de Diciembre de 2010 17:13
Indice del artículo
Estimando el valor del negocio
Cómo estimo el valor de las historias de usuario
Estimación del valor por parte del cliente
Todas las páginas

Muchos modelos de programación ágil se basan en que el proceso de desarrollo de software debe ser un proceso orientado a entregarle el máximo valor al cliente.  Suena genial, pero... ¿Qué es lo que le da valor al negocio?.

 

Todo software nace por una motivo, por una necesidad del cliente, y esa necesidad siempre está asociada con el dinero.  Para resumir, una empresa solicita desarrollar un nuevo software porque necesita cubrir una de estas necesidades:

  • Aumentar sus ganancias
  • Reducir sus costos 

Directa o indirectamente, todos los requerimientos del nuevo software está orientado a perseguir este objetivo, aumentar las ganacias o recudir los costos.

Por supuesto, que existen otras necesidades que pueden motivar a que una empresa solicite un desarrollo, como por ejemplo:

  • Satisfacer a sus clientes
  • Permanecer en el mercado
  • Evitar riesgos
  • Uso de menos recursos
  • Uso eficiente de los recursos
  • Promoción de sus productos 

Pero estas motivaciones forman parte, directa o indirectamente de una de las de arriba.  Por ejemplo, satisfacer a los clientes es una forma indirecta de aumentar ganancias, mientras que el uso de menos recursos es una forma de reducir los costos.
 
Pues bien, esto es el valor para el negocio.  Si un cliente necesita que se desarrolle un sistema X para usar reducir sus costos, el valor está en esas historias de usuario que efectivamente permiten cubrir esa necesidad.  

Ahora bien, para que en cada iteración podamos entregar el mayor valor al cliente debemos conocer cuales son las historias de usuarios que tienen más valor.  De allí surge la siguiente pregunta:

 


¿Cómo estimo el valor de las historias de usuario?

 

La respuesta es sencilla.  No lo haces.  Quien le da valor a la historia de usuario es el cliente, es el quién te dirá cuales son las historias que más valor tienen para el y en base a eso es que se deciden cuales historias se desarrollan en la próxima iteración.

 

Lo que podemos hacer nosotros como desarrolladores es estimar el costo de la historia de usuario en términos de puntos de historia.  Un punto de historia no es más que una medida arbitraria para medir cuan grande y complejo es la historia.  

 

Cada programador tiene una velocidad de programación distinta, por lo que una mismo historia va a ser terminada en tiempos diferentes por distintos programadores.  Esta diferencia depende en gran medida en cosas como el conocimiento de la herramienta, experiencia previa en desarrollo de historias similares, etc. Sin embargo, la complejidad de dicha historia va a mantenerse igual independientemente de quien la programe.   Por esta razón, la historia de usuario no puede estar relacionada con el tiempo, ya que el tiempo va a depender de la velocidad de cada programador.  Es como comparar la distancia entre dos ciudades, la cual se va a mantener igual independientemente del medio de transporte que uses (caminando, bicicleta, etc.).  Dependiendo del medio de transporte llegarás más rápido o no.

 

No existe una regla estándar para decir "esto es una historia de usuario".  Esto es algo que resulta frustrante, ¿cómo puedo medir algo si desconozco el método para medirlo?  Una forma sencilla de hacerlo es buscar en la lista de historias de usuario cual es la más sencilla de todas y asignarle el valor 2, y en base a ella, estimamos el resto de las historias.

 

El problema es que estas medidas tienden a ser bastante imprecisas, (más o menos un 50%) por lo que hay que podemos realizar nuestra medida usando la serie de fibonacci.  Es decir, asignarle a cada historia un valor de 1, 2, 3, 5, 8, 13, 21... Como podrás observar usando esta serie no puedes asignarle un valor de 4 a una historia.  ¿Por qué? pues una estimación de 3 en realidad significa 3+/- 50% por lo que el una estimación de 3 se extiende del 2 al 5, y el 5 +/- 50% se extiende desde el 3 hasta el 8, por lo que el valor de 4 ya está contenido tanto en una estimación de 3 como en una de 5.  Así se simple.  

 

Es importante acotar la serie, por ejemplo, usar los números de la serie de fibonacci hasta el 21, esto con la finalidad de acotar la complejidad que el equipo va a manejar.  Si hay una historia de usuario que el equipo estima que es superior a 21, la historia de usuario debe descomponerse en historias más pequeñas a las que se le pueda asignar una complejidad.  Las historias resultantes deben descomponerse entonces de una forma tal que el cliente pueda asignarle un valor.  Si el cliente no puede asignarle un valor, entonces no estamos hablando de una historia de usuario, estaríamos hablando de una tarea. 

 

Hasta ahora hemos medido la complejidad de una historia, pero esto no tiene nada que ver con el valor que le da al usuario.  De hecho, existen historias con poco valor y alta complejidad, así como historias con mucho valor y poca complejidad.  

 

Un problema que he visto es que los modelos ágiles hablan de darle valor al cliente, pero al igual que las historias de usuario, no dicen cómo medirlas.  Veamos cómo.


Estimación del valor por parte del cliente 

 

Medir el valor para el cliente puede resultar bastante sencillo en ciertas ocasiones.  Esto ocurre principalmente porque la motivación subyacente es una sola.  Pero hay muchos casos donde hay varias motivaciones.  Por ejemplo, una página web puede ser motivada por:

  1. Promoción de productos
  2. Permanecer en el mercado
  3. Satisfacer a los clientes 
 
¿Cuál de las motivaciones anteriores es más importante?  ¿Una historia que satisface el punto 1 tiene acaso más prioridad que una que satisface el punto 2?  Hay casos donde puede resultar fácil determinarlo, pero otros donde no.  Por ejemplo no podemos decir que es más importante promover los productos que la satisfacción del cliente o viceversa.  No sirve de mucho promover nuevos productos si los clientes están insatisfechos, o tener clientes satisfechos pero que no conocen todos los servicios.  A lo que quiero llegar es que muchas veces es difícil distinguir cual tiene más prioridad que otro.  Para poder distinguirlo hay que conocer el negocio y quien conoce el negocio es el cliente.  Por esa razón, es él, y no el equipo de desarrollo quien decide cuanto valor le da a cada historia. 

 

El cliente, en conjunto con el equipo, van colocando una a una las historias de usuarios en una lista, donde la primera historia es la que más valor tiene y la última la de menor valor.  Se pueden colocar historias una al lado de la otra indicando de esta manera que esas historias tienen el mismo valor.  Esa lista que hace el cliente, es la que conocemos como pila de producto, es una lista ordenada por prioridad y la prioridad está dada por el valor que esa historia le da al cliente, es decir, la medida en la que permite satisfacer su necesidad (aumento de ganancias o disminución de costos)

 

Una vez que se tiene la lista de las historias de usuarios, se asigna un valor numérico siendo el más bajo la ultima historia de la lista y el más alto el primero.  Para esto usamos de nuevo la serie de fibonacci.  No tienen que asignarse los números de la serie de forma secuencial, pueden saltarse, lo que es importante es que se mantengan ordenados.

 

Con este valor, podemos crear un gráfico, parecido al burn-up, pero que se confecciona con las estimaciones de valor de la historia de usuario y las iteraciones.  Y en el que se puede ver el valor acumulado durante cada iteración.  Dicho gráfico luciría más o menos así.

 

 

Esto sirve para medir cuanto valor está aportando cada iteración al producto.  La gráfica empieza con un crecimiento lento puesto que en la primeras iteraciones se está construyendo las bases del producto, serían esas historias que no son las que más valor aportan, pero son historias de las que dependen las demás para poder llevarse a cabo.  Una vez que esas historias están listas, pasamos a programar las historias que agregan valor al negocio, observando un crecimiento rápido.

 

Una vez que se concluyen las historias que más valor aportan el gráfico empieza a decrecer lentamente hasta un punto en que su crecimiento es muy lento, lo que quiere decir que estos incrementos no están aportando valor al cliente.  Llegado a este punto puede darse por concluido en cualquier momento el proyecto.  Esta decisión depende del cliente.

 

Una vez determinada la complejidad para cada historia de usuario, podemos obtener una relación valor/complejidad que nos indicaría cuanto valor aportaría cada punto de historia para una historia dada.  Aunque al equipo este valor no significa nada, para el cliente le puede ser de mucha ayuda, ya que se puede hacer una idea de cuanto trabajo puede requerir una historia para completarse y en base a este dato, decidir cuales historias se programan en una iteración dada.

 

También puede ayudar al cliente a tener una idea de cómo será el retorno de su inversión.  Estamos hablando de que el cliente es quien pone el dinero para el desarrollo, por lo que le puede interesar saber cuales historias le aportan el mayor valor con la menor inversión de esfuerzo, y como dije anteriormente, ayudarle a decidir cuales historias entran en una iteración.

 

 

 

 

Actualizado ( Sábado, 18 de Diciembre de 2010 17:17 )