archivo

Archivo de la etiqueta: Jim Highsmith

Comenta Jim Highsmith que: “Los clientes definen el valor y son los jueces de la experiencia de usuario”.

Y por supuesto que es así, al final son ellos (o los usuarios en última instancia) los que determinan si el producto cumple o no sus expectativas y las mismas no solo se centran en aspectos funcionales, sino también en términos de productividad y experiencia de usuario.

Desarrollamos software para ser utilizado por lo que es razonable que en la medida del éxito participen (el éxito tiene otros factores adicionales como por ejemplo la mantenibilidad del sistema) quienes van a ser usuarios del mismo. Es cierto que hemos podido trabajar bien, habernos dejado la piel, pero estas son las reglas.

Claro que es posible que el área usuaria (o el cliente en general) sea el principal culpable en muchísimos proyectos de que el producto final no sea bueno y no le satisfaga, pero eso no cambia la realidad y es que además de parte, también es juez en toda esta historia. Cuando esto sucede (dependiendo de muchos factores) en unos casos saldrá más perjudicado el cliente o el proveedor (no suele haber ganadores reales en estas situaciones de conflicto).

Comenta Alistair Cockburn que la distancia es cara. En el desarrollo de software lo es y más si lo centramos en la distancia con respecto al área usuaria.

Capturar requisitos no es trivial, capturar expectativas es todavía más difícil y todo esto se complica más cuanto mayor sea la distancia que tengamos con el cliente o con los usuarios. Cuando hablo de distancia no me refiero a términos puramente físicos, a veces dos personas que están a medio metro de distancia están más lejos que dos que se encuentran en ciudades diferentes.

El cara a cara ayuda mucho y desde mi punto de vista es necesario en los proyectos de desarrollo de software (en su justa medida). Los seres humanos somos seres sociales y esta proximidad física acompañada por una actitud de proximidad entre las partes crea un clima adecuado para conseguir, preservar o mejorar la confianza entre las personas.

Con confianza el terreno es mucho más llano.

Y esta cercanía con el cliente va más allá de lo que es un proyecto, sino que hay que analizarlo desde el punto de vista de la relación con el mismo. El vínculo no debe acabar con el proyecto porque aunque no haya una oportunidad a corto plazo de empezar uno nuevo siempre es posible que surjan oportunidades en el futuro y para tener opciones a ellas el conocimiento y la cercanía con el cliente proporciona una ventaja competitiva.

Sobre este tema me parece muy acertada la siguiente reflexión de Jim Highsmith: “La cercanía con el cliente es un factor crítico para el negocio ya sea para una organización ágil o no”.

La siguiente cita de Jim Highsmith es posible que provoque disparidad de opiniones entre quiénes la lean. “La fórmula para el éxito es sencilla: entrega hoy y adapta mañana”.

Muchos de estos autores cuando hacen estas afirmaciones buscan la reflexión del lector por encima de dar un mensaje o afirmación rotunda sobre un determinado concepto. En muchos casos es más interesante provocar una confrontación de esas ideas con las tuyas porque es probable que de esta forma el conocimiento adquirido se adapte más a tu contexto profesional”.

¿Fórmulas para el éxito? En el caso del desarrollo de software no las hay o si hubiera alguna no sería válida en todos los contextos o incluso siendo válida para el contexto inicial de un proyecto podría dejar de serlo ante cambios en el mismo (que lo más probable es que ocurran).

Es cierto que no hay fórmulas pero sí prácticas que pueden producir buenos resultados si se aplican adecuadamente en el momento y en las situaciones adecuadas.

Estoy de acuerdo en que cuanto antes se vayan entregando versiones del producto antes será posible evaluar las expectativas de los usuarios. Por este motivo soy partidario de enfoques iterativos e incrementales, ahora bien, sí que considero necesario que cada iteración se haga con una intención, no a probar por probar, no a especular a ver qué pasa. También resulta necesario evaluar el nivel de criticidad del sistema y de los controles que debería tener antes de pasar a un entorno real.

En cualquier caso sí que deberíamos buscar que dentro de las características del sistema a desarrollar y de su contexto el tiempo necesario para pasar una versión a producción evaluable por los usuarios (y a ser posible utilizarse en un entorno de producción real) sea el menor posible.

En esta filosofía de entregas rápidas (con los matices que he indicado) está implícito el concepto de adaptación como consecuencia del feedback obtenido tras la puesta en marcha de cada iteración.

Los procesos y la documentación generada en los mismos son instrumentos dentro de un desarrollo de software que de por sí no solucionan los problemas que podamos encontrarnos en los mismos.

Cuando se cree que por sí solos permiten que el proyecto avance estamos pasando de una visión orientada al producto a una visión orientada al cumplimiento de trámites que no es lo mismo ni se le parece.

Puede vestir mucho el cumplimiento a rajatabla de los procesos y la entrega de toneladas de papel, pero lo único que importa realmente es que el producto software satisfaga las expectativas de los usuarios y sea de calidad.

