¿Documentación en ambientes ágiles?

Ezequiel Glinsky nos invitó a Nicolás Páez y a mi a hablar sobre la documentación de arquitectura en desarrollo de software usando métodos ágiles, en la materia Metodologías de Documentación de la Maestria en Tecnología de la Información de la Universidad de Palermo.
¡Qué desafio!

Es acaso la documentación contraria a las ideas ágiles (Working software over comprehensive documentation)?
Evidentemente no. Pero como comenté en una entrada anterior en relación a la administación de proyectos, me acostumbre a hablar del "lado izquierdo" del Manifiesto Ágil, que es donde hacemos foco por considerarse más valioso, pero lo de la derecha también tiene valor, y por lo tanto a muchas personas les interesa saber que forma toman en un ambiente con metodologías ágiles la documentación, los procesos, las herramientas, los contratos, etc.
Después de darle un par de vueltas al tema, lo plantee de la siguiente manera:

• Motivos para implementar metodologías ágiles: la forma de documentación es una herramienta para lograr un objetivo, entonces debo entender los objetivos.
• Cómo cambian los roles y tareas relacionados con arquitectura: no pudiendo asumir que la gente conoce la forma de trabajo en ambientes ágiles, es necesario comentar como es afectada la definición de arquitectura, y por ende la documentación correspondiente.
• ¿Documentación?: y finalmente, ¿estamos hablando de documentación, o acaso nos referimos a Comunicación de la arquitectura? Es una diferencia interesante, ya que este diferente punto de vista nos cambia la perspectiva. Pair programing es una forma de comunicar la Arquitectura, como así también las reuniones de diseño ante un pizarrón. Con esta punto de vista, la documentación (wiki, documento, herramienta) es una forma más de comunicar. Sobre esto ha escrito Rebecca Wirfs-Brock. Por otro lado, también podemos consideramos que la Arquitectura es un idioma (o al menos un dialecto), que nos sirve para expresar la solución a la necesidad del cliente; con este punto de vista la pregunta es como hacer para que los miembros del equipo y otras perso.
  

La charla se dió en poco más de una hora, con 15 min de preguntas. Pueden encontrar la presentación acá.

Luego Nico comentó la experiencia de Snoop, lo que permitió bajar a tierra varias de las ideas y creo que logro un buena mezcla de ideas y práctica. Lo interesante es que nos pusimos de acuerdo a altisimo nivel, y sin embargo las presentaciones se complementaron muy bien. Para más información, pueden ver el grupo de la materia.

Preregistración a cursos en Agiles 2008

