miércoles, 30 de abril de 2008

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!

martes, 29 de abril de 2008

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.

sábado, 5 de abril de 2008

Curso “Administración de proyectos de software” en Rosario

Durante el mes de mayo dictaré un curso sobre “Administración de proyectos de software” en el Laboratorio de Calidad de Tecnologías de la Información, en Rosario.
Cuando hablamos con el Gerente del Laboratorio, Fabián Longhitano, sobre el contenido del curso, surgió una necesidad y un desafío que me interesó mucho.
Últimamente estoy presentando temas como Scrum, Critical Chain y otros, a personas que tienen conocimiento sobre las formas y herramientas “tradicionales” de administración de proyectos. Cuando es este el caso, en muchas ocasiones los ejemplos y explicaciones hacen foco en las diferencias, dando por supuesto las similitudes.
Por otro lado, el Laboratorio tiene un curso específico de Scrum, y en este momento yo creo que para la mayoría de los proyectos de desarrollo de software que encaramos en Argentina, Scrum es la mejor opción.

Entonces, ¿Cómo diseñar un curso de administración de proyectos de software, que sea útil y autocontenido pero complementario con el curso de Scrum, para personas que tienen experiencia en proyectos de desarrollo de software pero quizás no educación formal sobre administración de proyectos?
El resultado es un curso que plantea algunas de las herramientas tradicionales, pero desde un punto de vista iterativo e incremental, tomando algunas ideas de FDD, como el análisis y modelado de dominio inicial, y la planificación por funcionalidad (o features), junto con ideas de Critical Chain para la planificación. Algunas de estas ideas ya las presenté en otros cursos.
Adicionalmente, se plantean temas relacionados con la comprensión e interacción del equipo con su contexto. Esto es imprescindibles para cualquier equipo, independientemente de cómo se organice, y no suele ser desarrollados en las capacitaciones de Scrum básicas. Se dice que los 3 principales fuentes de problemas de los proyectos son la comunicación, la comunicación y la comunicación.
Parte de los problemas de comunicación se mejoran increíblemente en Scrum, pero la idea del Product Owner como único stakeholder externo al grupo es una simplificación o una transferencia del problema al Product Owner, que tendrá que manejar las expectativas y necesidades de los muchos stakeholders del proyecto.
Por último, una implementación de Scrum tendrá una definición de "ítem completo" (cuando se considera que un requerimiento está implementado) que inicialmente dejará muchas tareas fuera del equipo, como pruebas de performance, capacitaciones a usuarios, etc. Según un comentario de Ken Schwaber, un equipo puede requerir 3 años para que el producto liberado al final de cada sprint pueda ser pasado a producción sin ninguna tarea adicional. Mientras tanto, y mientras otros equipos, clientes, proveedores sigan utilizando terminología y formas de administrar proyectos distintas de Scrum, el contenido de este curso tendrá aplicación práctica para los asistentes.

El material del primer dictado de este curso se puede encontrar en los post del día 1, día 2 y día 3.

jueves, 3 de abril de 2008

Calidad en desarrollo de software ágil

Presenté este martes, 1ro de abril, la "Calidad en desarrollo de software ágil", en el IEEE.

En la charla, presenté lo mismo que habíamos dado con Lucas Campos en SEPGLA 2007, donde comentamos la experiencia de un grupo de Testing en la transición a una organización de desarrollo ágil (Scrum).
Además, presenté una elaboración posterior de la experiencia, tratando de generalizar y comentar cómo se modifican la participación de los Testers, Líderes de Testing y QA, la distribución de las actividades en los nuevos roles y el nuevo ciclo de vida. La presentación está disponible aquí.

La descripción de la convocatoria la pueden encontrar en el IEEE. Veremos si la podemos repetir, rogando que no coincida con algún otro evento político!

Agradezco a los valientes que quedaron en el centro de la Ciudad de Buenos Aires mientras la Presidenta daba su discurso en Plaza de Mayo!