Les voy a contar uno de los aspectos menos glamorosos de todo proyecto de software, incluso menos glamoroso que hacer pruebas de calidad al codigo: Documentar.
Si, documentar. A nadie le gusta documentar, por las siguientes razones:
* La documentacion se vuelve obsoleta desde el momento que la escribes: El software cambia, salen errores, hay mas o menos funcionalidades.
* No hay tiempo para hacer documentacion: Al menos que tengas alguien encargado seguramente un desarrollador es quien lo hace. Por supuesto no es la única cosa que tendra que hacer y al menos que sea la documentacion del usuario esta fase tendra una baja prioridad.
* No es bien visto: Por muchas razones: Hay cosas mas importantes que hacer (codigo, pruebas, soporte) o el "know how" no debe salir de un GRUPO SELECTO. Todo esto es un problema de percepción, sobre todo la de que el know how no debe salir de un GRUPO SELECTO de personas .
¿Asi que hacemos?. La documentación deberia recibir el mismo tratamiento que el software, ya que esta evoluciona con el tiempo, ademas de que deberia ser el resultado de un esfuerzo colaborativo. Y sobre todo, deberia ser facil de modificar y buscar.
Bueno, todo eso suena como un Wiki, Si bien cuando alguien habla de un Wiki, todo el mundo piensa en la Wikipedia, pero yo creo que uno de sus usos mas importantes es dentro de las compañias, en las Intranet.
¿Que tan efectivo puede ser? Bueno, habria que generar eventos de mantenimiento, documentacion de errores y caracteristicas obscuras de el sistema, uso de herramientas. Se pueden resolver errores comunes en menos tiempo; Lo mejor es que todos colaboramos para hacer mas util la documentacion y el numero de reglas que hay que seguir es tan pequeña que usarlo no toma mucho tiempo.
¿Y ustedes que usan para organizar la documentación de su empresa?
11 - Documentar para evolucionar mejor
.
lunes, 31 de marzo de 2008
2 catardockeadas:
Que tema!.
Estaría muy copado, un software o aplicaciòn a desarrollar como propio framework que vincule: Documentación -> caso de uso -> modelo clases -> clases
Incluso un debuguer que acumule comentarios y flujo del sistema y lo exhiba ante algun comando.
El punto débil de la documentación es lo tedioso de comentar algunos pasos pero sobre todo de tipearlo.
A mi entender sumado a lo expuesto estaría copado alguien que "grabe" desde un mp3 y otra persona que desgrabe y que tenga nociones de redacción.
Es importante documentar y es todo un paso, otro paso es documentar bien y otro hacerlo con buena gramática.
Pregunta.. Cuantos de nosotros tiene documentados sus procesos en cada area a la cual pertenece?
Es un trabajo pesado documentar, es pesado para quien esta construyendo..porque esta motivado en protagonizar la historia de su area, de generar productos/servicios/aplicaciones y no cumplir el papel de historiador, para eso estan los historiadoes contratados para documentar.
Comparto la idea de vincular estas funciones: Documentación -> caso de uso -> modelo clases -> clases
para que nuestro historiador tenga la materia prima para contar esa historia lo más claro posible.
Publicar un comentario