archivo

Archivos Mensuales: abril 2014

Cuando se elabora una documentación, como por ejemplo un catálogo de requisitos o una historia de usuario, se parte de una persona o grupo de personas que comunican en ese instante su visión del producto, de una funcionalidad o de una característica (se trata de una concepción abstracta por lo que ahí ya hay una diferencia entre lo que realmente necesitan y en lo que creen que necesitan), esa visión es transcrita por una persona o por un grupo de personas desde la interpretación que hacen de las mismas (por lo que también se pierde información), teniendo en cuenta que en el propio proceso de pasar esas ideas a lenguaje escrito también se pierden matices.

Esa documentación posteriormente es interpretada por las personas que la leen, por lo que, si nos ponemos a analizar, hay una diferencia (en unos casos más sensible que en otros) entre lo que se quiere y lo que se interpreta finalmente, y el documento, aunque deja constancia por escrito del trabajo que hay que realizar, es un elemento que introduce ruido sobre el objetivo final.

Por tanto, el documento no debe sustituir a la comunicación, sino que es en todo caso un instrumento en el que debe apoyarse la misma. Es un error pretender que los documentos sustituyan a la relación entre las personas porque de ser así, perdemos información, perdemos precisión y existirá desviaciones entre lo que se quiere y lo que se obtiene finalmente.

Todavía más duro resulta en contextos cambiantes o en productos que por sus características o complejidad requieran un feedback continuo del usuario, ya que resulta complicado dar una respuesta adecuada si tenemos que estar trabajando exclusivamente con pesados documentos que van de aquí para allá.

Algunos de los lectores habituales de este blog se preguntarán: “en un proyecto de desarrollo de software, ¿no tenemos que estar siempre atentos (alertas) a la necesidad de adaptarnos al cambio?, ¿no es la rápida capacidad de adaptación una ventaja competitiva?, ¿por qué haces un planteamiento tan rígido?”.

Por este motivo me he decido a darle una segunda parte al artículo publicado ayer.

Una organización siempre tiene que estar atenta a la oportunidad y a los movimientos del mercado. Llegar antes que los demás, si se aprovecha adecuadamente, te puede hacer ganar mucho dinero. Llegar un poco tarde te puede convertir en algo insignificante.

Esto es evidente y en nada contradice con lo comentado ayer. ¿Qué quise decir? Algo tan simple como que el desarrollo de software no hace milagros y que la agilidad es efectividad e intención. Una cosa es que un proceso tenga que cambiar para adaptarse a un nuevo contexto o para adelantarse o coger ventaja a la competencia y que eso pueda suceder en cualquier momento (cuando surge la oportunidad) y otra que tengamos que partir con unas condiciones que se sabe que no llevan a ningún sitio.

Para competir tienes que funcionar bien, si organizativamente eres un desastre difícilmente puedes competir con alguien, salvo que tengas un gran producto y/o unos grandes clientes (que en ningún caso van a ser eternos).

El software debe ir después de ese trabajo de reingeniería y a partir de ahí crecer (y cambiar, si es necesario) juntos. Si lo haces antes puede suponer una resistencia ya que tienes que repartir el enfoque entre los cambios organizativos y el desarrollo de software (perderá siempre el proyecto) y el coste será mayor.

La definición del flujo de trabajo es algo que está abierto y es lógico que así sea porque cada equipo de trabajo y cada proyecto tiene sus peculiaridades.

Es frecuente encontrarnos con tableros que no tienen una fase para el testing y suele ser provocado porque se entiende que de manera implícita se encuentra en la fase de realización, construcción, desarrollo o como se quiera llamar.

Conociéndonos como nos conocemos los desarrolladores y nuestras prácticas habituales de no probar de manera adecuada los componentes que construimos es una buena idea incluir una fase de testing de manera explícita. Es cierto que no te asegura nada (hacer testing requiere de disciplina y buenas prácticas) pero el simple hecho de considerarse una actividad y visualizarse es algo que tiene mucha fuerza.

Por ese motivo, aunque creas que la inclusión de esa fase no aporta nada, prueba a hacerlo y tras un tiempo, trata de sacar conclusiones de manera objetiva a través del número de defectos que se hayan conseguido solventar antes de alcanzar producción en comparación con los valores que estuvieras obteniendo hasta ahora, a partir de ahí ya tendrás todos los datos necesarios para continuar con estas prácticas de manera general, en proyectos o sprints concretos o tomar la decisión de, como hasta ahora, no incluirla.

