archivo

Archivos Mensuales: noviembre 2012

Uno de los fundamentos de Kanban consiste en limitar el trabajo en curso a la capacidad del conjunto de personas que lo tienen que llevar junto a la visualización del flujo de trabajo (gestión visual).

El flujo de trabajo es una división en fases o estados del ciclo de vida de una tarea teniendo en cuenta las particularidades que se pueden producir en el mismo.

El límite del trabajo en curso se puede definir para cada una de las fases en que se divide el flujo. Probablemente no aciertes a la primera (ni tu ni un experto), lo importante es ir depurando poco a poco esos límites.

Tampoco es obligatorio que pongas límite a todas las fases, puedes empezar con una de ellas. Lo mismo al principio para ir familiarizándonos con esta forma de trabajo puede ser suficiente con tener, simplemente, una visión del flujo de trabajo (sería como tener un límite infinito en cada una de las fases), teniendo en cuenta que no estaríamos aplicando Kanban porque no estamos limitando el WIP.

¿Por qué limitar la cantidad de trabajo en curso? Para ganar en predecibilidad. Si la cantidad de tareas abiertas es ilimitada difícilmente podemos hacer estimaciones realistas del tiempo que vamos a tardar en ejecutar una de ellas (una cosa es el tiempo estimado en realizar una tarea y otra el tiempo real que se tarda en ejecutarlas, teniendo en cuenta esos parones que se sufren por tener que abandonarla y dedicarnos a otras), salvo que se priorice de tal forma que el hecho de que aparezcan nuevas tareas no influya en su ejecución.

También permite ganar en eficiencia, no entran nuevas tareas hasta que existe capacidad para abordarlas, esto implica que el equipo y el departamento (o la organización) colaborarán (porque no les quedará más remedio) en solucionar los cuellos de botella o circunstancias que afectan a la producción.

A diferencia de lo que suele ser habitual el trabajo no es consecuencia de lo que entra sino de lo que va saliendo porque hasta que esto no ocurre no se pueden abordar nuevas tareas si se ha llegado al límite de capacidad.

También permiten detectar sobrecarga en la actividad (y/o existencia de cuellos de botella en alguna de las fases) que describe el flujo de trabajo cuando se generan colas en la entrada (esta idea es aplicable a si se producen colas en una fase concreta del flujo de trabajo). El límite a partir del cual se considera que existe sobrecarga dependerá del contexto de cada actividad, si bien y sin hacer ningún tipo de análisis concienzudo, si vemos que en momentos concretos o de manera continua la cola no para de crecer es que pasa algo y hay que analizarlo (otra cosa es que se pueda dar una solución, al menos, a corto plazo). Es la ventaja de poner límites y de realizar una gestión visual.

El producto que desarrollamos no es para nosotros (no suele serlo) sino que es para los usuarios del mismo. Olvidamos en demasiadas ocasiones algo tan simple y después nos genera muchos problemas ya que el producto no tiene que ser a nuestro gusto sino a gusto de quien lo va a utilizar.

Si el usuario no interviene de manera continua en el desarrollo, si lo hace con desgana o como su octava prioridad tenemos un problema y lo tenemos sea cual sea el enfoque utilizado en el proyecto. Si el usuario no quiere poco más podemos hacer nosotros.

En este tipo de circunstancias lo mejor sería rescindir el contrato o dar por terminado el proyecto y no invertir más esfuerzo en algo que probablemente no vaya a dar buenos resultados. Lo mismo acertamos y hacemos un producto decente y que se adapta a las necesidades del usuario pero ¿qué probabilidades hay que muestre el suficiente interés como para utilizarlo si no siquiera a mostrado interés en su desarrollo?.

Sin embargo los intereses del proveedor (hemos firmado un contrato por X euros y no nos vamos a conformar con quedarnos con X/4) y de los del cliente (ya hemos gastado X/4, ¿cómo justifico este gasto?) hace que pocas veces se decida parar con el proyecto.

Y esto pese a que el proveedor terminará perdiendo dinero ya que siempre habrá un problema nuevo reportado u ocasionado por el usuario en diferentes etapas del desarrollo que dará lugar a parones, a tirar y a volver a desarrollar parte de la aplicación, etc… (esto no lo considero feedback ya que para que sea entendido así debe realizarse con intención de evolucionar el producto y no con la intención de “boicotear” el proyecto) y pese al desgaste en las relaciones entre las partes porque este tipo de usuarios tiene la tendencia de echar la culpa al equipo de desarrollo y el cliente (salvo honrosas excepciones) tiende a defender a los suyos (incluso sabiendo que no tienen razón).

Y esto pese a que también el cliente perderá dinero ya que el gasto se terminará gastando X (en gastos directos con el proveedor) más otra cantidad por los propios gastos internos que ocasionará el proyecto (y probablemente se termine incluso pagando más al proveedor para realizar tareas de mantenimiento de un producto que nunca terminará de arrancar). Si al final el producto fuera un éxito podríamos pensar que bueno, tarde o temprano amortizaremos la inversión, sin embargo no será así, difícilmente será así porque el producto ha seguido una línea de desarrollo en la que el usuario no ha mostrado un interés real en que se construya un sistema que resuelva de manera adecuada y eficiente el proceso o procesos que se querían informatizar.

