archivo

Archivo de la etiqueta: Roy Miller

He mantenido muchísimas conversaciones con defensores de enfoques clásicos de desarrollo de software sobre este asunto y siempre es lo mismo, que se basan casi siempre en que no hay motivos por los cuales un sistema de software deba seguir una metodología o unos procesos diferentes que para construir un edificio y que no pensar eso es no creer en la ingeniería del software.

Prácticamente toda mi experiencia laboral se ha centrado en enfoques clásicos por lo que tengo criterio para tener una opinión totalmente contraria a eso. No hablo de teorías, hablo de realidades.

Y la realidad es que el software es flexible, es adaptable, es evolucionable y para que funcione tienes que programar hasta el más mínimo detalle. Un edificio no es flexible por lo que su posible adaptación (estructural) es mucho más compleja y costosa y no requiere tanto nivel de detalle para poder ser utilizado.

Precisamente por eso los procesos para la construcción son más rígidos y los cambios sobre las especificaciones iniciales son más por motivos técnicos que funcionales.

Si el software tiene esas características, ¿por qué ignorarlas?, ¿por qué aplicar un planteamiento predictivo (planos) cuando es posible aplicar un planteamiento evolutivo?, es más, ¿por qué utilizar un enfoque predictivo si la propia realidad del proyecto aconseja el incremento y la iteración?.

Para Ken Auer y Roy Miller: “Cuando se utiliza un proceso destinado a la construcción de cosas inflexibles como puentes para construir cosas flexibles como el software, no debe sorprender que más tarde el coste del cambio sea mayor”.

Como desarrolladores somos reacios a la realización de cambios y no es que seamos así genéticamente sino por el hecho de que se nos ha formado y después hemos trabajado en proyectos en donde nuestra capacidad de ser flexibles estaba muy limitada por el cumplimiento de una agenda de costes y plazos (mucho más lo primero que lo segundo).

Cuando se enfoca un proyecto con presupuestos inmovilistas y sobre todo, carentes de toda aproximación a la realidad no se puede pretender que acojamos los cambios dando aplausos porque lo que el presupuesto no cubre (hasta cierto límite, claro está) lo tendremos que cubrir con nuestro trabajo.

No se trata de trabajar con presupuestos ilimitados, sino de desarrollar con intención (que es lo mismo que tratar de desarrollar de manera eficiente) y de determinar cuándo el valor del producto es suficiente y cuándo deja de ser rentable el crecimiento del valor con respecto a la inversión que se está realizando.

Con esta visión del desarrollo del software el cambio resulta bienvenido ya que se entiende que a través de él se consigue dotar al producto de un mayor valor (como consecuencia de que cada vez se ajustará más al contexto existente y a las expectativas de los usuarios).

Ahora bien, el cambio debe hacerse con intención (evitando en lo posible las circunstancias de prueba y error) y con un sistema en los que los cambios se puedan realizar con agilidad (deuda técnica acorde a las características del sistema que se desarrolla, arquitectura y modelo de datos escalable, etc…).

Cuando uno se acostumbra a este esquema de trabajo se acepta el cambio como una parte más del proceso de desarrollo de software y efectivamente se cumple la siguiente reflexión de Ken Auer y Roy Miller: “La única manera de deshacerte de tu miedo a los cambios en el código es hacerlos una y otra vez”.

El responsable funcional siempre va a querer incrementar el valor del producto que se está desarrollando y/o con el que está trabajando, para ello lo evolucionará buscando incrementar la eficiencia y productividad en su utilización y para ello modificará funcionalidades ya implementadas, eliminará algunas que no tengan utilidad o desarrollará otras nuevas.

Ese incremento del valor será consecuencia de una inversión y tendrá como objetivo obtener un retorno de la misma traducido como una reducción de costes y/o una ventaja competitiva con respecto a la competencia.

No hay que esperar a tener una versión más o menos estable del producto, el responsable funcional conforme vaya viendo y trabajando con versiones del mismo, ya sea en producción (preferentemente) o en un entorno de demo, buscará incrementar ese valor (lo hará incluso cuando trabaje con prototipos de pantallas en la definición de una historia de usuario), por lo que los requisitos, las especificaciones, las mismas historias de usuario, siempre deben estar abiertos a una modificación y esa será la realidad con la que nos encontremos en cualquier sistema de información, hasta que termine su ciclo de vida.

