Software Ágil

Sesión Desarrollo comunitario en Ágiles 2011

2011-10-25T17:59:00.000-03:00

Como proponente de la sesión "Próximos pasos como comunidad" del Open Space Una del 3er día Ágiles 2011, trato de registrar lo hablado.
Se plantearon distintos temas:
- Difusión de metodologías ágiles en las universidades
- Difusión de las metodologías ágiles en las empresas
- Eventos en Argentina
- Eventos Internacionales
- Listas

Hacia el final de la charla, me tuve fui a una charla relacionada con Jim Shore y Jeff Patton, por lo que los últimos minutos de la sesión no los puedo reportar.

Vamos a (mi) resumen. Espero que otros asistentes comenten, para completar la visión de la sesión.

Metodologías ágiles en las Universidades
Hace un tiempo (2008) evaluamos hacer actividades específicamente orientada a los profesores. No se hizo.
Nuestra visión actual es que los profesores que están receptivos se suben solos, y los reacios no se subirán fácilmente. Apostamos a la difusión de las ideas internamente desde los early adopters de una universidad.
Lo que si estamos intentando en la comunidad argentina es ofrecer a las universidades charlas y cursos por parte de voluntarios, aunque en forma reactiva (a pedido de las universidades).

Difusión de las metodologías ágiles en las empresas¿Que problemas hay en la adopción de metodologías ágiles en las grandes empresas?
Algo a mejorar es el convencer a los CIO de las grandes empresas.
¿Cómo podemos llegar a ellos? Considerando que nosotros no necesariamente tenemos el lenguaje de ellos.
Lo que surgió es hacer un desayuno de trabajo, con la presentación de un caso de éxito de desarrollo ágil por parte de algún CIO.

Eventos en Argentina
Se comentó la idea de hacer un evento Argentino, probablemente con formato Open Space, en la primera mitad del año.
Seguir con el Agile Open Tour.

Eventos internacionales
No se habló mucho sobre el Ágiles 2012. Nada sobre otros eventos.

Listas
Había gente que no conocía las listas comunitarias
    http://tech.groups.yahoo.com/group/foro-agiles/
    http://tech.groups.yahoo.com/group/agiles-argentina/
    www.agiles.org

Pruebas con fechas

2011-09-26T11:14:00.000-03:00

En los últimos días me encontré dosveces conversando sobre pruebas que incluyen fechas: en el cursosobre Fitnesse, con pruebas funcionales, y con mis compañeros en UTISIS con TDD.

Ambas conversaciones me hicieronrepensar este tema, y aprovecho para volcar mi visión actual.

¿Por qué es especial la prueba que involucra afechas?

Hay otras razones,pero en este post me centraré en la dependencia con la fecha delsistema. Esta dependencia puede darse en dos situaciones:

crear la entidad o realizar una acción sobre la misma (emitir un documento legal, como un cheque o una factura), que asigna la fecha del sistema a algún campo de una entidad u objeto de la aplicación.
consultar a la entidad u objeto, siendo el resultado de la consulta dependiente de la fecha (posiblemente la fecha actual).

Ejemplos:

Un cheque se emite al día de hoy (fecha de emisión), y vence en 30 días.
Quiero consultar si puedo depositar el cheque (no debe estar vencido).

Si hacemos pruebasque tengan dependencias sobre un elemento que no podemos controlar(en este caso el paso del tiempo), nuestras pruebas van a ser pocorobustas (como pruebas unitarias).

Si quiero probarel sistema completo, me puede interesar explicitar el uso de lasfechas de diferentes servidores. Estaría haciendo prueba deintegración en vez de prueba unitaria.

¿Que alternativas tengo?

Usar los datos de la prueba de manera que el estado o condición a probar sea válida al día de hoy.

En el caso del cheque, es fácil probar si el cheque puede depositarse (no está vencido), ya que si creamos un cheque hoy, seguro está dentro del período.
Probar el caso de cheque vencido es más complejo: quizás puedo modificar la fecha en la base de datos.
Se puede tener una generación automática de datos de prueba de manera que se cumplan las condiciones deseadas.

Disponer de una manera de modificar la fecha que toma el sistema como fecha actual.

Se puede tener los datos con fechas fijas y lo que se cambia es la fecha simulada del sistema. Se requiere cambiar al sistema, para probarlo.

Ampliar la funcionalidad de manera de recibir la fecha de referencia (en vez de tomarla del sistema)

Es conflictivo si el cliente no siente esto como necesario, parece ser complejidad adicional, sólo algo para facilitar las pruebas.
Generalmente sirve para el caso de las consultas, no de la generación.

Realizar pruebas relativas.

No usar valores absolutos de fechas u horas. Esto tiene el inconveniente que (similar al caso 1), que no se puede acelerar el paso del tiempo: por ejemplo, si mi datos tiene precisión de días, y quiero probar el próximo día.

Ejemplos

Alternativa 1

TDD

El siguiente ejemplo, en PHP, muestracomo se preparan los datos para las pruebas relacionadas con cursos,en la que hay 4 fechas (inicio y fin de la inscripción, inicio y findel curso). Los primeros 4 números 'datos' son días relativos aldía de hoy.

La función __creaCurso traduce entrevalores relativos de las fechas y los valores absolutos con que sequiere probar.

