Agilismo y auditorías externas.

[Carlos Urtasun]

Hola.

Esta semana he estado involucrado en un proceso de auditoría, como
auditado.
Lo que se ha auditado no es un proceso de desarrollo de software sino
la gestión de una serie de tareas, realizadas hace dos años..
Si comento este tema aquí es porque conforme los auditores requerían
información, me iba preguntando, en background: ¿si hubiésemos
trabajado de forma ágil, hubiésemos podido responder a lo que me
requieren?
Quiero decir que en algunos casos he tenido que responder "Pues no lo
sé: ninguna de las personas que participaron en esto, trabajan hoy
aquí y no tengo constancia de lo que me pides".

Y es que a diferencia del manifiesto ágil, las auditorías se centran
en los procesos y las herramientas, en la documentación exhaustiva y
en el seguimiento de un plan.
La pregunta es: ¿agilismo y auditoría son incompatibles?

Puede que una respuesta sea: si tu organización es ágil, no va a
realizar ese tipo de auditorías.
El problema surge cuando estás dentro de una organización que a nivel
global no utiliza metodologías ágiles pero tú sí.

¿Os habéis encontrado en una situación parecida a la descrita? ¿Qué
opináis de los que comento?

Un saludo,

Carlos Urtasun

[Helder De Oliveira]

Hola Carlos

No me he encontrado en tal situación al 100%, pero comento primero lo que ocurrió en su día y luego lo que suelo responder ante este tema:

- Hechos - 

Proyecto ágil, todo exitoso. Llega meses después una auditoría de empresa para revisar su nivel CMMI y vi gente corriendo de un lado para el otro con papeles, word y excel ajustando los entregables de estos proyectos ágiles a los entregables de Métrica 3.

Dudo mucho que no puedas tener dos frentes abiertos, uno ágil y otro tradicional, con CMMI siempre que mantengas repetible y auditable estos procesos, pero es lo que pude ver en su día (y flipé).

- Ideas -

1. Vamos a partir de la frase (creo que de Einstein) que todas las personas son genios, pero medirlos a todos con los mismos parámetros es como medir a todos los peces por su efectividad de trepar árboles (o algo así).

En este caso lo mismo, un proyecto ágil debe ser auditado por sus propios procesos (que sí los tiene), y sus entregables y artefactos (que sí los tiene).

2. En mi humilde opinión, no existe nada más auditado y auditable que un proceso ágil, en esencia porque te auditas constantemente, todo el tiempo estás probando, todo el tiempo estás revisando las apreciaciones del cliente y el equipo, retroalimentando y haciendo mejor el proceso, hasta el punto de auditarte antes de comenzar a hacer algo (TDD y BDD por ejemplo).

3. Se que puedo estar muy sesgado por la informática y los procesos ágiles adaptados a esta área en particular, pero basta con hacer una retrospectiva de lo que hace Toyota con Kanban y ver que es altamente auditable, hay un registro de cada paso dado, es impresionante.

4. Y ya por cerrar, existen guías de auditoría constante como por ejemplo el Nokia Test que alientan a hacer las cosas de forma ágil e hiper-auditable. Es como poder ser auditado en todo momento, en lugar de hacerlo anualmente.

Puede que mi opinión difiera de las experiencias reales, pero me gustaría añadir una pregunta en ese caso: 

I. ¿cómo podríamos hacer cosas de forma ágil y que sean evidentemente auditables? 

y como alguien puede que matice sobre lo auditable entonces añado otra pregunta:

II. ¿auditable bajo qué parámetros?

Saludos

Helder De Oliveira
http://about.me/helderdeoliveira

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

[FranciscoJ...@codelta.es]

