sábado, diciembre 31, 2011

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.

Day 47/365 - Dead Tree Graveyard
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.

Actualización:


Índice:
Imagen: Kevin H.

    0 comentarios:

    Publicar un comentario en la entrada

     

    Copyright © binaridev Design by Free CSS Templates | Blogger Theme by BTDesigner | Powered by Blogger