Entorno de desarrollo de software mínimo (II) - Documentación y Metodología

Siguiendo con el post de Entorno de desarrollo de software mínimo, vamos a tratar la parte de metodología y documentación necesaria para poder desarrollar y entregar el proyecto y que este sea mantenible.


En primer lugar vamos a ver la documentación necesaria, que será parte de los entregables del proyecto. Para definir ésta, tengo en cuenta que el equipo que va a formar parte del proyecto son personas maduras y profesionales, no "code monkeys". Lo mínimo para poder desarrollar un proyecto con un equipo así sería:

• Acuerdo de especificaciones: En este documento, acordaremos con el cliente las especificaciones de la aplicación a implementar. Definiremos dos tipos de requisitos:

• Funcionales: Estos definirán la funcionalidad de la aplicación. Es muy recomendable bajar al detalle de estos para poder eliminar futura documentación. Se ha de escribir para que un desarrollador pueda utilizarlos de guía para implementar la aplicación sin apenas intervención de la persona que los escribió. Luego esto no es posible, pero es necesario tener ese objetivo en mente. Lo perfecto sería poder poner los flujos de trabajo, textos, errores, etc. Implicando de esta manera al cliente en el análisis, podemos ahorrarnos algunos cambios en el futuro. Si definimos a este nivel, el cliente se hace una idea más concreta de cómo acabará la aplicación. Otra herramienta a utilizar a la hora de definir la aplicación y que nos ayuda para dilucidar el objetivo final de la aplicación son los wireframes o bocetos de la aplicación (si lo que tenemos entre manos es una aplicación con interfaz de usuario). Son muy fáciles (técnicamente) de hacer, ya que es como dibujar, pero ayuda a que nos surjan dudas o posibles carencias de la aplicación que muchas veces salen en la fase de desarrollo. Si nos aparecen en este estado del proyecto, es mucho menos costoso resolverlas.

• Técnicas: Son opcionales. Si el cliente tiene el suficiente nivel técnico y requiere de tecnología específica, se pone en este apartado.

• Estimación y Plan de proyecto: Una vez tenemos el acuerdo con un nivel de detalle muy alto, podemos pasar a estimar el coste del proyecto y a planificar su implementación. Para la estimación, intentamos bajar a los posibles casos de uso de los requerimientos y estimamos cada uno. Bajando al detalle todo lo que podamos ayudamos a dejarnos lo mínimo posible sin estimar. Para el plan de proyecto podemos acudir a las herramientas de toda la vida para trabajar con diagramas de Gantt o un tablero Kanban como se hace en Scrum. Con el diagrama de Gantt nos podemos hacer mejor una idea (y el cliente también, ya que es muy visual) del tiempo de entrega al que se nos puede ir el proyecto.

• Plan de pruebas: Siempre validado por el cliente. Ayuda a tener por escrito las salidas de la aplicación que estamos desarrollando. Si se puede hacer antes de empezar el desarrollo aportará más al proyecto, ya que al igual que en los wireframes, pueden sacar a relucir dudas de la fase de análisis que solo surgirían en el desarrollo. También enfoca el desarrollo a pasar estas pruebas, que es lo mismo que desarrollar para que la aplicación tenga las salidas que espera el cliente. Sobre este tema podéis echar un vistazo a TDD (Test driven development). También definiremos las pruebas de integración con otros sistemas.

• Diseño de la base de datos: La importancia de este documento, más que para los entregables finales para el futuro mantenimiento, la veo para unificar criterios en el desarrollo. Si existen en el equipo más de una persona (que suele ser lo usual), y dejamos que cada uno se defina las tablas que necesita, podemos tener duplicidades y nomenclaturas distintas por cada desarrollador. Al ser la base de datos la raíz de la aplicación, lo mejor es definir una primera versión inicial para unificar criterios y guiar el posterior desarrollo. Lo que no quita que este diseño pueda ser modificado de manera iterativa.

La metodología a utilizar para realizar el proyecto, en caso de que fuese un proyecto pequeño, podemos utilizar el modelo en cascada sin aumentar la complejidad del proyecto. Para ello lo recomendable sería que la duración del proyecto no superase los 2 meses y que el equipo no sea muy grande (5-10 personas). Pero si el proyecto dura más o tiene más gente implicada, lo mejor es pasar a un modelo iterativo, con entregas cada mes (a estilo Scrum) y reducir el tamaño del equipo recortando alcance para sucesivas iteraciones o crear dos subproyectos.

De esta manera podemos ir tomando el pulso del proyecto de manera conjunta con el cliente al menos una vez al mes (aunque siempre es mejor tener una comunicación fluida con este) y que tanto el equipo como el que va a utilizar la aplicación vayan viendo que se consiguen hitos, lo que siempre es un factor de motivación. También se facilita el uso de reuniones diarias cortas con el equipo de desarrollo como en Scrum, ya que al ser poca gente se puede hacer en poco tiempo.

Con esto está cubierta la parte de metodología y documentación. En el siguiente post pasaremos al conjunto de herramientas mínimo que podemos utilizar.

Y como siempre, os animo a que comentéis que  os parece, si añadiríais algo más o quitaríais.

Imagen: Kevin H.

Entorno de desarrollo de software mínimo (I) - Introducción

Alguna vez nos hemos visto en la tesitura de implantar una metodología de desarrollo en sitios donde nunca se ha trabajado con ninguna. En esos momentos, para cumplir el objetivo de manera poco traumática para nadie (incluyéndonos a nosotros mismos) es necesario tener en cuenta a la gente que va a utilizar esta metodología.

No es buena idea entrar a una empresa o un entorno de trabajo pensando que lo que vamos a implantar va a solucionar la vida de la gente porque con nosotros ha funcionado. De esta manera lo único que conseguimos es cerrarnos a cualquier tipo de feedback y hacer caso omiso a su realidad.

Es un poco drástico empezar con metodologías muy pesadas como RUP y sus artefactos o ágiles como Scrum en sitios donde no utilizaban ninguna. Para realizar este tipo de acciones se ha de dedicar mucho esfuerzo a tener la disciplina necesaria para poder llevarla a cabo.

Por eso es necesario contemplar un planteamiento más minimalista, haciendo caso al primer principio de "Lean software development", e ir trabajándolo de manera iterativa. Primero implantamos una metodología mínima de desarrollo, un conjunto de buenas prácticas y vamos iterando para ir adaptándola a las necesidades del cliente y vamos añadiendo lo que veamos que sea necesario y eliminando lo que no aporte valor.

Por ello, y para quien le pueda interesar, he preparado dos posts que publicaré más adelante donde trataré los dos aspectos fundamentales de un entorno de desarrollo: la metodología y las herramientas.

Cómo no, espero que no dudéis en preguntar, comentar o aportar nuevas ideas a estos.

Foto: marekj

Calidad como una característica más

A principios de semana empecé el libro Peopleware de Tom DeMarco y Timothy Lister. Había leido muy buenas referencias de este libro sobre gestión de proyectos, y lo tenía en la lista desde hace tiempo. La verdad es que actualmente me tiene enganchado. Más adelante espero poder hacer un resumen en el blog.

Pero el objetivo del post, no es comentar el libro, sino un capítulo que viene relacionado con el post de Bajando Precios (que por cierto, se está convirtiendo en el post más popular del blog). Habla de una mala práctica bastante extendida, de poner hitos practicamente inalcanzables basándose en la Ley de Parkinson, para, de esta manera, abaratar el desarrollo o mejorar los márgenes. También de cómo se ve perjudicada la calidad del producto, ya que los desarrolladores no hacen lo mismo en menos tiempo, sino que con menos calidad. Pero se piensa erróneamente que de esta manera se aumenta la productividad, ya que se hace lo mismo en menos tiempo.

También comenta que, efectivamente, el mercado tampoco le da tanta importancia a la calidad del producto, ya que se ha ido acostumbrando tener cierto número de errores por desarrollo. De esta manera, se toma la calidad del producto como una característica más de éste, y no como algo que debería ser intrínseco.

Pero este problema no existe solamente en el mundo del software. En otro tipo de industria también. Cuando nos compramos un coche, si pagamos por un Tata (por ejemplo) no esperamos tener la calidad de un Mercedes. Y existen mil ejemplos más de este tipo.

Sólo comentar finalmente que el libro se publicó en 1999, pero creo que no ha perdido actualidad.

bajando precios

Desde el comienzo de la crisis, la calidad en los proyectos de software es algo que parece que se esté dando de lado. Las ofertas más baratas son las que están ganando los concursos. A veces, ves ofertas que están por debajo del coste real del proyecto. Y te preguntas, ¿Cómo puede ser esto?

En gestión de proyectos existe el "Triángulo de la Gestión de Proyectos", el cual está formado por los lados Tiempo, Coste y Alcance. Intenta representar que si en un proyecto modificas alguno de los lados o restricciones, afectará al resto. Por ejemplo, incrementar el alcance  aumenta el tiempo y el coste, reducir el tiempo puede significar un incremento en coste y una reducción en alcance; y un presupuesto limitado puede traducirse en un incremento en tiempo y una reducción de alcance.

