Feeds:
Entradas
Comentarios

Archivos de la categoría ‘Agile’


Hola a todos, aquí vuelvo a la carga con un nuevo post para desgracia de mis minoritarios lectores. El tema de los proyectos cerrados ya lo traté en otro post, explicando que en realidad el pensar que un proyecto está cerrado en alcance, tiempo y recursos es algo totalmente utópico. Sin embargo debido al ambiente de desconfianza que existe en nuestro sector entre clientes y proveedores, surgió esa mala bestia, el contrato cerrado, causante de tantos entuertos en nuestra profesión. Dado que ejercemos nuestra profesión en un ambiente hostil, nueve de cada diez veces vamos a encontrarnos en un proyecto con contrato cerrado. Los proyectos con contratos cerrados se han puesto siempre como ejemplo prototípico de un entorno donde Scrum y otras metodologías ágiles no podrían funcionar. Como este tipo de proyectos son los más comunes, muchos han usado esta aseveración para defender la postura de que trabajar en modo ágil es imposible en España (y alrededores). Yo no estoy para nada de acuerdo con esto, la verdad es que lo considero totalmente desacertado y un síntoma de lo mal que se está entendiendo el movimiento ágil. De hecho mi postura es radicalmente opuesta: los proyectos cerrados constituyen nuestro mejor aliado para implantar el modelo ágil en la empresa. O sea, no solo no pienso que el proyecto cerrado impida la gestión ágil, sino que es un aliado a la hora de hacer ver a nuestro entorno lo positivo que es Scrum. Todo pasa por una pequeña revelación: scrum es más eficiente que la cascada, sobre todo en proyectos cerrados. Aunque ya comenté algo al respecto en mi post anterior, quiero dar más detalle sobre mi postura a este respecto. Lo veremos a lo largo de este post, pero no os preocupéis, si se hace muy largo pienso dividirlo.

Como sabréis Scrum es un proceso iterativo, que al igual que cualquier otra metodología iterativa, divide la gestión y control del proyecto en pequeñas fases o iteraciones (sprints en scrum). Al final de cada pequeña fase se inspecciona el progreso del proyecto y se ajustan las planificaciones y la estrategia de desarrollo. El modelo clásico de cascada no es iterativo y se basa en una planificación y diseño detallado, tras la cual se realiza la construcción, y el producto no es inspeccionado y revisado por el cliente hasta el final. Obviamente el realizar la planificación y diseño detallado al principio es un error tremendo, ya que es cuando menos información tenemos, los requisitos están menos claros y la incertidumbre es mayor, con lo que seguro que nos vamos a equivocar en la planificación, y por mucho.

Es obvio, que una metodología iterativa es más eficiente que la cascada. En el caso de un contrato cerrado nadie nos libra de un análisis de requisitos con cierto detalle y una estimación afinada en la fase de preventa. Esto es intrínseco al modelo de contrato cerrado y concurso, necesitamos saber si podemos ir o no a presentarnos al proyecto y por cuánto dinero. Ya dije que esto es lo peor que podemos hacer, entonces, ¿de qué nos valen las iteraciones en un contrato cerrado? Simplemente para tener feedback frecuente. Esto redunda en un mayor control, por ejemplo:

  • Si el proyecto va muy mal, se puede detectar pronto, y cancelarlo con el menor coste para ambas partes. Algunos clientes (no todos) os agradecerán esta sinceridad e interés por no hacerle perder más dinero y tiempo.
  • Si el proyecto va muy mal, no se puede cancelar pero se puede retrasar, tal vez podáis negociar con el cliente un plazo extra de tiempo. Sí, sí, es contrato cerrado, pero el proyecto real no, en la práctica si el time-to-market no es muy crítico se puede negociar un retraso (aunque no te lo paguen).
  • Si el proyecto va muy mal, pero ni se puede cancelar ni retrasar, tendréis que usar la técnica de “más madera”. Si el cliente es bondadoso, podéis pactar un coste extra, aunque sea un contrato cerrado.
  • Si el proyecto va mal, pero se puede salvar, tomar las medidas correctoras pertinentes.
  • Si alguna circunstancia o requisito cambia os podéis enterar y aceptar el cambio de forma controlada. Sí, el contrato es cerrado, pero si el cliente decide cambiar un requisito o simplemente hubo un malentendido, lo correcto es aceptar el cambio de forma negociada. En caso contrario correis el riesgo de acabar el proyecto con éxito pero que no haga lo que quiere el cliente, y perder a éste de cara a futuros proyectos. Además, también las circunstancias y contexto del negocio cambia y no se pueden controlar, sería absurdo ponernos la venda en los ojos y pensar lo contrario.

O sea, que al planificar y cerrar la cosas al principio (contrato cerrado) estamos condenados a fallar. Pero usando una metodología iterativa podemos fallar por menos al controlar mejor el proyecto, e incluso aceptar cambios en el alcance si fuera necesario (aunque el contrato sea cerrado). También evita que andemos a ciegas hacia nuestra perdición. Estas ventajas están claras incluso en clientes muy tradicionales. La mayoría de ellos ya usan esquemas de trabajo iterativos, ya sea de forma explícita o implícita. En el último caso se suele tener un plan waterfall, pero muchas reuniones de seguimiento e hitos a intervalos regulares que implementan de facto un sistema iterativo. Otra variante se produce cuando el cliente divide un proyecto grande en múltiples fases, cada una de menos de tres meses, e intenta realizarlas de una a una en formato contrato cerrado. Desde el punto de vista del cliente esto es un ciclo de vida iterativo, desde el punto de vista del proveedor es simplemente una sucesión de concursos y contratos cerrados waterfall. Esta última forma de trabajar es bastante perversa, ya que no asegura al proveedor que realiza una fase del proyecto su participación en la siguiente, con lo que el incentivo por parte del proveedor para invertir en calidad disminuye, al no saber si se encargará de la evolución o mantenimiento prevista en la siguiente fase.

Como vemos el ciclo de vida iterativo es una mejora en proyectos cerrados, pero no es suficiente. Afortunadamente scrum no es sólo iterativo, sino incremental. En un proceso iterativo e incremental, al final de cada iteración no sólo se obtiene feedback de la marcha del proyecto, sino que se realiza una entrega parcial, que representa un incremento del grado de avance del proyecto. Existen varios procesos de desarrollo iterativos e incrementales, pero no todos ellos son ágiles. Los procesos iterativos e incrementales ágiles, como Scrum, entregan incrementos de funcionalidad, mientras que los demás entregan incrementos de construcción.

Un incremento de funcionalidad consiste en añadir nueva funcionalidad al sistema, que sea directamente útil al usuario, y que esté lista para entrar en producción, al final de cada iteración. Scrum sigue esta filosofía. El objetivo de cada sprint es entregar valor adicional al cliente, en forma de Product Backlog Items (PBIs) implementados y listos para entrar en producción. Por valor entendemos la utilidad, funcionalidad y/o rentabilidad de cada funcionalidad entregada. Los PBIs son unidades de funcionalidad, convenientemente analizadas y con una estimación de valor y coste. Pueden tener forma de historias de usuario o de casos de uso, según lo que se prefiera, pero eso no es lo importante. La estrategia de Scrum consiste no sólo en entregar valor al final de cada sprint, sino ir implementando los PBIs por prioridad, de forma que se entreguen primero los más importantes. La prioridad se calcula equilibrando el valor con el coste de cada PBI, de forma que dado el mismo coste se entreguen primero las de mayor valor.

La mayoría de las metodologías iterativas que se usan en el mundo empresarial no entregan incrementos de funcionalidad, sino incrementos de construcción. Un incremento de construcción consiste en entregar uno o más artefactos del proyecto al finalizar cada iteración. Ejemplo de tales artefactos son: documentos de diseño, esquema de BBDD, scripts de carga, capa de persistencia, pantallas. Estos artefactos, aunque necesarios para completar el proyecto, no aportan funcionalidad por si mismos. Estamos acostumbrados a que en cada hito, tengamos que entregar el documento de análisis, el de diseño, las tablas, etc. En el fondo esta forma de trabajar no es más que añadir un control iterativo a un ciclo de vida de cascada, de forma que cada iteración haga énfasis en una única fase de la cascada.

Otra diferencia importante entre los dos enfoques incrementales es en las reviews. En Scrum en cada sprint review se interactúa con el cliente, usuario y/o representante ya que vamos a enseñar funcionalidad. En esta reunión el cliente acepta o rechaza la nueva funcionalidad y nos proporciona un feedback de calidad sobre la funcionalidad del sistema. En el enfoque de entrega de incrementos de construcción no es posible interactuar con el usuario ni realizar aceptaciones de funcionalidad, ya que se entregan artefactos técnicos que son revisados por técnicos del cliente. En vez de aceptaciones de funcionalidad, se realizan aceptaciones de componentes tecnológicos. En este sentido no podemos tener feedback sobre la funcionalidad del sistema hasta bien tarde en el ciclo de vida de la aplicación (pruebas). Esto es totalmente ineficiente ya que el peor momento para detectar un error es al final, que es cuanto más caro es repararlo. También es bastante malo desde el punto de vista de la transparencia, ya que el usuario real no ve el sistema funcionando hasta el final. En realidad un enfoque iterativo incremental tradicional sigue siendo tan opaco para los usuarios como una cascada, ya que éste no puede interactuar con el sistema hasta el final. Esta forma de trabajar es un poco perversa, ya que al fin y al cabo, lo que el cliente conoce bien es la funcionalidad, y nos ha contratado porque sabemos de cosas técnicas. Lo lógico es que el cliente revise la funcionalidad, que es de lo que sabe y lo que le interesa, y que confíe en nuestro saber hacer. Tal vez esa confianza en nuestro saber hacer se ha visto envenenada por la moda de contratar “personal poco cualificado” y ofertar muy barato. Dicho todo esto, es obvio que Scrum proporciona una mayor transparencia y detecta los errores antes que una metodología iterativa incremental tradicional. Además proporciona resultados tangibles antes que un enfoque tradicional.

Como resumen, el hecho de aceptar un proyecto cerrado siempre conlleva un alto riesgo de no cumplir con las expectativas del cliente. Sin embargo scrum hace una mejor gestión que la cascada y otras metodologías no ágiles, al permitirnos:

  • Mitigar el riesgo de la estimación errónea. Si nos pasamos en la estimación al menos habremos entregado resultados tangibles y no artefactos “tecnológicos”.
  • Mitigar el riesgo de un lanzamiento prematuro debido a presiones de mercado. Si nuestros competidores lanzan su producto antes que nosotros, podemos ir a producción antes de lo esperado, ya que al menos tenemos algo con lo que ir a producción, en vez de documentos “técnicos”.
  • Ayudarnos a estimar mejor, al refinar mediante mejora continua nuestros procesos y usar timeboxing para que el proceso sea más predecible.
  • Ayudarnos a dar un precio más competitivo. De nuevo el timebox nos ayuda a enfocar nuestros esfuerzos y la mejora continua a aprender ser cada vez más productivos.
  • Mostrar al cliente el estado real del proyecto y entregarle valor de forma continua de forma que éste pueda empezar a confiar en nosotros. Tal vez el siguiente proyecto no sea tan cerrado…
  • Mitigar el riesgo/coste de cometer un error en el análisis funcional o aceptar un cambio. Detectar los errores cuanto antes es la forma más barata de solucionarlos, aceptar cambios de nuestros clientes es vital. Todo esto es posible ya que al final de cada sprint se puede mostrar funcionalidad, no tecnología, y por tanto recibir feedback del usuario.

En definitiva scrum falla mejor que otras metodologías a la hora de gestionar un proyecto cerrado. Los puntos claves que aporta scrum para conseguir todo esto son: transparencia con el cliente, mejora continua, iteraciones (sprints) y entrega incremental de funcionalidad real (valor).

Simplemente probad a gestionar vuestros proyectos cerrados con Scrum o similar, no es necesario que el cliente lo sepa de forma explícita. Seguro que la vais a pifiar (es un proyecto cerrado al fin y al cabo) pero lo haréis mejor que si hubierais usado la metodología “de toda la vida”, y vuestro cliente se sentirá mejor tratado y más satisfecho (pero no del todo). Construyendo pequeños éxitos, y poco a poco, vuestro cliente ganará confianza y podréis ir planteando otro tipo de relación, basada en la colaboración. Con el tiempo llegará el día que le podáis contar que usáis una cosa llama “agilismo”…

Ahora ya lo sabéis, no tenéis excusa, el agilismo va a llegar… incluso a los proyectos cerrados.

P.S. Uff, se ha terminado mi timebox de 2000 palabras, suficiente por hoy. En el siguiente post más sobre este tema, esta vez con dibujitos…

Read Full Post »


Hola a todos, lamento no haber podido escribir antes, pero tenía bastante trabajo acumulado y el deber me llamaba. Aprovecho que me iba a ir de fiesta esta noche y que al final no, para hacer algo útil con mi tiempo y escribir este post. Espero daros una crónica de lo que fue mi participación en la AOS2010, espero que un poco distinta y un pelín más crítica ;-)

Asistí junto con @ialcazar, @antoniodfr y @mcberros. Llegamos tarde, con la sesión de votación a mitad y un poco desubicados la verdad. Yo pensaba proponer una sesión llamada “los frameworks crean zombies” pero un tal Xavi Gost(@Xav1uzz) se me adelantó. Menos mal, porque con eso de llegar tarde, y ser mi primer open, estaba un poco cortado de verdad (a pesar del pequeño intento de @jmbeas de que saltara a la palestra). Mi compañero @antoniodfr no tenía muy claro si el formato open space iba a ser bueno o si por el contrario iba a degenerar en el caos. Al final se rindió al concepto de autoorganización y salió enamorado del concepto open.

Después vino una noche de parranda por los bares de Barcelona. Conté con la colaboración inestimable de Ramón Clariso y el inefable Aleix Cerecedo. Los bares al ver a una horda de agilistas por la noche de Barna iban cerrando a cal y canto, para que no entráramos en ellos ¡ y es que somos peligrosos ! Al final acabamos en un asador cerca del barrio de Graçia (¿está escrito bien?) donde tuvimos una animada charla con Roberto Canales(@rcanalesmora). Después el pobre Aleix tuvo la difícil tarea de buscar un bar en dicho barrio donde cupieran 40 personas. El pobre no dejaba de mirar atrás acojonado y diciéndome: “porque eres tu Enrique, sino salgo corriendo :-S “. Al final su plan “A” fue acertado y el sitio donde queríamos ir estaba vacío, pero en cuanto entramos quedo lo petamos. Desgraciadamente no servían mojitos, (mea culpa @kinisoftware) y lo peor es que no quedaba Moritz. Nos conformamos con gin-tonics y tercios de cerveza. A la llegada al hotel puse el despertador, este me informo amablemente que sonaría en sólo 3 horas, y cuando me quise dar cuenta ya estaba desayunando en el campus La Salle. Enrique, al lío.

