Chess - antoniomartel.com

Archivos por Etiqueta: ES

Ágil en todos los sentidos

Hace algunas semanas, una persona cercana a mí me pidió que le ayudara con la revisión de un trabajo académico que debía presentar a comienzos de septiembre.

Cuando le eché un vistazo, vi que había un gran trabajo hecho, se había leído muchísima documentación, notas y referencias a libros, artículos, ponencias y otra bibliografía estaban por todos lados y las hipótesis y las conclusiones eran claras. Sin embargo, aún era necesario dar cuerpo a todo el documento, revisar que se cumplían las normas de citación para cada elemento de la bibliografía y cumplir muchos otros aspectos.

Lo primero que hicimos fue tratar de saber qué quedaba por hacer para dar por concluido el trabajo. Elaboramos una lista de los puntos pendientes: revisión de citas, síntesis, abstract en inglés, palabras clave, relectura del documento para comprobar los errores gramaticales o de expresión, cumplir con los estilos de la institución académica, incluir mapas de localización, etc. Mucho por hacer y sólo quedaban unas semanas para entregar.

Después de preparada la lista, la priorizamos, colocando siempre en los primeros puestos aquellas tareas que eran imprescindibles para poder entregar el trabajo, seguidas luego de aquellas otras que sólo darían puntos extra o no eran imprescindibles para el aprobado.

Cuando la lista estaba avanzada nos dábamos cuenta de que necesitábamos añadir nuevos elementos a la lista. Preparábamos una nueva lista y volvíamos a priorizar siempre con la idea en mente de ‘Si tuviéramos que entregar mañana ¿qué tendríamos que tener hecho?’ A medida que íbamos eliminando elementos de la lista comprobábamos que las tareas eran cada vez de menor importancia y dificultad y la desesperanza del principio daba paso a las ganas de dar los últimos remates al trabajo.

Finalmente se completó el trabajo dos días antes de la fecha tope de entrega. El día anterior se dedicó a una última lectura y revisión entregándolo solo unas horas después.

Podemos llamarlo Ágil, GTD o simple sentido común pero ¡yo prefiero trabajar así!

Revista Proiectus

Hace algún tiempo algunos decidimos colaborar con la idea de Iván Tejera, al que algunos ya conocéis, en la creación una revista sobre la dirección de proyectos en Canarias.

Esta idea ha ido tomando forma, unos cuántos hemos escrito algún artículo, unos más largos que otros, para incluir en el contenido de esta nueva revista. Por algún artículo que he podido ver, todos me han parecido muy interesantes, así que recomiendo su lectura!

Su lanzamiento será en breve pero, mientras tanto, pueden ver una presentación de la revista en el siguiente Prezi:

¡Espero que les guste!

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

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.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad