Ser ágil no es ser rápido

Hoy vamos a hablar de la diferencia entre agilidad y rapidez. Y porqué las metodologías ágiles, no tienen que ver con hacer un proyecto más rápidamente, y por tanto, con acabar antes. Cuánta confusión veo constantemente, generada precisamente por los desconocedores y los interesados en las metodologías ágiles. Los primeros, porque asocian automaticamente ágil=rápido, ya que la semántica nos induce a ello. Y los segundos, porque siembran la red de confusión en este sentido ya que tienen intereses profesionales y económicos al respecto. No hay mejor argumento de venta que el decir: ágil=rápido=barato.

Sinceramente, creo que hemos llegado a un nivel de información en la red en el que tenemos que empezar a dudar en la credibilidad de todo lo que vemos escrito, y darle un poco de trabajo a nuestro sentido común (que en ocasiones parece el menos común de los sentidos), y a nuestro sentido crítico.

Este artículo, viene inspirado en diversas entradas que estoy leyendo en las redes y que insisten consistentemente en sembrar la confusión entre estos conceptos. Y señores, no son iguales.

Podemos encontrar multitud de artículos en la web en que incluso defensores del agilismo, admiten la confusión entre estos dos términos. Pero vamos a tratar aquí de usar un poco de sentido común para entender un poco más el problema.

El concepto de rapidez en los proyectos ágiles.

En los proyectos ágiles, la medida del avance es la rapidez. Otra contradicción, por otro lado necesaria, ya que la única forma de saber cómo vamos y cuándo vamos a acabar, es utilizar esta métrica.

Al contrario que los proyectos que no usan metodologías ágiles, el estar abiertos al cambio hace que los requisitos estén permanentemente sujetos al cambio. La única forma de anticipar cuándo acabaremos, no está por tanto en medir el avance por requisitos, sino basarnos en la velocidad. La velocidad o rapidez, es por tanto, lo único cierto y medible. El resto: dependerá de cuántos cambios asumamos. Puede que ahora tengamos 20 historias de usuario. Pero pueden cambiar, y ser mañana 30, o 15...

Notemos aquí lo curioso del tema. Al hacer proyectos con metodologías ágiles, también necesitamos predecir y controlar cuándo va a finalizar el proyecto. La diferencia es la que estamos comentando, que no se basa en el cuánto (nº de requisitos), sino en el cómo (rapidez). Es por eso que los diagramas burndown chart son los principales referentes a la hora de conocer el avance y tratar de predecir cuándo tendremos el producto.

La rapidez en estos proyectos con metodologías ágiles será el número de puntos de historia de usuario (u otra métrica relativa) que realizamos por unidad de tiempo. De esta forma, si hemos estimado bien, podremos predecir el futuro.

El concepto de agilidad en los proyectos ágiles.

En las metodologías ágiles, el término agilidad o ágil está relacionado con la capacidad de adaptación al cambio. Pero no tiene nada que ver, e insisto en el NADA, con la velocidad del proyecto.

Agilidad, es la capacidad para adaptar el curso del desarrollo a la evolución de los requisitos y a las circunstancias del entorno (fuente: Navegapolis.Net, "Gestión de proyectos ágil: conceptos básicos").

Es decir, que la palabra "ágiles" en metodologías ágiles, no tiene nada que ver con rapidez del proyecto, sino con la adaptabilidad al cambio: la disponibilidad y facilidad para asumir cambios en el alcance (nuevos requisitos, o requisitos existentes).

¿Confusión interesada?

Llegados a este punto, empiezo a preguntarme si la confusión de términos no es interesada. A ver, no tengo nada en contra de los defensores del agilismo. Yo también defiendo el agilismo. Pero si lees este blog, sabrás que la cuestión no es defenderlo, sino defenderlo si aplica. No defenderlo porque sí. Todo dependerá del proyecto, equipo de trabajo, cliente, y metodologías actualmente en uso.

¿Porqué a los usuarios no les gusta el desarrollo ágil?

Parece que los de ITWorld se han dado cuenta de algo que hace tiempo que vengo diciendo y que por otro lado, no es más que lo que muchos venimos observando: que las metodologías ágiles están en un punto muerto, están en crisis. Y no porque estén mal, sino porque el excesivo bombo y platillo que se ha hecho en los últimos tiempos, han hecho que se usen para todo. Sólo falta que sirvan para lavar la ropa.