Vayamos a las sesiones a las que asistí:

  • Coaching. Una sesión excelentemente moderada. Hubo un intercambio sano de ideas y experiencias, bastante refrescante. Allí me llamó la atención la intervención de Emma (¡dios, no se su twitter, que alguien me ayude, que quiero seguir a esta chica), según entendí es ScrumMaster quemada de muchas guerrillas en su empresa.
  • Software Craftsmanship. Propuesto por Xavi Gost y @ecomba. Bueno, nos contaron los principios del manifiesto y un poco como funcionaban, todo lo de los maestros y aprendices y demás. Me he leído el manifiesto y puedo decir que suscribo todo lo expuesto en él, ¿quién no podría estar de acuerdo? Es como los diez mandamiento, que aunque no seas judeocristiano, es probable que los pudieras firmar sin cargos de conciencia. Por ejemplo, el tema de educar mediante un sistema de maestro/aprendiz es obviamente la mejor manera de transmitir conocimientos. Por otro lado me sigue sin gustar el nombre o la analogía, ya que en el desarrollo de software no se construye nada. Los artesanos construyen pero en el software no se construye, se diseña. El que construye es el compilador. Por eso me sigue gustando más hablar de nosotros como ingenieros, y no como artesanos, porque nosotros diseñamos y el compilador construye. No veo por que el término ingeniero debe ser “evil”. En fin, es un tema de nomenclatura, porque a nivel de valores, que es lo que importa, me encuentro muy cercano a ésta forma de pensar. Un punto negativo en esta sesión fue que la moderación no fue muy efectiva, hablaron sobre todo Xavi y @ecomba, y la charla fue muy unidireccional (como me señaló alguien que no quiero nombrar).
  • La batalla de los frameworks. De nuevo con Xavi Gost, @ecomba y con la colaboración inestimable de @rcanalesmora en el papel del malo maloso de la película. Yo me lo pasé pipa y participé bastante, sobre todo para meterle caña a @rcanalesmora. Yo en esta estoy del lado del frente artesano y creo que los frameworks son armas de destrucción masiva a manejar con cuidado y mucha responsabilidad. El bando opuesto defendía que los frameworks te permitían contratar “personal poco cualificado” (a.k.a. “monos”) en masa para hacer los proyectos y ganar mucho dinerito calentito. El señor @rcanalesmora hizo una interpretación torticera de unas palabras que le dije la noche anterior, entre vinitos, y yo le respondí dándole cañita brava (pero con cariño).
  • Manipula. La señorita @rlaina nos dio una charla sobre el tema seguido de un debate. Tanto Emma como @jmbeas contaron sus problemas, que se parecen sospechosamente a los que tenemos todos. El problema es que cuando el debate se ponía interesante se nos acabó el tiempo y ¡ rompimos el timebox ! Cometimos el feo pecado de extender la charla a pesar de los heroicos esfuerzos de @amaliahern de salvar nuestras almas. La verdad es que el debate estuvo interesante, pero nos saltamos media comida.
  • Como tratar con locos paranoicos. Propuesta y dirigida por Xavi Albadalejo fue una de las charlas más interesantes. Usando la técnica de identificación de causas raíces analizamos porqué muchas personas recurren al Command & Control (a.k.a. “aquí se hace lo que yo digo”). Llegamos a la conclusión de que existían dos tipos de jefes autoritarios: los paranoicos y los desconfiados. Si te toca el primer tipo es mejor plantearte si dejar la empresa, ya que es una señal de que la cultura empresarial fomenta este tipo de personas como jefes. Si te toca el segundo tipo entonces hay esperanza. Lo curioso es que las técnicas que fuimos sacando para desactivar el ordeno y mando de un jefe desconfiado es simplemente… usar Scrum Efectivamente las técnicas propuestas por Scrum tienen como resultado aumentar la transparencia y esto acaba por aumentar la confianza. Muy enriquecedora esta sesión.
  • Diseño ágil. En esta sesión estuve bastante activo. Hablamos de como conseguir un buen diseño OO sin tener que hacer un diseño detallado al principio del desarrollo, práctica que va en contra de los principios ágiles. Yo conté mi experiencia, de que usando sólo TDD junto con un refactor continuo y agresivo, llegas a un diseño bueno. Sólo necesitas hacer al principio un pequeño diagrama de “cajitas” con la arquitectura de alto nivel. El detalle de cada “cajita” te la da el TDD+Refactor. También hice notar que esto por otro lado no te resolvía aspectos como el rendimiento y la seguridad, que tal vez sí hay que planearlos más de antemano. Algunos compañeros comentaron que ellos ponían pruebas de rendimiento en el build nocturno y que pedían a un experto en seguridad, que atacara el entorno de demo cuando el quisiera. Una aportación muy interesante. También se habló de las revisiones de código, y hubo unanimidad en que eran necesarias. Yo sostuve que la programación por parejas era equivalente a una “revisión de código continua”. Un asistente comentó que además ellos tenían un “moderador de proyecto”, que era externo al proyecto y neutral al equipo, que hacía revisiones de código. A mi me pareció una excelente idea. Ellos usaban un plugin de JIRA llamado Crucible, para hacer dichas revisiones. Lo tengo que probar. Todos estuvimos de acuerdo en que el UML era bueno para hacer bocetos de ideas y arquitectura de alto nivel. También consensuamos que había que hacer toda la documentación técnica necesaria para hacer el mantenimiento del sistema, pero por lo general, cuando el código está bien diseñado, éste es bastante legible, y necesitas menos documentación de la necesitarías normalmente.

Por supuesto hubo otras charlas, que supongo cada uno habrá comentado en su blog. Finalmente vino la retrospectiva, dinamizada, de forma genial, por el señor Ariel Ber (no se si tiene twitter). Se habló de las “AgileGirls”, de hacer un “Scrumbar” y de hacer el siguiente Open más grande. En concreto yo creo que una mejora para el AOS2011 debería ser que la gente participara más, me explico. En muchas sesiones la charla estuvo dominada por los “pesos pesados” y los “gurus” y vi a la gente un poco cohibida, lo que creo que impidió que se generara más debate. Yo mismo soy culpable de ese pecado y en muchas sesiones me hubiera gustado participar más, pero no me atreví. Tal vez en el siguiente open solucionemos eso.

Por supuesto hubo una segunda noche de fiesta, comimos en el “divinus”  y terminamos trasegando mucha cerveza y sangría en el “Ovella negra” (¿?) mientras @ydarias y compañía hacían lobby para que la siguiente AOS se celebre en Canarias (¡yo voto por vosotros!)

Quiero hacer mención especial de @amaliahern, que estuvo de fotógrafa e iba de sesión en sesión procurando que se cumpliera el horario. También creo que Ariel Ber estuvo excelente durante la retrospectiva, como comenté anteriormente.

Por último quiero poner mi opinión sobre un debate “silencioso” que se produjo de forma soterrada durante muchas sesiones: certificaciones sí, certificaciones no. De hecho hubo una sesión explícita sobre las certificaciones. Yo personalmente me he certificado CSM con Alan Cyment y Ariel Ber. Os recomiendo su curso, aprendí más sobre el espíritu de Scrum que en cualquier libro. Entiendo perfectamente a los que les da miedo que las certificaciones se perviertan y terminen siendo un modo fácil para que las grandes empresas se pongan el sellito de ágil y vendan por ahí lo que no son. También se corre el riesgo de que el agilismo quede preso de grandes consorcios certificadores. Sin embargo queda claro en todos sitios lo que significa ser CSM: que simplemente has dado un curso y que has comprendido lo que es Scrum, nada más. De comprender lo que es Scrum a practicarlo de verdad hay un mundo. De hecho la certificación que dice que usas Scrum con éxito no es la CSM, sino la CSP, en la que debes acreditar experiencia y pasar un “peer review”. De todas formas, sería de incautos juzgar la experiencia de alguien sólo por su certificación. Creo que los certificados son necesarios, pero no indispensables, y que tienen sus peligros, pero no por ello se debe generar un sentimiento de animosidad entre ambos bandos. Pensad, ¿se necesita ser universitario para ser un buen desarrollador de software? Por supuesto que no ¿Debemos abolir los títulos universitarios de ingeniería de informática por ello? Rotundamente no, aunque algunos políticos quieran. Pues lo mismo con las certificaciones.

En fin señor@s, yo vengo muy contento del AOS2010, y espero un AOS2011 aun mejor, tal vez en Canarias ;-)

P.S. Las fotos que tengo mejor no las cuelgo, curiosamente parecemos todos unos borrachos por la noche…

P.S.S. Señor @jmbeas péguele un tiro en la cabeza a su zombi, es para que no sufra el pobre :-D

Read Full Post »


… y lo sabéis en el fondo de vuestro corazón, ¿o no? Bueno, a lo mejor sí que existen, pero a mi me parece que no. En este post os voy a contar mi punto de vista sobre esto de los proyectos cerrados ¡ Bien, hoy no hay TDD, menos mal ! Creo que es importante tratar este tema de los proyectos cerrados, sobre todo en relación a las metodologías ágiles, ya que está muy extendida la idea de que dichas metodologías no pueden aplicarse en proyectos cerrados. Mi idea es que eso de los proyectos cerrados no existe, y que cuando se dice que un proyecto es cerrado en realidad estamos soltando una buena mentira.

¿Os acordais del teorema CAP? Bueno, pues lo que voy a contar a continuación se parece mucho. A alto nivel y desde el punto de vista de planificación y preventa de un proyecto hay tres variables: el alcance, el tiempo de entrega y el coste unitario. Veamos que son estas tres variables:

  • Alcance. El alcance es la cantidad de funcionalidad o de historias de usuario que va a tener el proyecto. También se puede interpretar como el tamaño del proyecto. En los proyectos de alcance pequeño sólo hay que implementar unas pocas funcionalidades, en los de alcance grande tenemos una lista de requisitos grande (o unos pocos requisitos enormes). Algunos factores no funcionales, como la complejidad de las tecnologías implicadas en el proyecto, o la complejidad a nivel de interlocución, también pueden afectar al alcance.
  • Tiempo de entrega. Cuanto tiempo tenemos para terminar el proyecto.
  • Coste unitario. El coste de mantener un equipo de trabajo y toda su infraestructura por unidad de tiempo. Cuanta más gente en el equipo, mayor coste unitario. Cuantas más máquinas y más caras, más coste unitario. Cuantas más licencias de pago tengamos, más coste unitario. No confundir con el coste total, que lo da la suma del coste unitario a lo largo de todo el proyecto.

Bien, todo sencillo. En este contexto podemos definir un proyecto cerrado como aquel que tiene un coste unitario, tiempo de entrega y alcance fijo. Sin embargo esto en la práctica no existe. Un proyecto cerrado sólo podría existir en un mundo estático, donde el entorno no cambia y las cosas son totalmente predecibles y repetibles, y el mundo real no es así. En la realidad las necesidades de negocio cambian durante el desarrollo de los proyectos, los clientes y usuarios se equivocan y cambian de opinión, la productividad de un equipo de desarrollo cambia con el tiempo. Sólo un novato puede pensar que un cliente no va a cambiar de opinión o que un acta de reunión se va a respetar (en Alemania tal vez, en España no). He visto demasiadas actas de reunión y contratos y análisis funcionales haciendo compañía al papel higiénico (hay que reciclar). Todo esto lo sabe la gran mayoría de los profesionales y por ello en la práctica tenemos mecanismos de defensa como:

  • Las notas de cambio de alcance y la gestión del cambio. Es el mecanismo de defensa típico del proveedor. ¿Que el cliente cambia el alcance? Pues pagas dinero. La opción de quitar alguna funcionalidad a cambio no es tan popular.
  • Las cláusulas de penalización si un proyecto se retrasa. Con esto el cliente se defiende tanto de un proveedor en el que no confia como de posibles retrasos debido a imponderables.
  • Precio total del proyecto cerrado. Como el anterior permite al cliente defenderse de proveedores malvados o ineptos o simplemente ante cualquier tipo de desgracia acaecida durante el proyecto.

Fijaros en la contradicción, todo el mundo habla de que los proyectos de verdad son cerrados, pero todo el mundo asume que habrá retrasos, malentendidos, incompetencia, imponderables y cambios de necesidades de negocio. Todo el mundo hace proyectos cerrados, pero a la vez usan tácticas de defensa. El problema real es que la gente tiene en cuenta la realidad, pero las metodologías tradicionales no. Las metodologías tradicionales asumen que una vez pasada la fase de análisis de requisitos (o preventa como se llama en España), se puede hacer un proyecto cerrado, ya que presuponen que el mundo es estático e inamovible. Como la realidad es caótica y cambiante, pero todos se empeña en usar metodologías pesadas, se producen estas contradicciones. Usar metodologías basadas en concepciones irreales es peligroso para tu negocio, no me extraña que la mayoría de los proyectos no sean exitosos. En vez de usar metodologías que no se ajustan a la realidad y que tienen una visión inocente respecto al nivel de caos de un proyecto real, es más eficiente usar metodologías diseñadas con la cruda realidad en mente, y que se basan en aceptar el cambio y gestionarlo. ¿Cúales pueden ser estas metodologías? Mmmm, ah, sí, eso raro del agile.

