Ajedrez - antoniomartel.com

Archivos por Etiqueta: Agile

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).

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.

Estadísticas de uso de SCRUM (2013)

Hace unos años, cuando comencé a interesarme por SCRUM, solo unos pocos habían oído hablar de este marco de trabajo y la mayoría desconocía sus principios. Ahora en cambio, cada vez con más frecuencia, oigo a más y más profesionales hablar de SCRUM y otras técnicas Ágiles y veo que cada vez con más frecuencia es un requisito imprescindible en muchas ofertas de trabajo. Incluso compruebo que alguna administración pública comienza a exigirlo en sus pliegos de prescripciones técnicas demostrando en el texto que no lo ha puesto solo de oídas sino que lo conoce bien y sabe lo que quiere de él.

Por todo esto he sentido la curiosidad de medir hasta donde están llegando estas metodologías ágiles. De eso va este post. La técnica estadística y los medios usados quizás no sean los más exactos, pero pueden ayudarnos a tomar el pulso al mercado.

En primer lugar he buscado palabras clave como SCRUM, Agile, TDD o PMP en los principales portales de búsqueda de empleo españoles y europeos para permitir su comparación. Este es el resultado:

En los datos de esta tabla sería necesario tener en cuenta el total de vacantes que cada portal publica para conocer su proporción real al compararla con otro país pero Monster no publica estas cifras. Necesario comentar también que en los resultados de búsqueda de ‘Lean’ también se incluyen resultados para ‘Lean manufacturing’ o ‘Lean process improvement’ (Ágil en todo caso)

La conclusión más directa que saco de estas cifras es que debo estar más atento al ‘Lean Software Development’ en el futuro.

Por último he usado Google Trends para mostrar las búsquedas realizadas desde el año 2004 sobre ‘scrum -espn -rugby’ (para eliminar los resultados del deporte), ‘pmp’ y ‘rup’. Esta es la gráfica:

Es curioso observar el descenso en el número de búsquedas de Rational Unified Process y de PMP. En cambio SCRUM sube mucho desde esos años aunque no conserva la misma aceleración que tuvo entre los años 2007 y 2010.

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).

Suscríbete