Hace poco, leía un artículo de ITWorld con un título similar a este que amigo lector, estás leyendo. Y es que el problema es que por un lado, hay que entender que las metodologías ágiles han subido como la espuma sobre todo por un motivo fundamental: gustan a los programadores. Pero al final, quienes han de pagar las facturas son los usuarios y los usuarios no ven con buenos ojos unas metodologías que presentan para ellos varios problemas:

 

Los usuarios no entienden las metodologías ágiles

Se usan metáforas complejas, conceptos muy novedosos y alejados del mundo de los clientes. El tener que participar para la revisión del producto final en cada iteración, puede ser demasiado para un cliente ocupado que por otro lado, ya ha gastado demasiado en un producto que nunca termina de estar.
El término ágil en en sí mismo contradictorio, ya que no siempre implica rapidez. En muchos proyectos, se prefiere abandonar términos y palabras de moda como "ágil" o "scrum", para centrarse en conceptos más simples y cercanos al cliente.

Los usuarios quieren saber cuánto les va a costar el software.

Claro, desde el punto de vista de los programadores, es distinto. Los programadores quieren hacer un software perfecto, que requiera el mínimo mantenimiento, y que acierte al 100% con la funcionalidad deseada. Y si esto es a costa de entregar las cosas más tarde (obviamente, el tiempo se invierte en realizar iteraciones que nos permitan hacer software cada vez más cercano a lo que querían los usuarios), no pasa nada. Pero el tiempo es dinero. Y el precio final, hay que conocerlo. Los clientes suelen funcionar con presupuestos. No tienen el dinero en un cajón y tampoco lo tienen detenido. Cuesta mucho esfuerzo para un cliente presupuestar el dinero requerido para ciertos proyectos, por lo que ahora no sirve volver al consejo de dirección y decirles: "oye, necesitamos más dinero pero no os preocupéis, porque quedan pocas iteraciones y creemos que terminaremos pronto".

Los usuarios gustan de lo predecible.

A los usuarios les gusta saber no sólo lo que les va a costar el software. Además quieren saber cuándo va a estar disponible, y mucha más información del producto y proyecto final. Que sea difícil de predecir, no deja de ser algo que es problema de los informáticos, no de los usuarios.

Al hablar de iteraciones, los usuarios ven desorganización

En ocasiones, la sensación del usuario es que los informáticos se han rendido a los caprichos de los clientes. "Nos adaptamos a los cambios", decimos. Pero los clientes ven desorganización y falta de control. Y ojo, no nos obsesionemos con que esto no es así. Yo no digo que sea así. Lo importante es que el cliente sí que lo ve así. Y con esto tenemos un problema (unos cuantos ya en este artículo).

Los usuarios quieren ver el final

La sensación que percibe el cliente es que las metodologías ágiles llevan a proyectos sin final. Al no existir una fecha cerrada de entrega, sólo tienen claro que se les va a entregar un producto que sigue los requisitos (al menos, eso les hemos vendido durante muchas iteraciones). Pero no saben cuándo. Y necesitan ver el final. Porque muchas veces, cuando tenemos una fecha planificada y nos retrasamos, el cliente se puede poner nervioso. Pero si estamos iterando, aunque nosotros como informáticos entendemos que nos estamos "acercando progresivamente" al producto final...resulta que el cliente no lo ve así. Es posible, muy posible que lo que el cliente vea es un "retraso iterativo", es decir, se están haciendo cambios, y más cambios, pero la fecha se sigue escapando de las manos.
"¿No eran esto metodologías ágiles? ¿No se supone que tendría que haber terminado esto ya?"

Los usuarios quieren control

Las metodologías ágiles son buenas en entregar cosas, pero el usuario quiere el control, no dejárselo a los programadores. La percepción del cliente es que por mucho que se le involucre en la revisión de historias de usuario que entran en cada iteración, y en la revisión del producto final de dicha iteración...su control es escaso. Y lo que es peor, hay una falsa sensación de control que se confunde con exceso de poder. El usuario tiene el poder de moldear el producto final...aunque esto le lleve a dar bandazos funcionales que en el fondo, no son el control. Porque el cliente no entiende como control añadir y quitar funciones.

¿Estamos ante el fin de las metodologías ágiles? Pues no lo creo. Yo llevo usando y conviviendo con ellas desde 1999. El problema es que han pasado de grandes promesas a grandes decepciones. Se puso demasiado énfasis y demasiadas esperanzas en las que prometían ser las grandes balas de plata del siglo 21. Y no han resuelto nada de lo que prometieron. Por supuesto, en los proyectos y clientes que encajan, las metodologías ágiles suponen una ventaja.