Visto que el caos de la realidad nos impide tener proyectos cerrados, ¿qué hacemos? Tal vez no podamos cerrar las tres variables, pero si algunas de ellas y jugar con las demás. Veamos que posibilidades tenemos:

  • Alcance abierto, coste unitario y tiempo de entrega cerrado. Este tipo de proyectos es el clásico ejemplo en las metodologías ágiles. Se tiene un tiempo de entrega cerrado, ya que en estos casos el time to market suele ser vital en el negocio. Dada una estimación del alcance, se propone un equipo cerrado (coste unitario cerrado). Se cierra el equipo ya que normalmente añadir o quitar miembros a un equipo suele ser malo para la productividad (costes de formación, ponerse al día con el proyecto, etc). Durante el proyecto se acepta cualquier cambio de alcance, pero al acabar el tiempo pactado, se entrega. Esto permite ofertar a coste total cerrado. El proyecto se considera exitoso si el alcance conseguido es similar al estimado. Más vale estimar bien, sino el cliente quedará descontento.
  • Alcance cerrado, coste unitario cerrado y tiempo de entrega abierto. Como ya he comentado con anterioridad este caso no se produce en el mundo real, excepto tal vez, en proyectos pequeños, debido a que el alcance siempre cambia, ya sea por cambios en necesidades de negocio o por malentendidos. Aun suponiendo que el alcance es cerrado, el que el tiempo de entrega sea abierto, implica que la eficiencia o productividad del equipo varía o se ha estimado mal la capacidad del equipo. Otra posibilidad es que el time to market no afecte al valor del proyecto, pero esto es poco realista. En este caso el coste total del proyecto es abierto, ya que no sabemos por cuanto tiempo vamos a tener al equipo trabajando.
  • Alcance cerrado, coste unitario abierto y tiempo de entrega cerrado. De nuevo como el anterior este caso no es muy real, tal vez se puede dar en aplicaciones pequeñas pero con un time to market muy estricto. Para conseguir llegar a la entrega se invertirán los recursos que hagan falta. De nuevo el coste total del proyecto es abierto.
  • Alcance y coste unitario abierto, pero tiempo de entrega cerrado. Se corresponde con un proyecto crítico, no sabemos exactamente lo que se va a implementar, pero tiene que estar listo en una fecha concreta. Para conseguirlo se pondrán todos los recursos que sean necesarios.
  • Alcance y tiempo de entrega abierto, pero coste unitario cerrado. Esto es un proyecto sin prioridad ni ningún tipo de urgencia. Puede ser un proyecto personal o entre amigos.

El tipo de proyecto que os podéis encontrar más frecuentemente en la realidad es el primero, el que deja abierto el alcance y cerrado lo demás. Qué casualidad que es el tipo de proyecto en el que se centran las metodologías ágiles. Este tipo de proyectos tiene unas cualidades muy interesantes: el coste total es cerrado y por otro lado se ajusta mejor a la realidad. Esto es bueno para el proveedor, ya que evita entrar en perdidas y puede asegurarse un beneficio económico. También es bueno para el cliente, pero sólo si el alcance conseguido es suficientemente bueno.

Esta circunstancia pone al cliente en una posición de debilidad con respecto al proveedor. Muchas consultoras sin escrúpulos se aprovecharon de esto en el pasado. Por eso los clientes ahora demandan “proyectos cerrados”. Lo que en realidad hacen es protegerse contractualmente. Es muy raro que un cliente admita “alcance abierto” debido a esa debilidad. Sin embargo si la relación cliente/proveedor es de una gran confianza y la experiencia pasada sea buena, si puede admitir este modelo de proyecto con alcance abierto, al fin y al cabo lo que le suele interesar al cliente es protegerse de proyectos que no se acaban nunca y que consumen dinero sin fin. Si el fracaso del proyecto no supone un gran perjuicio para el cliente, aumenta la posibilidad de que éste se preste a un contrato abierto. Otro caso es el de los proyectos internos, donde es absurdo penalizarse a uno mismo, y es mejor aceptar la realidad. En este caso el poder hacer “lo máximo posible” en un tiempo y coste acotado es bastante atractivo.

En el resto de los casos el cliente querrá un modelo de penalización o bien de precio cerrado. Esto no significa que no tengamos un proyecto con alcance abierto, sino que tenemos un contrato cerrado. Sólo debemos aceptar contratos cerrados si estamos muy seguros de poder cumplirlos o si estamos muy desesperados. Para tener esa seguridad nuestra organización debe ser lo suficientemente madura como para poder hacer estimaciones certeras. En este caso se trata de estimar el alcance, y en función de esta estimación saber que coste unitario hay que invertir para cumplir los plazos. Esto no es fácil, sobre todo si tenemos en cuenta que el coste unitario no afecta de forma muy predecible a la productividad del equipo. Podemos gastar mucho pero mal, por ejemplo comprando caras licencias de productos que no son adecuados o poniendo un pelotón de becarios en vez de unos pocos desarrolladores expertos.

En cualquier caso debemos estar preparados para lo peor. Sabemos que aunque el proyecto sea abierto el cliente normalmente se protegerá con un contrato cerrado, asi que ¿qué puede ocurrir si fracasa el proyecto? Es decir, ¿que pasa si el alcance logrado no da el valor suficiente al cliente? En estos casos el cliente tiene diferentes mecanismos para protegerse:

  • Si lo más importante para el negocio es alcanzar un nivel de funcionalidad aceptable, se da un tiempo extra al proyecto, a cambio de una penalización económica debido a los “daños” de no tener el sistema a tiempo.
  • Si lo que realmente importa es el time to market, se pone en producción pero se penaliza al proveedor en función de la cantidad de funcionalidad que falte, para compensar los inconvenientes de que el sistema no tenga suficiente funcionalidad.
  • Precio cerrado. El proyecto es precio cerrado, y el cliente no te pagará ni un céntimo más del pactado. Si el time to market es lo importante tendrás que aumentar el coste unitario para reforzar el equipo. Si lo importante es la funcionalidad, tu equipo estará más tiempo del planificado. Combinaciones de ambos escenarios son bastante típicas. Todo esto puede lleva a proyectos con poca rentabilidad o pérdidas si no consigues estimar bien.
  • Te demandan y/o devuelves el dinero más el perjuicio recibido por el cliente debido a no conseguir tener la aplicación.
  • Si aplicas una metodología que lo permita, se puede abortar el proyecto en cuanto se vea que se va a fallar. Las metodologías ágiles son especialmente adecuadas en este sentido. Si se falla al principio, el cliente aun está a tiempo de contratar a otro, con lo que tiene menos perjuicio. Desgraciadamente en España es raro ver proyectos abortados aunque claramente se encaminen al fracaso.

¿Cómo afrontamos los contratos cerrados? ¿Nos rendimos y hacemos lo “mismo de siempre”? Muy al contrario, lo ideal en estos casos es usar metodologías ágiles, aunque la idea parezca de poco sentido común. Desde el punto de vista de los contratos cerrados, las metodologías ágiles son muy eficaces, ya que nos permiten gestionar el riesgo mejor y por otro lado nos permiten tener estimaciones precisas. Uno de los pilares de dichas metodologías es el uso de ciclos de feedback frecuentes, lo que nos permite:

  • Enterarnos rápidamente de los cambios de alcance. Mediante entregas frecuentes y desarrollo incremental el cliente tiene acceso rápidamente a la funcionalidad con lo que nos puede advertir de los cambios de requisitos. Este es un mecanismo muy útil para mitigar uno de los riesgos más típicos: construir funcionalidad que el cliente no quiere.
  • Aceptar cambios e implementar la funcionalidad más importante primero. Cuando se llegue a la fecha de entrega, al menos se habrá cubierto la funcionalidad más importante, con lo que la posibilidad de fracasar disminuye.
  • Mediante las reuniones diarias nos enteramos de los posibles impedimentos al proyecto, lo que nos permite tomar acciones correctivas, mitigando riesgos tecnológicos y organizativos.
  • Análisis de viabilidad frecuente. Por ejemplo, en Scrum, podemos decidir al final de cada iteración o sprint, cancelar el proyecto, de acuerdo al feedback del usuario y de los equipos de desarrollo.
  • Las estimaciones mejoran más rápidamente, ya que al tener un feedback más rápido, tenemos más datos y por lo tanto podemos ajustar mejor las estimaciones. Con una metodología pesada el feedback es al final del proyecto, y las estimaciones sólo se pueden ajustar al final del proyecto. En Scrum ajustas las estimaciones al menos una vez por iteración (sprint). En kanban, una vez cada vez que se termina una historia de usuario.

También hay que tener en cuenta que cada sprint o iteración se puede considerar como un proyecto en si mismo, pero de alcance muy pequeño y duración corta. Si el alcance es pequeño y la duración corta,  pensar que el alcance está cerrado, sí es una buena aproximación a la realidad. Al contrario que en un proyecto real, durante un sprint, hay muy poco tiempo, y por lo tanto poca probabilidad de que el alcance del sprint cambie. Podemos considerar pues, que cada sprint es un verdadero proyecto cerrado en el sentido estricto del término. De esta forma gestionar un sprint sí es sencillo, comparado con gestionar un proyecto. De todas formas, en proyectos muy cambiantes (o altamente caóticos), el alcance cambia incluso durante el sprint. En estos caso Scrum puede que no sea la mejor opción, y habría que utilizar enfoques más ágiles todavía, como kanban o el agilismo minimalista.

Como vemos, los proyectos cerrados no existen, pero los contratos cerrados sí, lo que hace los proyectos sean arriesgados para el proveedor. Sin embargo el mito de que una metodología ágil no es útil con contratos cerrados se cae bajo su propio peso. Al contrario de lo que muchos piensan, las metodologías ágiles permiten una mejor estimación y gestión del riesgo de un proyecto con contrato cerrado, además de incorporar de forma natural la gestión del cambio. Tal vez, cuando tu cliente vea que no lo engañas y que cumples tus contratos, te deje hacer un “contrato abierto”.

Read Full Post »


Hola, seguimos con la polémica del TDD, pero no temais, en este post no voy a hablar de TDD (al menos no mucho). En el anterior post defendí que si se hacía bien el TDD, con su refactor y que si además se complementaba con un pair programming, la necesidad de métricas estáticas de calidad de código desaparecen. Comentarios a dicho post por parte de @jmbeas, Chuidiang e @ydarias indicaban que mi postura era correcta en un equipo experto, pero que si tenías equipos menos maduros, entonces necesitabas estas métricas porque los equipos no iban a hacer TDD, refactor y pair programming, ya sea por inexperiencia o por simplemente no querer. Bien, esto es cierto, de hecho es interesante que al enseñar TDD y refactor a equipos novatos,  usemos análisis de código estático para ver como de forma incremental, y emergente, el código alcanza una buena calidad.

En el fondo, mi problema es que pienso que los equipos que no hacen TDD o pair programming, sencillamente no están haciendo agilismo… Enrique, no te metas en más líos, mejor digamos que sencillamente no están usando una buena metodología. En el resto de este post voy a explicar tan inverosímil afirmación.

El agilismo propone un metaproceso para definir un proceso de desarrollo e ir evolucionándolo en el tiempo, con el objetivo de adaptarnos a los cambios en nuestro entorno y mejorar dicho proceso de forma continua, de manera que maximicemos el valor entregado al cliente. No vale con que el proceso sea bueno hoy, sino que debe ser mejor mañana y no debe quedarse obsoleto. Y por mejor entendemos que entregamos más valor al cliente en menos tiempo y con menos coste. Obviamente, para poder implementar el proceso de desarrollo en la realidad, y poder hacer mejora continua, se nos propone un conjunto de buenas prácticas. Mi pregunta es, ¿cuál es el conjunto mínimo de buenas prácticas para considerarnos ágiles? Dicho de otra forma, ¿cuál es la metodología ágil más ligera posible? Dada la definición de agilismo anteriormente expuesta, la metodología ágil más ligera, es aquella que sólo obliga prácticas que proporcionen lo más rápidamente posible información de los problemas del proyecto, y nos ayuden a resolverlos cuanto antes. Armados con unos ciclos de feedback rápidos, que nos informen sobre problemas en el proyecto, podemos practicar mejora continua, y terminaremos con una metodología que es perfecta para nuestro entorno de trabajo específico, y que va a evolucionar para adaptarse a cualquier imprevisto.

Dicho esto, hay que tener en cuenta que los problemas nos lo podemos encontrar a múltiples niveles: estimación y planificación, desarrollo, build y pases de entornos, explotación, etc. Necesitamos pues, ciclos de feedback y mejora continua en cada uno de esos niveles. Obviamente algunos de dichos niveles escapan a mi control, pero al menos planificación y desarrollo sí están bajo mi control. Al conjunto mínimo de prácticas, que te permiten conseguir mejora continua de forma efectiva, lo llamaré agilismo minimalista.

A nivel de control de proyecto y mejora continua lo mínimo que puedes hacer es:

  • Retrospectiva al final de proyecto. Hay que reunirse para saber las causas del éxito o fracaso del proyecto, y que cosas se pueden mejorar y cómo. Es el nivel básico de mejora, aprender del resultado de un proyecto para el siguiente. Debería participar la dirección de la empresa también y el cliente.
  • Múltiples reuniones de seguimiento del proyecto, a ser posible a intervalos regulares, predecibles y ni demasiado largos ni cortos. Un ejemplo de reunión de seguimiento es la retrospectiva de sprint dentro de SCRUM. Otro ejemplo es la demo de final de sprint, este último más orientado a obtener feedback del cliente. Nos permite enterarnos rápidamente de los problemas que se producen durante el proyecto sin esperar a que acabe. Si hay algún problema podemos tener la oportunidad de solucionarlo. También podemos ajustar nuestras estimaciones con la realidad del proyecto, y aprender a estimar mejor en el futuro. Se puede involucrar a todos los participantes en el proyecto, al fin y al cabo no se hace todos los días. Esto es importante para que la información del estado del proyecto llegue a todo el mundo por igual y no se quede información escondida en nichos. También debe participar un representante del cliente, para ver como va el proyecto, proporcionar información adicional y aclarar dudas.
  • Reunión diaria o daily scrum. Es un nivel de feedback más rápido, diario, que involucra a los miembros de un mismo equipo y al menos un responsable. En proyectos grandes pueden haber varios equipos cada uno con su propia reunión diaria.
  • Reunión de emergencia. Para solventar cualquier problema grave y no previsto, detectado mediante cualquier mecanismo.

A nivel de planificación y estimación:

  • Dividir el trabajo en unidades manejables. Dichas unidades deben ser estimables, representar un incremento en el valor entregado al cliente, concisas y claras, de un tamaño similar entre si, independientes entre si, tener un criterio de aceptación y no demasiado grandes. Esto se suele conocer como historias de usuario. La importancia de las historias de usuario es que te proporcionan una unidad de planificación y estimación que está bien correlacionada con el valor del proyecto desde el punto de vista del cliente. El criterio de aceptación es importante para saber cuando se ha terminado de implementar la historia.
  • Revisa las estimaciones frecuentemente, teniendo en cuenta los resultados obtenidos en las retrospectivas y reuniones anteriormente mencionadas. Si las historias no fueran pequeñas, independientes y de tamaños similares, el ajuste de las estimaciones basándonos en lo que pasó en otras historias sería prácticamente imposible.
  • Refina y revisa la definición de las historias frecuentemente. Tal vez a intervalos regulares (SCRUM sprint planning) o tan pronto como te sea posible (kanban). Para ello hay que hablar con el propio usuario, o en su defecto con un experto de negocio.
  • Implementa primero las historias con más valor. Esto maximiza el valor entregado al cliente. También nos evita tener que implementar historias que pueden cambiar o quedar obsoletas con el transcurso del tiempo.

