El otro día nos hicieron una auditoría interna de software. Como era de software, me soltaron a mí al auditor. Le duré menos de cinco minutos.
El auditor empezó su ristra de preguntas, que básicamente consistía en de los dos mil documentos que teóricamente pueden hacerse (requisitos, plan de desarrollo, diseño preliminar, manual de usuario, de instalación, de árbol de configuración, …), preguntarme uno por uno si lo hacíamos. Yo me dedico a codificar software y algunos de esos documentos sí me suenan, o bien porque me llegan, o bien porque incluso colaboro en ellos, pero del resto ni idea, ni si se hacen, ni cual es el proceso para hacerlos e incluso muchos de ellos, nombrados por sus siglas, los había oido por primera vez. De hecho, en la lista anterior he puesto algunos de los que sí conozco, porque de los otros mil novecientos ni siquiera me acuerdo ahora del nombre.
Cuando llegó el momento en que nos acercamos al tema de software real, vi llegar mi oportunidad, pero al auditor le importaba tres pepinos qué herramientas usábamos (cruise control, bugzilla, test de junit, etc). Unicamente hablamos de que usabamos CVS y hacíamos ramas de vez en cuando. Realmente lo que le interesaba era saber si teníamos controladas las versiones del proyecto completo y si teníamos algún documento que reflejara todas las mejoras y peoras de una versión respecto a la anterior. Asi que de software nada de nada, lo único de interes es que usamos CVS.
Cada vez me da más pena este mundo empresarial, en el que lo importante son las apariencias y no la realidad, en donde lo realmente importante del softwre son los documentos que le acompañan, y no el software en sí mismo. El software puede ser una patata, pero si va acompañado de varios documetnos tamaño "El Quijote", está bien hecho. Y si tienes todos esos documentos, aunque el software no vaya, cumplirás con las normas de calidad ISO 9001 y similares. Luego, claro, se sacan premios a la "excelencia empresarial" (nombrecito, ¿de dónde lo habrán sacado?).
February 29th, 2008 at 10:43 pm
En la empresa en la que yo trabajo son muy dados a “barrer para debajo de la alfombra”.
Todo es pantalla y todo funciona fatal.
Se bueno
March 1st, 2008 at 12:42 am
Por mencionar un poco experiencia de cada uno, en mi actual empresa solemos tener toda la documentación que vamos haciendo en un wiki propio del proyecto poniendo únicamente lo que se considere relevante. Tenemos estándares generales, si; pero documentación propia de un proyecto, la mínima. Exclusivamente la que se vaya a requerir para que un nuevo desarrollador pudiese ser útil en menos de medio día. Para leer tonterías ya tenemos el 20 minutos y similares.
Cuando los clientes quieren un proyecto con contrato inicial se hace un DAR (doc análisis de requisitos) por obligación, pues hay que incluir con el contrato, aunque siempre se intenta evitar ese “formato clásico” y ofrecer otras formas de contratación para evitar al máximo todo el papeleo inútil (que al final significa menor precio para el cliente y menor trabajo inútil para la empresa).
March 1st, 2008 at 3:12 am
en mi trabajo también estamos con la ISO, vino una chica, muy maja, y nos comenzó a explicar el proceso de desarrollo.
casi todos pusimos atención a lo que decía; no porque fuera interesante sino por respeto. Al ir a tomar el café, todos dijimos lo mismo, “¿esta tía sabe lo que hacemos aquí?” la respuesta: “NO”
Lo de sacarnos la ISO es solo por motivos comerciales, porque da puntos para concursos públicos. Manda narices que el estado te mande a tener un certificado de empresas privadas
March 3rd, 2008 at 8:27 am
Esta es una discusión que puede eternizarse y en la que nadie cambiará su posición.
Está claro que tener más documentanción no implica tener un mejor código y no tener documentación tampoco implica que el producto final sea malo. Pero eso no es lo importante. Lo importante es saber evolucionar y evolucionar en función de los intereses del conjunto.
Yo siempre he preferido tirar líneas de código y hacer la menor documentación posible, pero si en los procesos de la empresa está estipulado que es necesaria la documentación habrá que hacerla y para que se haga así será necesario tener un control de la misma. Eso no quiere decir que lo mejor sea tener mucha documentación ya que en bastantes casos puede ser lo contrario.
Vuelvo a decir que lo importante no está en tener o no tener documentación. Lo importante está en seguir una metodología de trabajo común en todos los proyectos, y un primer paso para tener una metodología común puede ser el tener una documentación del proyecto.
March 3rd, 2008 at 1:53 pm
Esto de los auditores me recuerda siempre a el film `Cubiculos de la oficina’ (Office Space), haha.
March 3rd, 2008 at 3:02 pm
Coño, ¿desde cuándo estamos en la misma empresa? O_o
Es penoso que para sacar un certificado de calidad de software, el software importe una mierda.
March 3rd, 2008 at 5:03 pm
No, si a lo peor no estamos en la misma empresa y hay más de una con la misma filosofía.
Se bueno.
March 11th, 2008 at 3:16 pm
La documentación de la cual hacen mención los auditores, es para beneficio de la empresa, en su proceso de negocio. El no tener documentación de los procesos y aplicaciones genera un riesgo potencial a la continuidad de esta, ya que si quienes actualmente la mantienen “desaparecen del mapa”, no tendrían como seguir manteniendola o adaptarla a los cambios del escenario comercial, eso en relación con la documentación técnica. En cuanto a la documentación de usuario, es “menos costoso” tener un manual de usuario que realizar una capacitación para un nuevo usuario.
Esto es en resumen, ya que la lista es larga.
Hay un dicho que dice “los hombres pasan, las instituciones perduran”…la documentación es para la institución.
March 12th, 2008 at 6:36 pm
Entonces, que no lo llamen “auditoría de software”. La documentación es necesaria, nadie en su sano juicio lo duda, pero si es el centro de la auditoría… algo no carbura…….
March 25th, 2008 at 11:17 am
De acuerdo 100%. Solo importan los documentitos. No me extrana que nos vaya como el culo por ahi.
Aqui en London no veo un solo documento estupido de esos, solo veo evaluationes cada 6 meses, tests para probar que el codigo funciona, y pair programming para lograr coherencia en el codigo.
Si, Lek, se puede vivir sin esa documentacion porque todo el mundo sabe que no hace falta y solo entorpece el progreso de un proyecto. Pero claro, si quitamos los documentos, hay gente que tendria que trabajar en serio y eso no lo queremos.