Hola Carlos Urtasun,
Nuestra empresa esta certificada por la iso y desarrolla diferentes
actividades.
Intentamos resolver este problema documentando de una forma muy simple
introduciendo en un pequeño programa Access las "Historias de usuarios" que
para nosotros son tareas, para ello uno de nosotros en tiempo real toma nota
con un portátil, dentro de cada tarea, de un resumen de los comentarios
importantes que la definen. Nunca supera el tamaño de Post-it y
entendemos que es la mínima expresión que no carga burocracia al agililismo
y tiene la gran ventaja que al llegar a nuestro puesto de trabajo recibimos
por correo las tareas asignadas.
Tareas que asociamos a un determinado Sprint y que en vez de hacer un acta
de reunión de los temas tratados simplemente agrupamos que tarea se trata en
cada Sprint y listamos los sprints con sus tareas correspondientes.
Es una forma ágil de contentar todos los requisitos de una auditoría
externa.
De este modo las "Historias de usuarios" (tareas para nosotros) nos
ofrecen la trazabilidad que exigen las auditorias externas o de calidad.

Un cordial saludo.

Francisco José Aguilar
Grup Codelta
Petits detalls ens fan professionals.
Pequeños detalles nos hacen profesionales.
Little details make us professionals.

FranciscoJ...@codelta.es
cal...@codelta.es
Oficinas:  Tel. 933 933 400- Fax. 933 933 433
Directo: Tel. 933 933 402- Móvil 609 811 011



-----Mensaje original-----
De: agile...@googlegroups.com [mailto:agile...@googlegroups.com] En
nombre de Carlos Urtasun
Enviado el: viernes, 18 de mayo de 2012 11:56
Para: agile-spain
Asunto: [agile-spain] Agilismo y auditorías externas.

[FranciscoJ...@codelta.es]

Hola Helder,

 

I. ¿cómo podríamos hacer cosas de forma ágil y que sean evidentemente auditables? 

 

2. ¿Que es más rápido que escribir a mano en un Post-It una “Historia de usuario”?

Un pequeño programa que te automatice la introducción y clasificación de historias y que lo que contenga no supere el tamaño de un Post-It y si quieres lo vinculas con impresiones, de pantalla, fotos de errores, videos, todo lo que no te lleve más de 2 minutos en documentar y que ayude a describir el problema.

 

 

Un cordial saludo.

 

Francisco José Aguilar

Administrador-Gerente

Grup Codelta

Petits detalls ens fan professionals.

Pequeños detalles nos hacen profesionales.

Little details make us professionals.

 

FranciscoJ...@codelta.es

cal...@codelta.es

Oficinas:  Tel. 933 933 400- Fax. 933 933 433

Directo: Tel. 933 933 402- Móvil 609 811 011

 

[Patricio Letelier]

Hola,

Entiendo que una cuestión clave en estos temas (auditorías y certificaciones) es el registro del trabajo realizado. Obviamente no es muy sensato generar a posteriori dichos registros, y menos si es solo por cumplir con una imposición, ajena a lo que ha sido el éxito o fracaso del proyecto.

Lo ideal es que dicho registro se integre en el trabajo diario del equipo. Así no supondrá una carga adicional y se podrá realizar en la medida que se desarrolla el trabajo. Pero este registro debe hacerse con un nivel de amplitud y detalle adaptado al proceso aplicado, ni más ni menos, es decir, si durante tu proceso de desarrollo haces estimaciones regístralas, si haces bocetos de IU regístralos, si especificas en algún nivel los requisitos regístralos, si haces pruebas regístralas, etc. 

Aunque no imprescindible, estaría bien tener una herramienta que te permitiera organizar todos esos registros, especialmente si hay que mostrar dicho histórico del trabajo realizado. Mi recomendación aquí es usar algo que se acople a tu proceso actual. Si tu proceso es muy sencillo o estás comenzando con la incorporación de prácticas ágiles sugeriría una herramienta básica basada en Kanban (he comentado algunas gratuitas en: http://bit.ly/JBWE0U), si tu proceso es más exigente puedes seleccionar entre las otras muchas herramientas (incluyo mis preferencias en: http://bit.ly/JoT9ou).

Si se requiere demostrar que se ha seguido un determinado proceso de desarrollo, debería bastar con mostrar "los registros de dicho proceso". Si tu proceso de desarrollo no cumple con un estándar o norma que se quiere certificar o auditar, y aún así tienes que someterte a ello, ya puedes empezar a contabilizar el desperdicio que esto te va a suponer :-). 