De momento a nivel de gestión y planificación, el agilismo minimalista no es ninguna sorpresa. El punto es que si no implementas todas estas buenas prácticas, no eres ágil. Simplemente no vas a poder reaccionar a los cambios en tu proyecto ni mejorar la forma de trabajo. Casi todas estas prácticas las realizan todas las empresas serias que conozco, excepto la reunión diaria, las historias de usuario y la implementación por orden de valor. Si no practicas la reunión diaria tendrás problemas ocultos y enquistados al menos hasta la próxima reunión de seguimiento, que será dentro de ¿entre 2 y 4 semanas? ¿No es muy ágil cierto? Hasta aquí casi todos estareis de acuerdo, pero todo esto no es suficiente para reaccionar ante problemas y mejorar en un proyecto software. Necesitamos tener en cuenta otro aspecto, la ingeniería.

Desde el punto de vista de mejora continua de la ingeniería y desarrollo:

  • Programación por parejas. Es otro ciclo de feedback, esta vez sobre el diseño y la calidad de código. Lo podemos considerar una revisión de código continua o una QA continua. El feedback proporcionado por un compañero a la persona que está tecleando es rapidísimo, del orden de segundos.
  • TDD. Nos permite saber si nuestro código funciona, o si la modificación que hemos hecho rompe algo. Feedback del orden de minutos.
  • Refactor frecuentemente. Dentro de un ciclo de TDD para garantizar que se hace a menudo, y guiado por la programación por parejas, nos permite mejorar de forma continua la calidad de nuestro código.
  • Integración Continua. Feedback a nivel de horas, que nos permite detectar problemas de integración.

Bien, con esto quiero decir que el agilismo minimalista necesita de mejora continua no sólo a nivel de gestión, sino a nivel de ingeniería, con lo cual necesitas hacer TDD, refactor, pair programming e integración continua, como mínimo, para ser ágil. Si no haces integración continua no detectas los problemas de integración hasta que no haces un pase, ¿es eso ser ágil? Si no haces TDD no detectas si has roto funcionalidad al introducir un cambio hasta que no lo prueba el equipo de QA, ¿es eso ser ágil? Además si no haces TDD no puedes hacer integración continua, sino como mucho, compilación continua. Si no haces pair programming no detectas errores de programación o fallos de diseño hasta dios sabe cuando, ¿es eso ser ágil? El refactor frecuente te permite arreglar tu código, sin necesidad de esperar al super arquitecto/guru. Lo importante es que todas estas prácticas se realimentan y se producen sinergias positivas entre ellas. Cada una cubre cosas que la otra no. Si quitas una sola el edificio se empieza a derrumbar. Por ejemplo si quitas el pair programming puedes introducir fake TDD o simplemente saltarte el refactor. Si quitas el TDD te cargas la integración continua. Las necesitas todas, no son opcionales, son obligatorias.

Ya contamos en la CAS2010 nuestra experiencia de implantación del agilismo. Hubo un momento que teníamos sprints, retrospectivas, etc. Pero no teníamos TDD ni pair programming ni se hacía refactor, y mucho menos integración continua. Eso no funcionaba. Asi que lo siento, a aquellos que piensen que puedes hacer agilismo con un equipo que no controle estas técnicas y no esté dispuesto a hacerlas, os aviso: no va a funcionar, no basta con el sprint planning y el daily scrum, no vas a ser ágil, necesitas prácticas ágiles de ingeniería y gente capaz de llevarlas a cabo.

Afortunadamente parece que hay gente por ahí de acuerdo conmigo, sino leed lo mismo que digo pero explicado de otra manera en este blog de Luis Artola. SCRUM y KANBAN sólo se ocupan del nivel de gestión y planificación de proyecto, pero no de la ingeniería. Para que tu proyecto sea exitoso, necesitas también buenas prácticas de ingeniería y trabajadores capaces de llevarlas a cabo. Muchos piensan que son ágiles porque aplican prácticas ágiles a nivel de planificación y gestión, pero se olvidan de la ingeniería. Esta es una maldición eterna en el mundo de los proyectos software, parece que por poner una capa de gestión se arreglan todos los problemas, pero nadie presta atención a lo más básico, la ingeniería y la capacidad profesional de los “pikachus”.

En resumen, lo mínimo que puedes hacer para considerarte ágil (agilismo minimalista) es: pair programming, TDD+Refactor, integración continua, reuniones diarias, reuniones periódicas de seguimiento (internas y externas para el cliente), retrospectivas de proyecto y planificación y estimación basada en historias de usuario. Si te falta, aunque sea una sola de estas prácticas, no eres ágil.

¿Y las demás buenas prácticas? Bueno, para mi no forman parte del agilismo minimalista, las considero muy dependientes del entorno en el que se mueva cada uno. Aquí es, donde creo yo, que se debe aplicar eso de probar a usar una buena práctica, experimentar y ver si va con tu proyecto o no. Lo importante es que con el agilismo minimalista irás descubriendo cuales son útiles y cuales no. Por ejemplo, a nosotros los sprints no nos han funcionado bien, por eso estamos pensando en pasar a kanban, pero conservando los principios del agilismo minimalista. Quizás esto de agilismo minimalista+kanban sea algo parecido al scrumban que he escuchado por ahí. En cualquier caso el resto de las prácticas debéis experimentar con ellas antes de adoptarlas en serio o no.

Corolario: si ves que necesitas métricas estáticas de calidad de código, es una señal de que no eres ágil, algo falla (pesaito soy). Saludos y ahora me voy a dormir, que ya me vale.

Read Full Post »


Hola a todos, de vuelta de la AgileSpain2010, y con un poco de “resaca” de la conferencia, me toca defender un par de frases que solté en nuestra sesión. Lo que ocurrió realmente fue lo siguiente:

Creando polémica en la CAS2010

Fanático del TDD en la CAS2010

Bien, pues lo solté y me quedé tan fresco, de hecho no me pareció que fuera una frase polémica, pero empecé a ver caras raras y a la salida de la sesión vi por twitter que mi frase había causado cierta extrañeza. Empezaré aclarando mi frase: “Si haces TDD bien no necesitas análisis de calidad de código estático”. Ojo, hablo de hacer TDD bien, no de hacer TDD a medias. Existe un malentendido respecto al objetivo del TDD, si bien uno de ellos es lograr un conjunto de pruebas automatizadas con alta cobertura de código, éste no es el único, de hecho es sólo la mitad de la historia. El otro objetivo, igualmente importante, es conseguir un código de calidad de forma incremental y/o evolutiva. De hecho algunos autores hablan de calidad o diseño emergente, pero yo prefiero no fliparme tanto de momento. Si tenéis el libro de Carlos Blé sobre TDD, veréis que se llama “Diseño Ágil con TDD”, no programación con TDD o pruebas con TDD o QA con TDD, sino diseño. Éste es el entendimiento general que todos los autores tienen sobre este tema: TDD lleva a pruebas automáticas de alta cobertura y a alta calidad de código, si lo haces bien, claro.

Llegado a este punto conviene explicaros mi percepción de los niveles de adopción del TDD:

  • Fake TDD. En este nivel de adopción el TDD no se practica, sino que se simula practicar. En el fake TDD los tests no representan realmente la funcionalidad de las historias de usuario o de la interfaz del componente que queremos probar. No se hace un esfuerzo serio por entender la funcionalidad del componente bajo pruebas y se escriben tests con poco contenido, contenido incorrecto o simplemente tests de relleno sin contenido. Ésto puede ser por desconocimiento de la técnica, con lo que habremos de dar más formación y hacer talleres. También puede ser por presión, que tiende a romper la disciplina del programador, y por miedo a no estar en fechas, se ignora el TDD. La tercera razón para hacer fake TDD la veremos en el siguiente post.
  • Naive TDD. Simplemente consiste en no realizar la fase de refactorización durante el ciclo de TDD. Las causas suelen ser de nuevo inexperiencia o prisas. Normalmente si no se entiende TDD como una metodología de diseño nos encontraremos en este caso. Otro tipo de Naive TDD se produce cuando se escribe primero código de implementación y después el test.
  • TDD. Adopción completa, haces test con funcionalidad correcta pero no consideras el ciclo terminado hasta que no has refactorizado. Para que un ciclo de TDD se considere completo y puedas hacer commit, debe existir un test, con los contenidos adecuados, que al ejecutarse pase, y el código que implementa la funcionalidad bajo prueba sea limpio. Si el código no es limpio debemos refactorizar.

¿Qué es pues código limpio? Pues es código que tiene unos niveles de calidad razonables, pero, ¿qué es la calidad del código? Difícil pregunta. Para ello las distintas organizaciones y empresas definen un modelo de calidad, que consiste en un conjunto de métricas de código que se van a tomar y que resultados mínimos son exigibles para esas métricas. Las métricas se clasifican en dos tipos: estáticas y dinámicas.

La métricas dinámicas miden propiedades de tiempo de ejecución del sistema. Ejemplos típicos son corrección, rendimiento y escalabilidad, seguridad y usabilidad:

  • La corrección la conseguimos con el propio TDD (hasta donde es posible dado que los requisitos son cambiantes y difusos).
  • El rendimiento y escalabilidad se consiguen con pruebas de stress, algo que está aparte del TDD, hasta donde yo sé.
  • La seguridad del mismo modo está en un mundo aparte, y que yo sepa no se pueden hacer pruebas automatizadas satisfactorias para esto, salvo quizás los ataques más típicos.
  • La usabilidad tiene que ver con la facilidad de manejo de la aplicación y su atractivo para el usuario, definitivamente esto no se puede probar de forma automática, para ello podemos usar pruebas de aceptación tradicionales.

Por otro lado las métricas estáticas miden propiedades del código que se pueden detectar en tiempo de compilación. Veamos:

  • Nomenclatura. Si tu código se ajusta o no a determinada nomenclatura. Bueno, que deciros, no considero esto importante para un desarrollo ágil, es mucho más importante la legibilidad y la documentación. Puedo entender que en un lenguaje con tipado dinámico esto pueda ayudar, al fin y al cabo no hay compilador que te diga si una variable es un string o un integer. Sin embargo si vas a usar un lenguaje de tipado dinámico (ruby, javascript, smalltalk, etc) es mejor que no pienses en java, sino que saques partido a las características de dicho lenguaje, que normalmente no está pensado para que una variable sea siempre un string, es simplemente otra filosofía de diseño.
  • Nivel de documentación. Bueno, esto sí es interesante, me habéis pillado :-) Sin embargo no considero que esto se pueda medir de forma totalmente automática. La dificultad radica en que es muy difícil automatizar la decisión de si un método o clase debe estar documentada. Desde el punto de vista del agilismo debemos documentar sólo aquello que merezca la pena, no todo, y por supuesto tampoco vale no documentar nada. Detectar si documentar un artefacto de código “vale la pena” o “o aporta valor” de forma automática es difícil, ¿no creéis?
  • Legibilidad. Lo más importante, tu código debe ser legible por tus compañeros, si no, no podrán mantenerlo. Esto tampoco se puede detectar automáticamente.
  • Estilo y formato de código. Esto realmente es un aspecto de la legibilidad.
  • Tamaño del sistema. No se muy bien para que se quiere medir esto, y además, ¿en qué lo medimos? ¿Lineas de código?¿Puntos función? Sin comentarios. Tal vez lo que queremos medir realmente es la cohesión.
  • Alta cohesión y bajo acoplamiento (principio de una única responsabilidad). Realmente estas son muy interesantes de medir y a mi juicio sí que son necesarias. Los artefactos de código que tengan muchas interdependencias entre ellos deben agruparse en artefactos de nivel superior. Por ejemplo, un montón de métodos que son muy interdependientes podrían agruparse en la misma clase. Y viceversa, si un artefacto esta compuesto de muchos subartefactos que apenas interaccionan entre si, podemos dividir ese artefacto en varios más pequeño. El ejemplo típico es la clase “monstruo” con todos los métodos del sistema dentro de ella, ay, cuantas de éstas habré visto a lo largo de mi carrera. Estas propiedad del sistema sí que se pueden medir automáticamente, al menos en los lenguajes de tipado fuerte. Si se pueden medir automáticamente en los lenguajes de tipado dinámico tengo mis dudas, pero me callo por no ser experto.
  • Duplicación de código. Esto se puede medir fácilmente con una herramienta. La existencia de código duplicado es un signo de mal diseño y baja calidad, excepto en el caso de extrema necesidad de legibilidad.
  • Malas prácticas. ¿Acaso el analizador de código estático es inteligente? No, es tonto, es un robot que se limita a pasar patrones sobre el código. Si no tiene inteligencia, ¿cómo va a saber si una práctica es mala? ¿Acaso entiende el código? Sólo va a detectar las malas prácticas más sencillas. No me lo creo a pesar de lo que me digan los vendedores de herramientas sofisticadas (y caras).

Existen muchísimas más métricas estáticas, algunas de alta complejidad. Yo personalmente no las entiendo, ni veo cual es su sentido. Todavía no conozco a nadie que me las haya podido explicar, así que de momento me quedo con las que os he contado anteriormente. En cualquier caso, ¿qué utilidad tiene medir una cosa sin entender lo que estás midiendo? Si alguien me sabe explicar alguna métrica arcana, que sea esencial para medir la calidad del software, y no haya mencionado, que me lo comente.