Hemos iniciado la pre-registración para los cursos que se dictarán los días 20 y 21 de Octubre.
Los cursos disponibles actualmente son (más información en http://agiles2008.org):

• Curso de Lean Development, dictado por Mary y Tom Poppendieck
• Curso de CSM, dictado por Tobias Mayer
• Curso de TDD, dictado por Dave Astels

En todos los casos, el costo del curso es de usd 600, pero en caso de pre-registro el costo es de usd 500. La pre-registración, con lo que se reserva una vacante, se realizará hasta el 30 de junio. El pago se realizará a partir del 1 de Julio.
Todos los cursos tienen una duración de dos días, 8hs por día e incluyen práctica, que en el caso de TDD es práctica con computadoras. Los cursos tienen cupo limitado y son en inglés, aunque habrá personas para ayudar con temas de idioma.
Los cursos se dictan en forma simultánea, por lo que debe elegirse uno de ellos. Si lo desean, pueden elegir uno adicional para el caso que el primero esté completo.
Los asistentes a los cursos tendrán derecho a acceder a las Jornadas, sin costo adicional. Para información obtener más información de las jornadas, consultar http://agiles2008.org
En el caso de sponsors, se aplica el mismo criterio, al indicar su participación reservan las vacantes correspondientes a su categoría, pero deben realizar el pago para confirmar su lugar. Para consultas sobre registración, cursos y oportunidades de sponsoreo, contactarse con info@...

Para pre-registrar, enviar un mail a registro@... con el siguiente formato
Subject: nombre

Body
Nombre:
Email:
Empresa: // opcional
Curso 1ra opción: Lean/CSM/TDD // elegir uno
Curso 2da opción: Lean/CSM/TDD // elegir uno
Procedencia: país/provincia/estado

IEEE CS - Reedición del curso Páctico de Scrum Q&A

Hola
Algunos de los asistentes al curso me hicieron llegar comentarios que me gustaría compartir

Adrian Ariza me comenta del sitio http://www.navegapolis.net/ donde hay mucho material en español de Scrum y metodologías ágiles en general.

Por otro lado Victoria Pocladova me acercó un documento con las notas sobre algunas de las preguntas y respuestas que tuvimos en el curso. Muchas gracias por pasarlo Victoria!
Algunas de las preguntas:

• Como planifico y hago contratos con Scrum?
• Scrum vs RUP?
• Scrum vs CMMI?
• Niveles de planificación en Scrum
• Importancia de Product Owner
• Scrum con desarrollo de terceros (soy cliente de una factory de desarrollo)
• Uso de reglas para disminuir conflictos en el equipo
• Tips para definir duración de los sprints
  

Saludos

IEEE CS - Reedición del curso Páctico de Scrum

En esta segunda vez hubo más ida y vuelta, con algunas preguntas muy interesantes, que muchas veces son fuente de discusión en scrumdevelopment y en laasd

• Convivencia de Scrum y CMMI
• Como manejo la mega tarea indivisible
• Puede le Product Owner ser el superior jerárquico de los Scrum Masters
• El
  

Con respecto a la organización general, mantuve algo muy parecido a lo anterior, pero la presentación está actualizada, sobre todo la primera parte.
Espero postear lo que hablamos sobre las preguntas en breve.

Self-directed work teams y Scrum. Comparando libros

El libro "Leading Self-Directed Work Teams", de Kimball Fisher, libro se refiere a la implementación de SDWT o Equipos de trabajo autodirigidos, en las organizaciones. Fisher prefiere el nombre High Performance Teams (HPT) o Equipos de alto rendimiento, ya que la idea de auto dirigidos o auto organizados suele interpretarse como sin líder, y no es así.

Por qué

El libro contiene una justificación de la utilización de HPT, un punto importante que tomo es que se incorpora a las empresas no porque es bueno para los empleados, sino porque es bueno para el negocio. Que además sea bueno para los empleados es un subproducto. Esto para mí es muy importante, ya que permite hablar con la dirección de la compañía sobre los temas de les importan (mejorar el negocio), y simplifica lograr que los empleados se sumen al cambio cultural ya que, al no depender de la personalidad de los mandos medios, tendrá más continuidad. Sobre este tema se vuelve cuando se describen las distintas formas de incorporar la cultura, desde la dirección, o desde los equipos.
A pesar de ser una parte interesante del libro, no es la más valiosa, ya que los ejemplos suelen estar alejados de la realidad de desarrollo de software e IT, y faltan ejemplos más recientes.

Cómo

Algunos temas particularmente interesantes son:

• Las cinco etapas de implementación del cambio (empowerment):
  Investigación (Entendiendo), Preparación (Aceptando), Implementación
  (Haciéndolo funcionar), Transición (Manteniéndolo), Maduración
  (Mejorándolo). En cada una de ellas se requieren cosas distintas por parte
  de los líderes. Se identifican 3 niveles de liderazgo: los directivos
  (Culture Leaders), los mandos medios (Management Leaders), los líderes
  operativos (Operational Leaders). Este último es llamado supervisor en la
  cultura de Teoría X y team leader en la cultura de Teoría Y.
• La descripción de la Teoría X (las personas sólo trabajan si alguien las
  controla y dirige) vs la Teoría Y (las personas se motivan y son más
  productivas si tiene libertad e información para actuar). Ver algo más de
  esto aquí.
• Mucho contenido sobre el impacto que tienen los mandos medios y los
  supervisores, como incorporarlos al cambio y cual es el rol en la nueva
  forma de trabajo, incluyendo las capacidades debe obtener, y ideas de como
  desarrollar esas capacidades. Incluso un cronograma de ejemplo de como
  evoluciona su foco y que tareas puede hacer para ejercitar. Dado que estos
  niveles son los más susceptibles a percibir negativamente el cambio
  ("pierden poder") y dado que son críticos para que el cambio sea exitoso, es
  importante incorporarlos.
• Ideas, concejos ejemplos sobre las actitudes que puede tener la gente
  ante el cambio (en cualquier nivel) y como puede ser manejada.
• Cómo lograr compromiso (Accountability). Fisher no toma la separación
  entre responsability/accountability (buena noticia para nosotros,
  hispanoparlantes, ya que tenemos una sola palabra para ambas), para él son
  una sola. Adhiere a la idea que una responsabilidad de muchos no es de
  ninguno, y plantea formas de lograr eso dentro de la idea de equipo.
• Cómo implementar HPT desde los equipos (nuestro jefe no está de
  acuerdo). Es posible, pero difícil. Esta parte es interesante, a pesar que
  no tienen recetas, al menos indica que debería pasar para tener éxito en
  esto. En muchos sentidos, lo veo similar a la situación de un consultor
  externo.
• Cómo hacer que el cambio sea sostenible. Esto incluye el esquema de
  remuneraciones y beneficios; el mantenimiento y desarrollo de capacidades
  técnicas en un ambiente en el que los se busca que los miembros de los equipos aprendan de los demás, tendiendo a ser generalistas; el mantenimiento en el largo plazo de esfuerzos en temas que son de larga maduración o contínuos (Start Point system) y que afectan a varios grupos.
• Los capítulos referidos a equipos de Information Workers y virtuales, no aportan tanto como algunos otros.

Comparando con los libros "The Enterprise and Scrum" y "Agile Project Management with Scrum", ambos de Ken Schwaber, encontré diferencias en el foco, no en el contenido.

• En Scrum, se dan reglas a los equipos, esto es equivalente a las Boundary Condition (condiciones de bordes) de Fisher, pero este último indica que se necesitan, da ejemplos, pero no las fija: interacción con lo que no es el grupo, organización interna en cuanto a avance, reuniones de planificación, demo, retrospectiva, reunión diaria, etc.
  
• Fisher da más detalle sobre como realizar el cambio cultural a nivel organización, aunque en esto hay superpocisión con el contenido de ""The Enterprise and Scrum".
• Fisher tiene mucho más tratado los temas relacionados con la inclusión y entrenamiento de los mandos medios y supervisores, para que sean incorporados a la nueva cultura.

En resumen, creo que las dos lineas de pensamiento y autores son complementarios y que la lectura de ambos enriquese la comprensión y da más herramientas para la puesta de práctica de HPT/Scrum :).