Hay una cita de Jim Highsmith al respecto que no requiere más comentarios: “La documentación no es comprensión, el proceso no es una disciplina, la formalidad no es una habilidad”.

Si el cambio es inherente al desarrollo de software e inherente a la propia evolución de las organizaciones y de si contexto y entendemos el mismo como algo inevitable, la mejor estrategia es estar preparado para poder responder cuando esos cambios se produzcan en lugar de responder cuando ya se hayan producido.

Puede parecer lo mismo, pero no lo es, al menos en el desarrollo de software, donde todos sabemos que los cambios sobre lo planificado son más costosos de llevar a cabo cuanto más tarde se traten, por ese motivo, las modificaciones en el sistema deben producirse lo más cerca posible del momento en que cambian las condiciones establecidas.

Martin Fowler y Jim Highsmith tienen en cuenta esta circunstancia cuando afirman que: “Facilitar el cambio es más efectivo que intentar prevenirlo. Aprende a confiar en nuestra habilidad para responder a eventos impredecibles es más importante que confiar en nuestra habilidad de planificar ante el desastre. Los procesos ágiles aprovechan el cambio para proporcionar al cliente una ventaja competitiva”.

Es importante tener en cuenta lo que afirman Fowler y Highsmith: la rápida adaptación al cambio y la aplicación de metodologías ágiles como instrumento, proporcionan una ventaja competitiva.

Cuando se va a afrontar un proyecto de desarrollo de software es necesario realizar una estimación del coste necesario para su desarrollo basándonos para ello en el alcance conocido del proyecto y de todas aquellas variables que podamos anticipar (tipo de cliente, tipo de usuarios, experiencia en otros trabajos anteriores con ese cliente, con esos usuarios, con esa tecnología, con ese tipo de proceso de negocio, la metodología a aplicar, los umbrales de calidad esperados, etc…).

Cuantos más datos conozcamos mejor, pero en la mayoría de los casos estaremos lejos de saber lo suficiente como para que la incertidumbre entre lo estimado y lo real sea residual.

En cualquier caso es necesario estimar (y analizar riesgos) porque te determina un marco y lo mismo se determina que lo más recomendable es no seguir con el proyecto. Pocos proyectos conozco, aunque los hay, donde el dinero no es un problema.

Ahora bien, la estimación debe tener en cuenta un aspecto esencial y es que conforme vayamos avanzando en el proceso de desarrollo se tendrán que ir realizando ajustes sobre el producto, fruto del feedback del usuario y sobre el alcance final, de ahí la necesidad de priorizar los requisitos del usuario, ya que de quedarnos sin presupuesto, lo más importante debe estar desarrollado y ajustado a las expectativas del usuario.

Otro aspecto a valorar es que además de esa estimación inicial, lo más razonable es realizar estimaciones parciales sobre cada incremento del software (enfocándolo a un esquema iterativo incremental) y cada una de esas valoraciones será cada vez más exacta, ya que el conocimiento del sistema y su contexto será cada vez mayor, además de definirse entregas con un tamaño moderado para adaptarse a unos ciclos de evolución del sistema cortos (un mes, dos meses, etc…).

Todo lo comentado en este artículo lo resume perfectamente Jim Highsmith en la siguiente reflexión: “Convertirse en ágil significa aceptar la incertidumbre sobre el futuro como una forma de tratar con el futuro. Cualquier esfuerzo de un proyecto de desarrollo debería ser el resultado de un equilibrio entre la anticipación (planificación sobre la base de lo que sabemos ahora) y adaptación (en respuesta a lo que aprendemos con el tiempo)”.

He tenido la oportunidad de leer una entrevista que Jim Highsmith publica en su blog y que realizó a Alistair Cockburn hace diez años. Os recomiendo que le echéis una ojeada porque representa la visión que tenía Cockburn de manera contemporánea al nacimiento del movimiento ágil.

En dicha entrevista Cockburn hace referencia a la complejidad de definir una metodología general para el desarrollo de software ya que lo que él había podido apreciar en proyectos de desarrollo de software dentro y fuera de IBM es que lo que se aplicaba en proyectos reales presentaba divergencias respecto a lo que definían teóricamente los libros.

Las metodologías se adaptaban a las necesidades de una organización, se moldeaban a las mismas, a su forma de hacer las cosas, por eso resultaba complicado trasladar estas normas de una organización a otra porque la cultura suele ser diferente. Sin embargo, Cockburn comenta que lo que realmente se podía trasladar con éxito eran las buenas prácticas.

Resulta también muy interesante como Cockburn comenta que cuando aplicó una recopilación de buenas prácticas (que al fin y al cabo conformaban una metodología) a un proyecto real se dio cuenta que aunque el proyecto se ejecutó con éxito, los técnicos en muchos casos no aplicaban las especificaciones metodológicas y que eso le provocó una serie de dudas hasta que comprendió que el desarrollo de software es así, se trata de personas que resuelven problemas, que están centradas en los mismos y eso perjudica el seguimiento de determinados aspectos de la metodología.