Sí y muchísimo. Y también dentro de las propias prácticas ágiles hay prácticamente una infinidad de alternativas.

No olvidemos lo siguiente: El proyecto se realiza bajo un contexto y el producto que se tiene que obtener a partir de él tiene unas características. Nuestro objetivo es aplicar la estrategia que mejor convenga al proyecto dentro de ese contexto y del conjunto de restricciones que tengamos.

Lo mismo lo más conveniente para el proyecto o las restricciones del mismo nos empujan a un enfoque clásico. Se trata de ser pragmático y pensar en cumplir los objetivos.

¿Por que defiendo entonces la agilidad? En primer lugar porque se trata de una actitud ante los proyectos que es prácticamente independiente de su enfoque. Incluso en un enfoque clásico puedo tomar decisiones o aplicar determinadas estrategias propias de metodologías ágiles. Esa actitud pienso que es positiva y se adapta a la propia naturaleza del desarrollo de software.

¿Por qué la agilidad es válida en más escenarios? Precisamente por su flexibilidad y por su versatilidad.

Yo he trabajado en muchos proyectos con enfoques clásicos y he sufrido muchísimo con ellos, de hecho (y así lo he comentado en el blog) cuando descubrí el agilismo fue como una bocanada de aire fresco porque precisamente es hacia allí donde se dirigía el enfoque que estaba intentando darle a los nuevos proyectos solo que todavía estaban dominados por enfoques clásicos.

¿Qué quiero decir con esto? Pues que tanto he sufrido con los enfoques clásicos que perfectamente podría pensar en mandarles a paseo y olvidarme de ellos, sin embargo, es algo que ni puedo ni debo hacer porque la aplicación de estrategias y/o metodologías ágiles de manera integral no siempre es posible y cuando esto ocurra tenemos que aplicar otro tipo de enfoques (sin olvidar que siempre podremos hacerlo desde una actitud ágil).

Es evidente, no hay nada más que ver la gran cantidad de conferencias, seminarios, certificaciones, etc… que tras el agilismo hay también un negocio. Muchas personas contrarias al movimiento ágil lo utilizan como argumento para deslegitimarlo: “…si la agilidad es algo tan positivo no entiendo porque es necesario darle tanto bombo”.

A mi no me parece mal que haya quienes quieran ganar dinero o ganarse la vida mediante la divulgación de este enfoque de desarrollo de software ya sea desde un punto de vista generalista o mediante la divulgación de estrategias o metodologías concretas y, por tanto, no entiendo que eso pueda ser utilizado como arma arrojadiza contra el agilismo.

¿Qué hay cierta saturación? Es posible pero no por ello tiene que ser negativo. Cada desarrollador, cada profesional expresa su punto de vista basado en su experiencia (contextualizada por los tipos de proyectos, tipos de clientes y la cultura de la región o regiones en las que ha trabajado) y su conocimiento y lo hacen a través de publicaciones, artículos, seminarios, conferencias, etc… Cada cual tiene algo que decir y probablemente tenga cosas que aportar con respecto a los demás porque se habrá encontrado con circunstancias diferentes que le habrá llevado a trabajar de una determinada manera o incluso trabajando en circunstancias similares ha podido aplicar un enfoque o un estrategia diferente.

Lo que sí hay que tener en cuenta que cada uno de esos expertos expresa su punto de vista, influido por el contexto o contextos en los que ha trabajado por ese motivo lo importante es reflexionar sobre lo que te cuentan, aplicar aquellas prácticas que consideres interesantes y no perder la atención si no consigues encajar lo que te cuentan con tu entorno laboral (tal vez no puedas llevar a la práctica lo que te dicen tal como te lo dicen pero es posible que haya ideas que permitan que en determinadas circunstancias puedas enfocar mejor los proyectos o determinadas contingencias dentro de los mismos).

La respuesta es compleja ya que depende del enfoque que tengas por lo que dar una respuesta en términos absolutos hará que los resultados en muchos casos sean erróneos.

En cualquier caso y con respecto a enfoques clásicos de desarrollo sí que supone una fuerte ruptura si bien la tendencia natural de la mayoría de los que han aplicado ese tipo de enfoque ha sido tender hacia enfoques más flexibles aproximándose a lo que sería un enfoque ágil. De hecho se venían aplicando enfoques ágiles, así como estrategias y metodologías mucho antes de que el Manifiesto Ágil fuera publicado.

¿Por qué una ruptura respecto a los enfoques clásicos? Porque sitúa en primer lugar al producto y a las personas mientras que en los enfoques clásicos todo estaba supeditado al proceso (o por lo menos estaba por encima del producto y las personas).

Según el enfoque clásico, estas son las etapas y los hitos a cumplir en cada una de ellas obteniendo análisis y diseños que después se materializarían mucho más tarde en un producto software (planteamiento más rígido). Hasta la entrega del producto el usuario no realizaba un feedback sobre un elemento no abstracto, hasta entonces lo menos abstracto con lo que había trabajado eran prototipos.