En el modelo de calidad que yo uso, y que me gusta pensar que es un modelo de calidad ágil, considero que el código es limpio si cumple en la medida de lo posible los siguientes criterios de calidad: corrección, legibilidad, sin código duplicado, bajo acoplamiento y alta cohesión. Si os fijáis, excepto la legibilidad, el resto de los criterios te los incorpora de forma natural el ciclo de TDD que incluye la refactorización. La legibilidad es algo que no se puede comprobar automáticamente. O sea que si hacemos TDD bien, y encima lo reforzamos con otras buenas prácticas, como la programación por parejas o la revisión de código, no necesitamos para nada complicar vuestro build con análisis de código estático. Una aclaración, yo considero que el código es limpio si todo el código pasa el modelo de calidad anteriormente mencionado. Esto implica no sólo el código de implementación, sino el código de test. La tarea de refactorización incluye también al código de test no sólo el código bajo pruebas. No es válido tener código duplicado en el código de test, y este debe ser legible, y poseer una buena cohesión. De hecho las pruebas unitarias deben ser independientes unas de otras, lo que implica un acoplamiento entre ellas muy bajo. Un error típico es no refactorizar el código de test, sólo el de implementación.

Muchos estareis pensando que todo esto es muy bonito, pero lo que queréis realmente es controlar que las cosas se hacen bien. Así que muchos me diréis, ¿cómo controlo que el código está bien hecho?¿Cómo se que se está haciendo TDD bien y no me están engañando? Muchos de los expertos en agilismo os dirán que el simple hecho de que hagáis esta pregunta significa que no sois ágiles. Si necesitáis que una herramienta os diga si el equipo está programando según las buenas prácticas es que no estáis al lado del equipo, que no practicáis go&see y que estais encerrados en vuestros despachos sin interactuar realmente con la realidad, es decir, con vuestro equipo.

Ciertamente lo comentado en el anterior párrafo puede ser cierto en las circunstancias típicas de un proyecto ágil. En otras circunstancias, como en el caso de trabajar con equipos distribuidos, es lícito que tengáis dudas sobre si vuestro equipo hace el TDD como debiera, ya que al fin y al cabo, no podéis estar en la misma sala con todos los equipos a la vez. Así pues, si tienes equipos distribuidos, ¿cómo sabes que se hace bien el TDD? La respuesta está en el nivel de cobertura y en aplicar un poco de psicología:

  • Si la cobertura es baja, entonces realmente no se está haciendo TDD bueno. Puede ser porque se está haciendo Fake TDD, y por lo tanto los tests al no ser suficientemente completos no ejerciten bien el código. Puede ser también que tengamos Naive TDD, y se escriba código de implementación antes que el test, con lo que puede quedar zonas del código de implementación sin probar. La falta de refactorización del naive TDD también puede llevar a baja cobertura, después lo comento. También puede ocurrir que simplemente no se ha hecho TDD en todos los casos, y se ha escrito código de implementación sin ningún tipo de test.
  • La cobertura es alta (mayor del 70%). En este caso existe una alta probabilidad de que el código tenga una buena calidad y se haya hecho TDD del bueno con refactorización. La razón de esto es sutil. Lógicamente si hacemos TDD bien vamos a tener una cobertura alta. ¿Podemos llegar a tener cobertura alta haciendo Fake TDD? Claramente no, a menos que el programador dedique sus esfuerzos a sabotear el proyecto y haga casos de tests con alta cobertura, que pasen pero que no prueben nada. Ciertamente esto es bastante bizarro. Sobre la gente que se dedica a hacer esto hablaré en el siguiente post ¿Pero y el Naive TDD? Al fin y al cabo sí hacen tests, podríamos tener alta cobertura a pesar de no refactorizar, ¿no? La verdad es que ciertamente es posible pero es difícil. Al no refactorizar duplicas código, y el diseño de tus clases hace que se vayan volviendo cada vez más difícil de testear, ya que no guardan el principio de alta cohesión, bajo acoplamiento, etc. Por un lado duplicar código hace que tengas que duplicar también los fragmentos de test que ejercitas ese código. Esto se va haciendo pesado y se tiende naturalmente a no hacerse con lo cual la cobertura baja. También la duplicación invita a que los tests fallen, ya que un cambio en una historia de usuario o un bug, implica cambiar código en muchas zonas de la aplicación, con lo que harán que el test que prueba ese bug falle. Finalmente, al no refactorizar, las clases van perdiendo calidad, y va siendo cada vez más difícil hacer pruebas unitarias, ya que estas se van acoplando cada vez más con su entorno, y no presentan una buena encapsulación y cohesión. Como vemos el no refactorizar al principio no tiene mucha importancia, pero conforme pasa el tiempo se hace más difícil añadir tests, con lo cual los tests se hacen más laxos y la cobertura baja.

Yo recomiendo encarecidamente mezclar TDD con dos prácticas más: programación por parejas y revisiones de código, especialmente de los tests. Ambas contribuyen a que los desarrolladores cuiden su prestigio y no pierdan la disciplina, con lo que baja la probabilidad de que rompan el ciclo de TDD. La programación por parejas tiene la ventaja adicional de enseñar la técnica a los más novatos. Os puedo contar que en el último proyecto estaba presionado de tiempo y rompí la disciplina del TDD para una funcionalidad que era “trivial”. Como no estaba haciendo programación por parejas pude hacer esta trampa. ¿El resultado? ¡ Zas, en to la boca ! Efectivamente sufrí una concentración de bugs en ese código “trivial”, necesité una jornada de 20 horas de programación ininterrumpida para solventar el desaguisado. Cuando llegué a casa mi mujer casi me mata de un sartenazo pensando que era un vulgar ladrón. Después estuve una semana KO por el sobreesfuerzo. Nunca más.

Si aun veis que queréis un análisis estático de código podéis usarlo como método didáctico. Conforme vais haciendo TDD, ireis viendo como vuestra cobertura aumenta y también los resultados de las métricas de calidad. Esto es recomendable para equipos que empiezan con el TDD y todo esto de la refactorización. Cuando se trata de un equipo que sabe hacer TDD y refactor, realmente las métricas os sobran, así que podéis aligerar vuestro sistema de integración continua y ahorraros un dinero en licencias desactivando tales métricas.

Por supuesto existe una razón no ágil para esto de las métricas: el informe de colores para impresionar a la dirección y a los clientes. Si necesitáis un informe lujurioso para justificar el avance de vuestro proyecto estais en una situación mala. Yo justifico el avance de mis proyectos con demos, enseñando software que funciona y que cada vez tiene más funcionalidad.

En el siguiente post os cuento la otra pequeña polémica que tuvimos.

Read Full Post »

Mi experiencia AgileSpain2010


Buenas a todos. Ya que no pude asistir a la sesión retrospectiva de la AgileSpain2010, en este post os ofrezco mi punto de vista de la que fue la primera conferencia sobre agilismo a nivel nacional. Realmente desde mi punto de vista se puede considerar todo un éxito tanto de asistencia como a nivel de ponencias y talleres.

A nivel de asistencia, deciros que se llenó por completo el cupo de asistentes, con una entrada de aproximadamente 200 personas. Muchos se quedaron sin poder asistir. Esto para mi fue sorprendente ya que desconocía que hubiera tanta gente que estuviera interesada en este tema. Yo esperaba la mitad de asistencia como mucho. Por lo que pude hablar con la gente, había bastantes personas provenientes de clientes y que estaban pensando en iniciar un esfuerzo ágil en sus empresas, noticia esta que considero muy buena.

Sobre las sesiones he de deciros que todas a las que asistí fueron interesantes. La keynote impartida por Henrik Kniberg fue bastante impactante. En una hora supo resumir de forma perfectamente clara y muy didáctica los principios del agilismo y porqué éste es ideal para el desarrollo de sistemas informáticos. Una persona que asistía conmigo, totalmente neófita al mundo del agilismo, salió de la keynote con una idea bastante clara de lo que es. Posteriormente asistí al workshop que el propio Kniberg dio sobre kanban y os puedo decir que los 200 euros que pagué merecieron la pena.

También asistí a dos sesiones de Jose Luis Soria. La primera, gestión ágil de la configuración, versó sobre como definir y documentar una política de branching y gestión de versiones de código, consistente con los principios del agilismo. La verdad es que me gustó ya que considero que definir esta política es esencial, no sólo para organizar nuestras versiones de código, sino para trabajar en equipo. Esto último especialmente importante para trabajar con equipos distribuidos donde la comunicación no es tan eficiente como en un equipo local. Ciertamente creo que es un tema importante que normalmente es menospreciado cuando se intenta implantar el agilismo. En la segunda sesión, gestión ágil de requisitos, explicó qué es una historia de usuario y qué no lo es, una plantilla con información para definirlas, y buenas prácticas para identificarlas. También habló un poco sobre usar estimación basada en unidades absolutas y relativas, definiendo en este último caso lo que es un punto de historia y como se relaciona con la velocidad de un equipo. Ambas sesiones fueron seguidas por un buen debate.

Xavier Quesada nos ofreció su visión de la integración continua, con una exposición muy amena y divertida, usando como no, tiza y pizarra en vez de transparencias. Sólo puedo coincidir con todo lo que nos contó, y me confirma que el enfoque que nosotros seguimos en nuestro día a día no es descabellado. Sorprendentemente encontré mucha resistencia en los asistentes a sus ideas. Casi todas derivadas desde mi punto de vista del desconocimiento y del fuerte cambio en el paradigma tradicional que la integración continua supone. Ciertamente he escuchado las misma objeciones en clientes, pero me sorprendió que provinieran de un público “ágil”. Seguramente lo que ocurre es que muchos asistentes se están iniciando todavía, ya que como dije antes, había muchos que simplemente están intentando comenzar con todo esto, lo cual es muy bueno. Opino que sería muy interesante impartir un workshop práctico sobre como hacer integración continua para disipar todos los miedos y dudas. El miedo más extendido era la necesidad de máquinas y que hacer con la base de datos.

Joscha Jenni nos ofreció, en toolchains for agile teams, su experiencia con herramientas para facilitar el desarrollo ágil en equipos distribuidos. Al parecer ellos usan Jira, Bamboo y Confluence, todo integrado mediante plugins. Me gustó porque expuso el problema de las hojas excel y las pizarras blancas en equipos distribuidos. Además el enfoque que tuvieron fue similar al nuestro.

Desgraciadamente me perdí sesiones muy interesantes, ya que por un lado tenía que ayudar a mis compañeros con el stand de atSistemas, al fin y al cabo @ialcazar y @antoniodfr también tenían derecho a ir a sus sesiones, y por otro, todavía no he descubierto como estar en dos sitios a la vez. Me hubiera gustado ir al de probando tu tdd, testing de aceptación con ruby, las administraciones públicas son como el agua y el aceite, diez maneras infalibles de asegurar que Scrum será un fracaso y pair programming strategies. También me habría apuntado al Coding Dojo de haber sabido lo que era, siempre es bueno mejorar tu kung fu. Lo mismo puedo decir de las contribuciones, que eran entes misteriosos, y que no averigüé hasta después de la conferencia lo que eran.

Finalmente la parte mala de la conferencia:

  • Los retrasos. Algunas sesiones empezaban tarde o se extendían más del tiempo pactado. Esto generaba un retraso en cascada de las demás conferencias y un poco de caos.
  • Me hubiera gustado saber lo que eran las contribuciones.
  • El hecho de que algunos ponentes tuvieran más de una sesión. Yo hubiera apostado por un límite de una sesión y un workshop por ponente, ¿por qué? Simplemente para aumentar el número de ponentes y por lo tanto la variedad y cantidad de puntos de vista distintos.
  • Las quejas sobre el dinero. A mi, 95 euros por dos días de conferencias de buen nivel, con comida incluida, no me parece caro. Pagar 50 euros por un Coding Dojo tampoco (al final oí que lo terminaron haciendo gratis, que país).

También quiero dar las gracias a @antoniodfr e @ialcazar. Al primero por secuestrarlo de improviso y decirle de repente, en medio de la comida, “¿Sabes que vas a dar una charla en la agilespain2010?”, en fin, política de fait accompli, la verdad es que a veces soy malo. Se vio obligado a abrir hueco en su apretada agenda y a echar unas horas de más para montar la presentación conmigo. Al segundo por ayudarnos a preparar las transparencias y pulir nuestra presentación, que aburrimiento debió pasar el hombre.

Por supuesto os tengo que contar algo sobre nuestra propia presentación. Lo más sorprendente fue… ¡qué tuvimos asistencia! Eso es, nada menos que 30 personas decidieron perder 90 minutos de su tiempo para escuchar a unos extraños desconocidos hablar sobre como la habían pifiado al implantar el agilismo, y como se habían recuperado de la pifia y ahora tenían algunos proyectos ágiles en funcionamiento. Y eso que competíamos con Ángel Medinilla. Otra cosa sorprendente fue que algunas de mis declaraciones generaron bastante polémica, con lo cual me veré obligado a hacer una par de posts sobre éstas en el futuro. Ya colgaremos fotos y por supuesto el vídeo de nuestra charla en youtube, convenientemente dividido en partes.

Finalmente de lo mejor del AgileSpain2010, fue conocer y desvirtualizar a bastante gente. Esos #pintxosagiles fueron geniales a pesar de que me esperaba un duro día y una ponencia al día siguiente. Espero que os gustaran los mojitos señor@s.

Bueno, os dejo tranquilos. En los dos próximos posts defenderé mi honor y mis ideas radicales sobre el TDD ¡ Salud !

Read Full Post »


¡ Oh no ! Otro post infumable sobre equipos de desarrollo… Si señores y señoras vuelvo a la carga con este tema que considero de importancia vital, no os preocupéis creo que es el último de la serie. Considero importante este tema porque si no tenemos un equipo bien estructurado lo tendremos muy difícil para tener éxito en nuestros proyectos.

En mi anterior post sobre equipos comenté que una estructuración plana y democrática era la más ágil y óptima para el desarrollo de software. Sin embargo al crecer en tamaño dicha estructura se colapsa debido a la sobrecarga de información de cada miembro del equipo. Además para explotar las ventajas de tal estructura de equipo lo mejor es que estén todos colocados en la misma sala. Esto nos lleva a un problema, ¿qué hacemos si necesitamos un equipo muy grande (más de 9)?¿Qué hacemos si no tenemos a todos lo miembros del equipo colocado? En estos casos necesitamos estructurar el equipo de forma diferente. Veamos alternativas.

