archivo

Archivo de la etiqueta: Kent Beck

Comenta Kent Beck que: “Los buenos equipos no sólo hacen su trabajo sino que además piensan cómo y por qué están trabajando. Analizan por qué tuvieron éxito o fracasaron. No tratan de ocultar sus errores en su lugar los exponen y aprenden de ellos. Nadie tropieza en la excelencia”.

Parece que es parte de nuestra condición huir de los errores, sin embargo, tratar de hacerlo es como intentar escaparnos de nuestra propia condición de seres humanos ya que todos cometemos errores, nadie es infalible. Piensa en alguien que crees que nunca se equivoca, pues sí, esa persona en la que estás pensando seguro que se equivoca tanto o más que tú, la diferencia realmente está en qué hacemos con nuestros errores, si lo utilizamos para evolucionar o simplemente los esquivamos.

Kent Beck insiste mucho en la oportunidad que se abre tras un error. Y me parece muy consecuente que lo haga porque tiene bien claro que la naturaleza del desarrollo de software es evolutiva y que en ese proceso de evolución hay aciertos y errores porque todos sabemos que acertar siempre a la primera es muy difícil y porque el mayor atajo para una solución compleja no es la línea recta sino pasar por soluciones más simples en las que se vayan afianzando ideas que tienen un origen abstracto.

Llegar a producción da miedo. El área usuaria siempre tendrá el “síndrome de la última versión” y, por tanto, querrá incluir toda la funcionalidad que puedan y pondrán los umbrales de aceptación muy altos.

A los desarrolladores también les entra el pánico porque por muchas pruebas que se hayan realizado al producto es en producción donde se pasa el examen final, todo lo anterior son exámenes parciales que si bien hay que superarlos no tienen más trascendencia (y no con ello quiero quitale importancia) que crisis puntuales en el proceso de desarrollo.

Si hay presión en el desarrollo, no es comparable con la que se recibe si el producto llega a producción y es un desastre.

Esta situación puede eternizar el paso a producción en muchos proyectos de desarrollo de software.

Ante esto hay que reflexionar (usuarios y desarrolladores) sobre las características del sistema de información que vamos a poner en producción, si se trata del software de una central nuclear o un software crítico que puede poner en riesgo vidas humanas, la salud de las personas, el medio ambiente o la continuidad de la organización se puede entender que toda precaución es poca, pero fuera de ese círculo (que es la inmensa mayoría de los sistemas que se desarrollan) hay que evaluar el coste real que implica retrasar sistemáticamente un paso a producción por el intento de alcanzar una perfección que nunca se va a conseguir.

Ya lo dice Kent Beck: “No estar en producción es gastar dinero sin hacer dinero”.

Es cierto que hay proyectos que entran en unas espirales que hace que prácticamente parezca eterno el tránsito entre su inicio y la puesta en producción de una primera versión del mismo.

Es muy mal síntoma (en términos generales) que un proyecto tarde mucho en poner una primera versión en producción. Es más, de primera mano os puedo decir que no conozco ninguno que tardando demasiado haya sido un éxito.

Tarde significa más tiempo en obtener feedback, más coste para evolucionar el producto (incluso habiendo cuidado la deuda técnica), llegar tarde al momento más adecuado para poner en marcha el producto y la puesta en marcha del sistema con una tecnología muchos meses anterior (incluso años anterior) a la que actualmente se desarrolla en la organización.

Muchas veces son las propias contingencias del proyecto las que llevan a eso pero en otros muchos casos somos los propios desarrolladores (utilizando como excusa esas contingencias o no) los que retrasamos la puesta en producción por ese afán de perfeccionar algo que hasta que no se utilice realmente seguirá siendo abstracto (o si es algo concreto el feedback no tiene la misma fuerza).

Me parece muy interesante la siguiente reflexión de Kent Beck como punto final a este artículo: “Prepárate para el éxito. No te protejas del éxito reteniéndolo. Hazlo lo mejor posible y después asume las consecuencias”.

Hace poco tuve la oportunidad de leer la siguiente cita de Kent Beck y realmente es una de las mejores definiciones de lo que supone el proceso de desarrollo de software: “El desarrollo de software es siempre un diálogo evolutivo entre lo posible y lo deseable”.

Tenemos que tener en cuenta que partimos de unas restricciones y que aunque algunas de ellas puedan ajustarse en el proceso de desarrollo sí que establecen una serie de límites en el resultado final del proyecto.

Tomaremos decisiones constantemente siempre por el bien del producto (o al menos esa debe ser la intención) en las que tendremos que sacrificar determinadas líneas de desarrollo, funcionalidades, estrategias de diseño o implementación a cambio de un mejor acabado. No es fácil tomar esas decisiones y resulta complicado alcanzar determinados consensos porque cada cual entiende que vela por sus intereses algo comprensible pero erróneo porque el interés real es que el resultado final sea satisfactorio y no tenemos infinitos recursos e infinito tiempo para conseguir ese producto perfecto (que probablemente no consigamos nunca).

Lo fácil es decir a todo que sí pero después hay que estar preparado para recoger los trozos que queden del proyecto cuando a medias nos hayamos quedado sin presupuesto, no haya posibilidad de ampliarlo y el sistema tenga una complejidad muy superior a la inicialmente prevista y, lo que es peor, muy superior a la que realmente necesita.