Dave Astels en Ágiles 2008!

Dave Astels viene al evento Ágiles 2008, donde participará dictando un curso de dos días (20 y 21 de Octubre) y dando algunas charlas durante el evento (22 y 23 de Octubre) en Buenos Aires.

Aún estamos definiendo los detalles, pero en líneas generales, el curso sería de TDD (Test Driven Development), y las charlas de BDD (Behavior Driven Development).
Entre otras cosas, se está hablando si el curso será sobre Ruby o Java. Las charlas seguramente serán sobre RSpec.

Los que estén interesados pueden registrarse en la página de contactos del evento. Describan que les interesaría más!

Calidad en desarrollo de software ágil (2da charla)

Presenté por segunda vez "Calidad en desarrollo de software ágil", en el IEEE, el jueves 24 de abril.
La charla fue básicamente la misma que la vez anterior (en esa entrada hay más datos de la presentación), salvo algunas correcciones menores en la segunda parte de la presentación.
En esta entrada quiero comentar algunas conversaciones que tuvimos con los asistentes.
Testers y líderes de QA/Testing
En ninguna de las charlas asistieron personas que tengan o hayan tenido como rol principal el de Tester o Líder de Testing/QA (excepto yo :).
¿Por qué vienen desarrolladores y project leaders y no vienen testers y líderes de QA/Testing?

