Sunday, 25 August 2013

¿Por qué fallan los proyectos?

Razones hay muchas, seguro que parándonos a pensar un poco se nos ocurren unas cuantas, pero hay una que no siempre es tan obvia. Las estadísticas parecen indicar que si reducimos el tamaño de nuestro proyecto podemos aumentar en un 50% su probabilidad de éxito.

Un estudio indica que los proyectos de más de 1 millón de dólares tienen un 50% más de probabilidades de fallar que los proyectos de menos de 350.000 dólares. ¿Cómo no se nos había ocurrido antes? Los proyectos pequeños son más fáciles de gestionar y ejecutar que los grandes.

En proyectos grandes con duraciones superiores a un año tendemos a establecer las reuniones, hitos y revisiones con una periodicidad mayor, mensuales, bimensuales o incluso trimestrales. No es suficiente para tomar el pulso al coste del proyecto y comprobar si se está trabajando en la línea correcta, si se entrega lo que se necesita o si nos estamos desviando mucho de lo previsto.

Por otro lado, con proyectos de duración superior a un año o incluso menos se corre el riesgo de que hacia la finalización del proyecto, los objetivos y necesidades del negocio del cliente hayan cambiado con respecto a lo que le motivó a contratarlo. Si desarrollamos una aplicación para móviles ¿el mercado será el mismo dentro de 1 año cuando queramos venderla? Si quisiéramos hacer una aplicación basada en la legislación laboral actual ¿será útil dentro de uno o dos años cuando vea la luz nuestro producto? Parece mejor ver los grandes proyectos como 'programas de actuación' divididos en proyectos más pequeños, en los que con cada uno de ellos se entrega una parte del resultado global.

Yo añadiría un aspecto más: los proyectos grandes suelen planificarse y presupuestarse de ese modo porque con ellos se trata de conseguir objetivos complejos. Lamentablemente, con cada orden de complejidad adicional se multiplica el tiempo necesario para resolverla.

Si nos fijamos atentamente, el mundo IT parece ir en una línea muy distinta a ésta y trata de mantener los productos a desarrollar tan simples como sea posible. Hace unos años, los productos software más populares tenían menús llenos de características, funcionalidades y opciones de configuración (recordemos cada versión de MS Office o MS Outlook) En cambio, la mayoría de los productos actuales, los que residen en la nube o en nuestros dispositivos móviles, son mucho más simples: un par de casillas de texto y un botón para aceptar ¡no hay más!

David Karp, fundador de Tumblr, dijo acerca de esto: "Every feature has some maintenance cost, and having fewer features lets us focus on the ones we care about and make sure they work very well"

Me parece un gran planteamiento ¡Cuántas funcionalidades no habré desarrollado que me parecían muy útiles inicialmente pero que nunca fueron usadas!

Fuentes: thisiswhatgoodlookslike y startupquote.

Sunday, 18 August 2013

Más sobre estimaciones

Cuando se habla de estimaciones usando técnicas Ágiles hay algunas cosas que son difíciles de aceptar para aquellos que ya llevamos unos años planificando y calculando tiempos y fechas.

Podemos encontrar muchas técnicas de planificación Ágil: Planning poker, tallas de ropa para la clasificación de tareas (S, M, L, XL, etc.) o el Team Estimation Game pero, admitámoslo, son difíciles de integrar en un entorno de desarrollo tradicional y menos aún por los clientes de nuestros productos (por lo menos con los que he podido trabajar)

No estamos acostumbrados a ver a un equipo 'jugando a las cartas' para una sesión de Planning poker (yo por lo menos no lo estoy) Sí estoy, en cambio, de acuerdo con la filosofía que hay detrás de estas técnicas y creo que el hecho de que se estén haciendo cada vez más populares se debe, en parte, al intento de desterrar ciertas creencias sobre las estimaciones:

Estimamos mal

¿Podemos hacerlo bien? Estimar es hacer una predicción sobre lo que vamos a tardar en hacer una tarea o de los materiales que necesitaremos para hacer un trabajo. Cuando hacemos una estimación con una incertidumbre alta, como cuando lo hacemos en base a unos pliegos de contratación, más que una predicción es una apuesta.