function testCursosActuales() {

$pruebas = array(

array('datos' => array(1, 1, 3, 3,false,false), 'actual' => False),

array('datos' => array(1, 1, 3, 3,true,false), 'actual' => True),

array('datos' => array(0, 0, 2, 2,true,false), 'actual' => True),

array('datos' =>array(-1,-1, 1, 1,true,false), 'actual' => True),

array('datos' =>array(-1,-1, 1, 1,true,true), 'actual' => True),

array('datos' =>array(-2,-2, 0, 0,true,true), 'actual' => True),

array('datos' =>array(-3,-3,-1,-1,true,true), 'actual' => False),

array('datos' =>array(-5,-3,-1,-1,false,true), 'actual' => False)

);

foreach($pruebas as $prueba) {

$id =$this->__creaCurso($prueba['datos']);

…

$this->assertEqual($prueba['actual'], $resultado);

}

Fitnesse

Dentro de una página se puede usar!today, que se reemplaza por la fecha / hora actual. También sepueden poner fechas relativas (!today -1).

Alternativa 2

En este caso, la forma de cubrir estoes la Inversión de Control / Inyección de Dependencias. Se debeutilizar el servicio de obtención de día y hora actual a traves deuna capa de abstración, de manera de poder reemplazarlo por unaimplementación controlada por las pruebas. Un ejemplo de esto semuestra en el capítulo 15 del libro FIT for Developing Software.

El SUT debe estar preparado (o debemospoder modificarlo para) para recibir la referencia al servicio.

Alternativa 3

En muchos casos el usuario pidefuncionalidad que depende de la fecha actual, pero esa funcionalidadpodría generalizarse para una fecha abitraria, con valor de negocio.Por ejemplo, cheque a depositar. Tiene sentido con fecha de hoy, perosi puedo poner fechas futuras, ayuda a la planificación.

Se puede evitar el aumento de lacomplejidad para el caso más usado con valores por defectoapropiados.

Alternativa 4

Puedo probar que un evento esté enintervalos temporales. Por ejemplo si quiero probar que un registrode auditoría es correcto, puedo almacenar el horario previo yposterior a la operación, y verificar que el registro esté dentrode ese intervalo.

Relación entre la frecuencia de entrega y los procesos

2011-08-12T01:05:00.009-03:00

Recientemente vi un video de Kent Beck, Software G Forces: The Effects of Acceleration, comentado por Mary Poppendieck en How Cadence Predicts Process.

Kent analiza como cambian los procesos y buenas prácticas según aumenta la frecuencia de entregas (Anual, Trimestral, Mensual, Semanal, Diaria, Horas). Comenta como algunas prácticas son buenas con cierta frecuencia de entrega y son malas en otras.
Plantea la relevancia de este análisis debido a que, según su percepción, la frecuencia de entrega de los equipos de software tiene a acelerarse.

Mi intensión es hacer un resumen, pero recomiendo ver el video que, aunque dura 90 min, es mucho más rico que este post.

Entregas anuales → trimestrales

Prácticas que se agregan: Test de aceptación automatizados, refactoring, Integración continua
Justificación: No se puede solo reducir los tiempos, hay que cambiar los procesos. No puedo tener un mes de integración y corrección de bug, con una o dos semanas de pruebas manuales para hacer regresiones. Entonces aparece Integración continua, y Pruebas de Aceptación Automatizada. No puedo tener uno o dos meses de diseño, aparece la necesidad de avanzar aún sin tener todo el diseño hecho o cerrado. Estoy seguro que tendré que cambiar el diseño, por lo tanto, tengo la necesidad de refactoring.

Cambios en el negocio: Suscripción.
Justificación: No se pueden vender 4 versiones por año. Necesito bajar el costo de transacción (tanto para la empresa como para los clientes).

Entregas trimestrales → mensuales

Prácticas que se agregan: prueba por parte de los desarrolladores, reuniones diarias, tarjetas en las paredes.
Prácticas que se quitan: Departamente de QA, soporte a múltiples versiones, Documento de diseño, Control de cabios, equipo de análisis, equipo de build.
Justificación: no hay tiempo para el ida y vuelta con un grupo separado de QA. La mayoría del testing y la reducción del defectos deben ser hechos por el mismo grupo, y probablemente por la misma personas (testers en el equipo y pruebas por los programadores), en el plazo de horas, no de días. La comunicación debe ser mucho más rápida, no podemos sincronizarnos y detectar problemas una vez por semana o mensualmente. Tenemos que estar al tanto cada día, solo tenemos 20 días para entregar (reuniones diarias), tenemos que planificar y re-planificar en forma barata y rápida (tarjetas en las paredes, dejar de usar control de cambios formales). No podemos dedicar mucho tiempo para escribir las decisiones detalladas de diseño antes de usarlas (Documentos de diseño).
Al aumenta la cantidad de entregas, el costo de soporte de muchas versiones se vuelve prohibitivo, y debemos mantener una o pocas versiones del producto (soporte de múltiples versiones). Necesitamos iniciar el diseño y el desarrollo, no podemos esperar una fase de análisis o el ida y vuelta en paralelo con un grupo de análisis (mismo problema que con QA).

Cambios en el negocio: Pagar por el uso.
Justificación: la suscripción no nos da suficiente feedback. Con pagar por el uso, sabemos realmente que funcionalidad que estamos desarrollando les interesa a los clientes.

Entregas mensual → semanales

Prácticas que se agregan: migración de datos en vivo, cero defecto, ramas temporarias, dovela clave (keystoning), kanban.
Prácticas que se quitan: equipos de test, migración en un sólo sentido, ramas de release, parches, diseño de usabilidad al inicio, venture capitals
Justificación: para poder cambiar las estructuras de datos en sitios con grandes volúmenes de datos y cantidad de usuarios, se debe hacer procesos de migración en dos o tres fases, de manera de cambiar la estructura sin nunca dejar de dar el servicio (migración de datos en vivo).
Como los tiempos son cortos, algunas funcionalidades se comienzan a agregar sin hacerlas visibles. Solo cuando está todo dispobible, se agrega la última parte (como la dovela clave de un arco de medio punto), y queda dispobible para los usuarios. Siendo que las entregas son tan rápidas, cualquier cambio, por más urgente que sea, puede incluirse en la próxima entrega. Se elimina la necesidad de procesos de emergencia (parches).

Cambios en el negocio: Bootstrap financing.
Justificación: La financiación de Venture Capitals necesita mayor predecibilidad en los planes, e impone restricciones a desarrollo de productos (a esta velocidad).

Entregas semanal → diarias

Prácticas que se agregan: inmunización, A/B testing
Prácticas que se quitan: staging, equipo de operaciones, reuniones diarias.
Justificación: algunos de los releases van a ser malos. Tenemos que tener formas muy sencillas de volver atrás o formas muy rápidas de corregir y continuar. No hay mucho tiempo para discusciones sobre diseño de interfase, se pude simplemente dar las alternativas y ver como lo usan los usuarios (A/B testing). Para hacer entregas rápidas, no podemos pasar por tantos pasos (ambientes) intermedios. Simplemente no hay tiempo para usarlos (staging), lo que se puede hacer es hacer instalaciones en distintos servidores de producción, que se va midiendo y obteniendo feedback. Todo esto lleva a que la operación debe ser parte de la responsabilidad del equipo (equipo de operaciones). La comunicación en el grupo tiene que ser tan continua y rápida, que no tiene mucho sentido para las reuniones diarias.

Mis conclusiones

Esta visión me hizo repensar mis ideas sobre La mejor manera de probar, reinterpretando parte de mis observaciones desde esta nueva perspectiva. La corelación entre ambas visiones es muy fuerte, pero no completa. Es interesante que la visión de Kent está muy asociada a situaciones en las que el software es el componente principal de los productos.

Como organicé un curso de Scrum de dos días

2011-06-29T10:06:00.011-03:00

Les cuento como organicé el último curso de Scrum que dí este lunes y martes en Córdoba. Experimenté con forma de manejar la agenda que funcionó bien.

La evolución de mis cursos, y origen de las ideas

En los últimos 3 años realicé más de 20 entrenamientos de Scrum. Inicialmente eran cursos introductorios de un día, con presentaciones con proyector intercaladas con actividades, como el folleto del spa para perros (similar a Resort brochure), o el ejercicio del nudo.
Luego, gracias a la insistencia de Jorge Ferndández, del Programa de Software del INTI, me animé a dar cursos de Scrum de dos días. En esos cursos tuve oportunidad de ampliar algunos temas, como las estimaciones o los problemas de implementación, que exceden la descripción básica de Scrum, pero que son necesarios para llevar Scrum a la práctica. Las presentaciones pasaron tener más diapositivas, al punto que imprimir todas las diapositivas del curso se volvió engorroso.
¿Por qué no hacer el curso de dos días como el que hice como asistente? Una presentación de medio día, y luego una simulación de día y medio (diseñar un juego que enseñe Scrum). Me encantó, pero no me sentía con capacidad para hacerlo (¡no al menos como lo facilitó Tobias Mayer!)
Por suerte, puede participar como co-entrenador junto con Alan Cyment y en otros cursos y actividades con Tobias y Diana Larsen. De ellos tomé las ganas y ejemplos de armar los cursos con cada vez menos proyector y más pizarrón, rotafolio y actividades.
También tomamos ideas de la experiencia de Fernando Waisman y Natalia Davidovich de organización de un curso cuatrimestral usando Scrum. Lo aplicamos en en la materia en la que participo (junto con Leonardo Fernández, Ezquiel Kahan, e invitados) en la Facultad de Ingeniería.

Este curso, ¿cómo fue?

Un problema de no usar presentaciones es la dificultad de tener contexto sobre que tema estamos dando, cuales ya dimos, cuales faltan.
Por otro lado, busco que la forma de dar el curso sirva como ejemplo de prácticas de Scrum. Esto es bueno ya que es una experiencia compartida con los asistentes.

Presenté en el curso la agenda como un taskbord que representa todo el release plan.

From Curso Scrum en Cordoba

Las columnas son: tema del sprint, ítems planeados, ítems realizados.
Cada ítem tiene un nombre y una estimación de tamaño (T-Shirt size S/M/L).
Los sprint son de medio día, y se estima que un ítem S se realiza en media hora, un ítem M en una hora y un ítem L en dos horas.

En el inicio del curso definimos las reglas (surgieron: uso de celular, horarios de almuerzo, conversaciones simultáneas) y las métricas con las que mediríamos el éxito del curso. Para esto último se usó: brainstorming, agrupamiento por temas y votación. Lo agregamos a nuestro taskboard.
Cuando surgieron consultas, revisámos si correspondia a un tema a tratar en el futuro, en cuyo caso lo agregamos al ítem correspondiente, o al sprint, si no quedaba claro inmediatamente a que ítem correspondia.
El resultado al llegar al primer almuerzo fue este:

From Curso Scrum en Cordoba

Al planear traté que en cada uno de los tres primeros sprint hubiera dos actividades. Esto permitió tener siempre una actividad de inicio del sprint, que sirve para empezar el sprint con energía.
Probé por primera vez la actividad ideada por Carlos Pantelides. Funcionó bien, pero por como la hice (una sola imágen recorriendo entre quince personas), perdió punch. Probablemente debería haber hecho circular simultáneamente dos conjunto de tarjetas.

From Curso Scrum en Cordoba

Al final del primer día hicimos una retrospectiva, en la que se propucieron nuevos ítems. Debido a que no podíamos hacer todos, repasamos el contenido propuesto de cada tema, y se voto cuales sacar (ya que eran menos los que había que sacar que los que quedaban). Entre todos, planificamos el orden del segundo día. Debamos los ítems descartados, por las dudas que nos sobrara el tiempo.

From Curso Scrum en Cordoba

En la mañana del segundo día, la dinámica del curso (consultas) llevaron a incuir algunos ítems que estaban inicialmente planeados para la tarde, por lo que tuvimos que alrerar el orden. El problema fue que la simulación (un ítem de tamaño L) quedó para el final del sprint, y no podíamos dividirlo.

From Curso Scrum en Cordoba

La simulación (el Pajarraco Scrumero, originalmente definido por Alan, y disponible en el blog de Ingrid Astiz) tuvo el éxito que siempre tiene.

!Gracias Hernán por la foto!

Finalmente a la tarde pudimos completar todo lo planificado para el segundo día.

Retrospectiva

En el cierre, hicimos una retrospectiva, que incluyó tres partes:

Radar del equipo: basandonos en las características seleccionadas al inicio del curso, se votó y llegamos a la conclusión: amplio acuerdo que el contenido es útil (puede ser aplicable en algún lugar), la mayoría cree que puede ser aplicable en la empresa, la mayoría cree que tiene el conocimiento como para iniciar la implementación.

Histograma de satisfacción con el curso (abajo, en la imágen): todos creen que el curso fue bueno(3) o muy bueno (4).

Sugerencias de mejora:
- material adicional disponible antes del curso (el material que hicimos con Ricardo Colusso lo distribuí al final del primer día).
- Referencias recomendadas para profuncizar los temas (falta bibliografía en el docuemento).
- Algo de presentaciones no vendría mal: solo use presentación para mostrar fotos de ejemplos de taskboard. Debo pensar como llegar a un equilibrio.
- Se hacen largas las 8 hs diarias.
- Tomar un caso de la compañía para mostrar un ejemplo de una histoaria pasando por todos sus estados.
- La agenda funcionó bien, aunque se podría mejorar indicando qué ítem se está tratando (bandera o nueva columna).

From Curso Scrum en Cordoba

A la gente de BHP (Ernesto Corona, Diego Nicotra y Laura Castro) que organizaron el curso, ¡Gracias!
Gracias también a los locales Flavia, Carla y Eduardo :D.

La mejor manera de probar, en Agiles@BsAs (video)

2011-01-13T22:39:00.005-03:00

Como parte de las reuniones mensuales del grupo Ágiles@BsAs, el martes 11 de enero presenté la charla ¿Existe 'la mejor manera' de probar? en las oficinas de Bs As de Southworks.

Pueden ver el texto en el que se basa presentación, o su versión en Software Guru (pdf) y los 'slides' prezi

Agiles@BsAs: ¿Existe "la mejor manera" de probar? from Southworks Showcase on Vimeo.

Gracias a los asistentes, que a pesar de ser enero, se acercaron. Y gracias a los organizadores, Adrián Eidelman, y la gente de Southworks, Martín Salias y Julián Scopinaro, además de prestar el lugar, filmaron y subieron la presentación. Gracias a Masa Maeda por invitarme a publicar en Software Gurú.

VI Jornadas de Software Libre en Junín

2010-11-08T11:47:00.008-03:00

El sábado estuve en Junín, invitado por los organizadores, la Rama Estudiantil del IEEE de la UNNOBA. El evento, ya en su sexta edición estuvo muy bueno (lamentablemente solo estuve en una parte del mismo)

Una buena noticia, los videos de las sesiones van a estar disponibles. Además, se difundieron en vivo!

Aún así, va un breve resumen de lo que escuché.

El amigo Andés Riancho presentó una visión de la seguridad en ambientes web de una manera muy entretenida.

Planteó un escenario (acceso pago a Internet en un hotel), y nos mostró como cuatro perfiles de atacantes distintos se comportarían, y en todo loos casos lograría acceso.

El primero, alguien que conoce mucho de sistemas operativos y networking (Charly García)

Usa un CD (BackTrack), una distro basada en Ubuntu, con herramietas de seguridad. Booteando desde el CD se tienen todas las herramientas para el ataque, ya configuradas (listas para usar)

En este caso, el ataque fue tcpdump y luego fakeo de la mac (ifconfig) de algún usuario con acceso.

El segundo, sabe de todo (Sheldon Cooper)

El objetivo es tomar control del servidor que tiene el proxy

- Nmap: info de los puertos abierto

- OpenVas: scanner de vulnerabilidades

- MSF: permite hacer exploits

En el ejemplo se encontro una vulnerabilidad, y se pudo usar un exploit que permite correr comandos en el servidor. Luego hay que trabajar para lograr un usuario de mayor nivel, ya que se entró por un servicio, cuyo usario tenía pocos privilegios.

El tercero sabe mucho seguridad informática (Paris Hilton)

Utiliza la herramienta de la que Andrés es creador (w3af), no encuentra nada obvio inicialmente, pero luego aplica una estrategia de Man in the Middle (MITM proxy provisto por la herramienta), y con eso falsea un post y consigue acceso gratuito.

El cuarto no sabe nada de Internet ni servidores ni seguridad informática (Chaqueño Palavecino)

¡Pero no es ningún tonto! Mira la página, y encuentra un fallo en el procedimiento. ¡Hace que le carguen el costo a otro huesped del hotel!

Esperen el video, un maestro Andrés!, como hacer que una charla de seguridad sea divertida.

Python y las aplicaciones extensibles, por Roberto Alsina

Roberto usó Qt (GUI multiplataforma), como una manera de hacer una aplicación rápidamente, para luego dedicarse a hacerla extensible.

Usó Qt Designer para hacer en 15 min un buscador de twitter (kwrite como editor, creo que lo usó solo para zoomerar)

Luego de tener la aplicación andando, la hizo extensible usando un framework (yapsy) para manejo de plugin. En poco tiempo tuvo una aplicación extensible!. Las extensiones son clases

Python con un método actual (un patrón command) y un pequeño archivo de configuración. Muy elegante.

Juan Pedro Fisanotti y Django

Fisa presentó Django y implemento un sitio sencillo.

Entre algunas de las cosas que resaltó estuvierno:

- Aplicaciones desacopladas (reusables), un plus de Django

- MVC: la forma de programar Web en estos días

- ORM: el mejor amigo del programador que usa datos en DB relacionales

- Plantillas: simplicidad (y posibilidad de no usarlo si uno no quiere!)

- Admin: el argumento de venta de Django, no vuelvas a escribir este código, chabón.

¿Existe la “mejor” forma de probar?

2010-11-01T10:46:00.014-03:00

¿La prueba manual de software es necesaria? ¿Es suficiente? ¿Y la prueba automatizada?

Es tentador pensar que si estudiamos el problema (prueba de software) lo suficiente y somos buenos profesionales, podremos encontrar “la mejor manera” de hacerlo. Si conocemos “la mejor manera”, los que realizan la prueba de otra manera están equivocados.

Alguna vez pensé conocer cual era “la mejor manera”. Luego, aprendí o cambié de contexto, y “la mejor manera” cambió.

A partir de estas experiencias soy algo escéptico cada vez que escucho (de otros, o de mí!) afirmaciones en este sentido. Esta nueva “mejor manera”, ¿que problemas viejos resuelve? ¿que problemas nuevos crea? ¿en que contexto está siendo usada?

Voy a comentar mi experiencia personal con diferentes formas y contextos de prueba. En cada contexto, analizaré los problemas comunes y cultura, y también si ese contexto es un estado final o sólo un paso hacia otro estado. Este texto se basa en la presentación que realicé en Ágiles 2010 – Lima.

No trato el problema más general de la calidad de software, sino solamente sobre la prueba.

El modelo

La comparación de los contextos está organizada utilizando el modelo de prueba comentado en el libro “Agile testing”, de Lisa Crispin y Janet Gregory, a su vez basado en las propuestas Mike Cohn y Brian Marick. En este modelo, tenemos 4 tipos de prueba (de arriba hacia abajo):

Pruebas Manuales
Pruebas de Interfase Usuaria (automatizada)
Pruebas de Aceptación o API (automatizada)
Pruebas técnicas o unitarias y de componentes (automatizada)

El costo de ejecución es menor en las Pruebas técnicas y va creciendo hasta el máximo costo, que es la ejecución de pruebas manuales. El costo de mantenimiento de las pruebas automáticas también es creciente, desde el mínimo en las pruebas técnicas, hasta el máximo en las pruebas de Interfase Usuaria. El mantenimiento de las pruebas manuales es equivalente o menor que el caso de pruebas técnicas automatizadas. En todos los casos, el costo y mantenimiento de las pruebas automatizadas requiere una inversión importante en experiencia e infraestructura. Pero esa inversión se puede llevar en muchos casos de un proyecto a otro. Los costos consideran esa inversión amortizada o distribuida en gran cantidad de pruebas.

La relación entre los costos lleva a sugerir que la forma más eficiente de dedicar esfuerzo tiene la forma de una pirámide, con las pruebas técnicas (unitarias y de componentes) en la base, las de aceptación (o API) luego, y finalmente las pruebas de UI en el vértice de la pirámide.

Contexto: Prueba Ad hoc

Durante los primeros 10 años de mi carrera, trabajé en grupos de 5 personas o menos, trabajando en desarrollo de software en áreas tan variadas como aplicaciones administrativas (ERP), adquisición y procesamiento de imágenes médicas (de medicina nuclear), y sitios de Internet que brindan información bursátil en tiempo real.

En estos equipos, no había separación de roles, todos hacíamos un poco de todo. En particular, las pruebas las hacíamos entre todos, intercambiábamos roles, probando la funcionalidad realizada por otro. La prueba final la hacían los jefes, usuarios o, si existían, las personas de servicio a cliente.

Al no haber responsables definidos la prueba solía quedar huérfana, sin mejora. En este contexto es un problema realizar pruebas de regresión, una tarea poco atractiva y compleja.

La evolución de este contexto suele ser incorporar un tester o área de testing para Prueba Manual (camino tradicional) o que los programadores empiecen a desarrollar Pruebas Técnicas o incluso TDD (camino del desarrollo ágil).

Cualquier camino de evolución pasar por un cambio cultural, ya que en estos grupos la prueba no suele ser valorada lo suficiente. Se suele escuchar “si los programadores hacen bien su trabajo, ¿por qué senecesitaría probar?”

Los problemas se hacen más notorios cuando el grupo debe crecer, tiene mucha rotación o debe mantener muchos productos.

Caso: en una importante compañía de fondos de pensión y seguros de retiro pidieron presupuesto para mantenimiento de muchas aplicaciones existentes (legacy: sin pruebas automatizadas). El cliente no aceptó una propuesta de equipo con cuatro personas, en la que una cumplía el rol de tester; sin embargo, aceptó un equipo de 4 personas con 3 programadores. Internamente el equipo se manejó con uno de los 'programadores' actuando como tester, con buenos resultados.

Motto: ¡No vale la pena probar!
Problemas: baja calidad, baja previsibilidad, regresiones
Cobertura: no hay métricas.
Responsable: todos y ninguno. Pruebas por el usuario.
Organización: generalmente chicas y con poca estructura

Contexto: Prueba Manual

En mi siguiente reencarnación, estuve 8 años en una compañía que trataba de convencer y ayudar a empresas de contexto Ad hoc a que la prueba es algo útil y necesario.

Este cambio cultural es difícil, y con riesgo de involuciones. Por eso se busca separar en un grupo autónomo a los responsables de probar. La separación y la función de probar, que a veces se desvirtúa como prueba de la persona en vez de prueba del producto, provoca enfrentamientos y fricciones con los programadores.

El diseño de las pruebas es divertido, pero ejecutarlas una y otra vez es terriblemente aburrido, lo que lleva a que pocas personas quieran quedarse mucho tiempo haciendo esto. Resultado: muchas personas capaces se van a otras áreas, más divertidas (como desarrollo), y por el recambio hay mayoría de novatos en los roles de prueba. Los que se mantienen en el rol suelen ser personas con poca inclinación a lo técnico. Para crecer profesionalmente, los testers se dedican a tareas de QA (procesos) o de Analistas de negocio, que son más valoradas en el mercado.

En este contexto, los problemas son que la prueba de regresión de productos medianos y grandes se hace muy costosa, lo que lleva a ciclos de desarrollo muy largos (para ejecutar pocas veces las pruebas de regresión) o disminución de las pruebas realizadas durante la regresión (lo que lleva a baja calidad).

La salida parece ser la automatización, pero lamentablemente no es una salida fácil, ya que las personas que están en el grupo de prueba no tienen conocimientos técnicos, y la relación con el grupo de programación, que puede aportar el conocimiento técnico, no es la mejor.

En algunos casos se pasa a Prueba Manual Optimizada.

Motto: ¡No vale la pena automatizar las pruebas!
Problemas: costo de ejecución, que a su vez lleva a seleccionar las pruebas, que baja la confianza y lleva a pocos releases
Cobertura: requerimientos, casos de uso
Responsable: Testers / QA.
Organización: testing separado
Prácticas: casos de prueba manuales, checklist

Contexto: Prueba Manual Optimizada

Luego de 6 años en Prueba Manual, reencarné en Prueba Manual Optimizada. Algo bueno habré hecho en mi vida anterior, porque un cliente exigió en un proyecto que automaticemos.

¿Por qué automatizar? Por criticidad del negocio o cuando se logra volumen suficiente en el área de prueba como para justificar la inversión.

¿Cómo hacerlo? Se suele incorporando programadores al grupo de prueba con el rol de Automatizadores de la Prueba.

Con gran esfuerzo se mantiene un conjunto de pruebas automatizadas, que permiten hacer pruebas de regresión en forma rápida, lo que permite mejorar la calidad, confianza y tiempo de respuesta. Pero por otro lado, debido a la separación entre los grupos de programación y los de prueba, es frecuente que cambios realizados en forma inconsulta en el producto rompan las pruebas automatizadas. Ysi sumamos el hecho que estas pruebas suelen ser de caja negra a través de la UI, el costo de mantenimiento de las pruebas automatizadas es alto.

Es una situación extraña, ya que en muchos casos nos damos cuenta que podríamos ser mucho más eficiente si algunas pruebas fueran de caja blanca y las hicieran los programadores, o si los testers pudieran participar en la toma de decisiones sobre cambios al producto. Pero no podemos influir en la forma en que se programa, es otro grupo.

Esta tensión puede resolverse cuando los grupos de programación y prueba empiezan a trabajar juntos y se pasa al contexto Técnico++ o al Nirvana.

Motto: No podemos mejorar la producción del código.
Problemas: mantenimiento de las pruebas
Cobertura: requerimientos, riesgos
Responsable: Testers, Testers automatizadores, QA.
Organización: organizaciones grandes, grupos de homologación separado
Prácticas: pruebas automatizadas de interfase de usuario

Contexto: Prueba Técnicas

Algunos equipos en los que trabajé (entre 2 y 40 desarrolladores) tenían la cultura de calidad incorporada con fuerte influencia de XP, por ejemplo con prácticas de Integración Continua, TDD y Pair programming incorporadas.

En estos equipos la calidad es alta comparada con los contextos de Prueba Manual. Se suele utilizar cobertura de código como métrica relevante. Los problemas que suelen presentarse son: mantener el tiempo total de ejecución de las pruebas bajo (<10 min)

La evolución natural es hacia Pruebas Técnicas++, ya que en este contexto ante los problemas la primera solución que se piensa es agregar pruebas automatizadas.

Caso: en un proyecto Ruby on Rails comenzamos con una funcionalidad de CMS sencillo para seguir luego con funcionalidad más compleja. Se trabajaba con coberturas de código por arriba del 80%. A los dos meses del proyecto, el usuario vuelve a utilizar la funcionalidad de CMS sólo para encontrarla rota, debido a un cambio en las vistas que pasó desapercibida por mucho tiempo. El análisis del problema llevó al equipo a agregar pruebas automatizadas con Cucumber y Selenium (API y UI).

Motto: Sólo vale la pena las pruebas automatizadas
Problemas: usabilidad, cumplimiento de requerimientos y regresiones en cuanto a requerimientos
Cobertura: líneas de código
Responsable: programador
Organización: equipo de programadores
Prácticas: TDD, CI

Contexto: Prueba Técnicas++

Los equipos en este contexto vienen de la Prueba Técnica, agregando prueba de APIs y quizás de UI, o de la Prueba Manual Optimizada, agregando prueba unitaria y quizás de API. En ambos casos, tienen des-balanceada la pirámide de prueba. En el caso de los que vienen desde Prueba Manual Optimizada, puede ocurrir que pierdan la prueba manual o la prueba de UI automatizada, dado que el esfuerzo por incorporar pruebas unitarias es grande, y se detecta duplicación de esfuerzo entre las pruebas existentes (manuales o automáticas a nivel UI).

Luego de lograr el balance en la pruebas automatizadas, el problema remanente son las pruebas de difícil automatización (¡ningún programador las quiere hacer!) y la falta de prueba exploratoria. Esto último puede llevar a productos que son correctos desde el punto de vista funcional y de robustez, pero que no son sobresalientes, ya que no se detectaron puntos a mejorar en forma temprana.

Motto: Sólo vale la pena las pruebas en automatizadas
Problemas: usabilidad, cumplimiento de requerimientos
Cobertura: líneas de código y requerimientos
Responsable: usuario y programador
Organización: equipo de programadores
Prácticas: ATDD, BDD, TDD, CI

Contexto: Nirvana

Aunque no he llegado aún al Nirvana. Pero estoy atento a los reporte de gente que estuvo, como Lisa Crispin.

Estos equipos han incorporado todas las prácticas de XP. Están en continuo aprendizaje sobre como complementar los distintos tipos de pruebas, la automatización a diferentes niveles y la exploración, para lograr la combinación óptima. Están en un equilibrio dinámico, siempre cambiante, atentos a cambios en el negocio, la organización, el producto y nuevos desarrollos de prácticas en el equipo y la comunidad. Se preocupan por la cadena de valor completa.

Motto: Optimizamos el todo
Problemas: buscar el balance óptimo
Cobertura: líneas de código y requerimientos, riesgos
Responsable: equipo completo (whole team)
Organización: Lean
Prácticas: ATDD, BDD, TDD, CI

Re-visitando

Las descripciones dadas en cada contexto plantean la visión que tenía de lo 'correcto' cuando estuve en ellos, aunque algunas cosas me hacían ruido. Mirando ahora hacia atrás, tengo una visión distinta, que comento a continuación.

Re-visitando: Nirvana

Hay quienes quieren ir más allá de las prácticas de XP.

Los usuarios se equivocan tanto como los desarrolladores, ¿podemos hacer algo para ayudarlos? Hace 5 años Sebastián Elbaum nos comentaba sobre las pruebas para los usuarios finales. Actualmente Excel indica (subraya) las fórmulas que considera “raras” y co posibles errores del usuario, como el caso de una columna con fórmulas que totalizan filas, excepto en una celda que tiene un valor (no una fórmula).

Soporte a la prueba exploratoria: Brian Marick nos comentaba el año pasado sobre experimentos que estaba haciendo para potenciar el mecanismo de UNDO de una aplicación, de manera de poder volver atrás en una prueba para tomar otro camino en la exploración de la misma.

Re-visitando: Ad hoc

¿Qué pasa cuando la solución implica poco o nada de programación en el sentido estricto, sino más bien configurar soluciones existentes o crear contenido?

Caso: hace un año, poniendo en marcha nuestro primer evento usando Open Space (Agile Open Bs As 2009), teníamos que decidir como hacer la registración de los participantes. Luego de evaluar un par de alternativas, incluyendo desarrollar, decidimos realizar la registración utilizando la funcionalidad de Formularios que brinda Google Docs. Una de las personas se quejó del formulario de registración, la pregunta “¿Le interesaría un evento de dos días?”, tenía sólo alternativas de dos días (dos días de semana, viernes y sábado, sábado y domingo) y era obligatoria. Hasta ahí, entendible. Pero la sugerencia que nos hacia era que deberíamos tener pruebas automatizadas. Probablemente esta persona se imaginaba que eramos un equipo de desarrollo en el contexto de Prueba Manual o Ad hoc, y nos sugería que deberíamos estar en Prueba Manual Optimizada o Técnica. ¡Pero la realidad fue que una sola persona configuró el formulario en media hora! Y el problema no tenía que ver con funcionalidad implementada, sino con la semántica del texto y la consistencia del mismo con el tipo de control utilizando. Este problema semántico pasó desapercibido por los revisores. Automatizar la prueba del formulario no hubiera encontrado el problema, y hubiera sido más costosa que el 'desarrollo'.

En algunas situaciones, la prueba Ad hoc podría ser lo mejor: desarrollo de sitios sencillos usando CMS, creando contenido y configuración.

Re-visitando: Prueba Manual

¿Podemos siempre tener un equipo integrado? ¿Podemos siempre confiar en el equipo?

Homologación de plataformas: cuando debemos proteger una plataforma, como en el caso de Microsoft, Apple o el entorno de producción de un banco, nos interesa validar algunos puntos mínimos, y simplemente no podemos confiar en que el equipo que realizó el producto (en muchos casos un tercero), haya realizado bien su trabajo. Pero por otro lado, aunque automaticemos algunas partes de la prueba (preparación de ambientes, comparaciones de antes y después), hay una buena parte de la prueba que es exploratoria, y que no tiene mucho sentido automatizar, ya que es de única vez.

Alto riesgo: aunque podamos ser un sólo equipo, cuando hay en juego mucho dinero o vidas, queremos redundancia. Podemos pagar pruebas manuales para lograr independencia (dos grupos, con dos técnicas distintas)

Productos que no controlamos, open source o no: cuando construimos sobre otros productos, la ecuación que justifica las pruebas automáticas nos juega una trampa, si el dueño del producto decide cambiar la aplicación, él solo evalúa sus costos, pero puede romper nuestras pruebas automáticas. (ej. en los que trabajé: Outlook y Liferay)

En algunas situaciones, la Prueba Manual podría ser lo mejor, buscando el mejor punto en el continuo que hay entre prueba manual totalmente definida y la prueba exploratoria. También debe considerarse tener ayudas automatizadas.

Re-visitando: Prueba Manual Optimizada

Cuando el producto no es sólo software, puede ser factible automatizar parte de la prueba (correspondiente al software) y realizar el resto en forma manual.

Algunos casos de esta situación podrían ser

CMS complejos, en los que no sólo se desarrolla contenido, sino también extensiones o aplicaciones.
Productos en los que el software acompaña al texto, y probablemente el texto sea lo más importante, como tutoriales
Soluciones que incluyan procesos: probar que los procesos se realicen correctamente (por ejemplo que las personas estén entrenadas y sepan qué hacer) es algo que debe probarse con las mismas personas.

Re-visitando: Prueba Técnica/ Técnica++

No encontré situaciones en las que convenga quedarse en estos contextos, siempre me parecieron pasos hacia el Nirvana. ¡Pero creo que es sólo cuestión de tiempo!

Conclusiones

Las metodologías ágiles han logrado una mejora muy importante en la calidad lograda en los desarrollos. Es tentador aplicar siempre las técnicas y prácticas que han permitido estas mejoras, y es tentador pensar que nuestros problemas se resuelven con más y mejor aplicación de las mismas.

Por otro lado, he escrito críticas a algunas prácticas (como el (ab)uso de métricas de cobertura de código), para luego encontrar que personas a las que respeto encuentran estas críticas inconvenientes, ya que se interpretan como un ataque a las técnicas de automatización de la prueba.

Estos contextos me han ayudado a aclarar las discusiones sobre la conveniencia de la utilización o no de las distintas prácticas. Espero que pueda ayudar a otros. ¿Tu que opinas?

Visita al PILP

2010-07-30T10:30:00.007-03:00

Estuve hace unas semanas en el PILP, dando un curso de un día sobre Scrum, como parte de una serie de presentaciones y charlas que estamos haciendo junto con Ricardo Colusso y Carlos Peix.

Pueden ver el resumen de una entrevista que me hicieron. Yo hubiera hecho otro resumen :D

Como siempre me pasa, una de las resultados que más valoro de dar cursos es encontrarme con gente que hace cosas interentes:

La gente del PILP está haciendo actividades de difusión de tecnología entre chicos de primaria y secundaria junto con Lego (First Lego League) y Microsoft (Gaming.NET). ¡Muy interesante! Yo había pensado ofrecerles hacer algo de TISP, pero con lo que están haciendo me parece que no es necesario.
¡Usá un telescopio de 40cm! La Universidad de La Punta pone disponible un telescopio para la comunidad de internet, gracias al desarrollo hecho por Moisés Rivas y otras personas del grupo dirigido por Mariano Terranova (Autopista de la Información).

Material curso Scrum

2010-06-23T22:54:00.002-03:00

Material (apenas) actualizado (ppt)

Algunas preguntas interesantes que surgieron hasta ahora:

¿Que necesito saber para ser un buen ScrumMaster?

mmm, difícil. ¿Práctica? parece razonable. ¿Cursos? espero que este ayude en algo, y hay otros (CSM/CSPO/CSD/Retrospectivas/...). ¿Libros? Aparte de los indicados aquí, me parece interesante el nuevo de Lyssa Adkins

¿Hay un checklist para las reglas que puede usar un equipo?

No que conozca. Las reglas las crean los equipos.

Algunas ideas en los libros de Schwaber. Algunas otras en otros libros. Y está la técnica de Pomodoro (y su crítica).

Referencias del curso de Scrum

2010-06-14T16:34:00.009-03:00

En los últimos tiempos fui disminuyendo la cantidad de transparencias en los cursos, para dar más lugar a las actividades interactivas y a la adaptación del nivel de detalle según el interés de los asistentes.

En el último curso, me basé completamente en la dinámica que no requiere proyector. En lineas generales me pareció que la dinámica fue buena, pero una pérdida fue que las referencias a libros, sitios y eventos quedaron repartidos a todo lo largo de los dos días de curso.

Trataré de cubrir aquí esa falencia. Si quieren pueden ver la presentación previa del curso.

Grupos y sitios

Foro ágiles: lista de correo de intercambio de ideas y experiencias, preguntas y anuncios de la comunidad hispanoparlante (Latam y España)

Ágiles: uno de los sitios comunitarios de metodologías ágiles en español.

Ágiles Argentina: lista de correo de la comunidad argentina para anuncios locales, organización de eventos

Blog de Juan Gabardini: ¡Este blog! Desarrollo ágil de software, con cierta inclinación hacia el testing

Scrum Development: lista de mails 'oficial' de Scrum.

Scrum Alliance: sitio 'oficial' de Scrum. Por ejemplo tiene la lista de capacitaciones de CSM.

Agile Alliance: sitio 'oficial' sobre el desarrollo ágil. Son los organizadores del mayor evento anual, Agile 20xx.

Eventos

Ágiles 2010 – Oct – Lima: Evento anual de la comunidad latinoamericana sobre metodologías ágiles.

Agile Open Tour: Serie de eventos argentinos realizados con el formato Open Space. Se han hecho 6 durante 2009 y hay planeados 8 eventos en el 2010.

Libros y otro material

Ken Schwaber: Agile Project Management with Scrum / The Enterprise and Scrum

Libros de referencia. El primero con foco en scrum dentro de un equipo, el segundo con la implementación en toda la organización. Ver mis comentarios previos.

Rob Austin y Lee Davin: Artful Making

Una visión novedosa sobre el desarrollo de software y otras actividades (teatro, planificación estratégica), que explica la secuencia desde el trabajo hecho artezanalmente, la producción industrial y la artística, con las motivaciones económicas y implicancias en cuanto a las condiciones necesarias y la forma de trabajo resultante. Ver mis comentarios previos.

Henrik Kniberg: Scrum and XP from the Trenches

Conjunto de experiencias en todos los temas enfrentados al usar Scrum, con referencias a libros y material adicional. Disponible en forma electrónica gratuita y en español.

Mike Cohn: User Stories Applied / Agile Estimating and Planning

Libros de referencia obligada para temas los temas del título. Además Mike tiene muchos recursos disponibles gratuitamente.

Craig Larman: Agile & Iterative Development: A Managers Guide

Buena introdoción a la idea general y sumario de los distintas 'metodologías'. Tiene varios libros interesantes y algunos documentos gratuitos muy interesantes, como Lean Primer

Kent Beck: Extreme Programming Explained: Embrace Change

Uno de los primeros libros sobre Desarrollo Ágil, con contenido relacionado con las pácticas técnicas, que no están cubiertas en los libros mensionados anteriormente.

Mary & Tom Poppendieck: Implementing Lean Software Development

Los conceptos de Lean están atrás de muchas de las buenas prácticas Ágiles. Uno de los tres libros de los Poppendieck (todos recomendables).

David Anderson: Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results / KANBAN, Successful Evolutionary Change For Your Technology Business

En el primer caso, David toma los conceptos de TOC aplicados al Software. El segundo es un libro de próxima publicación (con traducción a español) con la aplicación de Lean que el inició y nombró.

Notas de facilitación de Open Space

2010-06-07T02:04:00.005-03:00

Estuve en la organización y luego facilité el Agile Open Buenos Aires 2010 – ¡Programando!. Voy a comentar algunas cosas que hicimos e ideas sobre mejoras, que quizás puedan servir para otros que quieran organizar eventos similares.

Preparación

Luego del evento anterior en Buenos Aires (Agile Open Buenos Aires 2010 – Calidad), a varios de nosotros nos quedó la idea que hacer eventos más focalizados podría servir para tener conversaciones más interesantes para los más avanzados. Por otro lado, la idea de hacer los eventos más y más livianos en cuanto a la organización me llevó a consultar en uno de mis trabajos, sobre la posibilidad de hacerlo en Exactas.

Poner en marcha en evento fue impresionantemente sencillo:

Hablar con el responsable de la Secretaría de Extensión, Graduados y Bienestar (Diego Quesada-Allue), y gracias a él, con el responsable del comedor de Pabellón II de Ciudad Universitaria. Resultado: el lugar y la comida, resuelto. El único costo, la posibilidad de tener que pagar 100-200$ por uso de más luces.
Crear la página y el formulario de inscripción. Copiando de los eventos anteriores, un trabajo de un hora.
Difundir en la lista agiles-argentina y en la lista interna de Exactas, y acá :)
Crear el grupo de organización. ¡Gracias a los organizadores! Martín Alaimo, Diego Fontdevila, Marcelo Belnicoff y Francisco Tufró.