Nuestro trabajo no es conseguir imposibles.

Trabajamos con un presupuesto y tiempo limitado, es decir, trabajamos con unas restricciones. Se pueden y se deben ajustar si es necesario pero teniendo en cuenta que el chicle no se puede estirar indefinidamente.

También es frecuente que en el desarrollo normal de un proyecto nos encontremos en un momento dado con más tareas que las que podemos llevar a cabo ya sea a título individual o a nivel de equipo de proyecto.

Esto nos lleva tanto a nivel general del proyecto como a nivel de un momento determinado del mismo a una priorización de las tareas. Para ello es necesario que el área usuaria decida con criterio qué es lo más importante (teniendo en cuenta que todo tiene un coste) hasta que la dinámica de trabajo esté consolidada considerarán que todo es importante, crítico y urgente y aunque así sea (que no lo es) no tendrán más remedio que hacerlo (a veces cuesta que lo entiendan pero mejor así que darles unas expectativas que no vamos a poder cumplir). Una buena estrategia para la asignación de prioridades es la asignación por parte del usuario de un grado de importancia a la tarea del cero en adelante (la menor importancia es el cero) y sin tener la posibilidad de repetir un valor.

Hay que tener en cuenta que si aplicamos un enfoque evolutivo en el desarrollo de software el usuario irá poco a poco dándole forma a la idea general que tenía en la cabeza, la importancia de empezar por lo más prioritario permite que no se invierta el tiempo en realizar tareas secundarias dependientes de otras primarias y que podrían ser desechadas o modificadas si cambia la principal.

En eso consiste desarrollar con intención.

La visión de este problema por parte de Ken Beck y Martin Fowler la reflejan en el libro “Planning Extreme Programming” y es la siguiente (traducción libre): “Cuando estás saturado, no lo veas como que no tienes suficiente tiempo sino como si tuvieras demasiadas cosas que hacer. No podemos conseguir más tiempo pero sí tenemos la posibilidad de hacer menos, al menos por el momento”.

El enfoque de planifico todo el proyecto, realizo todo el análisis y después diseño, construyo e implanto está todavía presente en una gran cantidad de personas de nuestra industria.

Muchos desarrolladores recién llegados ven el proceso de desarrollo con ese enfoque, sin embargo el problema no son ellos, tienen todavía mucho tiempo para cambiar, sino personas que se dedican a esto desde hace mucho tiempo y que, como suele pasar en las organizaciones, con el paso de los años han alcanzado responsabilidades directivas.

Quien se ha criado en metodologías clásicas, quien ha trabajado durante muchos años con ellas le resulta muy complicado cambiar sobre todo si se está alejado ya del día a día de los proyectos de desarrollo de software. Con el paso del tiempo todo se idealiza, algo que además si no tiene mucho espíritu crítico te puede llevar a pensar que realmente no fueron tan mal todos esos proyectos en los que trabajaste y que utilizaron enfoques clásicos.

Por otro lado, en el área usuaria o funcional, el enfoque de los proyectos en los que trabajan que serán en su mayoría no software también será, por regla general, de tipo totalista, es decir, contrato un trabajo, lo ejecutas de una vez y adiós.

La aplicación de enfoques ágiles se encuentra con esta resistencia, personas que no terminan de entender por qué aplicas esa estrategia, personas que se sienten más cómodas trabajando sobre una planificación general, independientemente de que la misma nunca se cumpla o que el producto final se parezca bien poco a las expectativas que se tenían sobre el mismo.

Para que proyectos con este enfoque puedan llevarse a cabo es fundamental que todas las partes implicadas en él entiendan, comprendan y compartan que esta forma de entender el desarrollo de software es la que mejor se adapta a su incertidumbre inherente y por tanto, es la que de forma más probable te llevará al cumplimiento de los objetivos.

En general, apliques la metodología que apliques es fundamental que todas las partes remen en la misma dirección, de lo contrario a las resistencias que te vas a encontrar en el propio proceso de desarrollo tendrás que sumarle que estaréis solos tu equipo y tú para poder vencerlas y que las otras partes, por regla general, lo que harán será sumar más resistencia.

Kent Beck, describe todo esto de la siguiente manera: “El software es inherentemente poco fiable y los clientes están condicionados a aceptarlo. Los desarrolladores están condicionados a aceptarlo. Los testers están condicionados a aceptarlo”.

Pocas citas reflejan de manera tan contundente la realidad del proceso de desarrollo de software (traducción libre): “De lejos, el motivo principal para no liberar pronto es la resistencia a pasar del sueño del éxito a la realidad del feedback”.

Y esto es así, en los papeles todo puede llegar incluso a encajar y podemos dejarnos seducir por el pensamiento de que ya solo queda traducir a un lenguaje de programación (que no es poco) las especificaciones recogidas al usuario.

La realidad es bien distinta cuando el usuario se enfrente al producto y este no hace lo que esperaba y/o su experiencia de uso es nefasta y la probabilidad de que esto ocurra es mayor cuanto más tiempo pase desde que se realizó el análisis y cuanto más inestable sea la estructura organizativa del cliente y/o sus procesos.

El camino no es otro que asumir que el desarrollo de software es evolutivo, siempre con intención, siempre tirando a dar, admitiendo que a veces será necesario desandar parte del camino con el objetivo de no perdernos y llegar a la meta.