• ¿No les llegó la convocatoria?, no creo, la convocatoria del IEEE es amplia, y sé que a algunos les llegó.
• ¿Adversión a la palabra ágil entre los Testers/QA? Es una posibilidad. Una de los metodologías ágiles con más exposición pública se llama Extreme Programming, no Extreme Development, ni Extreme Testing ... una primera impresión diría que los temas de testing son de segunda clase. Por supuesto, no es así. Por algo Ron Jeffries y Ward Cunningham son activos participantes en agile-testing
• ¿Testing visto con menor aura que QA? A pesar del título, que indica calidad, y no Testing, la descripción de la charla claramente refiere a temas de Testing. Todos sabemos que la prueba no la crea la calidad. Lamentablemente, creo que este conocimiento se ha deformado en considerar a Testing como una etapa transitoria e inicial en cualquier plan de carrera. Me inicio como tester, pero intento rápidamente "avanzar" a desarrollador o Analista, o responsable de procesos. Esto es en parte consecuencia de la poca importancia que se da a la calidad de software en nuestro mercado y a la forma en que se prueba: principalmente prueba manual, siguiendo script hechos por los "Analistas de QA". Hay poca prueba automática, y esta es hecha por los "Automatizadores".
• Ligado a los dos temas anteriores, lo "profesional" para personas involucradas en calidad de software es procesos (ISO / CMMI). Esto es contrario a los principios del manifiesto ágil, pero parece ser la percepción generalizada. Por ejemplo, el INTI a puesto en marcha la carrera de especializacion "Calidad Industrial de Software", en el que el testing (V&V) tiene 5% de la carga horaria, con 21 hs. Quizás me equivoco, ya que en el tema correspondiente a "Modelos de madurez y capacidad" (tiene el 19% de la carga horaria) se nombran "CMMi y metodologías ‘ágiles’" ... pero en qué contexto, no :)?

Varias personas de empresas con equipos trabajando en froma ágil me comentaron la dificultad de conseguir personas que aporten los skill de testing y calidad, pero que se sientan cómodos trabajando en un ámbito con alta automatización de las pruebas, sin separación organizacional de roles, y focalizados a la mejora práctica (no de libro) de los procesos.
Otras empresas han optado por contratar estudiantes de carreras no técnicas (sociales, económicas) no por la necesidad de sus skills particulares, sino porque son recursos más baratos para una prueba manual, que sólo requiere algún conocimiento de uso de computadoras, ser ordenado y tener un nivel aceptable de comunicación interpersonal.

Problemas en la implementación de métodos ágiles
Como comenté anteriormente, la calidad es central a las metodologías ágiles, sin embargo las personas de Testing/QA no son generalmente agentes de cambio.
¿Por qué?

• Separación de roles: después de pelear por años para que las organizaciones "den peso" a la Calidad, muchas de las personas en estas áreas ven con reluctancia ceder estas posiciones. En una estructura jerárquica, con muchos niveles, el nivel en el que aparece una función es una indicacón de la importancia que le da la organización. Sin embargo, en una organización horizontal, los niveles son pocos, y los equipos incluyen personas de todos los skill. La gran mayoría de las decisiones se toman por acuerdos dentro del equipo, por lo tanto, la necesidad de separar los roles de testing en una rama jerárquica separada al resto de desarrollo se hace innecesario e improductivo.
• Luego de un cambio hacia una organización horizontal, hay menos "jefes", por lo que los mandos medios se sienten amenazados (¿cómo manejar esto?).
• Por supuesto, los dos puntos indicados arriba se aplican no sólo a las personas con roles de Testing/QA. También pasa con los programadores, que no quieren "probar" o tener contacto con usuarios, y los líderes de programadores, que sienten la misma amenaza que los líderes de testing. Pero esta charla no era para programadores y líderes de programación :)

Estas dudas tienen respuesta, y esa fue la intensión de la charla, pero ... no vinieron los principales involucrados.

Conclusiones

Veo en el mercado argentino un problema con respecto a la implementación calidad de software en general y en el caso de metodologías ágiles en particular. No es visto como un rol dinámico que debe profesionalizarse y mantenerse actualizado, que debe guiar las mejoras desde el día a día, que debe retener a los recursos valiosos y que aporta valor al desarrollo de productos de software.
Esto no significa que los testers deben ser programadores, pero sí significa que deben entender y participar en temas de análisis, diseño y programación, así como los perfiles más técnicos deben participar en temas de prueba.

En mi particular cruzada, estoy trabajando con gente de la Facultad de Ingeniería de la UBA para crear cursos con fuerte foco práctico, que permitan desarrollar algunas de los skills comentados aquí. Apuntamos a tenerlos en marcha a partir de Julio. Los mantengo al tanto.