Con respecto a los sponsors, la duda era si buscar o no. Por un lado, el bar es barato, por lo que no es gran esfuerzo económico para los asistentes. Y entonces, no buscar sponsors simplifica la organización.

Por otro lado, siempre es simpático tener la comida esté paga, y dar lugar para que las empresas que apoyan estos temas logren visibilidad.

Decisión de compromiso, sponsors según la cantidad de inscriptos (un sponsor cada 30 inscriptos) y sólo sponsors que nos hicieran la vida sencilla.

A medida que avanzaban las inscripciones, aparecieron algunos 'problemas' (al menos en mi visión de lo que podría pasar):

Había temáticas dispares, y me imaginaba que ser atomizarían mucho las charlas.
Por otro lado, los temas eran interesantes, pero quizás con poca gente especialista en ellos. La gente ser vería obligada a elegir entre muchas sesiones interesantes para escuchar, aunque quizás no pudiera aportar.

Como respuesta a estas situaciones, propuse un cambio en el formato:

Lightning talks: dedicar un tiempo (55 min) inicialmente a comentar una idea a todos los asistentes
Facilitar la realización de un gran número de sesiones en paralelo, de tamaño y duración variable: la agenda se arma sin indicar cuantas sesiones simultáneas puede haber. Los responsables de las sesiones deben realizar un cartel que deben poner en la mesa en la que están, de esta manera el que se quiere sumar, busca la mesa con el correspondiente cartel.
Reforzar la idea de libertad de tiempos: Las sesiones se planifican cada hora, pero se hace un aviso (cuenco japonés mediante) al cumplirse 45 min. Una señal para la gente que quiere hacer un break. Suena nuevamente el cuenco cuando empieza la siguiente hora, pero nada obliga a la gente que está en una mesa a cortar lo que está haciendo. Las nuevas sesiones sólo tienen que buscar una mesa libre.

Realización

Se lograron alto porcentaje de personas técnicas (más del 50%), y alto porcentaje de personas con experiencia en ágil (más de 50% con más de un año de experiencia).

Asistimos 34 personas. Se mantiene el promedio de aproximadamente el 50% de los inscriptos. Vinieron los amigos Julian Arocena y Esteban Roasio de Tandil y una persona de Córdoba.

Los lightning talks se usaron para presentar ideas de sesión en forma más amplia.

Como hubo menos de 11 propuestas de lightning talks, adelantamos la preparación de la agenda, que terminó relativamente rápido. Había bastante experiencia con Open Space, la gente propuso las sesiones en poco tiempo.

Quedó un tiempo entre apertura y la primera sesión, que se usó como un break y para socializar. Creo que se aprovechó.

La dinámica de las sesiones se apartó de lo que pensaba. Se dieron sesiones generalmente multitudinarias, normalmente había dos sesiones con más de diez personas cada una, y una o dos con menos personas.

Se crearon un par de sesiones nuevas a lo largo del día.

La energía del evento se mantuvo hasta el final, que fue a las 16hs cuando el bar cerró.

Resultados

Una demostración más de la robustez de los Open Space, y de la futilidad de tratar de prever como será el contenido.

Los lightning talks no funcionaron como me imaginaba, pero sirvieron. Muchas de las sesiones fueron habladas, sin usar computadoras, pero era lo que la gente quería. Ocurrieron, de todas formas, los intercambios mostrando ideas y herramientas directamente en la máquinas.

From 100605 AO Bs As 2010 Programando

El manejo de sesiones funcionó muy bien para el tipo de espacio en que hicimos esto.

El manejo de sponsors no fue tan transparente como pensábamos. Hay que dedicarle más tiempo.

Nos faltó proactividad para ayudar a que vengan personas de otros lugares del país. Por enfatizar el objetivo “hacer el evento lo más liviano posible”, perdimos la oportunidad de ser buenos anfitriones.

Realmente los eventos de este tipo son fáciles de organizar, pero a la pregunta, cuando es el próximo, no tenemos respuesta. Quizás sea bueno buscar ritmo (¿una vez cada 3 meses?). Y que tan no hacerlo siempre los sábados, para no dejar afuera a los que por diferentes razones no pueden el fin de semana?

Información de contacto y para sumarse a la comunidad

Sitio de la comunidad argentina: www.agiles.org/argentina
Lista de anuncios y organización de eventos: http://tech.groups.yahoo.com/group/agiles-argentina/
Lista de intercambio de experiencias hispanolatinoamericana: http://tech.groups.yahoo.com/group/foro-agiles

Y a mí, Juan Gabardini, me pueden contactar en twitter (jgabardini) o por mail, con el mismo nombre de usuario en computer.org

¡Espero recibir comentarios de los asistentes y verlos en otros eventos!

Agile Open Buenos Aires 2010 - ¡Programando!

2010-06-02T15:37:00.002-03:00

SEGB(*), junto con Ágiles Argentina, organiza este evento orientado a la difusión e intercambio de experiencias sobre metodologías ágiles. En este caso el tema es la faceta más técnica.

Los eventos Agile Open se originan en Bélgica en el 2005 pero se realizan en todo el mundo. El primero en Latinoamérica se realizó en Buenos Aires en marzo del 2009. En el país ya se han realizado 9 eventos, en 7 ciudades (Buenos Aires, Córdoba, Tandil, La Plata, Bahía Blanca, Mar del Plata y Rosario). Agile Open se organizan y realizan usando Open Space Technology.

En este evento en particular el foco será en las prácticas y herramientas que utilizan los equipos que realizan desarrollo ágil de software, por ejemplo Pair Programming, B/TDD, Integración continua, Coding Katas, Coding Dojos, y las distintas herramientas que utilizan los asistentes, como por ejemplo Ruby y Rails, Groovy y Grails, PHPUnit, PHPCodeSniffer, Project Mess Detection, jXMLCoverage, JUnit, Mockito, NoSQL.

Sumate a los más de 60 inscriptos!

Dónde: Bar del Pabellón II – Ciudad Universitaria
Cuándo: 5 de junio, 9:00hs – 16:00hs
Registrate: http://bit.ly/AOBsAsProg (también podes ver las sesiones propuestas)

(*) SEGB: Secretaría de Extensión, Graduados y Bienestar de la Facultad de Ciencias Exactas y Naturales de la Universidad de Buenos Aires.

Open Space Technology

Esta forma de organización de eventos permite realizar, con poca preparación previa, eventos de alta calidad en forma auto-organizada. Funciona para reuniones desde 5 personas hasta reuniones de varios miles de personas.

Es particularmente apto para encuentros en los que se deben resolver problemas complejos y en los que los asistentes tienen interés y pasión por tratar. En los Agile Open se utilizan como forma de difundir conocimiento e intercambiar experiencias.

El interés y la pasión se logra por un proceso de autoselección en la registración: una vez definido el Tema de la conferencia, los asistentes a los que les interesa el tema se anotarán, y al ser en un día no laboral, no dependen tanto del interés de las empresas en las que trabajan como en su deseo personal de participar. A su vez, los temas a tratar en cada sesión son propuestos y votados por los asistentes.

La dinámica durante el evento es:

Se explica el formato y sus pocas reglas
Los asistentes proponen sesiones (presentaciones, paneles, workshops, ...)
Votación de sesiones (todos los asistentes votan)
Armado de agenda (se asignan las sesiones votadas a los horarios y aulas)
Se realizan las sesiones.
Cierre

Curso introducción al testing en SADIO

2010-05-03T09:38:00.003-03:00

Hace un par de semanas realicé una reedición del curso de Introdución al Testing de Software en SADIO (ver curso previo).

Dejo disponible el material aquí.

Si usan el material, dos consideraciones:

Tiene más contenido que el que se puede incluir en dos días. Decidí dejar el material como referencia para los asistentes.
La idea de "Introducción" es relativa, asumo que no hay duda sobre la necesidad de probar, y asumo que se trata de hacer desarrollo iterativo e incremental. Espero postear más sobre esto en breve.
Han quedado algunas partes de la presentación en inglés. Espero terminar de pasar a español en el futuro.

Agile Open Buenos Aires 2010

2010-03-01T09:46:00.005-03:00

Ágiles Argentina te invitan a la próxima experiencia comunitaria: el Agile Open Buenos Aires 2010.

Tema: Calidad en el desarrollo de Software
Cuándo: 13 de marzo
Dónde: UNTREF - Sede Centro Cultural Borges - Viamonte esq. San Martín 3p.

Sobre el tema
Estamos pensando en CI, B/TDD, ATDD, pair programming, calidad por procesos, ... pero lo importante, ¿qué es la calidad para vos?
Este evento está orientado a los que están aplicado metodologías ágiles y están interesadas en contar experiencias, escuchar y aprender de otros, en todo lo que para vos esté relacionado con la calidad.

Lo hacemos bien liviano en cuanto a organización: compramos pizzas o empanadas en el momento y llevamos mate o café para los breaks. Más información.
(pero si alguna empresa quiere pagar las pizzas o traer catering para los breaks... les agradecemos, me contactan)

Inscribite

Saludos, y nos vemos!

Pueden ver como fue el evento anterior en Buenos Aires (en este blog y en agiles.org).

jXmlCoverage

2010-02-26T18:40:00.003-03:00

La cobertura ayuda a saber lo que no estamos probando. Nos ayuda poco a saber si estamos probando bien lo que estamos probando.

Hay discusión sobre la utilidad de la mediciones de cobertura. Por ejemplo ver el resumen de una discusión sobre el tema, de donde tomo la idea que lo único seguro sobre la cobertura es que nos indica que partes no hemos probado.

Por mi parte, hice un rant sobre el uso del % de cobertura como métrica, sobre todo por parte de personas que aprendieron el concepto sólo como un subproducto de TDD.

Pero si entendemos las características de la cobertura, puede ser una ayuda importante para la actividad de prueba (sea quien sea que haga esa actividad).

Hay muchos tipos de cobertura. Por ejemplo, podemos comprobar si estamos probando que se cumplan los objetivos de negocio, o los requerimientos, si hemos probado todos los riesgos identificados, todo el código o las entradas y salidas del programa.

La cobertura de código es la más común de las métricas de cobertura, quizás porque es la más fácil de medir. Incluso dentro de las cobertura de código, hay muchas posibles coberturas: de clase, de método, de linea, de instrucción, condicionales, de camino, etc.

En toda métrica de cobertura, se define el universo de los puntos posibles, y luego se mide cuantos de estos puntos están siendo cubiertos por algún caso de prueba.

Por ejemplo, en una cobertura de líneas de código, cada línea es un punto. Si esa linea es ejecutada al correr alguna prueba, se dice que ese punto está cubierto.

Se puede tomar el porcentaje de cobertura como la cantidad de puntos cubiertos sobre la cantidad total de puntos.

Pero como dijimos anteriormente, es más valioso conocer los puntos no cubiertos.

La herramienta

La herramienta que estoy por comentar, jXmlCoverage, mide cobertura basada en los XML utilizados por el Sistema bajo Prueba (en inglés, SUT).

En muchos SUT se utiliza XML, como entrada, salida o configuración. Por ejemplos, los Web Service. En estos SUT, se dispone, o se puede crear, un XSD que corresponda al contrato que daebe cumplir los XML correspondientes.

Nos interesa el grado en que nuestras pruebas ejercitan las diferentes posibilidades de valores en los XML, y sobre todo, saber que valores no estamos probando.

Para esto, debemos definir el universo que queremos medir. Lo que hacemos es, para cada elemento definido en el XSD, decidir las particiones de equivalencia que son interesantes tomar. Por ejemplo, para un entero, podrían ser los enteros positivos, el cero, los negativos y un valor fuera de rango. A esto lo llamamos subdominio. Cada subdominio es un punto sobre el que se medirá cobertura.

Pasada la etapa de definición y configuración del universo de prueba, medimos la cobertura.

Para medir la cobertura se toma el conjunto de los XML usados y se evalúan contra los subdominios, contando cuantas veces un subdominio es utilizado (cubierto) por los casos de prueba.

Como resultado, podemos obtener los subdominios que no fueron cubiertos.

Como en todas las mediciones de cobertura, se debe evitar caer en la tentación de considerar un sub-dominio cubierto como un sub-dominio bien probado.

Libertad vs estándares

2010-02-01T09:01:00.003-03:00

Como parte de la Scrum week @ Bs As, unas 15 personas nos encontramos en las oficinas de Southworks para pensar sobre los problemas y soluciones sobre el Escalamiento en Implementaciones de Scrum (Scaling Scrum). La consigna inicial era hacer una actividad guiada por Tobias, pero lamentablemente no pudo venir, y lo re-definimos como un open space.
Comento una de las sesiones (50 min) que hicimos.

Libertad vs Estándares

Pensamos que los estándar pueden un surgir como una imposición desde fuera del equipo, o como un aprendizaje compartido.
La primera elección debería ser que los estándar sean el resultado de compartir experiencias.
En los casos de imposición, la pregunta es quien impone. Eso nos llevó a hablar sobre quien es el dueño de los estándar (ownership).
En el caso del aprendizaje compartido, la pregunta nos llevó a como compartir el conocimiento.

¿Quién crea y mantienen los estándar? (ownership)

Los personas que están realizando las tareas son las mejor posicionadas para definir estándar sobre como hacer esas tareas. Pero solo lo harán si tienen motivación y liderazgo.
Grupos como las PMO y grupos de Arquitectura suelen ser los que hacen los estándar en muchas empresas. Pero tienen el problema que muchas veces fueron formados con personas que tienen experiencia, pero que luego quedan aislados del día a día de los proyectos. Aún así, sería bueno tener en cuenta toda la experiencia (libros, implementaciones) sobre PMO y grupos de Arquitectura.

Responsabilidad: algunos de los estándar requieren el uso de algún recurso compartido, o sincronización entre equipos. Por ejemplo, los repositorios de fuentes y los ambientes de integración continua. Sin un responsable, se produce una degradación que atenta contra la utilidad del estándar. Tiene que haber una clara responsabilidad. Una persona, un grupo de personas o un equipo.

Disciplina: los estándar deben cumplirse (mientras tenga sentido, ver más abajo). Si el estándar es una restricción auto-impuesta, entonces necesitamos auto-disciplina (auto en este caso es primero individual y luego grupal). Sin auto-disciplina, aparecen los mecanismos para imponer disciplina desde afuera (registros, auditorias) que nos llevan a algo inefectivo.

¿Cómo difundimos los estándar?

No profundizamos mucho en esto. Las formas de comunicación que surgieron son: Wiki y reuniones. Con respecto a las reuniones, el consenso es que debe ir uno o dos miembros de cada equipo. No necesariamente la misma persona, y debe ser la persona que sepa del tema a tratar. Por ejemplo, no tiene sentido que el SM vaya a una reunión sobre estándar de arquitectura. Esta reunión sirve tanto para definir como para comunicar. Luego cada asistente comunica los resultados en cada grupo. Los asistentes pueden ser rotativos, para evitar que surja el “rol de arquitecto”.

¿Qué significa tener un estándar?

Una sugerencia: nos pusimos de acuerdo con una forma de hacer las cosas que nos parece apropiada en muchos de los casos que analizamos. Pero la decisión final sobre aplicar o no es del equipo. Esto está muy ligado con la Disciplina que comentamos antes. Si no hay disciplina, va a haber muchas excepciones. No debería pasar que las excepciones sean comunes, ya que esto indicaría que el estándar no es bueno. Las excepciones son una oportunidad para revisar el estándar, pero no necesitamos un estándar que responda todas las preguntas. Sería demasiado complejo.

La representación del conocimiento actual de equipo extendido: es la forma en que comunicamos las decisiones de arquitectura/diseño, organización, etc. Deben evolucionar a medida que el equipo aprende.

Alineado con los objetivos de la empresa: lo que hacen los equipos debe contribuir a lograr los objetivos de la empresa (*). Mientras se desarrollan y revisan los estándar, es bueno tener esto presente, lo que nos ayuda a traducir los objetivos (alto nivel) con nuestras prácticas (bajo nivel).

En el cierre de esta sesión quedó inconclusa una discusión sobre Scrum y Auto-organización. Hasta donde entiendo: lo que hablamos en la sesión, aplica a Scrum o a cualquier Auto-organización. Implícita está la discusión: Scrum incluye toda forma de auto-organización, o auto-organización incluye toda forma de Scrum, o ninguna de estas.

(*) Mientras escribo este resumen, me encuentro tentado a agregar comentarios propios, no dichos durante la sesion (de la que fui moderador, por lo tanto traté de no participar opinando... mucho). En el caso de los objetivos de la empresa, por ejemplo, sería importante que los principios de Scrum (y/o auto-organización :D) se apliquen a todos los niveles. Por lo tanto, esos objetivos deberían ser un emergente de todos las personas de la organización.

Semana Scrum en Bs As!

2010-01-13T14:37:00.002-03:00

Tobias Mayer ya ha venido varias veces a Argentina, y dio 6 cursos de CSM. Alan Cyment es el único CST hispanoparlante, y dio muchos cursos en Argentina. En enero Tobias nos visita en la semana del 25 al 26 y aprovechamos con varios actividades:

Enero 25: Scaling Scrum (gratuito) (x Tobias)
Enero 26: Consultas CSP (gratuito) (Alan y Tobias)
Enero 27: The Spirit of Scrum - (pago *) (x Tobias)

Enero 28: Improvisation for agile teams - (pago *) (facilitado por Alan Cyment, co-facilitado por Tobias)

(*) En ambos casos, cada día cuesta 220 usd + IVA. Tomando ambos curos el costo es 330 usd + IVA - La facturación la realizará Agilar, que organiza estos eventos.

NOTA: inicialmente planificamos un CSM los días 25 y 26. Por el interés en los talleres avanzados, finalmente suspendimos ese CSM. Para los interesados en CSM, en marzo sr hará uno (Alan)

NOTA: Las actividades con Alan son en español, las actividades con Tobias son en inglés.

Charlas en Exactas - UTI

2009-12-19T11:59:00.010-03:00

Estoy participando en UTI, un equipo de administradores de IT y desarrollo web en la Facultad de Ciencias Exactas y Naturales de la UBA (Exactas, para los amigos).
El equipo de desarrollo esta conformado principalmente por estudiantes de Exactas o FADU (Facultad de Arquitectura, Diseño y Urbanismo).
Es una experiencia desafiante. Por ejemplo, en el:

Part-time: El equipo está y estará conformado por personas part-time, con horarios cambiantes en cada cuatrimestre. Nos ha pasado tener que exforzarnos para poder estar todo el equipo junto dos veces a la semana.
Experiencia: los alumnos se incorporan al equipo con relativamente poca experiencia, y se van del equipo cuando se reciben o antes. Hay poca experiencia en el equipo y alta rotación.
Visibilidad: Somos un equipo chico (4 personas part-time), con muchos usuarios y sistemas en producción. ¿Cómo lograr que nuestro trabajo sea visible para la comunidad usuaria? ¿Cómo dar valor a un porcenteje alto de los usuarios durante el año?

Decidimos hacer actividades orientadas a mejorar la visibilidad e incorporar buenas prácticas: una serie de charla mensuales.
Este año hemos tenido las siguientes charlas

Control de configuración y SVN

Sergio Romano, del Grupo Esfera, comentó los principios del control de configuracón del código, y luego lo ejemplificó con Subversion (SVN).
Gracias a esta charla mejoramos y extendimos el uso de SVN. Cambiamos la estructura de los repositorios de código de nuestros proyectos.

Panel de Frameworks web MVC

Se invitaron a 4 personas a presentar sendos frameworks:

Seam (Java) - Mariano Tugnarelli - Grupo Esfera
Seaside (Smalltalk) - Esteban Lorenzano - Smallworks
ASP.NET MVC (.NET) - Edgardo Rossetto - Lagash
Ruby on Rails (Ruby) - Gustavo Andrés Brey - IBM

El panel llegó un poco tarde para la elección. Ya habíamos tomamos la decisión de usar CakePHP basados en popularidad dentro de PHP (consideramos también Symfony).
Pero fue muy útil escuchar las discuciones que surguieron. Pueden escuchar los podscast y ver el material.

Gestión de Servicios de tecnología

Sergio Villagra y Jorge Mazzini prepararon (Sergio presentó) ideas de como manejar los servicios en general y los de IT en particular.
Le habíamos pedido una charla de ITIL, pero prefirió dar una charla general sobre el manejo de servicios y luedo comentar distintos modelos. Uno de ellos es ITIL.
Aún es muy reciente y vinieron las fiestas, como para sabe como influyó en nuestro trabajo. Lo que puedo decir que despertó interés.

Y.. ¿con qué seguimos?

Las próximas charlas serán (días a confirmar y oradores TBD):

Seguridad Web (19 de Marzo): la gran mayoría de nuestros desarrollos son web, la seguridad es un tema ineludible.
Usabilidad (Abril 23): considerando nuestro énfasis en dar valor a los distintos usuarios de nuestros servicios (profesores e investigadores, personal no docente, alumnos, escuelas, ...), creemos que mejorar la usabilidad de nuestras aplicaciones sería muy importante.
Single Sign On (Mayo): queremos que los usuarios puedan acceder a todos los servicios de IT brindados por la facultad autenticándose una sola vez. Un objetivo ambicioso.

CSM en Buenos Aires: Tobias Mayer

2009-12-15T09:48:00.004-03:00

Tobias Mayer facilitará un curso de Certified ScrumMaster en Buenos Aires, Argentina.

El curso Certified ScrumMaster Training (CSM) consiste en dos días de presentación, charlas grupales y experiencias y ejercicios interactivos diseñados para enseñar efectivamente los principios y prácticaqs de Scrum.

No hay transparencias y los momentos en que Tobias “da clases” se mantienen al mínimo. El valor de Scrum surge de hacerlo, y el curso se focaliza en la acción. Al finalizar el curso, los participantes tendrán la confianza y comprensión para comenzar la incorporación de Scrum en sus organizaciones y ayudar a los equipos de desarrollo a mejorar sus procesos. Al aprobar, cada uno de los participantes recibirá la designación oficial de “Certified ScrumMaster”, un título otorgado por la Scrum Alliance.

Cuándo: 25-26 de enero de 2010
Dónde: Perú 375, 1^er piso (Southworks)
Costo: usd 700 + IVA
Registración: http://tinyurl.com/tobiasBsAsCSM

Este evento es organizado por Agilar Argentina

Taller Tobias Mayer: The Spirit of Scrum: Road to Joy

2009-12-14T13:39:00.006-03:00

Tobias Mayer facilitará un taller de un día en Buenos Aires, Argentina. Está orientado a Scrum Masters y agile coaches.

Se explorarán los principios y valores de Scrum. Este taller no se focaliza en las prácticas (se asume que los participantes tienen familiaridad con ellas) y explora Scrum en un nivel más profundo y humano. A través de una serie de juegos, ejercicios interactivos y conversaciones facilitadas, se adquirirá una comprensión más profunda del nuevo esquema de pensamiento requerido para hacer Scrum. Esto no es sobre metodologías o procesos, es sobre divertirse

Cuándo: 28 de enero 2010
Dónde: Perú 375, 1^er piso (Southworks)
Costo: usd 220 + IVA
Registración: http://tinyurl.com/tobiasBsAsWorkshop

Este evento es organizado por Agiles Argentina y Agilar Argentina

Este evento será dado en inglés. Aunque por el tipo de evento no es imprescindible el hablar y entender perfectamente, ya que el resto de los que asistimos podremos dar una mano.

Más información

Marcar tiempos en reuniones: cuenco japonés

2009-11-28T20:18:00.004-03:00

Durante este año tuve la oportunidad de participar y facilitar en varios eventos open space (Agile Open Tour y otros).
Para el primero, Alan Cyment pidió consejo, y le recomendaron comprar una campana tibetana.
Muy buena para marcar los momentos del open space. Por ejemplo cuando se inicia, cuando se finaliza la etapa de propuestas de sesiones, al inicio de cada break y al inicio de cada tiempo de sesión.
Alan fue al barrio de Once, y consiguió una campana. Realmente funciona muy bien, lo usamos en el Agile Open Buenos Aires, y Alan se tomó el trabajo de llevarlo al Agile Open Córdoba. Por que digo que se tomó el trabajo... porque es pesada y grande!

En Tandil y La Plata nos arreglamos sin campana, pero no está bueno. Por algo fué el consejo inicial. Por eso, cuando organizábamos el evento en Bahía Blanca, se me ocurrió pedir una tapa de olla Essen. Me parece que tiene un sonido similar a la campana, pero yo no quería cargar una campana (ni una tapa) todo el camino hasta Bahía.
En eso, surgió la idea salvadora de Soledad Paredes, que nos prestó un cuenco japones, con muy buenos resultados. Es chico y transportable, y tiene muy buen sonido.
Finalmente me lo compré en www.tibet.com.ar. Me lo enviaron a domicilio. En mi caso, pedí envío por Correo Argentino y me costó $140 (35 usd) entre cuenco y envío.

Como no puede ser de otra manera, poco tiempo después lo vi en Deva's, en Agüero 1635, a metros de Santa Fe (subte D), y salía $132.
Al cuenco también lo usó Diana Larsen en el curso que tomé con ella sobre Agile Retrospectives.
En resumen, una buena compra para cualquier facilitador de reuniones con muchos asistentes, sean estas reuniones de retrospectivas, open space, u otras. Nota: tiene sentido para más de 6 personas. Para menos, no es lo mejor, aunque se puede usar la forma de tocar el cuenco frotando alrededor del borde en vez de golpearlo, lo que facilita controlar el volumen.

Río IV: Adm. Proyectos

2009-11-26T12:40:00.003-03:00

Los primeros tres días de la semana estuve, por un acuerdo entre el INTI y la Universidad de Río Cuarto, dando un curso sobre Administración de Proyectos de Software.

No conocía la ciudad, y algunas cosas me sorprendieron. Una ciudad de 160 mil habitantes, con una universidad con 22500 personas (20000 alumnos). El peso de la Univ. en la vida de la ciudad es alto!
En las fotos verán algunos edificios que me gustaron. Una ciudad con historia.

Fuimos unas 20 personas. Por supuesto los puntos altos del curso son las actividades. Verán en las fotos la de negociación, que se puede identificar porque siempre hay personas en movimiento. ¡Increíble la energía que se genera!.

El material no lo subo, está en el Campus virtual de la UNRC, pero salvo algunas correcciones, es lo mismo que pueden encontrar aquí.

091123 Rio IV

Un agradecimiento a Jorge Guazzone, y a toda la gente de de la universidad, que me trataron tan bien.

La semana que viene, me tendrán que soportar nuevamente, esta vez con un curso de Scrum.

Revistas gratuitas sobre Testing y otras yerbas

2009-11-18T10:55:00.003-03:00

Hace unas semanas estuve hablando con Rodrigo Guzman sobre la profesionalización de los testers, y surgió la necesidad de leer y aprender contínuamente.
Derivamos en que, además de los libros y foros, en las publicaciones periódicas, normalemnte todas con registración, pero gratuitas.

http://www.softwareguru.com.mx/ - No necesariamente testing ni ágil. Español.
www.testingexperience.com - No necesariamente ágil. Inglés.
Better Software - No necesariamente testing. Inglés.
SD Times - Noticias IT & desarrollo software. Inglés.
Software Test and Performance - Normalmente ágil. Inglés.

Que lo disfruten (¡y sepan manejar el exceso de información!)

Costo de multitarea personal

2009-11-17T10:14:00.004-03:00

Hace un mes, en una charla que dió Xavier Quesada Allué sobre Lean Software development y Kanban, realizó una actividad nueva para mí. La medición del costo de cambiar de tareas. Es muy sencilla de explicar, requiere pocos elementos, y tiene resultados llamativos.

Se pide a las personas que se organicen en pares. Uno tiene que medir los tiempos (cronómetro con segundos) el otro tiene que escribir en una hoja, de dos maneras distintas.
El resultado final es siempre el mismo, tres columnas, la primera con números arábigos (1-10), la segunda con letras (a-j), la tercera con números romanos (I-X)

La primera vez, deben escribir por columnas, primero los números arábigos, luego las letras, luego los romanos.
Se registra el tiempo.
Opcional: se puede indicar que, dado que ya tienen experiencia, esperaríamos tener mejores resultados.
Luego se escribe por fila (1, a, I), (2, b, II), etc.
Se registran los tiempos.

Se pide a todos que indiquen cuanto tardaron comparativamente.

En casi todos los casos, la diferencia en la segunda forma de realizar el ejercicio es mayor de 10%.
Un caso interesante fue que la segunda vez se tuvo un error. Se salteó una letra, y se detectó recién al llegar a la última fila.
En el caso de Lima, con unas 200 personas, hubo alguien que indicó haber tardado menos en la primera vez. No tuve oportunidad de averiguar con más detalle que habia pasado en ese caso.

En la discusión posterior se puede comentar sobre la técnica de Pomodoro o Pair programming/testing

Visita a Lima - COREIS Lima y más

2009-11-17T09:37:00.015-03:00

La semana pasada estuve 4 días en Lima, Perú, gracias a la invitación de los organizadores del 1er COREIS Lima.
Tratando de aprovechar mi estadía, organizamos una serie de actividades, muy interesantes todas. Ver Videos

Charla de Requerimientos y testing en System Support and Services

En la empresa que trabaja Gustavo Quiroz armamos una charla informal sobre requerimientos y las pruebas de los mismos para las personas que trabajan en equipos de desarrollo (hacen desarrollo ágil) y otras personas relacionadas en la compañía. Entiendo que hubo gente de ventas y algunos directivos.
Hicimos dos actividades: la medición del costo de switch y el origami.
En este caso, el experimento que hice fue tener una descripción narrativa del proceso de armado del origami (vs la descripción con imágenes que generalmente uso). Una persona, que había quedado sin par, trató de realizar el origami, y pudo avanzar menos que cualquiera de los otros pares. Traté de describir lo mejor posible el proceso, y me llevó bastante tiempo. Se puede argumentar que no lo hice bien, pero hice lo mejor posible. Creo que el mensaje es válido: es la peor forma (excepto quizás, no tener ninguna guía?).

Curso de Requerimientos (PUCP y Open Edge Technologies)

Nuevamente Gustavo Quiroz, en este caso como socio de Open Edge Technologies y ex-alumno de PUCP, organizó el curso.
El material puede encontrarse aquí.
El primer día (martes) arrancamos algo lento. No estuvo muy interactivo. Creo que en parte fue porque yo estaba cansado, y por otro lado, el aula era grande, y no me di cuenta de pedir a la gente que se juntara, por lo que estaban bastante dispersos. Tratamos sobre los objetivos de negocios, las estrategias para lograrlos, y el lugar de los los requerimientos dentro de esa jerarquía (Objetivos, Estrategias, Requerimientos). También comentamos que hay un continuo entre requerimientos y diseño, y por lo tanto definir que es un requerimiento y que es diseño es hasta cierto punto arbitrario.
Comentamos la representación de requerimientos con Historias de Usuario (User Stories).
El segundo día (miércoles) comentamos Casos de Uso (Use Cases) y los comparamos con las historias de usuario. Finalizamos el curso con una simulación de 90 minutos de un taller de obtención de requerimientos. Creo que esta última parte fue el punto más alto del curso.
Luego, con los comentarios, me di cuenta que todos los presentes ya conocían Casos de Uso, y podría haber obviado la explicación. Lección aprendida: validar los conocimientos, para usar mejor el tiempo.

Almuerzo sobre Ágiles 2010

Raúl Uribe, Gustavo Quiroz y yo, estuvimos comentando (miércoles) sobre alternativas para Ágiles 2010. El grupo local está buscando lugar, y no quieren fijar fecha hasta tenerlo. Parece haber varias alternativas.
Nos da la impresión que no tenemos una figura de keynote speaker Latam. Comentamos de Ricardo Semler, pero sin más información, quizás haya que hacer un año más con personas del norte. Discutimos algunas alternativas adicionales, pero sin llegar a un nombre que nos convenciera completamente a los presentes.
Comentaron la idea de hacer más incapié en la cultura local, con actividades y obsequios. Me parece buena idea (ver comentario en COREIS).
Quedan dudas sobre como lograr la comunicación y organización entre los locales y los remotos. Claramente hacer reuniones con remotos es "más lento", por problemas de coordinación y formas de comunicación menos eficientes. Pero por otro lado, si el grupo local avanza sólo, se pierde la riqueza de ideas, contactos, integración, participación y trabajo de los remotos.
Mucho para hacer en estos temas.

Charla sobre Prueba en Desarrollo Ágil en GESFOR

En la empresa en la que trabaja Raúl Uribe (GESFOR) armamos una charla informal sobre testing. GESFOR es un grupo con presencia en muchos países hispanoparlantes y USA.
Asistieron principalmente gente que trabaja en testing y QA. GESFOR tiene en Perú unas 200 personas y fueron evaluados CMMI nivel 2, apuntan a ser evaluados como CMMI nivel 3.
Este es el material, que extendí informalmente con otro contenido, ya que no tenían mucho conocimiento previo sobre Scrum, Extreme Programming y Desarrollo Ágil.
Agradezco al Raúl y a la gente de GESFOR por la invitación.

Charla sobre Prueba Exploratoria en Agile Perú

Visité a la comunidad Agile Perú, hicimos una charla en instalaciones de la Universidad de Lima.
Presenté las ideas de la Prueba exploratoria y realizamos una práctica, que fue muy interesante.
!Fue la primera vez que lo hacía y no sabía que esperar!
Estuvo muy bueno, varios de los asistentes tuvieron su primer contacto con la Prueba (exploratoria o no) y se detectaron algunos defectos. Los inicié en el camino al lado oscuro de la fuerza :D

Charla sobre Scrum en COREIS

Viernes a la mañana (9:30) luego de 4 días de evento... no el mejor momento para tener asistentes despiertos.
¡Y dónde! Teatro para 500 personas, con escenario elevado y foso para orquesta. Un entorno en el que tengo poca experiencia, por decirlo suavemente.
En ese contexto, tomé algunos riesgos, presenté este material y hice dos actividades: el costo de la multitarea, y el nudo o spaghetti o Tangled Mess.
El primero funcionó bien, salvo un caso que nunca había visto: alguien que afirmó haber hecho más rápido completando el ejercicio con multitareas.
El segundo, pedí voluntarios (tratando de ocultar el pánico que tenía para el caso en que nadie se ofreciera) y rápidamente subieron suficientes personas como para hacer dos rondas de 8, una con un líder que daba órdenes.
Fue muy instructivo:

El equipo dirigido no llegó a un resultado en el tiempo disponible
El equipo autodirigido se bloqueó en un momento. Intervine diciendo "traten de probar alternativas, experimenten". Fue suficiente.
Al finalizar y evaluar, el equipo dirigido le hechó la culpa al lider.
El equipo autodirigido la pasó notoriamente mejor. Con risas durante todo la actividad.

Resumen de mi estadía

Como siempre que visito Perú, me sorprende las ganas y el trabajo de las personas, y la cordialidad con la que tratan a los visitantes.

¡Muchas gracias!

Metodologías Ágiles en Morón

2009-11-12T11:54:00.003-03:00

Carlos Fau, docente de Ingeniería de Software de la Universidad de Morón, me invitó a comentar sobre Metodologías Ágiles (presentación).

Basé mi presentación en la que dí el año pasado en el mismo lugar.

Sólo agregué algunas actividades, como el experimento para medir el costo de switching de tareas (que conocí gracias a Xavier Quesada Allue). Muy bueno, porque es fácilmiente escalable y lleva 5 min.
Con respecto a escalable, voy a hacer un experimento en Lima, dónde presento ante más de 200 personas!

Me pareció interesante que entre los asistentes había más personas que conocian algo de las metodologías ágiles que el año pasado. Y dos personas trabajan en empresas que en mayor o menor medida usan metodologías ágiles. Una de ellas, Zoologic, tiene 4 o 5 años de XP. Creo que pocas empresas en la Argentina tienen esa historia.

Primer día en COREIS Lima 2009

2009-11-11T19:44:00.004-03:00

Llegué a Lima ayer, pero hoy fui por primera vez a COREIS, en la UNI de Lima.

Asistí a la presentación de Marco Taipe, sobre la aplicación de un enfoque sistémico para mejorar la Universided del Centro. Fue muy interesante, y me hace pensar sobre los temas no resueltos en mi cabeza sobre las mejoras de 2do o 3er orden y el enfoque ágil.
El comentó como la modelización y luego el diseño de los procesos llevó quizás un año de trabajo. Y aún queda trabajo de implementación. Por un lado, me parece razonable. Cambiar política y culturalente una organización no es un tema menor. Por otro lado, ¿se podrían haber hecho entregas incrementales?
Y sobre eso me quedé pensando, como compatibilizar:

la necesidad de entender un sistema complejo, que queremos cambiar, y en el el software es sólo una parte.
La idea de iteraciones y entrega de valor rápido.

Usando las ideas de Artful Making, ¿es posible (y necesario) usar Arftul Making en las mejoras organizacionales (reingeniería de procesos, cambios culturales)?

Luego, cuando terminó la charla, salimos hacia el teatro. Me sorprendió la cantidad de alumnos, y el entusiasmo. En el video vemos a uno de ellos, consultando con uno de los ponentes, Hernán Lopez Garay de Venezuela, que junto conmigo estuvo presenciando la charla.

Semana en Lima

2009-11-04T00:02:00.013-03:00

Entre el 10 y el 13 de Noviembre estaré en Lima. Realizaré varias actividades

I COREIS

El viernes 13 presentaré una charla en el Primer Congreso Regional de Estudiantes de Ingeniería de Sistemas e Informática. Pueden acceder al blog del evento
Mi presentación, ¿Qué es Scrum y como implementarlo? será el viernes de 9:30 a 11:30.
Ya me estoy lamentando perderme la mañana del martes, en las que estarán Grady Booch. El resto del contenido parece interesante, y hay un taller del amigo Raúl Uribe el viernes a la tarde, sobre Scrum in Games.

Curso de requerimientos

La gente de Open Edge Technologies y la Pontificia Universidad Católica de Perú y me invitaron a dictar un curso de Requerimientos en Desarrollos de Software Iterativo y Evolutivo.

Comentaremos y haremos ejercicios sobre requerimientos, sin estar restringido al Desarrollo Ágil, sin negar mi actual inclinación.
Será los días 10 y 11 por la tarde.

Visitas

Aprovecharé para hacer visitas a empresas, e intercambiar ideas y experiencias. También espero interactuar con los organizadores locales de Ágiles 2010, que se hará en Lima! (Raul Uribe, Gustavo Quiroz y Gustavo Veliz, entre otros).

Pairwise testing

2009-11-02T14:31:00.009-03:00

Cuando tenemos que probar una aplicación, el número de pruebas para hacer una prueba completa depende del número de entradas que acepta la aplicación y los valores posibles de cada entrada.
Sabemos que si intentáramos probar con todos los valores posibles, el número de pruebas se transforma en virtualmente infinita. Por eso usamos particiones de equivalencia para disminuir los valores posibles de cada entrada.

Aún así, con un número alto de entradas se produce una explosión combinatoria.
¿Cómo podemos manejarlo?
Podemos empezar probando todos los valores posibles, pero solo cambiando una variable de entrada a la vez. Esto permite que el número de casos de prueba crezca linealmente.
El siguiente paso sería probar de manera que todos los pares de valores posibles se hayan probado al menos una vez. Esta es la técnica de pairwise testing.
La técnica estricta diría que con esto ya tenemos una cobertura razonable y podremos detectar la mayoría de los errores presentes.
James Bach y Patrick Schroeder han escrito sobre limitaciones de la práctica

Hay varias herramientas, yo estuve usando jenny.

Una dificultad de jenny es que hay que hacer algunas conversiones entre los datos que usa la aplicación y los resultados de pares obtenidos.
Para facilitar un poco esto, pueden bajar el wrapper de jenny que hice.
Que hace el wrapper:

Lee un archivo de texto con los valores posibles de cada dimensión (variable de entrada de mi aplicación)
Cuenta cuantos valores hay en cada dimensión y invoca a jenny
Convierte la salida de jenny nuevamente en los valores de las dimensiones

Instrucciones de uso

Instalar Python 2.6 o posterior
Bajar jenny.exe para MS Windows o usar el jenny que viene en el zip (es solo la compilación del código fuente)
En un directorio poner jenny.exe, jennywrapper.py (en el zip) y dimensiones (ejemplo en el zip)
Editar el archivo de dimensiones. El formato es:

Nombre dimensión 1
valor 1 de la dimensión 1
valor 2 de la dimensión 1
...
valor n de la dimensión 1
(linea en blanco)
Nombre dimensión 2
valor 1 de la dimensión 2
valor 2 de la dimensión 2
...
valor n de la dimensión 2
(linea en blanco)

Ejecutar python jennywrapper.py

Indirectamente, esto está ligado a mi rant sobre la cobertura de la prueba.

Adm. Proyectos en INTI Bs As

2009-10-26T23:52:00.004-03:00

Realicé un nuevo curso en el INTI sobre Administración de Proyectos de Software.
El material (ppt): día 1, día 2, día 3

Durante el curso hicimos algunas actividades:

Planificamos una fiesta, lo que sirvió para discutir sobre los objetivos de negocio, los distintos grados de involucramiento de las personas en el proyecto, la planificación de alto nivel y bajo nivel, como manejar las alternativas de solución y como incorporarlas a la planificación.
Realizamos la WBS de un proyecto, usando la dinámica de dividir en sub-grupos y luego reportar al equipo completo
Analizamos los riesgos de un proyecto, donde comentamos algunas técnicas de brainstorming
Negociamos, donde surgió la dificultad de buscar alternativas Ganar-Ganar

Tuve la suerte de contar con alumnos del curso de Scrum, a los que les agradezco que asistieran. Me ayudaron a darme cuenta que este curso necesita más actividades, para hacerlo más entretenido y también para facilitar el aprendizaje.
Espero incorporar más actividades para la versión de este curso que daré en Rio Cuarto a mediados de Noviembre.

Intro al testing de software en Rosario

2009-09-21T23:08:00.003-03:00

El pasado viernes y sábado di un curso en Rosario, organizado por el Centro de Calidad e Innovación del Polo Tecnológico de Rosario, similar al que había dado hace unos meses en SADIO.
Con Fabián Longhitano estuvimos trabajando para armar el curso, balanceando horario, duración, costo y contenido, hasta lograr un producto que tuvo buena aceptación. Asistieron 26 personas.
¿Cuáles fueron los cambios? Lo más importante desde el punto de vista de contenido es que redujimos la duración a 10 hs, para que sea fuera de horario laboral. Esto implicó muchos cambios al contenido (originalmente el curso es de 16hs)

Decidí mantener el material (tiene cambios menores con respecto al anterior), para que pueda servir de guía sobre como ampliar los temas.
Cambié el ejercicio del Pajarraco ya que requiere al menos 90 min. Es una gran pérdida, porque este juego es muy bueno para entender el manejo de requerimientos y aceptación en ambientes ágiles, así como la dinámica de grupo y el desarrollo incrementar.
Sumé el juego de los 99 globos, que también es muy bueno para ver temas de aceptación, y también conceptos de calidad desde el punto de vista de Lean, y tiene la ventaja que puede ser realizado en 30 min (aunque no es una analogía tan buena de Scrum y XP, que tuve que explicarlos, pero no practicarlos).
Hicimos también el Origami (igual que los 99 globos, lo estuve haciendo últimamente en varios entornos). Usé principal mente para explicar el pair programing y como sirve para que los testers participen en sesiones de TDD.

Origami

Quité la mayoría de los recorridos por herramientas, solamente las nombré y mostré Fitnesse. No hice una mini sesion de TDD con jUnit, ni mostré Findbugs, Hudson, SVN/Tortoise, FIT, Selenium y Marathon como hice en el curso anterior.

Aún no tengo el resultado de las encuestas, pero creo que a la gente le resultó útil.

Veremos como seguimos!

Scrum en el INTI - Sept

2009-09-07T18:51:00.004-03:00

Hoy tuvimos el primer día de curso, similar a los anteriores. Sin embargo, algo cambié en la presentación.
Además agregué algunas actividades:

99 globos: funcionó bien. Sirvió también para descontracturar un poco a la gente.
Origami: no anduvo bien. Las instrucciones fueron muy difíciles, y no hubo éxitos (origamis armados), por lo que la conclusiones fueron menos obvias.

Agile Open Bahia Blanca - Notas de facilitador

2009-09-01T00:43:00.006-03:00

Van algunas notas sobre la facilitación el evento, luego espero postear sobre las sesiones.

Nos repartimos con Nico Paez la tarea de facilitación, sabiendo que no es lo mejor. Pero queríamos tener tiempo para participar de sesiones, incluso como responsables de sesiones.

La cantidad de inscriptos, confirmados y asistentes fue muy parecida a la de Buenos Aires. Sabiendo eso, nos preocupamos cuando vimos la sala de la biblioteca, que es bien amplia, pero con mesas de lectura grandes, sacarlas o apilarlas eras mucho trabajo, y llegamos desde la terminal con poco tiempo de margen (8:45, la registración empezaba a las 9:00 y la apertura a las 9:30).

Había un par de sala adicionales, de unas 15 personas cada una y una muy grande (aula 72), no sé de cuantas personas... 150 quizás. Con un ligero desnivel, y con sillas individuales con apoyo para escribir. ¿Adonde hacer la apertura?

Primer lección aprendida: pedir fotos de los lugares, y un plano de la relación entre las salas.

Decidimos hacerlo en el Aula 72, a mover sillas. Como siempre, las sillas con apoyo para escribir son un problema al momento de apilar. Esto, y el apuro, hizo que dejaramos demasiadas sillas. Esto dificultó la circulación de las personas, tanto para sentarse en el círculo como para luego ir a poner las propuestas.

Segunda lección aprendida: pedir que se saquen la mitad de las sillas (o casi). No es suficiente en estos casos dejarlas apiladas, ya que no se pueden apilar mucho y de todas formas ocupan lugar. Si hay que apilarlas, que sea en el extremo (era rectangular) no en los costados.

Las sesiones tardaron en aparecer, y no aparecieron con gran ritmo. Esto causo que esperabamos más antes de cortar, y nos retrasamos con la sesión inicial. Luego, en la votación, no hubo dispersión en los votos, y además algunas sesiones se unificaron. Quedaron pocas por franja horaria, que se asignaron a las salas más grandes. Habíamos dividido el Aula 72 en 3 áreas y la sala de lectura en 2, para un total de 7 tracks, pensando en que si teníamos +100 personas, pudiera haber un promedio de 15 personas por sala. En la práctica, ya en la agenda no había más de 4 actividades simultaneas. Peor aún, las dos salas chicas no estaban bien identificadas y creo que ante la duda, la gente se quedó en las salas grandes. También se dio el caso de responsables que no se quedaban en la sala, por lo que los que tenían interés iban a ver, y al no encontrar a nadie se iban a otra sesión.

Tercera lección aprendida: mantener el espacio abierto. Creo que deberíamos haber dedicado más tiempo a sostener las sesiones con pocos asistentes.