La primera tentación es montar una jerarquía. Ciertamente las jerarquías disminuyen la cantidad de lineas de información que llegan a una persona, lo que permite que esta se sature menos si el equipo es grande. Desde este punto de vista los equipos organizados en jerarquías escalan bien con el tamaño. De hecho el número de lineas de comunicación crece mucho más despacio (logarítmicamente)  que con equipos planos (crecimiento lineal). Otra ventaja es que la toma de decisiones la toma el jefe, lo que permite mayor velocidad de decisión que la basada en consenso. Es la forma tradicional de organizar los equipos. Todo parece bonito pero… esta estructura ¡no es ágil! y además ¡ es frágil ! Veamos:

  • Frágil. La estructura depende de las personas que son jefes de equipo. Con suerte puedes tener un jefe que sepa lo que hace y sea competente, si no tienes tanta suerte te toca un jefe que es una nulidad. Cuanto más arriba en la jerarquía esté la persona, más vital es. Un equipo plano es más robusto ya que no depende de una sola persona.
  • No ágil. Cada miembro del equipo no tiene una linea de comunicación con sus compañeros sino con su jefe. Si una información necesita pasar desde una persona a otra, no puede hacerlo directamente, sino que debe pasar por al menos un jefe o más. Por cuántos intermediarios pase depende de la “distancia” entre las dos personas, si están en el mismo equipo pasan por un sólo jefe, si están en equipos organizatívamente lejanos pasa por varios intermediarios. De hecho el número máximo de intermediarios crece logarítmicamente con el tamaño del equipo mientras que en un equipo plano se mantiene constante en cero. Paradójicamente, esta estructura hace que los jefes más importantes, los que deben tomar decisiones vitales, reciben la información más anticuada y desvirtuada ya que son los que tienen siempre más intermediarios con la realidad.
  • No favorece el espíritu de equipo y colaboración sino la competencia entre jefes y la “política”.

Evidentemente este modelo radical de jerarquía no suele aplicarse. Es más común el tener pequeños grupos planos que están coordinados por un jefe. Esto disminuye un poco el problema pero no lo elimina por completo, sobre todo si tenemos en cuenta que los equipos planos están en la base, y que es más raro encontrar equipos planos de jefes.

Otra forma típica de estructurar un equipo es alrededor de especialistas. Se suelen tener grupos de especialistas, donde cada grupo es experto en un componente del sistema o en una tarea o actividad. La idea detrás de esto es que los especialistas son muy eficientes en realizar unas actividades en concreto, por lo tanto la forma más eficiente de organizar un equipo es que cada individuo o grupo haga lo que mejor sabe hacer, su especialidad. De esta forma el rendimiento del equipo de desarrollo será óptimo, ¿verdad? Pues no, ¡ FAIL ! Veamos el siguiente dibujo ilustrando un equipo basado en especialistas:

Equipo organizado en grupos de especialistas

Especialistas

Como se ve desde que una historia de usuario se extrae del product backlog hasta que se completa y reporta un valor al cliente (y dinero para nosotros), ésta pasa por… ¡un montón de intermediarios! Cada intermediario (especialista) de nuevo añade un posible punto de encolamiento (“el otro equipo está tardando mucho en darme trabajo, yo no tengo la culpa….”) y de malentendidos (“pero suponíamos que la interfaz entre el componente A y el componente B era así, no nos la explicásteis bien”). El hecho de que cada grupo sólo entienda de su especialidad agrava los problemas, ya que provoca entre otras cosas:

  • Cada uno intenta optimizar el proceso global y el código desde el punto de vista de su especialidad sin tener en cuenta el objetivo global. Esto produce optimizaciones locales que no son eficientes. Por ejemplo un desarrollador puede decidir escribir código sin pruebas rigurosas, lo que optimiza su trabajo (acaba antes) pero genera un problema en el equipo de control de calidad.
  • Crea rivalidades y evita el espíritu de equipo. Cada grupo tiende a ver a los demás como “tontos” que no entienden su trabajo (especialidad).
  • No se produce una diseminación del conocimiento entre los distintos empleados. Cada uno se queda “encasillado” en su especialidad para siempre.
  • No hay un feedback rápido ante problemas. Un problema introducido por un equipo puede no ser detectado hasta que llega a otro equipo, potencialmente alejado.
  • Como normalmente los equipos de especialistas no colaboran entre si, se necesita la figura de un coordinador.
  • Normalmente llega a una utilización ineficiente de las personas. No todas las “historias de usuario” tienen que necesitar de todos los especialistas. Si en un momento dado sólo hay historias de usuario que necesitan a los especialistas A, C y D, el especialista B se quedará desasignado. Esto es una consecuencia obvia de usar especialistas, los especialistas no son siempre asignables y pueden llevar a una utilización ineficiente de los recursos.
  • El efecto “patata caliente” y “tu la llevas”. Se suele echar las culpas a los demás equipos y pasarle el marrón al siguiente. Esto es debido a que cada grupo de especialistas no comparte una meta común con los otros grupos y además son incapaces de ver el proyecto en su conjunto, con tal de que su trozo esté terminado no les importa que el producto en global esté mal (la culpa será de los otros, mi parte está bien).

Como hemos visto la jerarquía y la organización en grupos de especialistas genera intermediarios y colas que son fuente de múltiples problemas. Por cada intermediario se produce un retraso, con lo que la información llegará más anticuada al receptor. Por cada intermediario hay una cierta de corrupción de la información y malentendidos, con lo que la información se perderá por el camino y lo que llegue al receptor no puede no ser lo suficientemente veraz o preciso. Si encima cada intermediario tarda una cantidad diferente y no predecible de tiempo en procesar la información se producirán encolamientos. Si quieres un equipo ágil, evita intermediarios. Las colas son también fuentes de ineficiencias. Por cada cola tenemos trabajo a medio hacer, parado que no genera valor. Por cada cola se retrasa el feedback, haciendo que un montón de posibles defectos y problemas estén escondidos, a la espera de aparecer en el momento más inoportuno y cuando todo el mundo está ya “en otra cosa”. Si quieres ser lean debes evitar las colas.

Lo más eficiente es organizar los equipos grandes de forma que se minimicen el número de intermediarios y colas. Para esto tenemos dos armas: la autogestión y los equipos multidisciplinares. Veamos algunos consejos generales en este sentido:

  • Organiza en equipos planos colocados en la misma sala a toda la gente que necesite comunicarse con mucha frecuencia y responder ágilmente. Equipos que no deban interaccionar tan a menudo pueden estar en otras salas o en centros remotos.
  • Cada equipo debe ser multidisciplinar, debe tener varios especialistas. Además estos especialistas irán enseñando sus tareas a los demás miembros del equipo. Esto genera una transición gradual de especialistas a técnicos multidisciplinares y un mejor espíritu de equipo.
  • Cada equipo debe tender a la autogestión, tanto de sus cometidos como a la interacción con otros equipos. Esto evita la figura del coordinador y aunque tengamos un coordinador su actuación no sea tan vital.
  • Para coordinar varios equipos cada equipo puede nombrar a uno de sus miembros como representante. Este nombramiento puede rotar con el tiempo. Todos los representantes de todos los grupos se organizan de forma democrática y se reúnen periódicamente para discutir temas de organización.
  • Cada equipo es responsable por entero de la entrega de la tarea que tiene encomendada. No se debe responsabilizar a individuos. Esto genera una meta común y une al equipo.
  • De la misma manera todos los equipos son responsables del éxito o fracaso del proyecto en su conjunto.
  • Mantén los miembros de un mismo equipo juntos durante mucho tiempo, de esta forma se conocerán entre si y su coordinación crecerá.
  • De vez en cuando ofrece la posibilidad a los miembros de un equipo para cambiarse a otro equipo. Asi no se quemarán ni se cansarán del mismo ambiente y tendrás un nivel adicional de diseminación de información.

Si implementamos estos consejos podemos montar un equipo estructurado en base a “feature teams”. En este tipo de estructura cada grupo o “feature team” se encarga de realizar una historia de usuario. Veamos el siguiente dibujo:

Proyecto organizador en equipos por historias de usuario

Feature Teams

Como vemos eliminamos las colas. Cada equipo es multidisciplinar y tiene su propio Product Owner. De esta forma es capaz de coger una historia de usuario e implementarla sin necesidad de pasar por otros grupos. Como cada equipo es plano, éste se comporta de forma ágil y rápida. En la figura hay cuatro equipos, cada uno de ellos en su propia sala. Los equipo que pertenecen a “Color Features” están en el mismo edificio porque cogen historias de usuario que tienen bastante relación entre si, son funcionalmente próximas, por lo tanto los dos equipos necesitan comunicación ágil y por lo tanto proximidad. De la misma manera “Alpha Features” está en otro centro de trabajo y se estructura de forma similar. El uso de autogestión y representantes de equipos disminuye mucho la necesidad de coordinadores. Sin embargo siempre es bueno es tener varios scrum masters itinerantes o coachers que se dediquen a resolver dudas,  aconsejen a los equipos, desatasquen potenciales problemas globales o arbitren en disputas “irresolubles”. Estos “coachers” no serían coordinadores sino facilitadores y maestros. Tampoco es mala práctica que además del representante de equipo se reúnan periódicamente los product owners de cada grupo para mantener una linea de coherencia estratégica del producto.

Un hecho interesante es que como cada historia de usuario requiere de varias tareas o componentes para ser completadas, cada grupo debe trabajar sobre distintas áreas de código. Esto hace que todos los grupos tengan una responsabilidad compartida sobre todos los componentes de código de la aplicación. De esta forma a todos los grupos le convienen que todos los componentes de código estén hechos con una calidad y mantenibilidad decentes, porque te puede tocar usarlos o modificarlos para la siguiente historia de usuario. Contrasten este efecto con lo que ocurría con los especialistas, cada especialista sólo se preocupa de su componente y no de los demás. El hecho de que varios grupos modifiquen simultáneamente las mismas zonas de código nos genera un problema de gestión. Este problema se soluciona con varias prácticas del agilismo:

  • Pair programming. Para aumentar la calidad del código (revisión continua) y la diseminación de la información (enseñanza mutua entre los miembros de la pareja).
  • Repositorio de código con control de versiones y concurrencia optimista. Es vital que el sistema de control de versiones de código no bloquee los ficheros. Si los bloqueara se producirían encolamientos entre dos grupos que necesitan modificar el mismo componente de código.
  • TDD. Para mantener una suite de pruebas que te permita tocar el código de otro sin miedo a romperlo y no darte cuenta.
  • Integración continua. Para integrar de forma continua los cambios de los distintos grupos, disminuir la probabilidad de conflictos, y agilizar la fusión de versiones en caso de que los hubiera.

Finalmente, todo esto funciona porque los miembros de tu proyecto que necesitan una comunicación más rápida y ágil son los que están implementando una misma historia de usuario. Dos personas implementando dos historias de usuario distintas no tienen tanto acoplamiento y necesidad de intercomunicación como dos personas que están trabajando sobre la misma historia de usuario. De hecho el acoplamiento entre dos “feature teams” se produce sobre todo a través de la base de  código compartido. En este caso dicho acoplamiento se puede optimizar mediante TDD e integración continua con lo cual no es necesario una intercomunicación tan frecuente. Dicho esto aprovecho para introducir una práctica muy necesaria en este escenario, pero tenida por no ágil: la documentación. Como vemos la comunicación se realizará de forma más intensa por código entre dos “feature teams” distintos, por lo que además del TDD y la integración continua es necesario reforzar el grado de legibilidad del código, y eso se hace precisamente con una buena documentación. Recordad que el agilismo no prohíbe la documentación, sólo dice que documentes lo justo y necesario. En proyectos grandes, la cantidad de documentación justa y necesaria es mucho mayor que en un proyecto pequeño. Si no vas a implementar TDD, integración continua y no vas a mantener una buena documentación, tus “feature teams” no podrán coordinarse con efectividad y tu proyecto fracasará.

Como conclusión: es posible gestionar proyectos grandes usando agilismo aunque nuestro equipo se muy grande o esté distribuido. Ciertamente no es el caso óptimo pero la realidad manda. Para afrontar esto hay que estructurar tu proyecto en múltiples equipos pequeños, colocados en la misma sala, multidisciplinares y autogestionados, donde cada equipo implementa una historia completa de usuario detrás de otra. Como sacrificio podemos hacer que cada equipo pueda estar en su propio centro de trabajo, pero la menor interacción entre dos “feature teams” hacen que el TDD, la integración continua y la documentación sean vitales. Como prácticas a evitar están la de estructurar en grupos de especialistas y minimizar el grado de jerarquía.

Read Full Post »


Bueno, aquí sigo con la serie de posts sobre equipos de trabajo ágiles. Me voy a meter en un terreno más especulativo que en los posts anteriores. En éste y en los siguientes posts intentaré investigar y razonar como debemos configurar un equipo desde el punto de vista de su estructura o topología. El razonamiento lo haré desde la perspectiva de la toma de decisiones y la difusión de la información.

Partamos de la estructura más sencilla: un equipo sin estructura, en el que todos los miembros sean iguales, tomen las mismas decisiones y estén igual de informados que los demás. Llamaremos a esta estructura un equipo plano. La idea es que todos los miembros del equipo se comunican entre si de forma libre y van tomando decisiones individuales sobre la marcha. En la siguiente figura se muestra un esquema de como sería un equipo de este tipo con 5 miembros:

Equipo Plano

Equipo Plano

Los nodos representan miembros del equipo y los arcos líneas de comunicación posibles. Como se aprecia cada miembro del equipo tiene acceso directo a cualquier otro miembro, y no existen intermediarios innecesarios. Existen distintos modos de comunicación posibles:

  • Peer to peer. Existe un único emisor y un único receptor. Es la más simple. Un ejemplo sería una conversación privada o una llamada de teléfono.
  • Multicast. Se produce cuando la comunicación alcanza simultáneamente a un grupo escogido de miembros del equipo. Un ejemplo típico es cuando varios miembros se juntan y hacen una reunión, tal vez informal junto a la máquina de café.
  • Broadcast. La recepción de la información es global entre todos los miembros del equipo. Puede ser por ejemplo una comunicación general o un mail masivo. Un ejemplo de broadcast es la difusión de información mediante ósmosis. Ésta se produce cuando tenemos a todos los miembros del equipo en la misma sala, y la información se difunde simplemente interceptando los comentarios de la gente que te rodea, o sea, lo que siempre se ha llamado “enterarte de lo que se cuece”.

Otro punto importante es que parte de la comunicación se realiza mediante señales no verbales, tales como gestos y expresiones faciales. Además el compartir un mismo contexto y entorno agiliza la transmisión de información. Es por esto que se recomienda como buena práctica ágil el tener a todos los miembros del equipo en la misma sala. Ésto va a facilitar la transmisión de información y la toma de decisiones. De hecho existe alguna buena práctica en este sentido como el radiador de información que consiste en tener un tablero o pantalla, bien visible, con información importante del proyecto (estado del build, grado de avance del proyecto, retrasos, etc). La ventaja de  la comunicación broadcast es su rapidez y que evita que se formen grupos de gente que no tengan información importante.

