Acerca de algún Workflow

Últimamente, y con la vorágine de metodologías que se acerca, es difícil establecer un proceso coherente para el desarrollo de aplicaciones en los plazos previstos. Otro día, metodologías, hot es la guerra.

Básicamente existen 4 problemas que deben ser resueltos desarrollando software (en muy pequeña escala):

1. Entregar el software a tiempo. Ni antes ni después. Después no porque puede que el cliente nos pase la factura por retrasar SU planificación. Antes tampoco, porque el hecho de haber tenido suerte esta vez forzará al cliente a pedir un plazo más corto para el siguiente proyecto.
2. Entregar el software sin errores. No comments.
3. Mantener las previsiones de coste y de coste por errores en el desarrollo. Planifica bien.
   
4. Utilizar lo ya desarrollado, tanto las técnicas como el código que pueda ser aprovechado. Y sobre todo, el knowhow.

¿Y de que manera podemos cumplir muchas de ellas? En multitud de libros de texto se ha visto siempre maneras para reducir y mantener desarrollos de software. Analizad la palabra mantener. Desarrollar hoy, significa enfrentarse a un maremagnum desorganizado de recursos, herramientas y personal especializado. Para las recomendaciones teóricas, coge cualquier libro de texto, para la guerra del día a día, atiende:

3 pequeños (grandes) consejos que te pueden salvar algún día de trabajo:

1. Utiliza un sistema de Gestión de la Configuración del Software (SCM), cualquier simple control de versiones puede ser útil como comienzo. Controla quién a hecho qué, en cuanto tiempo y además recupera una versión anterior en cualquier momento. Se disciplinado y reconoce de una vez que el mayor peligro para el código eres tu. Perforce rules again, pero CVS es open source. Tienes demasiado código para seguir numerando los archivos module1.3.45.cs, module1.3.46a.cs...
   
   
2. Bugtracking, sigue la pista de los errores. Planifica, ordena qué tareas son más necesarias en cada momento del tiempo. BugZilla se usa en medio mundo, y es open source. Añade más y prueba a organizarte con JIRA.
   
   
3. Los cambios, desde los requisitos, al código. Jamás cambies directamente sobre el código, por mucho que el cliente al otro lado del teléfono este a punto de darle un infarto. Si, ya se que son dos líneas de código, pero, ¿realmente puedes asegurar que no afectarán al resto del código? y si resulta que si, ¿no afectará también al diseño de la aplicación? ¿y ese diseño no está basado en unos requisitos? Ten en cuenta que el equipo de pruebas empieza a diseñar las pruebas desde los requisitos de la aplicación.
   
   ¿Sigues cumpliendo que la aplicación hace lo que tiene que hacer?. No te confundas, no es una buena idea hacer un cambio de abajo arriba. Empieza por arriba, mira si el objetivo es correcto, y luego sigue avanzando por el diseño antes de que tres o cuatro cambios de tres líneas de código acaben destrozando tu aplicación.

Por hoy, todo, próximamente: sistema de build y producción de software.

PD: Implementar estos tres pasos en una pequeña organización no lleva un mes, entre escoger herramientas, formar al personal, instalar todo, y sobre todo, discutir con todos ellos y despojarlos de la verdad absoluta y del cetro sagrado del conocimiento. Hazlo ahora, o por lo menos plantéatelo. No olvides que probablemente cambiarás la forma de trabajo de muchos de ellos. Improve the way you do business.

posted by Luis Belloch at 13:14 | permalink