archivo

Archivo de la etiqueta: incertidumbre

El enfoque clásico de desarrollo de software hace aguas en un entorno de incertidumbre como el que rodea a la mayoría de los proyectos. Me pide el cuerpo poner todos en lugar de mayoría porque la incertidumbre es inherente al desarrollo de software (desde mi perspectiva), otra cosa es que la misma pueda ser mayor o menor, materializarse sus riesgos asociados o no, sin embargo prefiero dejarlo así por no cerrar todas las posibilidades.

Y es que hacer predicciones partiendo de un conocimiento incompleto del problema y en un contexto que puede cambiar, incluso radicalmente, es muy complicado. No hay más que ver la gran cantidad de errores de estimación de esfuerzo y tiempo que se producen, incluso poniendo sobre la mesa la experiencia personal y un estudio previo del problema.

Como os he indicado en diversas ocasiones vengo de una formación clásica y de años trabajando con este enfoque y os puedo asegurar que no funciona. No quiero decir que sea imposible cumplir los objetivos, satisfacer las restricciones de plazo o de tiempo o satisfacer las expectativas del usuario, claro que es posible, generalmente con un gran desgaste de las personas implicadas en el proyecto porque las desviaciones no favorecen un clima de cordialidad y concordia. Sin embargo, lo habitual es que el proyecto y en consecuencia el producto se resienta.

Tal vez mi caso no sea muy representativo pero no hay más que mirar los resultados que se obtienen por regla general con este enfoque (no quiero decir que los otros enfoques sean infalibles) y seguro que no tienes que mirar muy lejos para hacerlo.

Cuando se falla en las estimaciones estamos golpeando en la línea de flotación del proyecto y también contra nosotros mismos. Se falla muy a menudo y después toca sufrir las consecuencias porque se adquieren compromisos que costarán muchísimo esfuerzo ser respetados.

¿Por qué nos equivocamos en las estimaciones? Son muchos los factores que pueden influir:

- La incertidumbre inherente que tienen los proyectos de desarrollo de software. Si aplicamos un enfoque iterativo incremental con sprints cortos tiene una menor o nula influencia dentro de ese segmento de trabajo, pero si consideramos el proyecto en su totalidad sí que la tiene cuando hay cambios significativos ya sea sobre las condiciones iniciales o sobre el producto que se lleva desarrollado.

- Se tiende a estimar considerando situaciones ideales y después sabemos que hay problemas.

- Se estima en muchos casos sin conocer suficiente detalle sobre el trabajo a realizar.

- Se estima en muchos casos sin conocer suficientemente las restricciones de la tecnología o del entorno de trabajo.

- No estima quien va a realizar el trabajo.

- La presión del cliente por tener plazos más cortos (y a menor coste).

Estoy seguro de que se os ocurren otro montón de causas que provocan que no se acierte con las estimaciones. Ahora bien, una cosa es que sea difícil estimar y otra que no se intente acertar en lo posible con las mismas porque no queda otra, por ese motivo es importante tomar el control de todos aquellos factores que estén en nuestra mano y que puedan afectar a la calidad de la estimación, esto dependerá como no podría ser de otra forma del proyecto en sí y de su contexto.

Como sabemos los problemas que hay con las estimaciones y que es necesario dar la importancia que se merece al feedback sería recomendable que el cliente pensase más en términos de valor que de agenda, si bien, no resulta sencillo conseguir esas condiciones ya que se mostrarán, por términos generales, reacios a considerar que el presupuesto inicial puede variar después …

Los presupuestos fijos en los proyectos sobre una base de funcionalidades que hay que desarrollar (y que son o pueden ser innegociables) dan lugar a fuertes desviaciones en las previsiones iniciales que se pueden ver reducidas o acentuadas en función del conocimiento del negocio, tecnología y de las personas (componentes de los stakeholders) que van a participar en el proyecto y de la materialización o no de los riesgos previstos e imprevistos.

Cuanto mayor sea la incertidumbre más probabilidad hay de que las estimaciones sean erróneas. Por tanto, cuanto más cerca estemos del inicio del proyecto, más probabilidad de error habrá.

Mike Cohn lo cuantifica de la siguiente manera (traducción libre): “Durante la fase de estimación de la viabilidad de un proyecto la estimación realizada se sitúa entre el 60% y el 160%”.