El punto de vista tradicional del agilismo, en lo que respecta a estructuración de equipos, consiste en tener un equipo de gente colocado en la misma sala, que aproveche los modos broadcast de comunicación tales como la ósmosis de información, reuniones diarias y usar técnicas como los radiadores de información. Hasta este punto todo parece sentido común, sin embargo la cosa no es siempre tan bonita como lo pintan. De hecho yo siempre me hago la misma pregunta, ¿cómo de grande puede ser un equipo con estructura plana? En la literatura ágil se suele dar una cifra de un máximo entre 9 o 12 personas. Pero, ¿por qué esto es así? ¿Cómo escala la productividad de un equipo plano en función de su tamaño?¿Qué pasa si realmente necesito un equipo de más de 12 personas debido al tamaño y tiempos de entrega de mi proyecto?¿Tendré que renunciar al agilismo en este último caso? Intentaré explorar estos temas.

Partamos de un modelo sobre como tomamos decisiones. No pretendo que sea un modelo exacto, pero si aproximado, y aunque no tengo datos cuantitativos reales, al menos puedo basarme en mi experiencia. Suponemos que tenemos un tiempo máximo para tomar una decisión, pasado ese tiempo la utilidad de la decisión se desvanece. Este tiempo máximo puede depender del tipo de decisión al que nos enfrentemos. Por ejemplo, si es una decisión de diseño de software podemos tener un par de horas de tope, o si es una decisión sobre como llamar a la siguiente clase que vamos a codificar podemos tener un tope de unos minutos. Para tomar decisiones necesitamos un flujo de datos entrantes que nos informen del estado del mundo. De ese flujo de datos debemos descartar lo que es irrelevante, la información duplicada, valorar posibles falsedades y errores en la información, etc. Esta tarea de filtrado normalmente la hacemos inconscientemente y no la percibimos. Mi idea es que cuanto más flujo de datos tengamos más tardaremos en tomar una decisión acertada. Veamos el siguiente gráfico:

Tiempo de decisión VS. flujo datos entrante

Tiempo de decisión VS. flujo datos entrante

Como vemos al principio nos llega poca cantidad de información, por lo que podemos filtrarla rápidamente, de hecho podemos filtrar y tomar la decisión antes de que nos lleguen más mensajes del exterior. A esta zona le he asignado un tiempo de toma de decisión constante, ya que no se nos “atasca” la información entrante. Si aumentamos el flujo de información vemos que cada vez nos cuesta más filtrar y separar lo que es importante de lo que no lo es, por eso el tiempo va aumentando. Tal vez no aumente linealmente como en la figura, pero aumentará. Sin embargo todavía podemos tomar la decisión antes de que el plazo expire. Finalmente llegamos a una zona donde simplemente no nos da tiempo de analizar todo ya que expira el plazo, en estos casos nos forzamos a tomar una decisión porque “no tenemos tiempo”, decisión que tiene mayor riesgo de ser equivocada. Como siempre todo esto depende de la persona en cuestión que tome las decisiones, en función de experiencia y capacidad algunas personas podrán procesar la información más rápidamente que otras. De nuevos nos encontramos con una de las máximas del agilismo: los miembros de tu equipo deben tener talento, poténcialos.

Os estaréis preguntando que tiene todo esto que ver con la organización de un equipo. Muy sencillo, la forma en la que esté organizado el equipo impacta en como crece este flujo de información en función del tamaño del equipo. En el caso de un equipo con estructura plana, cada miembro recibe un flujo de mensajes de todos los demás miembros, por lo tanto el flujo de información entrante aumenta al menos linealmente con el tamaño del equipo. Si juntamos este hecho con el modelo presentado anteriormente nos damos cuenta que los equipos con estructura plana pierden eficiencia rápidamente conforme aumenta el tamaño de éste. En la siguiente figura podemos ver un esquema de como sería:

Productividad y eficiencia VS Tamaño de equipo

Productividad y eficiencia VS Tamaño de equipo

Conforme el tamaño aumenta, el flujo entrante de información aumenta igual de rápido, esto hace que el tiempo de filtrado de información aumente aún más rápido hasta alcanzar el límite de tiempo de decisión, a partir del cual la calidad de las decisiones degenera debido a las “prisas” y “sobrecarga” y la productividad del equipo disminuye. Cuando estamos todavía en la zona de carga baja añadir un miembro al equipo incrementa la productividad linealmente ya que el tiempo de filtrado sigue siendo constante. Cuando entramos en la zona intermedia, la productividad todavía aumenta pero menos, ya que el tiempo de filtrado de información va aumentando. Cuando alcanzamos la zona límite, donde no cumplimos con el tope máximo de tiempo, añadir un miembro más al equipo sólo empeora las cosas. Como vemos los equipos con estructura plana no escalan bien con el tamaño. Una forma sencilla de arreglar esto es poner personas con más capacidad en el equipo, pero esta medida tiene sus límites.

Otro tema a tener en cuenta es que si bien muchas decisiones son individuales otras conciernen al equipo y al proyecto en su conjunto. Las formas más básicas de tomar decisiones de equipo son las siguientes:

  • El jefe. Existe una persona con la responsabilidad y autoridad para tomar decisiones globales.
  • Comité de sabios. Un subconjunto pequeño de los miembros más expertos del equipo toma las decisiones.
  • Democracia. Se vota y gana la mayoría, ya sea simple o absoluta.
  • Consenso. Todo el mundo debe estar de acuerdo con la decisión.

Los modelos de democracia y consenso escalan mal con el tamaño del equipo. En un modelo de decisión democrático se genera un debate de cara a la votación, si el tamaño del grupo es grande se vuelve a producir la sobrecarga de información o bien el voto “desinformado”. El modelo de consenso escala aun peor ya que cuanto más grande sea el equipo más dificultad existirá para poner de acuerdo a todos. Por otro lado en equipos pequeños estos modelos funcionan bien ya que aumentan la calidad de las decisiones y la moral del grupo.

El modelo del jefe puede minar la moral del equipo y puede ocurrir que la persona a cargo no tenga la capacidad necesaria para tomar las decisiones. También puede desembocar en dinámicas viciosas como la explicada en un post anterior. Es mejor escoger a alguien de mucha confianza y muy respetado para este rol.

En cualquier caso siempre es necesario, tanto para tomar decisiones individuales, como de equipo, que los miembros de éste tengan responsabilidad e iniciativa. Por otro lado, el tener especialistas, en vez de personas multidisciplinares en tu equipo, crea la dinámica de que cada uno toma decisiones para optimizar su “trozo de responsabilidad” y no el conjunto global. De hecho al ser especialistas y no entender el trabajo de los demás, son incapaces de tomar decisiones globales. Esto es especialmente importante si usas el modelo del jefe o de comité de sabios. Éstos deben ser responsables, multidisciplinares y tener iniciativa.

Con todo esto podemos empezar a entrever algunas guías para montar equipos con estructura plana:

  • Si puedes, coloca a tu equipo en la misma sala, aprovecha la ósmosis de información y usa radiadores de información.
  • Tu equipo no debe ser muy grande ya que sobrecargarás de información a los miembros de éste, y su eficiencia tomando decisiones disminuirá.
  • Contrata gente con talento para tu equipo, no solo serán más productivos, sino que admitirán mayor flujo de entrada de información, lo que permitirá que tu equipo escale mejor, pudiendo tener equipos grandes.
  • Los miembros del equipo deben ser responsables ya que sobre ellos recae el tener que tomar decisiones.
  • Monta equipos multidisciplinares, y si es posible que los miembros de éste también sean multidisciplinares. Ésto evita errores y habilita a más gente participar en la toma de decisiones globales al equipo.
  • Si el equipo es pequeño usa consenso o democracia, si ya tiene cierto tamaño es mejor un comité de sabios.

En la otra cara de la moneda, no deberías montar un equipo con estructura plana si:

  • Tienes un equipo distribuido en distintos lugares de trabajo.
  • El proyecto es grande y por lo tanto necesitas un equipo con un tamaño mayor al soportable por una estructuración plana.
  • Los miembros de tu equipo no tienen mucha experiencia o quizás les falta un poco de talento o responsabilidad.

Pero todos sabemos que a veces los proyectos son grandes, la gente no está en la misma sala o simplemente no tienen el nivel de responsabilidad o capacitación. ¿Qué hacemos? Si es un problema únicamente de responsabilidad y capacitación ve pensando en cambiar de miembros de equipo. Si es un tema de tamaño y localización piensa en cambiar la estructura de tu equipo. Este último aspecto lo exploraremos en futuros posts.

Read Full Post »


Continúo con la serie de post dedicado a la definición de equipos de desarrollos ágiles. En el anterior post hice un repaso general de malas prácticas y dinámicas sociales negativas que generan éstas. En éste veremos más en detalle los valores y características que debe tener un miembro del equipo para que éste sea eficaz.

Montar un equipo agile es más que incrementar la frecuencia de feedback, disminuir la burocracia y otras buenas prácticas. Lo más indispensable de todo es simplemente contar con la gente adecuada. No se trata de que simplemente pongamos un jefe de proyecto “buena gente” o de que tengamos programadores de alto nivel, sino de que todos los miembros del equipo, desde el primero hasta el último, jefes, técnicos y gerentes, compartan unos mismos valores y capacidades. Si hay una fracción significativa de los miembros del equipo que no cumplen ésto, simplemente fracasarás en tu intento de implantar el agilismo, uses las prácticas que uses.

El agilismo, en el fondo, propone un metaproceso capaz de adaptar el proceso de desarrollo en si, tanto a los cambios externos como a los errores detectados, con el fin de hacerlo cada vez más eficiente. Por lo tanto no nos vale con contar con gente capaz de seguir un proceso de desarrollo, sino que además deben ser capaces de mejorarlo de forma continua.  Ésto es vital, ya que aunque empecemos con un mal proceso, a través de la mejora continua podremos llegar a uno bueno. Si en cambio, empezamos con un proceso eficaz, y no tenemos capacidad de adaptación y mejora continua, simplemente ocurrirá que tarde o temprano nuestro entorno cambie y nuestro proceso ya no sea eficaz en el nuevo entorno, aunque lo fuera en el antiguo. Cada una de los valores que presentaré a continuación tienen pues como objetivo último, el capacitar a la organización para realizar una mejora continua del proceso de desarrollo, y adaptarlo a cambios en el entorno. Para cada uno de ellos indicaré ejemplos positivos y negativos:

  • Capacidad de aprender las habilidades necesarias para el trabajo. Una persona que tiene esta capacidad puede aprender por si mismo y de forma suficientemente rápida. En el extremo malo nos encontramos con personas que no quieren aprender, o sólo aprenden si reciben cursos. Esta habilidad es vital para poder adaptarse a nuevas tecnologías, métodos y circunstancias de forma rápida y eficaz.
  • Capacidad de detectar errores y problemas. La persona capaz de oler los problemas e ineficiencias, no solo en el código, sino en el proceso de desarrollo, son muy valiosas. Nos permiten reaccionar rápidamente para arreglar problemas, incluso antes de que estos produzcan daños. En el extremo malo encontramos personas que simplemente hacen sus tareas sin darse cuenta de los problemas, aunque se produzcan delante de sus narices ¿Alguien sabe leer una traza de una excepción?
  • Aprender de los errores. Equivocarse no es malo, lo malo es equivocarte y no aprender de ello, equivocarse una y otra vez en lo mismo. Ésto es propio de zombis no de personas.
  • Capacidad para enseñar a los demás. Esto es fundamental sobre todo en los roles de más responsabilidad. Un rasgo importante de un jefe eficaz y de un buen compañero es saber enseñar a los demás a hacer las cosas bien y a mejorar. Esto nos permite absorber a gente sin experiencia o incluso con malos hábitos y convertirlos en miembros del equipo productivos, te permite mejorar no a ti, sino a la gente que te rodea.
  • Capacidad de cuestionar las cosas de forma racional, incluyendo los modelos mentales ya establecidos. De esta forma simplemente seremos capaces de no quedarnos ciegos con modas y modelos mentales preconcebidos, impidiéndonos ver nuevas posibilidades y haciéndonos vulnerables al marketing. Ya hablé de esto en mi primer post.
  • Jugador de equipo. Los proyectos son realizados por equipos, no por individuos. Se necesita gente que mire por el conjunto del equipo y no solo por sus propios intereses, ignorando las necesidades del conjunto. Actitudes típicas tales como “el marrón es tuyo” o “balones fuera” son propias de gente egoísta y totalmente prohibidas en un equipo ágil. Todos deben colaborar para conseguir el objetivo común. Si no que se lo digan a algún que otro equipo de fútbol.
  • Iniciativa para ejercer todas las capacidades anteriores de motu propio sin necesidad de que alguien te lo ordene. Si no tienes iniciativa, a lo máximo que llegarás es a ser un burócrata que “hace su trabajo según el procedimiento”, y eso con suerte. Esto es totalmente opuesto a la filosofía agile.
  • Motivación. Este factor es muy frágil y no depende totalmente de la persona, sino de su entorno. Si los compañeros juegan en equipo, los proyectos tienen éxito, aprendes y ganas un sueldo digno, tu motivación sube.

Aprovecho ahora para definir el termino calidad referida a una persona. Cuanto más y mejor cumpla una persona los valores y capacidades definidos anteriormente, diré de ella que tiene más calidad. No penséis que me refiero a su calidad como ser humano, sino a su calidad como miembro de un equipo que cobra por hacer un trabajo. Tampoco penséis que la calidad depende sobre todo de la experiencia o titulación de esa persona. Pensad que es mucho mejor contratar a alguien sin experiencia pero con capacidad de aprender y jugar en equipo, que a alguien de mucha experiencia sin estos valores. El primero aprenderá sobre la marcha, y cuanto más listo y experto sea, más rápido aprenderá, pero aunque no sea el más inteligente terminará aprendiendo. Por el contrario es muy negativo tener a un super experto pero que no juega en equipo, que no enseña a los demás, no colabora y echa siempre balones fuera.

Es importante detectar si la gente que ya tenemos cumplen estos valores, y si no los cumplen, diagnosticar por qué no. Tal vez sólo están inmersos en una dinámica negativa y no conocen otra cosa, pero pueden llegar a mejorar. O en el peor de los casos simplemente esa persona es incapaz de mejorar, en cuyo caso es mejor prescindir de ella.