Un tema diferente (aunque relacionado) es el tratamiento de la documentación, entendida como los documentos que se adjuntan al producto software en su entrega. En este caso si el contenido de dicha documentación no ha estado integrado en el proceso seguido por el equipo (probablemente porque no se ha querido ajustar el proceso a dicha documentación exigida), como de todos modos habrá que elaborar dicha parte de la documentación, se tiene la elección de hacerlo cuando el producto está ya desarrollado. Un ejemplo extremo (pero usual) es cuando se exige incluir en la documentación ciertos modelos usando diagramas UML pero el equipo no los usa porque no forman parte de su proceso de desarrollo, lo mejor es que, sin sonrojarse :-), dichos diagramas se elaboren al final del desarrollo. Obviamente este sería un pobre aprovechamiento de dicho esfuerzo, pero es preferible esto que forzar la elaboración de partes de la documentación durante el proceso de desarrollo, sabiendo que esto solo se hace para cumplir con las restricciones de la entrega. Así también se evitaría tener que actualizar dichas especificaciones durante el desarrollo, pues posiblemente irían cambiando.     

Un saludo, 

Patricio Letelier

[FranciscoJ...@codelta.es]

Patricio,

Totalmente de acuerdo contigo. “no es muy sensato generar a posteriori dichos registros” lo que no se hace en tiempo real y no añade valor al trabajo diario real no es ágil, por tanto es burocracia.

 

Gracias por compartir tus trabajos y conocimientos, los he encontrado muy frescos, didácticos e interesantes, de los mejores estructurados.

 

 

Un cordial saludo.

 

Francisco José Aguilar

 

[Juan Quijano - The troll]

Buenos días,

Justamente estoy metido en un proceso de certificación de Prince-2 con Scrum.

Realmente lo complicado es hacer entender a dirección, gerencia y otros gestores, las diferencias conceptuales del glosario y herramientas y artefactos.

Cuando le dije a un compañero que no necesitabamos matriz de requisitos, ni plan de pruebas, ni catálogo de requisitos; ya que eso se conformaba con la pila de historias de usuario; entonces encontré los impedimentos serios porque tuve que explicar las ventajas y desventajas de este sistema.

Con dirección es más fácil, porque obviamente es mucho más barato de construir y mantener documentación Scrum que un waterfall clásico.

Básicamente en las certificaciones te piden que puedas mantengas una trazabilidad y un orden pre establecido en la forma en que vas a desarrollar tus productos. Pero ojo, no solo en el momento de construirlo. Si no también desde el momento en que aparece la oportunidad de negocio, y mucha información más.

Como estamos hablando de un trabajo importante tanto en volumen como en tiempo, por ello las herramientas ganan importancia. Ya que puedes tener los procesos mejores y más agiles del mundo, pero sin una herramienta adecuada (lo he vivido en mis carnes) todo se convierte en algo lento y farragoso; y por ende caro.

Centrandome en el tema, MSF Agile o Scrum, son metodologias que se adaptan muy bien a certificaciones de madurez de los procesos de producción, ya uqe cubren prácticamente todas las necesidades.

Por cierto, mi herramienta es Tema Foundation Server, que descarga enornemente al equipo y a la gestión de trabajo.

P.D. Tengo que escribir una serie o un libro sobre mis experiencias. Que he visto de todo y, alguna vez, he fracasado.

[Carlos Urtasun]

Gracias a todos por vuestros comentarios, extensos y detallados.

Cuando escribí el post tenía en mente lo que comenta Helder: "Llega