Es obvio que necesitamos estimar. Debemos intentar predecir lo que pasará para poder tomar decisiones, pero a menos que hayamos hecho esa misma tarea muchas veces antes y que lo hayamos hecho con el mismo equipo y bajo las mismas circunstancias, tenemos que saber que hay altas probabilidades de equivocarnos (ver la explicación que da Rodrigo Corral sobre el cono de incertidumbre).

Cuanto más esfuerzo le dediquemos a la estimación más nos aproximaremos a la realidad

Estimar tiene un coste y es un coste alto. Cuando no conocemos el detalle de cada uno de los puntos del trabajo a realizar ¿tiene sentido que nos dediquemos horas y horas a dilucidar sobre tareas que no conocemos bien? Hagan un ejercicio por mí, cuando terminen su próximo proyecto revisen el tiempo registrado en cada tarea. Verán que en lo que estimaron 20 tardaron 100 y en lo que estimaron 100, con suerte, tardaron 20. Verán también que en otras tareas nadie imputó horas. Simplemente no fueron necesarias. En cambio sí hay muchas horas registradas en tareas que se añadieron con posterioridad y que nadie contempló en la estimación inicial.

Con ésta o aquella técnica estimaremos mejor

Técnicas de estimación hay muchas pero pocas serán tan útiles como la simple comparación del tiempo tardado en hacer proyectos similares, la des.composición del trabajo en tareas más pequeñas o el juicio de expertos (si contamos con varios mejor)

El hecho de utilizar complejas técnicas de estimación puede darnos una falsa sensación de seguridad sobre nuestra estimación y no haber aportado una fiabilidad mucho mayor. En cambio sí puede habernos hecho incurrir en un coste muy alto (ver punto anterior) e invertir un tiempo que podíamos haber utilizado mejor en otras cosas (como reducir la incertidumbre).


Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.



Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).

Sunday, 11 August 2013

Behavior Driven Development con Cucumber

Es habitual en muchos proyectos que nuestro cliente nos defina unas funcionalidades que quiere que nuestro producto le proporcione. Documentamos esas funcionalidades, las diseñamos y las desarrollamos pero cuando el cliente las ve, o peor aún, cuando se ponen al uso de todos los usuarios vemos que no satisfacen sus necesidades reales o contienen defectos. Es ahora cuando empezamos a retrasarnos en nuestras entregas, el presupuesto se nos va de las manos y encima de todo esto, el cliente no tiene lo que esperaba.

Para intentar evitar estos problemas, en lugar de hacer un gran esfuerzo de diseño antes de comenzar a desarrollar (Big Design Up Front) podemos utilizar la técnica Agile, Behavior Driven Development (BDD) que pregunta a los usuarios e interesados por el comportamiento que debe tener la aplicación antes y durante el desarrollo evitando fallos en la comunicación. La meta de BDD es la validación de los requisitos (construir la funcionalidad correcta) y no la verificación (construir correctamente la funcionalidad)

Tal como pude verse en el curso CS-169.1x Software as a Service (de edx.org, lo recomiendo siempre que lo menciono) podemos usar herramientas como Cucumber para dirigir el desarrollo por el comportamiento que debe tener la aplicación.

Captura de pantalla de Behavior driven development con Cucumber


Por ejemplo, si quisiéramos comprobar una funcionalidad (feature) de nuestro producto por la cuál una película añadida a la base de datos debería aparecer siempre en el orden correcto, escribiríamos:

Feature: movies when added should appear in movie list

Scenario: view movie list after adding movie

  Given I have added "Zorro" 
  And   I have added "Apocalypse Now"
  And   I am on the RottenPotatoes home page sorted by title
  Then  I should see "Apocalypse Now" before "Zorro"

Como podemos ver esto es lenguaje casi natural y por tanto fácilmente entendible por el cliente de forma que podrá validarlos e incluso él mismo podría escribir estos tests.

Para que un step como Given I have added "..." funcione tendríamos que escribir algo como esto:
Given /I have added "(.*)"/ do |title|
  steps %Q{
    Given I am on the Create New Movie page
    When  I fill in "Title" with "#{title}"
    And   I press "Save Changes"
  }
end

Given, And y Then son alias para el mismo comando y solo existen para hacer el texto más entendible por los humanos. A su vez tendríamos que crear las funciones para Given I am on ..., When I fill ... pero como nos podemos imaginar después de escribir unas cuantas funciones como éstas tendremos un repertorio de pasos (steps) con los que podremos escribir la mayoría de tests.

Ya saben, mejor testear que debuguear.