Algunos estaréis pensando lo mismo que yo: en muchas empresas la política de contratación y RRHH es totalmente diferente, se basa en criterios como el sueldo, la apariencia o simplemente el azar. Todo esto forma parte de la dinámica negativa que comenté en el post anterior. En cualquier caso, nunca he visto a ninguna empresa completar los proyectos con éxito con este enfoque, aunque sí ganar dinero (usando prácticas poco éticas).

Por último sed indulgentes conmigo y permitid que me flipe un poco ;-) A continuación mostraré un gráfico sobre cómo evoluciona la productividad de un equipo en función de la calidad media de sus miembros. Por supuesto es un gráfico totalmente subjetivo y basado en mi experiencia. Para hacer uno objetivo tendríamos que poder tomar métricas sobre productividad del equipo y sobre la calidad de una persona, cosa que en si sería una tarea muy compleja. Sin embargo tras muchos años uno coge un feeling sobre como funcionan las cosas. Sin más preámbulos allá va:

Productividad en función de la Calidad Humana

Productividad en función de la Calidad Humana

Como veis tiene dos lineas: la del sentido común, y la que me dice mi experiencia. En la primera todo va como esperado, el aumento de productividad del equipo es lineal con respecto a la calidad de sus miembros. Sin embargo mi experiencia me dice que esto no es real. Si os fijáis en la otra serie, la productividad aumenta mucho más rápido en función de la calidad del equipo. Tal vez sea una aumento exponencial, ¡ o mayor ! Incluso puede llegar a producirse un efecto de discontinuidad: una persona de alta calidad será capaz de solucionar problemas que una persona de baja calidad sea incapaz de resolver, produciéndose en este caso un aumento infinito de la productividad (discontinuidad).

Como conclusión: si queréis montar un equipo eficaz, el primer paso es contar con la gente adecuada, mientras no consigais esto, no os molesteis en intentar otra cosa. Al fin y al cabo el proceso de desarrollo lo implementan y ejecutan personas, si éstas no son capaces, el proceso fracasará.

Read Full Post »


La idea para este post me la dio un comentario en el post de víctimas de la moda, alguien dijo que un arquitecto era visto como 5 programadores por parte de los gestores de proyecto. Ésto me hizo pensar en escribir una serie de posts abordando como se suelen montar los equipos de desarrollo y el efecto de éstos en el éxito de los proyectos. En este post daré mi opinión sobre los roles en un proyecto típico.

Muchas veces viendo como se organizan los equipos de desarrollo me da la impresión de contemplar un sistema social basado en castas, más propio de eras anteriores que de un entorno de alta tecnología. En mi opinión en muchos entornos empresariales los roles de los miembros de un equipo típico se asemejan más a clases sociales que a otra cosa. Esto es una tendencia muy peligrosa que hace que el equipo no actúe como tal, sino como una jerarquía señor/vasallo, y se transforme en varios grupos que desconfían los unos de los otros y se desprecien mutuamente. ¿Cómo se llegó a esta situación? Es difícil de saber, pero creo que hay varias causas:

  • El mal entendimiento por parte de los gestores en muchos clientes de lo qué es un proyecto software.  Ésto es comprensible ya que la mayoría de los clientes no saben construir software, no es su negocio, ¡ si lo supieran no necesitarían subcontratar ! Esta falta de entendimiento fue explotada por algunas empresas del sector, lo que ha creado desconfianza ¿Recordais cómo era todo antes del crack de las punto com…?
  • El concepto de gestor universal. Un gestor universal es alguien que cree que puede gestionar un proyecto de un área que no entiende usando herramientas genéricas. Tal gestor aplicará las mismas técnicas de gestión a un proyecto de software que a un proyecto de construcción de vivienda que a la organización de un equipo de administrativos. Obviamente esto es una concepción errónea que lleva al desastre. Si creemos en este principio terminamos con jefes de proyecto que no saben informática y que no se enteran de lo que ocurre de verdad en su proyecto.
  • Derivado del punto anterior nace la concepción errónea de que los informáticos son intercambiables, como si fueran piezas mecánicas de una maquinaria. Ciertamente esto puede ser real en otras áreas de gestión, pero no en la informática. El resultado típico es que los gerentes ven a los técnicos como simples obreros que no dan valor añadido y no son muy distinguibles de un administrativo, generando actitudes altivas y poco colaborativas y dialogantes. Además este prejuicio puede llegar a hacer que se considere que un técnico deba cobrar poco comparado con otros roles. Como reacción el técnico pensará mal del jefe de proyecto y lo considerará un opresor. Esta creencia es falsa, entre otras cosas porque un técnico tiene mucha información en su cabeza sobre el proyecto que uno recién llegado no tiene, y la productividad de los técnicos varía en función de su talento de una forma mucho más acusada a como varía ésta entre dos personas que realizan tareas mecánicas y repetitivas.
  • Carrera profesional. Como cada rol pertenece a una casta, es normal pagar más dinero a las castas más altas. Como la casta más baja es la de programador entonces será la que menos cobre. Te puedes encontrar con un jefe de proyecto sin nada de experiencia que cobre mucho más que un desarrollador con mucha experiencia y que produzca por diez desarrolladores normales. Lo que es peor, este desarrollador experto y talentoso tendrá un sueldo similar al de un desarrollador sin iniciativa ni talento. Esto hace que los desarrolladores se desincentiven, y no quieran seguir siendo desarrolladores, sino jefes de proyecto. Al fin y al cabo nadie va a reconocer nuestra capacidad como tales. Esto genera una dinámica que lleva a que escaseen los desarrolladores expertos y arquitectos, disminuyendo la calidad del equipo y aumentando la dificultad de contratar a un nuevo desarrollador que sepa lo que hace.

Todo esto puede generar dinámicas muy dañinas y un sistema de trabajo vicioso:

  • Alta rotación. Los miembros de las castas más bajas se sienten maltratados y deciden marcharse. Ésto genera a su vez que el conocimiento escape del equipo y la productividad baje. Como reacción el gerente para reemplazar esta baja puede decidir contratar. Como éste y RRHH no saben distinguir a un buen técnico de otro que no lo es, le resulta muy golosa la opción de contratar más barato. De esta forma podrá tener más miembros en el equipo con lo cual todo va a ser más productivo, ¿verdad? Y además al ser más barato se lo tendrá “menos creído y será más dócil”. Total, tampoco es muy importante la cualificación, porque no es más que un “obrero”. Para escribir en un teclado no hace falta saber mucho. Por este camino puedes llegar a terminar con un equipo bastante grande, lleno de gente sin capacidad técnica y/o sin iniciativa.
  • Sabotaje. El técnico está tan quemado que simplemente realiza código de baja calidad, no hace pruebas, copy&paste, etc. Al fin y al cabo al jefe de proyecto sólo le interesa llegar en fechas, y tener terminado tal funcionalidad para la reunión de seguimiento tal, que si no le riñe el cliente. Además el jefe de proyecto no es técnico con lo que no puede detectar estas malas practicas. El que se introduzcan defectos en el software no es evidente en el momento, lo que hace que el jefe de proyecto piense que todo va bien hasta que la situación explota.
  • Más madera. Como tenemos problemas, pongamos más gente. Hay que presionar a RRHH para que contraten rápido y barato. RRHH ante esa presión contrata rápido y barato, es decir mal. Tu equipo crece sin mesura y se llena de técnicos sin capacidad.
  • Zombis. Ya que contratamos barato, puedo convencer al cliente de que su proyecto va mal y necesita “más madera”. Yo le vendo que le contrato 10 técnicos de los buenos más, a tarifa buena y contrato 10 cadáveres para que calienten la silla. Los cadáveres son baratos y el volumen del proyecto aumenta, con lo que es más rentable. Realmente esto es un técnica propia de consultoras sin ética ni escrúpulos, que es posible debido a que el cliente no sabe diferenciar entre zombis y desarrolladores.
  • Proyecto cerrado y horas extras como recurso común. La defensa del cliente ante “más madera” y “zombis” es cerrar el proyecto en tiempo y dinero. De esta manera no puede ser engañado por empresarios sin escrúpulos. Esto genera que cualquier sobrecarga de trabajo se termine ejecutando como horas extras y la consiguiente bajada de productividad y “quemamiento” del equipo, lo que aumenta la rotación.
  • Metodología pesada. Debido a “más madera”, tienes un equipo muy grande. No sabemos como hacer que muchas técnicas del agilismo escalen bien a equipos grandes. Además los malos resultados del proyecto hacen que el cliente desconfíe. Como conclusión los gestores se sienten reafirmados en su metodología pesada, ya que el agilismo es “para proyectos de juguete” y “tenemos que controlar a todos estos sinvergüenzas”.

Si pensáis que lo que cuento es una exageración, yo he conocido proyectos en los que los jefes de proyectos no sabían manejar un ordenador pero si hablaban un inglés de nivel. He visto zombis atestar salas de trabajo, sí, lo he visto en alguna gran consultora, aunque afortunadamente nunca he trabajado para ellos y no todas son tan malignas como las pintan.

Lo peor es que esta dinámica se refuerza a si misma con lo que es muy difícil de romper y se transforma en el modelo mental por defecto de las personas involucradas en la informática. Lo aceptan como una verdad evidente y no se plantean que las cosas pueden ser de otra forma y te dicen olvídate del agilismo, es un cuento de hadas“. Cuando alguien llega nuevo a este negocio, los que ya están en él, y metidos en esta dinámica viciosa, te cuentan que las cosas son como son y que no se pueden cambiar. Que se contrata barato y mal porque no te puedes fiar de un desarrollador y el proyecto siempre se sale del presupuesto; que se hacen proyectos cerrados para que el presupuesto no se vaya de madre y no nos engañen; que te olvides del TDD que eso lo que hace es quitarte productividad y nadie te lo va a agradecer; que te olvides del pair programming, que lo único que hace es disminuir la productividad a la mitad, y encima cuando viene el cliente ve la mitad de sillas ocupadas… No se dan cuenta que esta dinámica ineficiente no es una propiedad intrínseca de los proyectos software sino causados por una mala gestión y por muchas concepciones erróneas. Ésto es una de las causas más importante de resistencia al agilismo, el pensar que el desarrollo de software es así y no se puede hacer de otra forma.

Precisamente en el agilismo se intenta eliminar este ciclo vicioso. Para ello usa diversas técnicas:

  • Tener una persona que actúe como puente entre el cliente y el equipo. Sepa defender los intereses del cliente pero de forma razonable e interaccione frecuentemente con el equipo. Debe filtrar y priorizar los requisitos del cliente y ser capaz de pasárselos al equipo. Es como tener un cliente a tu lado continuamente, es el Producto Owner.
  • Enseñar resultados frecuentemente al cliente. Resultados tangibles, demos, pruebas de concepto, prototipos, la aplicación parcialmente construida, etc. El cliente puede no entender de software pero si que va a entender la demo. Al permitir un mejor seguimiento, evita recelos por parte del cliente y aumenta la confianza con lo que la dinámica social del proyecto mejorará.
  • Persona que actúe como jefe de proyecto, actuando como enlace principal con el Product Owner, siguiendo el desarrollo del proyecto día a días, y encargado, de forma principal, de eliminar cualquier impedimento para el buen avance del proyecto. Al contrario que el jefe de proyecto tradicional, debe tener la suficiente capacidad técnica como para entender problemas de índole técnica, además de problemas organizativos. De esta forma será capaz de tomar decisiones cabalmente y detectar malas prácticas. Además debe hacer una labor de enseñanza del método de trabajo que se esté siguiendo. En SCRUM, por ejemplo, a este rol se le denomina Scrum Master.
  • Tener siempre en el equipo a un miembro de gran talento y experiencia que además de trabajar y producir en el día a día, se encargue de evitar pitfalls típicos, de plantear soluciones problemas difíciles y que actúe además como mentor del resto del equipo. Tradicionalmente lo más parecido a esto es un arquitecto. La diferencia está en que es un arquitecto que trabaja continuamente con su equipo, produciendo código y enseñando a los demás. No es alguien que aparece para arreglar un incendio y desaparece. Ni tampoco alguien que desprecia a los desarrolladores, se dedica a pintar cajitas y citar a gurús. Si la carga de trabajo lo permite, este mentor y el Scrum Master pueden ser la misma persona.
  • Motivar a los desarrolladores. Pagarles justamente y evitar horas extras como recurso común, escuchar lo que tengan que decir (daily meetings, retrospectivas, reuniones de planificación, …) Esto evita la rotación y aumenta el entusiasmo del equipo. También evita el cansancio de las horas extras.
  • Si se necesitan horas extras, que sea de forma excepcional, y que todo el mundo las sufra, desarrolladores, jefes de proyecto, etc.
  • Contratar a personal competente y eliminar de tu equipo a personas sin motivación para hacerlo bien y sin capacidad de hacer su trabajo. Esto normalmente implica hacer una buena selección de RRHH, lo que a su vez es incompatible con las prisas.

Un error común al implantar el agilismo es usar como Scrum Master a un jefe de proyecto con la mentalidad tradicional, y contratar como miembros del equipo a personas sin motivación y sin capacidad técnica. Esto hace que al final no se haga agilismo, por mucho que los roles parezcan ágiles. El desarrollador sin motivación y capacidad producirá poco, no escribirá código con calidad suficiente, no tendrá iniciativa, etc. El jefe de proyecto que siga pensando que está por encima del resto de los miembros del equipo y que no entiende el proyecto, generará la misma dinámica viciosa de siempre.

Otro error clásico es hacer que el Product Owner o no exista o sea el mismo jefe de proyecto. Esto es un error porque el primero representa al cliente y el segundo al equipo, si hacemos coincidir los dos roles en el jefe de proyecto corremos el riesgo de no atender a las necesidades y prioridades reales del cliente y caer en prácticas no éticas. Si hacemos coincidir ambos roles en una persona del cliente el proyecto se convierte en barra libre y nadie atiende a las necesidades y problemas reales del equipo.

En el fondo de todo esto está la enseñanza que creo más valiosa del agilismo: lo más crítico no es el proceso sino la gente que componen el equipo y dan vida a ese proceso. No gastes pues tanto en procesos, y preocúpate porque la gente que contrates sea apta para su puesto y sobre todo que sepan jugar en equipo, al fin y al cabo el desarrollo de software es un juego de equipo, no de individualistas.


Read Full Post »

« Newer Posts - Older Posts »

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 41 seguidores