¿Qué podemos hacer con los usuarios? Pues como hemos visto en este artículo, los usuarios, el cliente, pueden no entender o incluso ser poco receptivos a las metodologías ágiles. Y es nuestra obligación RESPETARLOS. Sí, no podemos pedir respeto para nuestra profesión, y luego tratar de imponer cosas al cliente, faltándole al respeto. Tenemos que solventar estos problemas con el usuario a base de:

• Disciplina
• Uso consistente y coherente de buenas prácticas
• Educación
• No agobiar al cliente con conceptos ágiles. Usar terminología adaptada al cliente. Somos nosotros los que debemos esforzarnos en hablar su lenguaje, NO AL REVES.
• Formación
• Introducción progresiva de las técnicas ágiles, aun cuando los proyectos no usen metodologías 100% ágiles.
• Flexibilidad. Si el cliente no encaja técnicas ágiles, buscar sustitutos adecuados (sin obsesionarnos con si son ágiles o no, solamente en que sean adecuados al proyecto/cliente).

Sólo así lograremos credibilidad con nuestros clientes y éxito en nuestros proyectos.

El escalado y la falta de criterio

Hoy, vamos a ver el concepto del escalado. Y aunque os puede sonar un poco teórico, no sólo no es así, sino que por desgracia, se produce habitualmente en cualquier empresa.

En ITIL, se conoce al escalado (entre otros ámbitos) dentro del proceso de Gestión de Incidentes, al caso que se produce cuando algo no se puede resolver de forma inmediata, y es necesario recurrir a un especialista (léase experto, tanto a nivel de conocimientos, como a nivel de decisión o poder), para tomar decisiones que escapan a su responsabilidad.

Es decir, se han de dar una o varias de las siguientes condiciones:

• Ha de haberse producido un problema o incidente real
• Ha de producirse una situación que realmente no podemos resolver
• ...o bien ha de producirse algo que escape a nuestra responsabilidad.

¿Hasta aquí todos me habéis seguido? ¿Alguien se ha perdido? Espero que no.

Hasta ahora hemos hablado del escalado: qué es lo que debe cumplirse para que pueda producirse un escalado, y qué violaciones o negligencias se pueden realizar. Pero aún falta hablar de la otra mitad del post...la falta de criterio.

¿Cuál es el problema? Pues el problema viene cuando alteramos o manipulamos el escalado de una de las siguientes formas:

• No se ha producido el problema o incidente que mencionamos. También puede ser que lo estemos exagerando, o que ocultemos parte de la verdad en nuestro beneficio (o en perjuicio de terceros).
• No hemos intentado resolver la situación. La escalamos sin actuar, esperando que otro se ocupe de ello. También se conoce como "pasar el marrón" o "que le explote a otro".
• No actuamos a pesar de ser nuestra responsabilidad. Claro, si es nuestra responsabilidad, si o si, tendremos que actuar ANTES de escalar. El problema es cuando no queremos responsabilizarnos del problema, y por eso lo escalamos (aunque tal y como hemos visto, técnicamente no sería un escalado, ya que deberíamos habernos responsabilizado primero de ello).

¿Y tú? ¿Escalas?

¿Todavía quieres ser programador?

Hace cosa de un mes, estaba leyendo uno de mis blogs favoritos. Jeff Atwood es todo un elemento, una figura reconocida en la red. Y sin embargo, consiguió sorprenderme (otra vez). Y no es porque no sea un tema conocido y de candente actualidad. Me gustó su enfoque. Y es que como tantas otras ocasiones, Jeff daba en el clavo.

Yo, personalmente, me ocupo de recibir y guiar en su inicio a las nuevas incorporaciones que suelen llegar a mi oficina. Es algo esporádico, y que no suele gustar a mis compañeros. Bueno, en nuestro entorno, es difícil encontrar a gente que en general les guste hablar en público. Pero sigamos. A esas nuevas incorporaciones, les trato de contar brevemente lo que pueden necesitar, sobre la empresa y nuestro sector. Pero también me encuentro muchas veces (y no sólo en mi empresa actual, sino más bien en todas), programadores que no tienen claro cuál es su futuro.