Sobre esto, Roy Miller realizó la siguiente reflexión: “Los requisitos son una conversación que nunca termina”.

Comenta Roy Miller (consultor y autor experto en metodologías ágiles) que: “Todo lo que necesitamos saber es el primer paso que tenemos que dar para dirigirnos hacia donde pensamos que queremos dirigirnos en ese momento”.

Este tipo de reflexiones se realizan principalmente para llamar la atención sobre un aspecto concreto y en este caso lo que trata probablemente de hacer Roy Miller es que dediquemos unos minutos a pensar por un lado en la incertidumbre característica de todo proyecto de desarrollo de software y por otro en su enfoque evolutivo en el cual vamos construyendo poco a poco el producto objetivo que lo mismo difiere de manera sensible de la idea que del mismo tenían inicialmente los usuarios y el propio equipo de desarrollo.

Siguiendo un enfoque evolutivo sí que resulta relevante cuál es el siguiente paso que tenemos que dar ya que nos permitirá llegar a la siguiente etapa y allí ya veremos pero no por ello, y estoy seguro que Roy Miller piensa de manera parecida, debemos obviar otro tipo de información que puede resultar de utilidad como por ejemplo los riesgos del proyecto y su situación (que llevamos hecho, qué tareas estarían pendientes de realizar, cuál es el presupuesto restante, qué problemas nos estamos encontrando en el proyecto, cuáles están originando resistencia al desarrollo, etc…).

No se trata de control sino de ser consciente de cómo estamos algo importante para evolucionar porque el siguiente paso importa pero también desde dónde se da.

Procesos o interacción entre personas, enfoque clásico, enfoque ágil. Dos mundos, que no son incompatibles salvo que uno no se quiera uno mover de los extremos, algo que desde luego y desde el punto de vista del agilista no sería nada ágil.

Ya sabéis cuál es mi punto de vista en el desarrollo de software y que vengo del mundo de los procesos. Ser un converso no me impide ver que los procesos tienen que existir como background al proceso de desarrollo y que puede haber casos donde sea necesario que su presencia sea mayor.

Lo que no puedo entender y no es la ceguera del converso es que se siga pensando en los procesos como la única solución a los problemas del desarrollo de software, como si las personas fuéramos algo secundario. Es cierto que en su momento supusieron un primer avance cuando se pasó de los desarrollos heróicos a un enfoque más organizado pero una vez subido ese primer peldaño no consiguió superar el siguiente que es mejorar la situación (o erradicarla) que provocaba la crisis del software.

Es cierto, como decía antes, que los procesos pueden producir buenos resultados en ciertos contextos, pero siempre será necesario que el factor humano funcione porque como comentan Roy Miller y Christopher Collins: “Ningún proceso es lo suficientemente completo como para que sus usuarios puedan apagar el cerebro”.

La siguiente cita de Roy Miller refleja algo, desgraciadamente, demasiado frecuente dentro de nuestra profesión: “Lo malo de gran talento técnico es la actitud suele aparecer junto con él. Es difícil encontrar un gran programador que no cree que está un peldaño por encima de los simples mortales”.

Cuando un día sientas que no has sido humilde piensa que ese día te has equivocado. Si sientes que generalmente no eres humilde tienes un problema.

Ten en cuenta que trabajas con otras personas, que no estás solo y que las vas a necesitar de la misma forma que ellos te necesitan a ti. La mejor forma de trabajar de manera cooperativa, con comunicación, interacción es tratando a tus compañeros con respeto y ese respeto se pierde cuando empiezas a desechar otras ideas, sin siquiera analizarlas, por el simple hecho de que vienen de alguien con menos capacitación que tú.

No se trata de que dejes de ser un gran desarrollador sino de que pienses que tu objetivo no es brillar por ti solo y que hablen con admiración de tu gran talento sino de desarrollar toda tu capacidad en los proyectos haciendo que tus compañeros trabajen mejor, para que de esta forma ellos hagan que tú también puedas conseguir mejores resultados.

Un talento que no consigue resultados no me vale y difícilmente los conseguirá si no entiende que no trabaja solo.