Me encontré por primera vez con el caso de una persona que estaba suficientemente interesada en el tema como para dedicarle un sábado completo, pero por otro lado haciendo acotaciones cada vez que se proponía una sesión con un estilo que parecía de crítica.

Cuarta lección aprendida: ¡me falta conocimientos! ¿cómo manejar a estas personalidades?.

Quizás deberíamos haber dividido el pizarrón en partes iguales para el marketplace y la agenda. De todas formas no se notó tanto porque no había tantas sesiones.

Para marcar los momentos del evento, yo había pensado en la tapa de una olla Essen, por experiencia personal (cuando la lavo) se que tiene un sonido importante. Pero una de las personas (Soledad Paredes, ¡gracias Soledad!) de Bahía nos salvó el día, y nos prestó un cuenco japonés, que suena muy bien, es fácil de transportar y lo pueden comprar aquí.

En cuanto a la organización, Mariela Cantarés me comentó que a pesar de los mails, la idea para los organizadores locales recién quedó clara cuando tuvimos una conference call. Creo que es algo a mantener.

En el cierre, nos focalizamos en los próximos pasos como comunidad, para no perder el ímpetu.

Surgió que hay que aprovechar la (relativa) cercanía con Tandil (vinieron Julian Arocena y Esteban Roasio) y el entusiasmo en ambos lugares, para hacer un núcleo generador de actividades. ¡Espero que se concrete!

Gracias a los organizadores locales: Victor Ferracutti, Mariela, Fernando Ariel Martinez, Jerónimo Spadaccioli, Ariel Trellini y otros que ayudaron desde Bs As como Natalia Fraga y Virginia Cuomo (que tiene un pie en cada ciudad). ¡Perdonen a los que olvidé!

En un próximo post comentaré sobre las sesiones en las que participé. Además hay material del evento en agiles.org

El % cobertura no significa nada

2009-08-26T17:40:00.007-03:00

Los que venimos del testing, que raro nos suena escuchar a programadores hablar sobre la calidad del software. ¿No es ese nuestro terreno?

La llegada del desarrollo Ágil a creado muchas mejoras en la forma de trabajo. El énfasis en la calidad ha logrado que muchos programadores incorporen la idea de testing como algo necesario en el proceso de desarrollo.

Los test unitarios, hace no mucho tiempo un lujo poco frecuente, se han ido incorporando como una buena práctica en muchos equipos. Esto, junto con otras prácticas como integración continua, pair programming e involucramiento del cliente durante toda la duración del proyecto han requerido un cambio de las actividades realizadas por los miembros del equipo (como ejemplo, ver mi visión sobre los cambios de los testers en Tester's Dilemma, para el caso de los analistas, puede verse la presentación de Cooper).

Pero los cambios también trajeron algunos nuevos problemas. En los últimos tiempos he escuchado discusiones entre personas a las que respeto mucho sobre si es posible o no llegar al 100% de cobertura. En una reciente discusión en foro-agiles, se ha propuesto un umbral de % de cobertura como una requerimiento contractual para equipos externos (outsourcing).

Por un lado... ¡música para mis oídos! Prefiero mil veces discusciones sobre cuánto debemos probar y cómo (automatizado vs exploratorio, unitario vs integración vs sistema, …), quién (testers, programadores) antes que discutir sobre si tenemos o no que probar.

Por otro lado...

¡El porcentaje de cobertura no significa nada!

Bien, ya tiré la bomba... ahora a tratar de justificarlo.

Desmenucemos un poco el problema. Cuando un programador habla de cobertura, en general se refiere a cobertura de lineas de código por pruebas unitarias automáticas. Empiezo entonces por mostrar que la cobertura, en ese sentido, puede no significar mucho. Luego vamos por los otros significados que puede tener la cobertura.

Cobertura de lineas de código por pruebas unitarias automáticas

¿Qué queremos medir? Si estamos trabajando en un equipo de desarrollo ágil, quizás estemos trabajando con TDD, en cuyo caso estrictamente no deberíamos escribir lineas de código sin que estas correspondan a un test que falle.

En este sentido, si tenemos un equipo que trabaja a conciencia, podríamos asumir que un porcentaje alto de cobertura es la consecuencia esperable de tener buenos casos de prueba y que estamos siguiendo la práctica de TDD.

Pero TDD está muy asociado a refactoriong, y el refactoring aplica tanto al código del producto como al código de la prueba. Podemos hacer refactoring tranquilos, siempre que los test sigan corriendo verdes, no?

Hagamos un experimento:

Tomo mi proyecto estrella, con buena cobertura de pruebas.
Refactor: quito todo el código innecesario en las pruebas (me refiero a todas las llamadas a assertXXX)
Corro las pruebas. Pasan (verde) y ¡¡con la misma cobertura que antes!!

¿Qué falló?

Luego de eliminar los assert mis pruebas son apenas mejores que un compilador con checkeo de tipos (tema para alguna tesis :) ).

Entre la prueba automática y el producto se mantiene una coherencia y sincronización, justamente esto es lo que nos permite decir que, a diferencia de los diseños en documentos, las pruebas automatizadas deben estar siempre actualizadas. Pero la relación entre el código del producto y las pruebas no es simétrica. Si tengo pruebas de mala calidad, el código del producto no las detectan.

¿Cómo podría medir la calidad de mis pruebas? Este es un tema muy interesante, y una razón por la que deberías tener testers en el equipo :D. Como ejemplo, algo que se puede hacer es mutation testing: modificar el producto (aka inyectar errores) para ver si las pruebas detectan los errores inyectados.

Otras coberturas por pruebas unitarias automáticas

En herramientas de medición de cobertura se pueden medir distintos tipos de cobertura. Por ejemplo en Java (con EMMA) se puede medir cobertura por paquete, por clase o por línea. También se podría medir cobertura por función o por expresión. Todas estas, con la idea que cobertura significa que en algún momento se haya ejecutado esa parte del código.

Sin intentar hacer un tratado sobre coberturas, nombro otras:

Flujo de datos: el comportamiento puede depender de los datos. En el ejemplo, si tengo una sola prueba assertEquals(2,dividir(4,2)); tengo 100% cobertura pero no estoy probando el caso relevante dividir(x,0)

Código a probar: int dividir(int a, int b) { return a/b; }

Camino: si consideramos cada bifurcación del código como un nodo, cada camino en el grafo resultante puede ser significativo desde el punto de vista de prueba. El problema es que el número de caminos crece exponencialmente.
Cobertura de requerimientos: damos vuelta la métrica, dado que no podemos probar cobertura de código que no existe (tendríamos cobertura mayor que 100%), medimos la cobertura de los requerimientos para ver cuales está implementados. Algo parecido pasa con las API cuando son impuestas (podemos medir si cumplimos con el contratos de las APIs).

¿Cuál es la cobertura correcta? Es como preguntar cuanto dura un día. Puede ser simple (24hs) o complicado.

Nota: no puedo dejar de nombrar la cobertura de XML, que puede ser pensada como un tipo de cobertura de Flujo de datos o de requerimientos.

Coberturas por pruebas de integración

Las pruebas unitarias parten del diseño. Es una forma de diseño ejecutable, gracias a eso nos aseguramos que la aplicación cumpla con el diseño.

¿Pero es correcto el diseño? Por ejemplo, cuando extendemos o nos integramos con productos de terceros, tenemos que validar que nuestra comprensión de esos producto sea correcta y, desde el punto de vista de regresión, que ese comportamiento no haya cambiado en el tiempo.

Estuve en proyectos en los que construíamos addin a MS Outlook, o extensiones a Liferay, y la importancia de estas pruebas era tan grande (por la evaluación de riesgo) que se ponía en dudas la conveniencia de hacer pruebas unitarias. En estos casos, en vez de la pirámide tradicional de automatización de la prueba (mucha unitaria, algo de integración, poco de sistema desde interfase usuaria), se tenía niveles similares de prueba unitaria y de integración.

Si quisieramos medir la cobertura de las pruebas de integración, tendríamos que medir incluyendo al producto plataforma (Outlook o Liferay)

Otras pruebas

Y no todo termina ahí. ¿Hemos probado seguridad, robustez, usabilidad, etc?

¿Son todas las pruebas basadas en ejemplos? ¿Cómo medimos la calidad de la prueba cuando probamos con técnicas que usan oráculos no humanos, invariantes y fuzzing?

¿Hacemos el producto correcto?

Comentamos que en ocaciones necesitamos saber si el diseño es correcto. Pero más importante, ¿hacemos el producto correcto?

Ya sea que hagamos pruebas exploratorias o que tengamos las pruebas de aceptación automatizadas, ¿cómo medimos que estas pruebas sean buenas?

Conclusión

Repitiendo lo que dije al principio, prefiero mil veces discusiones sobre cuánto debemos probar antes que si tenemos o no que probar.

Pero es una discusión que tenemos que tener en el equipo. Y como siempre, la respuesta no es única.

Charlas en Exactas: Panel de framework MVC para desarrollo Web

2009-08-23T11:10:00.002-03:00

El viernes próximo tendrá lugar un panel de Frameworks Model-View-Controler (MVC) organizado por la Secretaría de Extensión, Graduados y Bienestar, que contará con la participación de los especialistas Mariano Tugnarelli (Seam), Esteban Lorenzano (Seaside), Edgardo Rossetto (ASP.NET MVC) y Gustavo Andrés Brey (Ruby on Rails). Esta es la 2da charla abierta (ver la anterior).

El panel consistirá en una primera parte en la que cada panelista presentará brevemente el framework, seguida de un espacio para preguntas a los panelista.

VIERNES 28 de AGOSTO
de 15.00 a 17.00 hs
AULA E24
PABELLÓN I de CIUDAD UNIVERSITARIA
Más info en http://www.exactas.uba.ar/uti

La descripción original del patrón Model-View-Controller fue hecha para Smalltalk en 1980. Durante un tiempo las aplicaciones web no lo utilizaron pero actualmente la existencia de frameworks potentes, que permiten completar aplicaciones muy rápidamente, hacen que la tendencia es que la mayoría de los desarrollos web utilicen alguno de los frameworks. En el panel se discutirán las ventajas y desventajas comparativas de los frameworks Seam (Java), Seaside (Smalltalk), ASP.NET MVC (.NET) y Ruby on
Rails (Ruby).

Resultados de la charla en Rafaela

2009-08-22T19:24:00.007-03:00

El miércoles estuve en Rafaela, Prov. Santa Fé, dando una charla sobre Desarrollo de Software Ágil en UCSE Rafaela.
Rafaela tiene una carrera de ingeniería de software en la UCSE, y una tecnicatura en programación de la UTN, en ambos casos son recientes.
Se está acelerando la cantidad de profesionalesans serifsans serifs del software y las empresas están creciendo en forma acorde.
Aproveché mi visita para visitar algunas de las empresas de software. Rafaela no tiene una gran empresa cliente que defina el mercado, y el mercado local no es muy grande, por lo que las empresas crecen hacia mercados remotos, frecuentemente internacionales.
En ese contexto (más profesionales, empresas creciendo, mercado internacional) varias de las empresas están interesadas en incorporar formas de mantenerse organizadas (crisis de crecimiento) y lograr algún 'sello de calidad'. Siendo empresas chicas, la elección parecería ser Desarrollo ágil + ISO 9001.
En mi presentación traté de indicar las razones por las que se elegiría utilizar desarrollo ágil (y por ende, cuando no), seguido con una introducción a Scrum y una aún más breve para eXtreme Programming, indicando que implementar Scrum sin XP es difícil en el largo plazo.
Hubo 100 personas, lo que superó nuestras expectativas. Muy buena la organización, va mi agradecimiento a Darío Karchesky, las autoridades de UCSE por invitarme, y a todas las personas de UCSE que ayudaron en la organización.

Para los asistentes, si quieren sumarse a la comunidad y ver próximos eventos (además de este blog ;) :

Foro ágiles: discusión latinoamericana de desarrollo ágil.
Ágiles Argentina: organización y eventos argentinos
Ágiles: portal en español

Configuración de Software y SVN

2009-08-14T20:07:00.004-03:00

Hoy se realizó la primera charla organizada por el equipo en el que estoy trabajando en la Facultad de Ciencias Exactas y Naturales de la UBA.

Por ser la primera charla, y habiéndose retrasado por el tema de la gripe, sinceramente no esperábamos mucha asistencia. Una grata sorpresa fue que hubo unas 20-25 personas (nosotros somos 6).

En la foto se puede ver a Diego Quesada Allué presentando al disertante, Sergio Romano, del Grupo Esfera y ex-alumno de la casa.

En nuestro blog publicaremos la presentación en breve, y en una o dos semanas el video de la charla.

La próxima charla será el 28 de Agosto, un panel que discutirá sobre diferentes frameworks MVC.
¡Nos vemos!

Desarrollo de Software Ágil en Rafaela

2009-08-14T19:37:00.006-03:00

El miércoles 19 estaré en Rafaela, en Universidad Católica de Santiago del Estero, presentando algunas ideas sobre el desarrollo de software:

El Desarrollo del software está en el medio de un proceso de cambio. Luego de estar fuertemente influenciada por estándares surgidos de proyectos enormes del Departamento de Defensa de EEUU (CMMi), desde hace una década se está imponiendo una forma de trabajo, el Desarrollo Ágil de Software, que permiten a las empresas crear productos innovadores de mejor calidad y menor costo. Otra característica importante es que los equipos que trabajan de esta manera están más motivados y contentos con su trabajo. Presentaremos los principios algunas de las metodologías ágiles, Scrum y XP, y veremos como estas metodologías pueden ser implementadas en forma incremental, y conjuntamente con normas ISO 9001.

Más información

Resultados de la charla

Registración a Ágiles 2009!

2009-08-12T23:15:00.005-03:00

Ya puedes registrate a Ágiles 2009 is open! (evento y cursos)

Ágiles 2009 se realizará los días 6-9 de Octubre en Florianópolis, Brasil.

Ágiles 2009 busca ser el punto de encuentro de los profesionales de TI de latinoamérica interesados en compartir experiencias, discutir y aprender sobre el Desarrollo Ágil de Software.

Entre los invitados internacionales que participarán en Ágiles 2009 están Matt Gelbwaks, Naresh Jain, Dave Nicolette, Joshua Keriewsky y los oradores principales Brian Marick y Diana Larsen.

Lo conferencia consistirá en presentaciones, sesiones interacticas y talleres. Esperamos unas 800 personas de todas partes del mundo.

Antes del evento habrá cursos de CSM, CSPO, TDD y Retrospectivas.

Puedes registrarte en http://www.agiles2009.org/es/registracion.php

Para más información del evento, programa o sede consulta en www.agiles2009.org

Organizadores de Ágiles 2009
Ágiles 2009 es posible gracias a la colaboración de OnCast Technologies y al apoyo de nuestros sponsors:

[Gold Sponsor]
Globo.com | ThoughtWorks

Scrum en INTI

2009-07-14T12:20:00.001-03:00

Recientemente facilitamos (junto con Pablo "Bauna" Nussembaum), un curso de dos días sobre Scrum, en el INTI. Pueden ver la presentación.

Algunas de las actividades que hicimos:

La ronda o el nudo (de autoorganización, ver la descripción en inglés)
Hacer un folleto del spa de perros (simulación de tres iteraciones con una sola presentación al usaurio, copiado de Jeff Sutherland)
Estimación de paises (estimación, tomado de Mike Cohn, similar a Doggy Planning)
Pajarraco (simulación de desarrollo iterativo e incremental, con 3 iteraciones con revisión del producto por el usuario, y nuevos requerimientos al inicio de cada iteración, tomado de Alan Cyment)
Retrospectiva (sobre el pajarraco, detectar problemas y sugerir mejoras).

Como siempre, la actividad que se lleva todos los elogios es el Pajarraco, con los grupos tomándose fotos con el producto. Un rasgo muy importante, creo que demuestra que hacer el producto fue divertido o que están orgullosos (o las dos cosas) y tienen ganas de compartirlo con otros. Ese es el sentimiento que buscamos que tengan todos los equipos.

Usamos también la idea de postear las preguntas. Este punto no funcionó muy bien. Creo que lo que faltó es un momento específico para revisarlas y contestarlas.

Por otro lado, hubo muchas preguntas, que fueron complentando el contendido del curso, sin necesariamente seguir el orden de la presentación. Me llevo la fuerte idea de reducir presentación y hacer mucho más foco en la dinámica y actividades del curso.

Artful Making

2009-07-13T00:11:00.004-03:00

Al pensar usamos nuestro lenguaje. Así el lenguaje limita lo que pensamos o al menos podemos decir que es mucho más dificil manejar conceptos o abstraciones sobre los que no tenemos palabras apropiadas. Cada tanto tenemos la suerte de agregar nuevas palabras a nuestro lenguaje, que nos permiten expresar más sencillamente algo que teníamos dando vuelta en la cabeza.
Esta vez me pasó con el libro “Artful Making”, de Rob Austin y Lee Davin (pueden ver gratuitamente el prólogo y capítulo 1).
Este libro, entre otras cosas, me dió las palabras-conceptos Artful Making e Industrial Making. El nuevo modelo mental es poderoso (“Mindbending” dice Kent Beck). Me hicieron replantear parte de mis ideas CMMI y Agile con resultado parcialmente reflejado en parte 1, parte 2.
Artful making es el proceso de creación de valor en el cual la innovación es un factor importante. Pero no siempre se puede o no siempre es bueno. Los ejemplos dados son la preparación de las obres teatrales, el desarrollo de software y la planificación estratégica. Pero es probable que estas ideas sean aplicables a la mayoría de los trabajadores del conocimiento, simpre que se den condiciones necesarias. Y la tendencia es que los trabajos son cada vez más asimibles a trabajo del conocimiento.
Industrial making es el proceso de creación en el que se replica lo hecho, mientras que en artful making se reconcibe, nunca se hace lomismo. Es la forma en que se trabaja en las fábricas.
¿Cuáles son las características para poder hacer artful making?

Necesidad de innovación
Iteraciones cortas
Repeticiones confiable

Para que las iteraciones sean cortas, deben ser baratas. El costo de iteración tiene dos componentes:

Exploración: probar caminos y soluciones alternativas. En una automotríz podría ser hacer un nuevo modelo a escala o un prototipo de un nuevo modelo.
Reconfiguración: cambiar el producto/proceso para mejorar el producto u obtener otro producto. Por ejemplo, en una automotriz, los cambios necesarios en las herramientas, layout, etc. necesarios para producir otro modelo.