Normalmente, todos tienen claro que quieren más en su futuro laboral: más dinero, más categoría profesional...Pero no tienen claro cómo es el negocio del desarrollo de software y la programación, y por tanto, tienen dudas. El mundo del cine, prensa y televisión nos vende como un negocio lleno de oportunidades, con gran cantidad de puestos de trabajo, y porqué no...¡guay!

Pero los jóvenes que llegan a trabajar recién licenciados, empiezan una carrera como informática, o incluso otras diferentes como matemáticas o físicas. Y me da la sensación de que no tienen claro en qué se han metido. Y no me refiero a que sea malo. Simplemente, que al ser una profesión nueva y en constante evolución, creo que no hay información realista disponible sobre el sector, enfocada a los pre-universitarios. O incluso a los universitarios.

Normalmente, en este sector, los recién titulados empiezan programando. Simplemente porque hay mucha más oferta en programación en por ejemplo ... administración de sistemas o diseño de circuitos.

El problema, es que la programación no tiene porqué gustar a dichos recién titulados. Y se nota en las preguntas que hago del tipo:

• ¿Sabes qué es un ciclo de vida?
• ¿Has oido hablar de la ingeniería del software?
• ¿Cuántos tipos de pruebas conoces?
• ¿Has automatizado pruebas funcionales?
• ¿Has programado en algún lenguaje?

Y por desgracia, las respuestas son decepcionantes. Y seguid sentados los que defendéis que tan sólo deben programar informáticos, y que el intrusismo por aquí, y que el resto no saben programar, y bla bla bla. Digo seguid sentados, porque las respuestas son igualmente decepcionantes para los que vienen de carreras como informática (técnica o superior). No digo que la universidad no sirva para nada. Digo simplemente, que hay una brecha significativa entre lo que prepara la universidad, y la realidad de las empresas y el mercado.

Y aquí es donde viene la pregunta. ¿De verdad te gusta programar? ¿Quieres ser programador? Porque te tiene que gustar. Porque lo tienes que disfrutar. Y porque de esa manera es como puedes mantenerte actualizado, y sobrevivir a proyecto tras proyecto (y empresa tras empresa).

Jeff Atwood va un poco más allá en su blog, y plantea una pregunta con trampa: "¿Todavía quieres ser programador?". Y es que Jeff plantea que por desgracia, hay que tener en cuenta que esta profesión, no todo el mundo es capaz de aguantarla toda su vida. ¿Quieres seguir siendo programador a los 30...40...50...60? Alguno comentará que no hay problema, que a los 2 o 3 años te hacen analista, y en otros tantos, jefe de proyecto. Sí...claro. Y yo soy Mickey Mouse.

En esta profesión, como en muchas otras, no todo el mundo puede ascender para siempre de forma continuada. La carrera profesional está ahí, pero cada 100 nuevos recién titulados no pueden ser mañana 100 jefes de proyecto. No es posible. Así que hay que prepararse en nuestro sector para una pregunta clave, que Jeff sabe plantear en su blog con acierto: "¿Todavía quieres ser programador?". Porque a cierta edad (no hablo de 40 o 50 años, sino mucho antes), la ganancia en productividad de la experiencia, se ve contrarrestada por otros factores. Y no nos engañemos, hay gente que simplemente, no tiene esa pasión y esas ganas de investigar y estar al día: volver de trabajar tras una jornada agotadora y ponerse a leer lo último (lenguaje, herramienta, metodología, etc.), probarlo, etc, etc.

Hay muchas posibilidades en nuestro sector, pero hay que saber moverse. Hay muchas posibilidades en las que aplicar nuestro conocimiento adquirido tras años y años programando, y disfrutando (o sufriendo) en múltiples proyectos y en múltiples empresas y clientes. Tanto si en el fondo no te gusta tanto programar como pensabas (o como decías), tanto como si llevas tanto programando que empiezas a estar ya saturado, existen opciones como:

• Gestión.
• Testing.
• Calidad.
• Analista
• Analista funcional
• Escritor técnico/documentación
• Implantador de software.
• Ventas

En muchos de estos roles, encontrar gente realmente conocedora de los entresijos de hacer software, es muy difícil. Así que ¿porqué no aprovechar tu experiencia y conocimientos adquiridos en algo más? ¿No es eso mejor que quedarse estancado en tu carrera, siguiendo con una programación que realmente nunca te gustó, o dejó de hacerlo hace mucho?

Y tú...¿todavía quieres ser programador?