meses después una auditoría de empresa para revisar su nivel CMMI y vi
gente corriendo de un lado para el otro con papeles, word y excel
ajustando los entregables de estos proyectos ágiles a los

entregables...".
Esa dicotomía entre cómo se hacen las cosas y cómo se "demuestran"
luego que se han hecho.

Porque el problema puede surgir de que el equipo de desarrollo está
integrado en una empresa en la que a las metodologías ágiles "ni están
ni se les esperan".

Un saludo,

Carlos Urtasun

[José Manuel Beas]

Hola,

A mi me surge la pregunta: ¿por qué necesitas pagar para que certifiquen tus procesos? (En el coste no sólo incluimos el de la empresa certificadora sino también el coste del esfuerzo realizado por toda nuestra organización para pasar la certificación).

Quizás respondiendo a esa pregunta podamos encontrar una mejor respuesta a la pregunta de Carlos. Porque, por vuestras respuestas, parece que no hay alternativa posible a trabajar sin pasar las dichosas certificaciones incurriendo en un desperdicio evidente, al menos para mi.

Un saludo desde la soleada Sierra de La Cabrera,
Jose Manuel Beas

http://jmbeas.es

http://agilismo.es

http://twitter.com/jmbeas

[Helder De Oliveira]

Hola Jose Manuel,

Lo veo más que posible, de hecho lo veo mucho más fácil de forma ágil superar una auditoría. ¿El pero? que debe ser un proceso integral.

Si los "procesos" son ágiles y los "entregables" son herramientas que facilitan el agilismo, son esos "procesos" y "entregables" los que deben ser auditados bajo una óptica ágil.

Un poco lo que comentábamos es que falta la labor del coach ágil y de los scrum master (o su análogo en otra vertiente ágil) para inyectar ese pensamiento en la empresa que no lo vea así, en la empresa que paga por una auditoría de peras cuando trabaja con lechugas.

Es más un tema de compromiso de la dirección de la empresa y de foco sincero del auditor, que suelen ver solo clavos cuando tienen el martillo en la mano (por ejemplo el martillo Métrica 3).

Otro tema recurrente, y ahora hablando del "¿por qué necesitas pagar para que certifiquen tus procesos?", es el famoso sello. Promovido más por el cliente y amparado por la directiva empresarial, existe la idea que el tener el "sello" de tal o mas cual empresa auditora de calidad da más confianza al cliente y más posibilidades a la empresa de ganar ofertas. 

En otras palabras, mucho sello sin importar la efectividad.

Sí, no es necesariamente ágil.

Sí, puedes ganar un cliente poco comprometido.

Sí, puedes estar al mando de una empresa poco comprometida.

En contra-partida, la visión de la directiva; "ya, ya, ¿pero así ganamos o no ganamos a ese cliente?". 

O la típica frase de ventas; "¿a quién tengo que matar para conseguir ese cliente?".

Lo dejo por aquí porque creo que le he echado mucha leña al fuego y saldrán muchos temas. 

Saludos,

Helder De Oliveira
http://about.me/helderdeoliveira

[Juan Quijano - The troll]

Buenas,

 

Creo que la respuesta a la pregunta es sencilla. Si te la haces es que necesitas una auditoria externa. Que alguien con criterio por experiencia y conocimiento, pueda aportar ese algo que a toda empresa le falta para mejorar y que no se puede ver desde el interior de la misma.

 

Si además te deja un papel que puedes enseñar y que tiene credibilidad entre tus clientes y te abre puertas que el no tener te mantiene cerradas, pues bien venido sea.

 

La dura realidad es que el poseer una certificación o no, te puede hacer la vida mucho más dura en cierto tipo de mercado. La mayoría de las empresas, dan como una muy buena inversión el coste que implica obtener las certificaciones  adecuadas.

 

Por otra parte, aunque no sea el ámbito de nuestro foro, hay grandes sectores industriales en donde las certificaciones son imprescindibles. No puedes trabajar si la empresa no las posee. Por ejemplo, la industria aeronáutica.

Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com