Sobre esa afirmación se podría pensar que todos los proyectos están abocados al desastre. Tal vez quien piense eso no anda muy mal descaminado, sobre todo si el proyecto se realiza en un contexto de inflexibilidad en el que las distintas partes no se centran en el problema: que es desarrollar un producto software de la mayor calidad posible teniendo en cuenta los recursos disponibles.

¿Qué es ese contexto de inflexibilidad? Este es el presupuesto y esto es lo que hay que hacer, no hay posibilidad de negociación ni voluntad de analizar las causas que han dado lugar a esa situación.

Es importante que tengamos en cuenta lo que nos dice el Manifiesto Ágil al respecto: “Se valora la colaboración con el cliente, por encima de la negociación contractual”, a lo que habría que añadir también que “Se valora la colaboración con el proveedor, por encima de la negociación contractual”.

Y es que las causas hay que analizarlas con el objeto de determinar cuál o cuáles han sido los orígenes de esta situación porque en base a eso hay que dialogar y negociar. Generalmente los problemas de ese diálogo o de esa negociación lo tenemos también como consecuencia de una situación de inflexibilidad y la negativa a reconocer errores por parte del cliente y del proveedor.

Dado que el desarrollo de software es evolutivo soy de la opinión de que el presupuesto en un proyecto debe evolucionar de la misma manera que lo hace el software teniendo siempre presente el cliente y el proveedor el coste de cada actuación. Sobre esta materia recomiendo leer la serie de artículos sobre Contratación ágil que escribí hace un tiempo.

El tamaño y la incertidumbre importan. Para un proyecto donde se prevé el desarrollo de un nuevo sistema de información de medio o gran tamaño o un mantenimiento evolutivo importante del mismo resulta muy complicado acertar, es más, soy de la opinión de que si se acierta es por casualidad.

Un gran desarrollo tiene incertidumbre inherente porque es sabido que en la mayoría (aplastante) de los casos, los usuarios no saben realmente lo que quieren hasta que se va avanzando en la construcción del producto y esto sucede independientemente del enfoque de desarrollo que se le quiera dar. Si a eso le sumas otros factores como la inestabilidad de los procesos de la organización cliente, de la propia organización, el mercado, etc…, todo se hace mucho más complicado.

Por ese motivo es importante que todas las partes sean conscientes de lo complicado que resulta acertar en un contexto como ese. Desgraciadamente en muchos casos, los usuarios y los clientes no atienden a razones y dan lugar a una gestión orientada a la agenda (a intentar mantener un equilibrio en el triángulo de hierro) en la que se sufrirá mucho si la desviación entre lo estimado y la realidad es sensible y que fracasará seguro si se superan los umbrales del Death March Project.

¿Por qué es importante tener en cuenta que estimar en esas condiciones es una batalla perdida? Pues precisamente para considerar la estimación como una referencia pero no como una losa que llevar a la espalda durante todo el proyecto, es decir, no se debe malgastar el presupuesto pero se debería ser flexible en su gestión y tener la mente abierta a la necesidad de contar con más presupuesto en el caso de que sea necesario.

Las estimaciones irán mejorando conforme se vaya avanzando en el conocimiento del producto y el equipo de trabajo se vaya familiarizando con el entorno tecnológico y el negocio. También se reducirá el margen de error si las historias de usuario o funcionalidades a desarrollar no son de gran tamaño.

Aún así se seguirá fallando y será necesario gestionar esas desviaciones, sobre todo en lo que al cumplimiento de los compromisos de la iteración se refiere, ya que en este caso, al estar más acotada la estimación y ser mayor el conocimiento que existe, las desviaciones a nivel de esfuerzo serán poco significativas (lo suficiente para fastidiarte o ponerte muy difícil cumplir con los objetivos del sprint) pero con escaso impacto a nivel presupuestario,.

Cuando se trata de evolucionar un producto sin consolidar ese avance tenemos que plantearnos si efectivamente se trata de tierra ganada.

Una cosa es la experimentación, otra el desarrollo iterativo incremental o la incertidumbre y otras bien distinta es dar pasos rápidos que lo que van dejando atŕas es tierra quemada.

Experimentar es necesario, es una de las bases del desarrollo de software, realmente es lo que se hace cuando se implementa lo que creemos que hemos entendido de lo que cree que quiere el usuario. Esa diferencia se va paliando a través del feedback, salvo que se piense que se va a acertar a la primera, algo poco probable por muy buena voluntad que pongan las partes.