Esta era la primera teoría. Pero posteriormente, se refinó un poco añadiendo una nuevo componente más, llamado Calidad. De esta manera es posible modificar alguna de las restricciones y afectar solamente a la calidad. Así, aumentando o disminuyendo cualquiera de las 3 restricciones, aumentamos o disminuimos la calidad del entregable del proyecto.

Por lo tanto, si queremos entregar algo manteniendo el tiempo y el alcance, pero bajando el coste, la única manera es bajando la calidad. Esto se hace de muchas maneras: quitando tiempo de pruebas, contratando personal junior, etc. Pero parece ser que quien se encarga de elegir la mejor oferta, no tiene en cuenta este tipo de cosas.

Quizás, podríamos empezar a justificar la existencia de los Colegios de Informática para que empezasen a informar a los clientes, tanto públicos como privados, sobre este tipo de conocimientos básicos. Creo que tanto clientes como empresas podríamos ganar. ¡Pero esto será tema para otro post!

hacer más de lo que te piden en un proyecto

Cuando te enfrentas a un primer proyecto con un cliente nuevo, una de las cosas que siempre se pasan por la cabeza, es: "Lo voy a deslumbrar". Normalmente este tipo de pensamientos vienen impulsados por una voluntad de continuidad en la relación laboral con el cliente. Que vea que somos unos cracks. Pero, ¿es esta la mejor actitud?

Mi experiencia, la formación recibida en gestión de proyectos y mi sentido común me dicen todo lo contrario. Existen muchos motivos para no hacerlo. Entre ellos, yo me quedaría con estos dos:

• No existe la aplicación con 0 errores. Lo único que puedes hacer es testearla hasta ir reduciendo estos para que tiendan a 0, pero nunca llegará. Por lo tanto, ¿vas a ir tonteando con cosas nuevas si puedes testear mejor lo que te han pedido? Si te sobra tiempo en un proyecto, hay miles de cosas mejores que hacer que ponerte a añadirle guindas: Documentar, refactorizar, test, etc. Porque, si el cliente te ha pedido ciertas funcionalidades, ¿no será mejor que funcionen bien? Él quiere lo que te ha pedido. Ésa es la prioridad.
• ¿Cómo lo voy a sorprender? Es tu primer proyecto, no lo conoces. No sabes lo que le gusta (es muy dificil saberlo a la primera). No sabes a qué le da más importancia. ¿Cómo vas a sorprenderle si no sabes qué hacer de más que no te haya pedido? Puedes montarle una interfaz con el uso de las últimas tecnologías, perder días en ello y que no le importe lo más mínimo, debido a un caracter pragmático.

Éstos son para mí los motivos más importantes por los que haría simplemente lo que me piden, pero lo haría bien. Y vosotros, ¿qué opinais? ¿Se os ocurren otros? ¿O pensais que hay que sorprenderle aún con los riesgos que conlleva?

la cultura de Facebook

Ya hablé en otro post sobre los secretos de Facebook para escalar. Entre ellos se encontraba, lo que a mi modo de ver es el más importante: su cultura empresarial. Ésta se basaba en 3 puntos:

• Muévete rápido e innova, no te preocupes en romper cosas.
• Alcanzar gran impacto con equipos pequeños. Se trabaja mejor, más rápido y hay mejor comunicación.
• Se valiente e innova. Un poco extensión del primer punto.

Quizás, esta cultura viene de la estadounidense, donde el fracaso (según dicen) no se ve como tal, sino como algo por lo que pasas, aprendes y sigues adelante. Pero creo que a veces, nos dejamos deslumbrar un poco por el método yanqui y creemos que lo que se hace allí, aqui no se hace por cómo somos. Si llegase un desarrollador y, siguiendo estos 3 pasos tumbase un módulo de facebook, teniendo en cuenta las pérdidas que eso traería, creo que le caería una buena, si no lo ha hecho siguiendo el procedimiento que han de tener.

Yo creo que en España funciona de manera muy parecida. Nuestro problema es que nos vendemos peor. Hay una barbaridad de empresas nacionales que desarrollan un producto y funcionan así. Desde las nuevas empresas (o startups) que están saliendo, hasta las ya estabilizadas.

Igual en las más antígua se necesita más consenso a nivel de dirección para añadir cosas nuevas al producto, pero hay que tener en cuenta que en esa dirección suelen estar los que crearon el producto en sus inicios.

El problema es que lo que abunda en este pais en TI son las empresas de servicios. Y eso ya es otra historia. Y son igual aquí, que en EEUU que en China. Aunque creo que en una empresa de servicios no se opondría a que organizases un hackaton un fin de semana para sacar un producto o tecnología nueva para vender.

Y vosotros, ¿que opinais?