También es interesante descripción y progresión descripta (con justificación económica) entre la forma de trabajo del artesano medieval, del ingeniero de procesos industriales (“white collar”) seguidor del scientific management, y por último, el trabajador de conocimiento, con sus puntos de contacto con el trabajo de los artistas. Tendría que revisar el post que hicimos hace unos meses sobre Ingeniería vs Artesanía.
Hay que tener en cuenta que el público objetivo del libro son los gerentes, de ahí el subtítulo “What managers need to know about how artists work”. Para ver la realción de la innovación con las personas que hacen el trabajo, es más apropiado el libro Free Play.
Hay algunos conceptos del libro que resuenan en la forma en que Tobias Mayer y Alan Cyment realizan las capacitaciones CSM. Y no es extraño, ya que ambos tienen background teatral. Y durante la organización de Ágiles 2008, Tobias se puso en contacto con Lee Davin, para que viniera. Lee estaba de acuerdo, pero lamentablemente no teníamos dinero confirmado en el momento en que lo hablamos. Volviendo a las coincidencias, la idea de trabajar al límite, sentirse ligeramente incómodo. No tan incómodo como para trabajar stressado y tan cómodo como para caer en la complacencia y no mejorar.
Otro punto que me parece muy bueno es el control liberando (Control by release), un concepto complejo de entender y transmitir. Creo que está bien implementado en Scrum: definir claramente los objetivos (tema e items en el backlog), imponer ciertos límites (iteraciones de duración fija con entregables definidos y calidad de producción) y dejar libre al equipo.

Muy recomendable, ¡sobre todo para lo gerentes!

Lo pude leer gracias a Diego Fontdevila que me lo presó, pero si lo querés comprar...

alt.net Argentina 09

2009-07-10T08:18:00.003-03:00

Carlos Peix y Martín Salias catalizaron el inicio de Alt.NET en Argentina. Esta es una movida interesante, y en alguna medida, paralela a los Agile Open.

Las reuniones de Alt.NET son en formato Open Space, igual que los Agile Open, pero la temática es distinta. Son reuniones de gente que desarrolla con la tecnología .NET, pero sin ser "guiada" por Microsoft.

Microsoft Argentina ofreció las oficianas, pero el resto fue todo comunidad. Carlos y Martín están muy relacionadas con el Microsoft User Group (MUG).

No pude asistir, pero me comentaron que salió muy bueno. Algo genial de este evento es que lograron hacerlo más JIT que los Agile Open: pidieron pizzas, tomando en cuanta cuantos asistentes había. Ese tema aún no lo tenemos resuelto en los AO, pero no se si se puede, ya que con eventos más grandes es más complidado.

Pueden ver algunas fotos del evento en el blog de Leo Micheloni, y más aquí.

Y si quieren formar parte de la comunidad, pueden sumarse en http://groups.google.com/group/altnet-argentina

Intro al testing en SADIO

2009-07-08T23:39:00.004-03:00

A mediados del mes pasado di un curso sobre Introducción al Testing en SADIO.

Como siempre me pasa la primera vez que organizo cursos con alguna entidad, y a pesar de todas las experiencias previas (SADIO nos ayudó mucho en la organización de Ágiles 2008), antes del curso tenía cierta ansiedad por ver la convocatoria, que tipo de gente participa, cómo es la organización y logística del evento, etc.

Por suerte, la organización estuvo muy bien, y la convocatoria fue muy buena. Encontré a algunos comocidos, pero a muchos desconocidos, lo que es bueno! Todos muy entusiastas y comprometidos. Gente de Gral. Pico, de Córdoba, de La Plata, y por supuesto de la Cdad. de Buenos Aires. Muchos testers, algunos desarrolladores. Una pena que la gente de Córdoba no conocía al Lab de Calidad del INTI, y los cursos que dan sobre testing. Una muestra (y van ...) que los testers no tenemos una comunidad. Los pocos cursos que se dan los conocen pocas personas.

En lineas generales, el experimento salió bien. Pueden ver las transparencias y el código.

En cuanto a contenido, creo que debería haber recortado cantidad, en favor de más ejercicios. Dos días con mucha presentación se vuelve aburrido. Aún así, tuve que saltear contenido.

El códido está con NetBeans, junit, emma, y Marathon. Es el caso ultra simple de los triángulos, que usamos para hacer un brevísimo TDD (junit), mostrar cobertura (emma) y realizar pruebas automatizadas desde GUI (Marathon).

Hicimos el juego del Pajarraco, y como siempre, sirvió a su cometido: ser una referencia para todo lo que vimos después.

No me quedé conforme con la presentación de los temas de cobertura. Quedó como una presentación teórica, dada a las apuradas. No logré lo que buscaba: una herramienta y demostración sobre el valor adicional que podemos dar los testers.

Tampoco dió el tiempo para hacer prácticas sobre pruebas exploratorias, algo que me hubiera gustado.

Veremos si cambio un poco para Rosario (Agosto). Y después vienen los cursos de Automatización, en FIUBA (si logro organizarlos) y en Rosario, también con el Lab de Calidad del Polo.

Ágiles 2009 - Llamada a Participación

2009-07-03T20:02:00.003-03:00

Qué opinas de formar parte del equipo de expositores que reune nombres como Brian Marick, Diana Larsen, Matt Gelbwaks, Naresh Jain, Dave Nicolette, Joshua Kerievsky, Alan Cyment, Alexandre Magno, entre otros? El próximo lunes 6 de julio será la última oportunidad para presentar tu propuesta de charla en Ágiles 2009!

Ágiles 2009, a realizarse en Florianópolis, Brasil, es un evento sin fines de lucro, organizado por profesionales entusiastas del tema, unidos por el objetivo de crear un espacio amplio de discusión sobre las metodologías ágiles y su adopción en América Latina. (más información)

Como expositor, tendrás acceso libre a la conferencia y otras ventajas que los organizadores están preparando para ti! Puedes proponer una presentación, un tutorial, un reporte de experiencias o un workshop. Accede a http://www.agiles2009.org/es/submissions.php para ver la información que debes proporcionar para presentar tus propuestas.

¡Esperamos contar contigo en Ágiles 2009!

Organizadores de Ágiles 2009

Agiles 2009 es organizado por OnCast y es posible gracias a nuestros sponsors

[Silver Sponsor]

Baufest | Scrum Alliance | Agilar | AdaptWorks | Industrial Logic

[Institutional Sponsor]

SADIO | Agile Alliance

Panel CMMI vs Ágil (2/2)

2009-06-27T23:56:00.003-03:00

Voy a comentar algunas de las preguntas que nos hicieron al panel (parte 1: resumen de las presentaciones del panel) y algunos pensamientos y situaciones que tuve luego del evento.

asistente: ¿Puede aplicarse ágil en grupos grandes?
yo: ¿qué es grande para vos?
asistente: El sistema de defenza de China
(no conteste, alguien más lo hizo)
Ugh? ¿acaso estaría esa persona en ese equipo? ¿si no, que interés práctico puede tener una pregunta así? Mi hipótesis es que hay una suposición subyacente: lo que es bueno a un proyecto enorme, debe ser bueno para un proyecto chico. Según esta hipótesis, los problemas de escalamiento sólo se darían al agrandar, no al achicar.

asistente (otro):¿cómo logro con ágil que todos los equipos trabajen en forma similar?
yo: ¿Por qué querés que trabajen en forma similar?
asistente: la compañía tiene que tener una forma definida de hacer las cosas
yo: ¿Qué valor de negocio tiene eso? (y comenté el caso de Toyota, en el que cada planta que hace el mismo vehículo tiene layout diferentes, y cada uno es óptimo en cuanto a condiciones locales)
asistente: pero los trabajos que hacen deben tener algo en común ...
(perdí la atención del asistente, y el hilo del diálogo fue hacia otro lado)

¿Por qué la unificación de las formas de trabajo es visto cómo una verdad indiscutible?

La semana pasada estábamos en una clase de la facultad, en la simulación de una retrospectiva. El problema a resolver era: requierimientos muy cambiantes.
alumno: una mejora sería "estandarizar el proceso de elicitación de requerimientos"
yo: ¿Por qué te parece que esto resolvería el problema?
alumno: está muy estudiado como deben obtenerse los requerimientos. Deberíamos incorporar esto a los procesos.
yo: ¿Pero eso ya se hace en la compañia?

alumno: ...

yo: Digo, porque si decimos que queremos estandarizarlos es porque en algún área o grupo ya se están aplicando y queremos llevarlo a otros, no?

alumno: ...
yo: Si no se usaron nunca, quizás debiérmos probarlos en algún grupo, antes de estandarizarlos
alumno: (cara de no estoy de acuerdo con lo que decis pero sos el docente)
Ya no es sólo la unificación dentro de una compañia, sino la unificación a nivel industria. Implísita está la idea de que debe haber sólo una forma de manejar los requerimientos.

Paréntesis

Recientemente me prestaron Artful Making, espero postear más extensamente sobre el libro, pero para este post basta con comentar que los autores plantean que hay dos formas de hacer las cosas: Artful Making, muy ligada a la innovación, con costo de iteración y de error bajo (ejemplos: teatro, software, estrategias corporativas); e Industrial Making, que es lo que ha tenido tanto éxito (revolución industrial), que nos parece como natural e innegable (producción en serie, economía de escala).

¿Qué encuentro en común en las sitiaciones descriptas arriba?

La idea de "la mejor solución". Esta es una visión Taylorista, en la que alguien pude analizar el problema y encontrar la mejor forma de hacerlo. Por lo tanto, los operarios deben seguir al pié de la letra esa solución, ya que es la mejor.

Esto tiene dos problemas: por un lado, si estamos en una situación que permitiría usar Artful Making, lo estamos perdiendo. Por otro lado, si estamos en una situación de Industrial Making, nos quedamos con métodos de principios del siglo XX. Todo lo aprendido a partir de los '60 por los japoneses, y a partir de los '80 por el resto del mundo, no lo aplicamos: Lean Production.

¿Es esto un problema?

¿Es un problema que algunas personas mantengan la idea de "la mejor solución"? Vuelvo sobre mi post CMMI y Agile, y le doy otra vuelta de tuerca, porque voy a tocar el proceso de evaluación.

En una charla con Mary Poppendieck, ella comentó los efectos nefastos y no deseados de las certificaciones: se incian tomando las buenas prácticas, se estandarizan, se instruye a los evaluadores y se los controla para evitar desvios y subjetividades, esto pone restrincciones externas a las empresas, que para no perder su status (certificación) establecen áreas internas que replican la idea de evaluadores que controlan el cumplimiento.

Todo esto genera una gran inercia. Si una empresa quiere innovar tiene que convencer a sus auditores, que tendrán que convencer a los evaluadores, que tendrán que convencer al organismo originador del estandar.

En el panel, yo noté exactamente esa dinámica. El movimiento ágil se desarrolló casi totalmente fuera del alcance del SEI y las empresas CMMI. Luego que tomó fuerza, se hizo notorio que es algo bueno, por lo que muchas empresas emprezaron a usarlo y el SEI se puso a trabajar (luego que las ideas llegaron al mainstream) en mostrar que CMMI no es incompatible con Ágil. Y ahora está tratando de convencer a sus evaluadores de esto (y le cuesta).

Replanteando la pregunta, ¿será que por construcción el CMMI refleja el mainstream, lo común, y no fomenta la innovación?

¿Puede incorporar el estado actual de las prácticas ágiles, pero inmediatamente lo congelará como el nuevo estándar, sólo para ser superado por las empresas que no son CMMI?

Panel CMMI vs Ágil (1/2)

2009-06-27T23:45:00.005-03:00

Hace un mes tuve la suerte de participar en un panel organizado por Liveware sobre CMMI y Desarrollo Ágil.

Asistió mucha gente, creo que con alto porcentaje de gente de áreas de mejora de procesos, y por lo tanta bastate CMMI.

Antes del panel huvo una presentación de Jorge Boria sobre la evolución de la Ingeniería del Software, para poner en contexto la aparición de CMM/I y de Agile Software Development, explicando brevemente Scrum y XP, y relacionándolos con ideas previas. Es muy dificil hacer todo esto en 2 hs, exige un nivel de síntesis muy grande. Creo que Boria logró hacerlo bien. Algunos puntos de Scrum y XP yo los habría comentado distintos, lo que me pasa con cualquier discertante.

Luego fue el panel, muy bien moderado por Alejandra Goldin (Liveware). Sobre el panel voy a comentar mi resumen, y en otro post algunas preguntas que se hicieron e ideas que me surgieron, todo filtrado por mi subjetividad y memoria. Espero que los otros panelistas y asistentes me corrijan.

Esteban Zuttion (Liveware): planteo el enfoque que tanto el modelo CMMI como las ideas ágiles pueden ser útiles en la mejora, y que ser evaluados con cierto nivel de CMMI puede tener beneficios de negocio. Que se hace es una decisión que debe analizarse con respecto a la estrategia de la compañía y las necesidades del negocio, como algo absoluto.

Martín Salías (Southworks): comentó que las prácticas ágiles soportan los objetivos de CMMI, incluso las métricas. Se generan un montón de datos como subproducto de las prácticas ágiles (nro de build rotos, % cobertura, etc). Comentó que en algunos casos no hay métrias pero las prácticas pueden equipararse a métricas (me hubiera gustado que se explayara en esto).

Santiago Ceria (Hexacta): Si uno aplica la típica combinación ágil de Scrum + algunas prácticas de XP logra un buen cubrimiento de los Niveles 2 y 3 de CMMI, en particular Scrum con prácticas de Nivel 2 y XP con las de Nivel 3. Digamos por ejemplo que la cobertura es de un 50%. El tema es que al implementar el resto de las prácticas que pide CMMI, se deben hacer cosas que presentan incompatibilidades con los principios ágiles expresados en el Manifesto. En particular mencioné la cantidad de documentación que hay que generar, el concepto de Quality Assurance que es incompatible con el principio de “trust” y la presencia por todos lados en CMMI de cosas que llevan a una implementación de una organización jerárquica (“senior management”, “Project manager”, “Project leader”, “team leader”) que es incompatible con las estructuras horizontales auto organizadas propuestas por los métodos ágiles.

Juan Gabardini (Agilar): hablé sobre lo extraño que es ver que, partiendo de premisas parecidas (mejoras continua, Deming), se llegan a culturas a primera vista tan distintas. Me pregunto si esas diferencias culturales son compatibles en una misma organización, si una de las culturas se impondrá o si surgirá una nueva cultura que sea la síntesis de ambas. Más detalle de mis 10 min aquí.

Mariela Rodriguez (Globant): después de mi vuelo estratosférico, Mariela comentó la realidad de Globant, en la que se realizan proyectos de desarrollo ágil aún con contratos de tiempo y costo cerrado. Hay reuniones periódicas, se muestra producto y se puede agregar nueva funcionalidad ... siempre que se saque otra. Algunos puntos muy interesantes: no lo pueden hacer con todos los clientes, algunos no quieren esto de reunirse cada mes. Y por otro lado, los equipos que trabajaron agilmente no quieren trabajar de otra forma.

Viviana Rubinstein (Liveware): tomó el guante de Santiago y diferenció claramente entre la evaluación y el modelo CMMI. En su punto de vista, el modelo no tiene conflictos con el desarrollo Ágil, pero la evaluación si. Me encantó una frase: "Cuando algún evaluado empieza a quejarse sobre lo que tiene que hacer (para que la evaluación de cierto nivel) le digo: yo estoy acá porque vos me llamaste"

También refutó a Santiago sobre la obligatoriedad de algunas actividades. No puedo opinar sobre este cruce, no tengo conocimiento. Resumen: si querés ser evaluado, y si, te va a salis más caro que si no lo haces.

Finalmente Alejandra resumió nuestras ideas y rescató la cercanía de las mismas.

Fue muy interesante participar, y me dejó pensando, con los resultados que pueden verse en este post.

Juegos en educación

2009-06-24T01:09:00.004-03:00

En la enseñanza de el desarrollo ágil solemos usar actividades lúdicas (también llamados juegos :D).
En los cursos oficiales de Certified Scrum Master suelen usarse. En los cursos de Scrum que yo doy (no oficiales) uso juegos. También los aplicamos en las clases de la materia Administración de Proyectos Informáticos II - FI UBA. El juego del Pajarraco (una versión del XPGame hecha por Alan Cyment, pueden ver algunas fotos aquí) lo uso en toda ocasión en que necesito explicar desarrollo iterativo e incremental.
El IEEE tiene un programa (TISP) orientado a acercar a los estudiantes secundarios a las ingenierías a través de juegos.

Hay muchos más, y paso una lista de recursos para los que les interese.

Para los que quieran recursos,
http://blog.tastycupcakes.com/ (el caso de Mr Happy Face)
http://wilderdom.com/games/InitiativeGames.html
http://www.dosideas.com/wiki/Juegos_Agiles
http://www.tryengineering.org/

Agile Open La Plata

2009-06-23T00:06:00.006-03:00

El sábado nos reunimos en la Universidad Católica de La Plata unas 70 personas para intercambiar experiencias sobre el desarrollo ágil de software.

Como en todos los casos en los que participé (Buenos Aires, Córdoba, Tandil), la experiencia fue muy buena. Las gente es entusiasta, y se crea un clima de aprendizaje muy bueno.

Verán en las fotos que no logramos hacer que la sesión inicial y el cierre fueran con un círculo plano. Sin embargo esto no afectó el funcionamiento. Además, hacer las sesiones en un museo, entre pinturas y esculturas, le dió un toque interesante. Podríamos haber usado el patio, pero estuvo lloviznando de a ratos.

Martín Alaimo facilitó la apertura y las dinámicas de las sesiones, mientras que Diego Fondevila facilitó el cierre.

Apertura: En la apertura, tardamos en votar y en armar la agenda. Creo que fue por no tener suficiente lugar para que varias personas estén paradas frente al mercado o a la agenda. La gente para votar se toma un par de minutos, leyendo las propuestas. Esto es algo parecido a lo que pasó en Córdoba. Pero no encontramos mucha alternativa.

Las sesiones salieron rápidamente, sin miedo. Pero también se cortaron rápido. No fue necesario descartar sesiones, cuando se unieron las similares, había suficientes slot para todas.

Sesiones: a diferencia de otros AO, no estuve en ninguna sesión con poca gente (menos de cuatro). Las sesiones fueron muy buenas. Tuvimos el juego del pajarraco, que facilitó Nico Paez, pero pasé a tomar fotos.

En otra sesión se dió un caso interesante: en una sesión se dieron cuenta que todos querían escuchar una intro a metodologías ágiles, pero no había nadie presente para comentar el tema, ¿cómo lo resolvieron? se fueron a la sala de al lado y pidieron ayuda. Nico tomó la posta.

En un par de sesiones me levanté luego de un rato. Un poco porque habían perdido empuje, y otro poco para fomentar que la gente se mueva un poco. No vi mucho movimiento, me parece que la gente en general se quedó en las sesiones.

Las sesiones a las que fui: Intro Lean, Equipos Chicos, Testing, Retrospectivas, Arquitectura.

Cierre: como en los cierres de Cba y Tandil, el radar/termómetro del final es bueno por paliza. Esto no es tan raro, ya que se quedan hasta el final los que están más enganchados, pero aún así, se quedaron muchos. Hubo muchos comentarios positivos, y se habló un poco de como seguir. Sin embargo, los próximos pasos fueron más hablados en los pasillos, y en los mails posteriores.

