archivo

Archivos diarios: mayo 28, 2011

Brian Marick es un experto en testing y en el lenguaje de programación Ruby. Fue uno de los firmantes del manifiesto ágil.

Toda la problemática del desarrollo de software viene originada por su naturaleza adaptativa que es el resultado de la infinidad de contingencias que se pueden producir a lo largo del proceso de desarrollo. Si lo que sucede a lo largo del proyecto fuera más previsible probablemente existirían menos problemas.

Sobre este tema Brian Marick realizó la siguiente reflexión:

“La verdadera complejidad de nuestro trabajo es que todo esta planificado bajo condiciones de incertidumbre e ignorancia. El código no es lo único que cambia: las calendarios se deslizan, se añaden nuevos objetivos, los requisitos cambian desde que se definen y durante el desarrollo, es cuando todos los participantes llegan a comprenden mejor el producto que se está implementando.”

Como en la traducción hay cambios sensibles respecto a la cita original (he realizado los cambios para que la idea quede más clara), os la pongo a continuación:

“The real complexity in our jobs is that all planning is done under conditions of uncertainty and ignorance. The code isn’t the only thing that changes. Schedules slip. New milestones are added for new features. Features are cut from the release. During development, everyone – marketers, developers and testers – comes to understand better what the product is really for.”

Si un proveedor entiende que en un proyecto es suficiente con hacer una entrega o una serie de entregas donde las funcionalidades que van a utilizar los usuarios a corto plazo tengan una cierta calidad, pero donde se descuidan otra serie de funcionalidades que tardarán más en ser probadas, está muy equivocado.

Tal vez sirva para cerrar el proyecto, pero el cliente, cuando se empiece a encontrar con un problema tras otro, se acordará muy mucho de quién ha realizado el trabajo.

Si la intención es fidelizar clientes, con lo complicado que es hoy en día conseguir eso, hay que entender el sistema que se desarrolla como una entidad en la que hay que cuidar la calidad en toda su extensión. Esto es compatible con hacer más énfasis en unos módulos que en otros, siempre y cuando en cada uno de ellos se supere un umbral mínimo de calidad exigible.

A veces buscar y conseguir un éxito cortoplacista supone encontrar un fracaso a largo plazo.

Entregar un hito, documental o de software, en malas condiciones por el hecho de cumplir un plazo solo sirve para que el cliente se enfade (y con razón). Al final supone una pérdida de tiempo mayor, por la vuelta a atrás del entregable, el tiempo que se ha dedicado a la revisión y el esfuerzo necesario en realizar las correcciones.

Por curioso que parezca, lo mejor que puede pasar es que se detecte que no está en condiciones porque el impacto de que el entregable se considere definitivo y se pase, por ejemplo, el producto a explotación con fallos que pongan en riesgo la disponibilidad del sistema, un manejo eficiente del mismo, una pérdida de datos o una combinación de estos problemas con otros muchos más que se pueden producir.

Si no cumples los plazos, no los cumples. Si no se ha podido replanificar o si has cometido el error de no avisar que va a existir una desviación, toca dar la cara, mucho mejor esto que entregar algo defectuoso, ya que el pecado es doble, no has cumplido el plazo porque entregar un hito así no es cumplir nada y otra incurrir en el riesgo de entregar algo de mala calidad.

A veces la fecha es inamovible y los plazos incumplibles y a veces el cliente lo sabe, otras no y otras se hace como que no lo sabe. Solo en estos casos, puede estar justificado entregar por entregar, pero advirtiendo siempre con suficiente antelación hasta dónde se puede llegar y los riesgos que se van a asumir y por supuesto, dentro de las posibilidades, intentar que la entrega tenga la mayor calidad posible.

La PM Declaration of Interdependence, actualmente llamada The Declaration of Interdepence for modern management, está compuesta por seis principios que tienen como objetivo mejorar el resultado de los proyectos mediante la aplicación de una serie de estrategias en la gestión de proyectos (inicialmente estaba orientada a responsables de proyectos que aplican metodologías ágiles, aunque puede generalizarse su utilidad a gestores que utilicen otras metodologías).

Fue consensuada en 2005 por quince profesionales de reconocido prestigio en el campo del desarrollo de software entre los que se encuentran un par de autores del manifiesto ágil como son Alistair Cockburn y Jim Highsmith.

Los seis principios son los siguientes (traducción libre):

Nosotros…

– Mejoramos el retorno de la inversión – haciendo continuo hincapié en el valor de nuestro enfoque (ágil).

– Obtenemos resultados fiables mediante – la interacción continua con el cliente y la responsabilidad compartida.

– Esperamos la incertidumbre y la tratamos a través de – iteraciones, anticipación y adaptación.

– Damos rienda suelta a la creatividad y a la innovación mediante – el reconocimiento de que las personas son lo más importante y creando un entorno donde puedan marcar la diferencia.

– Mejoramos el rendimiento a través de – la responsabilidad del grupo por los resultados y la responsabilidad compartida en la efectividad del equipo (el grupo en su conjunto es responsables del éxito o del fracaso y los componentes del equipo de proyecto tienen que colaborar en que el grupo funcione).

– Mejoramos la efectividad y confianza a través de – la aplicación de estrategias, procesos y prácticas específicos para el proyecto en cuestión.

Como la traducción que he realizado tiene cambios respecto al manifiesto, os pongo a continuación los principios tal cual se publicaron:

“We …

– Increase return on investment by — making continuous flow of value our focus.

– Deliver reliable results by — engaging customers in frequent interactions and shared ownership.

– Expect uncertainty and manage for it through — iterations, anticipation and adaptation.

– Unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.

– Boost performance through — group accountability for results and shared responsibility for team effectiveness.

– Improve effectiveness and reliability through — situationally specific strategies, processes and practices.”