Pero no se trata solo de intentar que el feedback del usuario sea de la mayor calidad posible y cuanto antes, sino que se trata sobre todo de entender la singularidad de los proyectos y de su realización en un contexto concreto que probablemente cambie, lo que hace necesario centrar la atención en el producto y en las personas que intervienen en su definición y construcción, se trata de adaptarnos por tanto al producto que se va a desarrollar dentro del contexto en que se realiza el proyecto, no se trata por tanto de aplicar una metodología o un proceso como un martillo de oro que asegura el éxito en todos los casos sino de adecuar nuestros esquema de trabajo al producto que vamos a desarrollar.

En un entorno con una incertidumbre inherente es fundamental poder adaptarse al cambio y eso implica por un lado no poder estar atado con procesos rígidos (salvo que el contexto del proyecto o la naturaleza del producto que se desarrolla te obligue a ello) y por otro la existencia de una comunicación fluida entre todos los participantes en el proyecto pudiendo realizar, dentro de los márgenes que existan para ello, ajustes sobre condiciones o planificaciones que previamente se han establecido.

El enfoque ágil no es la consecuencia de hacer menos pesados los enfoques clásicos, no se trata de trabajar con procesos más ligeros o entregar menos documentación (no es solo eso), sino que supone un cambio más radical (entre otros): producto sobre proceso, cambio del modelo de comunicación entre las personas y adaptación al cambio.

Leyendo una lista de correos sobre desarrollo ágil y Scrum de hace algo más de diez años me he encontrado con una interesante cita de Tim Rentsch de hace treinta años: “…La programación orientada a objetos será en los años 80 como la programación estructurada lo fue en los 70. Todo el mundo estará a favor de ella. Cada proveedor promoverá sus productos y le dará apoyo. Cada gestor pagará por ella. Cada programador la practicará (diferentemente) y nadie sabrá que es lo que es”.

Es cierto que cuando se expande un concepto y se convierte en moda se tiende a ir ciegamente hacia ese modelo sin ni siquiera pensar los fundamentos que hay detrás de él. Se cree que por el simple hecho de haber golpeado fuerte es necesario seguirlo sin condiciones.

No te conviertes en agilista por aplicar Scrum (o estrategias similares), como no te hace carpintero saber utilizar una sierra, una lija y un martillo. Primero es necesario adquirir actitud ágil entendiendo por qué surge este movimiento y cuales son sus fundamentos. Aplicar estrategias, enfoques, metodologías, instrumentos, etc… viene después.

Según Beedle la reflexión de Rentsch era totalmente válida para la década de los 90′, situando la tasa de absorción de la programación orientada a objetos en torno a 20 años o más que es más o menos el tiempo que predice (lo hizo hace diez años) que se tardará en que el agilismo no sea solo un concepto extendido, sino que además sea mayoritario su entendimiento entre sus practicantes.

Es cómodo trabajar y probar el programa en tu equipo, lo tienes preparado a tu gusto y tienes todo lo necesario para que el sistema corra.

Sin embargo, cuanto más tardes en integrar tu trabajo con el resto del producto o cuanto más tardes en probar tus desarrollos en un entorno de integración mayor será el coste de resolver las incidencias que te puedes encontrar, es más, si decides entregar el producto sin ni siquiera haber realizado un testing serio en integración estás cometiendo una temeridad (eso del “funciona en mi equipo” mejor ni siquiera mencionarlo).

Y es temerario (porque siempre se suelen dejar cabos sueltos y porque en tu máquina no tiene que coexistir con otros sistemas de información que estarán instalados en el mismo servidor) incluso aunque te hayas esforzado (cosa que no se suele hacer) en utilizar la misma versión de máquina virtual que el sistema operativo del servidor de integración, las mismas infraestructuras que se van a utilizar para instalar la aplicación en el entorno de integración (control de versiones, repositorio de librerías dependientes, sistema de integración continua, etc…), la misma versión del servidor de aplicaciones, la misma base de datos y juego de datos, etc…

Es necesario acudir a un entorno de integración (a ser posible en sede de cliente con una infraestructura tecnológica que sea lo más similar posible a producción), no es ninguna pérdida de tiempo. La pérdida de tiempo (y de dinero) viene después cuando te echan para atrás la entrega ya que al coste adicional de corregir las incidencias hay que sumarle el hecho de que te corta el ritmo de desarrollo ya que no es lo mismo corregir determinadas incidencias leves que se hayan colado en producción a tener que revisar una entrega completa (con su testing correspondiente) independientemente de que los errores estén más o menos localizados además de preparar la entrega correspondiente.

No recomiendo utilizar el entorno de integración como entorno de desarrollo (de diario) porque generalmente se deja “basura” que después termina quedándose en la entrega y que pueden provocar que la misma sea rechazada (al fallar el testing del sistema en un entorno de preproducción) o que la misma, siendo inocua termine llegando a producción y nos encontremos por ejemplo con tablas de base de datos que no sirven para nada, clases que contienen métodos que no se utilizan, etc…