El desarrollo iterativo incremental refleja esa evolución del producto, tratando de consolidar lo ya realizado a la par de que se van incluyendo nuevas funcionalidades. No es tan importante el concepto como la aplicación de un enfoque adecuado, siendo recomendable pensar en pasar de estados más simples a otros más complejos.

La incertidumbre es lo que rodea al desarrollo de software y también a los negocios. Se está sometido a tantos factores que el contexto puede cambiar de manera lo suficientemente sensible como para que impacte en el proyecto. No se trata de huir de la incertidumbre sino de entenderla como algo inherente, por lo que se trata siempre de estar adaptado al cambio.

Dar pasos rápidos con el objeto de obtener un feedback necesario para obtener una orientación del producto es una buena estrategia. El problema es cuando se confunde ir rápido con la toma de atajos. A veces viene bien cogerlos pero cuando dejan de ser una excepción tenemos en un problema porque probablemente estemos sacrificando estabilidad y deuda técnica (capacidad, a fin de cuentas de adaptación al cambio) por más funcionalidad, que por otro lado hay que ver si es necesaria y que nos restará capacidad de maniobra en el caso de que sea necesario cambiar de enfoque.

Por todo eso, resulta necesario analizar si efectivamente los pasos que se van dando en el proyecto dejan tierra ganada.

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.

El cono de incertidumbre de Steve McConnell viene a expresar algo que ya sabemos y es que efectivamente se acierta más cuanto más conocimiento tenemos del proyecto, su contexto, sus problemas, de las personas que participan, etc…

Ese conocimiento se adquiere conforme se va desarrollando el proyecto, con el proceso de definición de las historias de usuario, su construcción, el feedback y las retrospectivas. Cualquier otra actividad de carácter teórico puede producir mejores estimaciones, de base no lo niego, pero siempre limitada y siempre menor que la que se adquiere con la experiencia.

Entonces, ¿de qué valen las estimaciones que se realizan en la definición del proyecto y que tienen como objeto asignarle un presupuesto? Para definir un punto de partida e interesa que el mismo no esté muy equivocado, si bien lo realmente importante es la actitud que cliente (sobre todo el cliente) y el proveedor tienen sobre esas condiciones de partida. Si la orientación es al contrato, a su lectura literal, procura acertar (al cliente porque la satisfacción de sus expectativas respecto al producto final dependerá del acierto y al proveedor porque tendrá que prepararse a sufrir y perder mucho dinero).

En cualquier caso es conveniente dedicar tiempo a hacer la mejor estimación posible con la materia prima disponible, teniendo en cuenta que hay que saber cuándo parar porque si se pretende llegar a un conocimiento muy detallado, además del tiempo que se requiere para ello, se estará suponiendo que después la línea de desarrollo va a ir en esa dirección y lo mismo (lo más probable) se van produciendo cambios conforme el usuario vaya teniendo más claro qué es lo que quiere.

Las estimaciones iniciales no van a ser buenas, las finales estarán más ajustadas y no solo es cuestión de conocimiento técnico y funcional, sino que nos habremos dado cuenta de varios errores que se cometen sistemáticamente con las estimaciones (y que no sería de extrañar que los volvamos a repetir en el siguiente proyecto): considerar condiciones ideales, dejarse llevar por el optimismo, ser demasiado permeable a las presiones externas para admitir más capacidad o para producir estimaciones sin un conocimiento más en detalle de la historia de usuario o del requisito, exceso de ambición, etc…

Volviendo al cono de incertidumbre, hay que tener en cuenta que Steve McConnell lo planteó sobre una secuencia de fases que bien podrían ajustarse a un ciclo de vida clásico o en cascada, si bien podría ser extrapolable, al menos conceptualmente a otros enfoques de desarrollo de software.

McConnell señala que las estimaciones iniciales con un conocimiento insuficiente sobre la visión del producto (visión abstracta del sistema a desarrollar) se suelen desviar hasta cuatro veces por encima o por debajo de lo que viene a ser el esfuerzo real. En el momento en que se avanza más en la definición de la visión del producto, la desviación se ajusta hasta dos veces por encima o por debajo. Vuelve a bajar en la definición de requisitos (un 50%) y así sucesivamente hasta la entrega.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.217 seguidores