Los sistemas de información no resuelven los problemas organizativos que existen de base. Es una falsa creencia pensar que la informática va a solucionar procesos mal diseñados, malas relaciones entre departamentos y/o personas o malas estrategias y políticas a nivel organizativo. Puede ayudar, no lo niego, pero no va a solucionar los problemas y no va a existir un retorno de la inversión.

Tampoco es buena idea aprovechar el proyecto de desarrollo para que el cliente trate de cambiar sus procesos. Es una solución mejor que la anterior (en la que simplemente se ha plasmado en un sistema de información todas las imperfecciones que ya existían). ¿Por qué no es bueno? Porque las prácticas deben consolidarse para que exista una cierta estabilidad en las mismas. De lo contrario el desarrollo del sistema estará sometido no solo al feedback propio de cada iteración, sino también al feedback de los cambios en los procesos organizativos, lo que hará el proceso de desarrollo más inestable y con un coste mucho mayor.

Es mucho mejor empezar a desarrollar el sistema cuando se hay realizado el trabajo de simplificación y racionalización de los procesos y éste ha adquirido una cierta madurez. Es posible que durante el proyecto se sigan realizando ciertos ajustes sobre el mismo, pero los cambios, por regla general no serán muy sensibles.

El problema es que muchas veces se ha realizado la contratación del desarrollo antes de que desarrollador y cliente hayan caído en la cuenta de que es necesario realizar ese trabajo de reingeniería. Es un problema porque generalmente se toma la decisión de tirar hacia adelante, con los riesgos ya comentados que trae eso consigo.

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 …

En potencia todo, salvo el papel en blanco (y seguro que conocemos casos donde se han realizado estimaciones con un nivel de conocimiento del trabajo a realizar que se aproxima muy mucho a ese papel en blanco), es estimable, sin embargo, lo que queremos son estimaciones que se ajusten lo máximo posible a la realidad y para ello se requiere que cada historia de usuario esté lo suficientemente desarrollada como para conseguirlo.

Vuelvo a insistir en lo que comenté en el artículo de ayer, suficientemente desarrollada no es lo mismo que absolutamente detallada y/o llena de formalismos, sino que se adapte a lo que el proyecto (y su contexto actual) necesite.

Otra cosa es que nos equivoquemos en la estimación, cosa que sucederá sobre todo en los primeros sprints y/o hasta que se tenga dominada la tecnología y entorno sobre el que se va a desarrollar.

¿Para que sirven entonces las reuniones de planificación de sprint? Para terminar de perfilar el sprint. ¿No se hacen todas las actividades necesarias para poder estimar? La base son las historias de usuario y aunque puedas invitar al product owner a participar y aclarar dudas con él, cuando el proyecto se encuentra en una fase inicial o se incorporan funcionalidades con una cierta complejidad, no da tiempo en una reunión de planificación de sprint a tener lo suficientemente claro el alcance de la tarea por lo que la estimación corre más riesgos a lo que hay que sumar las consultas que de forma más que probable habrá que hacerle al product owner durante el sprint y que podrían bloquear determinados trabajos si no se han resuelto antes de que esas tareas se lleven a cabo.

Aplicando prácticas de Scrum y si me apuráis, por puro sentido común, tenemos que tener como objetivo que el resultado de cada sprint sea una versión entregable y por tanto, que se pueda pasar a producción.

Es muy importante desarrollar con intención para reducir el número de iteraciones (o dicho de otra forma para ganar en cantidad de trabajo efectivo por unidad de tiempo o lo que es lo mismo para ganar en productividad), para ello debemos minimizar (siendo el objetivo máximo eliminar), el número de componentes (funcionalidades) defectuosas que llegan al final del sprint (y por extensión a producción).

Para ello cada historia de usuario debe estar completamente terminada. ¿Qué es eso? Desde luego no es programar las tareas en que se descompone la historia y hacer cuatro pruebas, sino de tener la certeza de que efectivamente funciona, lo que implica una buena batería de testing y la verificación de que efectivamente cumple con las expectativas del usuario.

Una primera aproximación a esto último son las medidas para verificar la misma que aparecen en la historia de usuario, en las cuales tenemos que minimizar las ambigüedades para poder dar por bueno o rechazar la misma, ya que no debería haber medias tintas.

Estas medidas pueden estar implícitas en la propia descripción de la historia o separadas en un apartado diferente de la misma.

Otra cosa es que después, el product owner o por extensión los usuarios, se den cuenta de que la especificación realizada no satisface sus expectativas, en este caso el problema está en la especificación y para solucionarlo se requerirá evolucionar (modificar) esa funcionalidad en uno de los siguientes sprints.