Termino agradeciendo a Liliana Rathmann, Horacio Sampaoli y Martín Alaimo, que llevaron en sus hombros gran parte del peso organizativo (el costo de ser local!)

090620 AO La Plata

Fomentando la ingeniería (TISP)

2009-06-14T18:48:00.010-03:00

El viernes particié en una actividad TISP en el Instituto 13 de Julio.
TISP (Teacher in Service Program) es un programa del IEEE para fomentar las carreras de ingeniería. La idea es que los alumnos de secundario no eligen ingeniería porque es visto como algo aburrido y poco interesante. Se trabaja entonces con los docentes, difundiendo actividades que sirvan a los objetivos educativos del secundario pero que además sean divertidos.

La Rama Estudiantil de IEEE AR - URN Regional Bs As, ya había organizado una actividad TISP, y de allí surgió las ganas de los docentes del Instituto para hacer las actividades con los alumnos.

Yo me sumé, y fue una muy linda experiencia. Suelo hacer capacitaciones que incluyan juegos (Lean, Scrum), pero nunca los había hecho con chicos de 4to año. Todos teníamos dudas, ¿cómo andaría? ¿Se entusiasmarían con los juegos?

El resultado fue muy bueno (fotos), les gustó, y durante los momentos de diseño se los veía muy compenetrados en la discusión de alternativas y en el proceso de armado del prototipo. Notable la satisfacción de ver su producto soportar pesos que nunca hubieran imaginado que pudierna soportar: bolsas hechas con separadores de nylon para freezer y hilo de algodón soportando más de 2,5 Kg, o estructuras hechas con 12 cartas soportando a una persona parada arriba!

O... no se si tan notable. Ver el producto de nuestro trabajo es siempre bueno,

Espero que haya servido y al menos a uno o dos de los chicos les haya despertado la inquietud de ingresar a una carrera de Ingeniería.

Muy buena la organización (Federico Di Vruno, Juan Pablo Perello y Santiago Maudet) de la Rama Estudiantil! (FRBA UTN)

Muy buena onda, tanto los estudiantes como los docentes del Instituto (Hernán Bosco y Pablo Milione). Muchas gracias!

Introducción al Testing de Seguridad en Aplicaciones Web

2009-06-13T11:55:00.003-03:00

Ya está disponible en la página web del IEEE la documentación de la Conferencia 'Introducción al Testing de Seguridad en Aplicaciones Web' dictada por Andrés Riancho y Martín Tartarelli el 19 de mayo ppdo. En la misma sección también hay información sobre otras actividades realizadas en el ámbito de IEEE Argentina.

Andrés y Martín presentaron la necesidad y técnicas para realizar este tipo de pruebas. Andrés además presento la w3af, la herramienta FLOSS en que está liderando

Acceder desdehttp://www.ieee.org.ar vía Botón 'Actividades' y opción 'Documentación'.

La conferencia la organizamos junto con Marcelo Doallo (IEEE AR - computer Society).

¡Gracias, Andrés y Martín!

Ágiles 2009!

2009-06-11T00:08:00.002-03:00

Estamos organizando Ágiles 2009 - 2das Jornadas Latinoamericanas sobre Metodologías Ágiles.

Este año se organizan en Florianópolis (Floripa para los amigos) – SC – Brasil, entre el 6 y 9 de Octubre. Para los que no la conocen, Floripa tiene unas playas espectaculares.

Pero no vamos (sólo) por eso. Ya están confirmados Brian Marick, Diane Larsen, Matt Gelbwaks y Naresh Jain. Alan Cyment estará dando un curso de CSM, y... los invitamos a que propongan sesiones sobre sus ideas y experiencias, para presentaciones, tutoriales, y workshops, relacionados con la adopción de Desarrollo Ágil en Latinoamérica y en el mundo.

Si te interesa, puedes visitar el sitio oficial. Si querés ayudar, por favor difundilo y blogea al respecto.

También hay oportunidades para sponsors.

Este evento tiene el impulso del éxito de Ágiles 2008, sumado al tamaño de Brasil. Tendrá mucha mayor difusión (InfoQ).

¡Espero que nos veamos allá!

Calidad de Software y Desarrollo Ágil

2009-06-10T20:05:00.008-03:00

Participé en un evento organizado por IRAM y la Universidad de Belgrano.

Luego de breves comentarios de Juan Lestani (UB) y Gustavo Pontroliero (IRAM) sobre las organizaciones, Paula Angeleri (IRAM y UB) comento algunos temas de normas que impulsa IRAM, más allá de ISO 9001. Me enteré que tienen normas de evaluación de nivel de madurez (estilo CMMI) y una norma estilo MoProSoft, de alcance latam. Otras cosas, ya las había escuchado, como la norma de calidad de producto y la certificación de ITIL.

No me queda claro por qué una empresa estaría interesada en esas normas. Creo que eso merece más tiempo para ser explicado.

Después yo presente un básicamente el Desarrollo de Software Ágil (la presentación, de 45 min la pueden bajar aquí). Fue tan básico que no nombré el rol del ScrumMaster. Por suerte luego Diego completó los huecos que yo dejé.

También me da la impresión que hay que hablar del cliclo más ámplio: los releases. Hablar sólo de los sprint deja una impresión incompleta. Por suerte, esto también fue comentado, en este caso por Pauline, la otra presentadora. Esta obra está bajo una licencia de Creative Commons.

Diego Gonzalez comentó la experiencia de Lagash, que entiendo fue una presentación similar a la que dió en Ágiles 2008, de la cual pueden ver los videos, salvo el hecho de tener 10 meses más de experiencia con ISO.

Pauline Morrison Fell comento el caso ThreeMelons. Una cosa que me gustó mucho de este caso es el uso de los posters, que creo son muy piolas como forma de documentación y difusión.

Llamativa la cantidad de personas, unas 90.

Espero que se repita.

Curso Introducción al Testing

2009-05-27T23:45:00.003-03:00

Luego de la experiencia del curso de Automatización de Testing nos pareció (a Lucas y a mí) que se había hecho muy largo (50hs). Es difícil mantener la dedicación durante más de 3 meses, aunque sea un día a la semana. Y el horario (18:30 a 22:00) es muy cansador.

Decidimos hacer otra versión del curso más focalizado, de manera que se pueda hacer en 24hs. No tiene fecha confirmada, pero propusimos hacerlo en agosto y septiembre.

Por mi lado, me pregunté si parte del material que dejamos afuera podría ser incluido en un curso más introductorio. Cuando me puse a pensar, me pareció que la Automatización de la prueba es una consecuencia importante de las necesidades del testing en ambiente ágil, pero que hay otros temas de testing que no tienen mucha relación con el testing automatizado: el testing exploratorio.

También me interesa hacer un experimento: ¿es mejor para la gente dedicar dos días, un formato más compacto, y con horas laborales? El tiempo dirá :)

En resumen, a los que les interese y puedan dedicarle dos días, nos vemos el 10 y 11 de junio en SADIO, para hablar sobre el Testing!

Podés ver los resultados y el material.

CMMI y Ágil - ¿Choque de civilizaciones?

2009-05-21T00:57:00.009-03:00

Fui invitado por Liveware para un evento sobre CMMI y métodos ágiles (parte 1, parte 2). Después de consultar con la comunidad sobre opiniones, di varias vueltas para elegir un tema y buscar un balance entre algo picante que haga interesante el panel y mi natural postura ecléctica. Decidí hablar sobre una diferencia cultural que percibo entre los viene del campo CMMI y los que vienen de Desarrollo Ágil.
Posteo la versión larga, tuve que reducirla para que entre en 10 min.

Una comparación superficial entre empresas CMMI y Ágiles muestra grandes diferencias. Pero en ambos casos los espacio de posibles implementaciones son amplios, con intersección, y hay implementaciones que son tanto CMMI como Ágiles, como lo demuestran casos de empresas como las que estuvieron representadas en el panel.

Podemos encontrar bases comunes, como las ideas de Deming, y en el foco en la mejora continua.

Tuve la suerte de escuchar a Watt Humphrey en Santiago de Chile (SEPGLA 2007), en su presentación comentó "La clave para manejar trabajadores del conocimiento es: los trabajadores deben manejarse a sí mismos." … Lo podría haber dicho un gurú Ágil.

En el libro de Boehm “Balancing Agility and Discipline”, Boehm comenta una comunicación personal de W. H. diciendo que un equipo XP cumple con el TSP con “sólo agregar algunas métricas”. “sólo agregar algunas métricas”… después vuelvo sobre esto. Alan Cyment comentó alguna vez que lo que define a Scrum es la mejora continua, todo el resto es modificable.

Podría seguir con similitudes y puntos de contacto… pero hablemos de las diferencias.

Antes de seguir, un disclaimer. Se puede hablar de “qué es CMMI”, está el SEI para decirlo. Es más difícil con Desarrollo Ágil, no hay una fuente oficial.

Al recibir la invitación para el panel, decidí hacer un experimento, pregunté en una lista Latinoamericana que pensaban de la interacción de CMMI y Ágil. Recibí algunas respuestas negativas, pero la mayoría de los que tuvieron experiencia real con ambas formas de trabajo, dicen que se pude implementar ideas ágiles con CMMI. Sin embargo no hubo ninguna respuesta que recomendara implementar CMMI para empresas ágiles.

Esto llama la atención. ¿Cómo es posible que un modelo hecho para que las empresas mejoren no sea recomendable?

Se entendería para barreras de entrada, como SOX. Nadie espera ser más eficiente por cumplir con SOX. Es un mal necesario si quiero entrar en cierto mercado.

CMMI tiene dos caras: ser una barrera de entrada (evaluación), y por otro lado un modelo de mejora. No voy a discutir la primera parte. Hablemos de la mejora, desde varios puntos de vista.

Observo que las empresas CMMI tienen algunas características que no se encuentran en empresas ágiles:

Mejora cuantificada: Existencia procesos y sus métricas como precondición a la mejora.
Mejora centralizada: un grupo de mejora o un consultor externo.
Foco en la repetibilidad y el cumplimiento de normas.

Mejora cuantificada: Los procesos en las metodologías ágiles

Un amigo empezó a trabajar en la planta de Toyota en Zárate desde el día uno. Me comentó que el layout inicial era ultra sencillo, lineal, sin paralelismos. El único objetivo: producir la primera camioneta, como sea. ¿Era eficiente? No. Pero a partir de ahí, se ponía en marcha la mejora continua. Con todo lo que sabía Toyota de fabricación, podrían haber hecho un mejor layout, no? NO. La planta es sólo un paso en la generación de valor, todo el ecosistema de autopartistas, canales de distribución, … es necesario para entregarle una camioneta al cliente, y ese ecosistema es único y cambiante. La forma óptima es que la planta local se amolde al ambiente existente y influya en el ambiente, en un proceso de continua adaptación y mejora.

Los procesos surgen como las reglas que cada equipo se impone. Son el resultado de un trabajo ordenado y de la mejora continua, no al revés.

Pero si yo mido existencia de procesos como forma de medir la madurez, promuevo que aparezcan procesos aunque no tengan valor para el equipo. Doy un ejemplo: si creemos que un cliente que va a un restaurante va a están más satisfecho si lo atienden personas que están contentas con lo que están haciendo, podría verme tentado a sugerir a los empleados que atiendan siempre con una sonrisa, pero si planteo esto como obligatorio, obtendré de los empleados una continua sonrisa vacía, que tiene un efecto contrario al esperado.

Mejora centralizada: El control y la confianza

La estructura de los programas es un reflejo de la estructura del grupo que lo hizo. No sé quien es el autor de la frase, pero creo que muchas veces es verdad. Si un equipo no está aglutinado, se tendrán un producto hecho por pedazos, cada uno de los pedazos más o menos integrado con el resto.

Creo que algo así pasa con las organizaciones. El SEI y el CMMI nacen de la relación de desconfianza institucionalizada que existe entre el DoD y sus proveedores. Esta estructura macro (dos partes involucradas, que desconfían entre si, usan un tercero “neutral”) se repite a nivel empresa (QA: valida que los procesos se cumplan) y equipo (Test: valida que lo que pidió el usuario se cumpla).

La falta de confianza está también reflejada en organizaciones fuertemente jerárquicas, en la que cada nivel “superior” comanda y controla al nivel “inferior”.

Foco en repetibilidad y cumplimiento: Cómo analizamos los problemas y cómo aprendemos

La forma CMMI de mejora tiene mucho en común con el método científico. Fijo las condiciones (proceso), planteo la hipótesis (cómo mejorar el proceso), hago el experimento, mido los resultados. ¿Es lo esperado? Si, mi hipótesis es la correcta. Paso a la próxima hipótesis. ¿Cuál es el problema?... ¿de dónde surgen las hipótesis? No es algo que el método científico resuelva.

¿Es la única forma de mejorar? ¿Cómo hacen los grupos de teatro?¿Los músicos? No parece que sepan mucho de control estadístico de procesos, por lo tanto debe haber otra cosa.

El desarrollo de software tiene un fuerte componente social. Si queremos resolver la dinámica de grupo con el método científico, me parece que no llegamos a nada.

Por otro lado, si queremos lograr aumentar la confiabilidad de un servicio, un análisis de modos de fallo, Ishikawa y otras técnicas de mejora de proceso probablemente nos ayuden mucho más que una retrospectiva en que tratemos de evaluar como nos sentimos (enojado, triste, contento) cuando se cayó el servicio y nos llamó el cliente para decir que no cumplíamos con el SLA.

Ahora la pregunta del millón, si quiero innovar, ¿me alcanza con el método científico?

Estas tensiones aparecen incluso dentro de la comunidad ágil.

¿Hay diferencias culturales?

No sé suficiente de CMMI como para asegurar que las diferencias observables en cultura son una consecuencia inevitable o, si por el contrario, es sólo un resabio indeseable de formas superadas de implementar el modelo.

Lo que si tenemos que tener en cuenta es que esa diferencia cultural suele estar presente y debemos considerarla. No sé si pueden convivir dos culturas tan diferentes en una organización. Me parece que lo más probable es que una de ellas prevalezca, absorbiendo o desplazando a la otra.

En cualquier caso creo que en el intercambio ambas culturas pueden salir enriquecidas.

Agile Open Córdoba - impresiones como facilitador

2009-05-11T10:06:00.003-03:00

Participé en el Agile Open Córdoba 2009 hace unas semanas. Fue mi primera experiencia como facilitador (salvo la versiones reducidas de la facultad).

Como pasó en el de Buenos Aires, como organizadores nos genera cierta ansierdad la instancia previa, siendo un evento gratuito ¿Vendrán?, y por otro lado ¿Saldrá bien?

Y en ambos casos, el resultado fue muy bueno. Voy a postear desde distintos puntos de vista. En este post me centro en impresiones generales del evento.

Como moderador, traté de usar un estilo minimalista. Por suerte lo tenía a Alan Cyment, para validar las ideas o recibir consejos. Arranqué con una presentación general, no creo que haya durado 5 min, comentando en lineas generales la dinámica de evento, y la agenda a grandes rasgos (Viernes: Propuesta de Sesiones, Votación, Armado de Agenda; Sábado: Slot temporales, aulas disponibles, tiempos entre sesiones, cierre).

Las instrucciones y reglas las fui comentando JIT: justo antes que necesiten usarse. Por ejemplo, las 4 reglas de Open Space las comenté al final del viernes, y en la apertura del Sábado. No las comenté en la apertura.

Impresiones

Propuestas de sesiones: tuve que cortarlas! El miedo como facilitador es que no se animen, pero en este caso, creo que tuvimos casi una propuesta por persona en promedio. Mentalmente contaba los segundos de silencio. Y cuando llegué al minuto (dos veces), pregunté si quedaban propuestas en el tintero, y siempre había. Las últimas eran sin embargo de relativamente poca utilidad, se superponían con otras ya presentadas.

Votación: la votación se concentró en las sesiones propuestas por gente conocida, y hubo mucha dispersión en el resto. No hubo suficiente fusión de sesiones similares, y las fusiones se hicieron sin consultar con el autor. En charlas con Alan Cyment (asistente a AO Córdoba y facilitador del Agile Open Buenos Aires), creemos que parte de esto fue debido a que no habia lugar para que mucha gente participara simultaneamente. Por lo tanto, si alguien preguntaba por el responsable de una sesión, era probable que no estuviera.

Armado de Agenda: El armado funcionó bien, salvo que se repitieron los problemas de unión de sesiones sin consultar a los autores. Extrañamente, quedaron algunos huecos. Esto fue porque habia relativamente pocas sesiones muy votadas, y muchas poco votadas. Parecía un desproposito asignar un slot para una sesión votada por tres personas.

Desarrollo: El desarrollo no tuvo problemas. Mi tarea principal fue de time-keeper, lo que fue más que sencillo. Hubo sesiones de 2 personas y otras de 30 o más. No vi en ningún caso sesiones explísitamente planteadas como presentaciones, aunque en varios casos había una persona que guiaba fuertemente la sesión en cuanto a contenido. Esto lo veo como un problema. Creo que parte de las quejas recurrentes de los novatos en agilidad se refieren a esto. El énfasis en repetir en las sesiones el formato open space (circulo) fomenta las discusiones democráticas, lo que no significa que sea la mejor o única forma de enseñar/aprender.

Cierre: el cierre, más parecido a una retrospectiva que a un cierre Open Space, me pareció más productivo que el que tuvimos en Bs As. La gente habló, y se plantearon pasos a seguir.

Nos vemos en Tandil!

Resultados de Agile Open Córdoba

Fotos de Pablo RF

Blog de Matías Iacono blog / ¿Por qué Agile?

Blog de Fabio Grigorjev blog

IES21: nota (en la foto Pablo Rodríguez Facal, Matías Iacono, Juan Gabardini, Fabio Grigoriev, Claudio Ochoa, Alan Cyment)

Diario Comercio y Justicia: nota

Aprendiendo Lean Manufacturing con un juego

2009-05-10T17:16:00.004-03:00

En la materia Adm. y Control de Proyectos II vemos el modelo de organización por procesos y también técnicas de desarrollo ágil, como Scrum y Lean Software Development.

Estamos siempre buscando mejores maneras de aprender estos temas.

Este cuatrimestre decidimos probar con Mr. Happy Face, uno de los juegos propuestos en Tasty Cupcakes. Es un lindo lugar para buscar ideas.

El resultado, como siempre que hacemos juegos, fue tener una clase muy entretenida, con todos los participantes prestando mucha atención. El resultado fue muy bueno, se pudieron comentar los principios Lean y algunos conceptos como JIT, Pull y Kanban desde la experiencia.

Ricardo Colusso se tomó el trabajo de filmar partes de las actividades. Gracias!

En la primera parte se trabaja con una linea de montaje "tradicional", tratando de predecir las ventas. En la segunda parte se usa pull, produciendo sólo lo vendido, y usando kanban para comunicar las necesidades de partes a lo largo de la linea.