martes, 25 de octubre de 2011

Sesión Desarrollo comunitario en Ágiles 2011

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

lunes, 26 de septiembre de 2011

Pruebas con fechas


En los últimos días me encontré dos veces conversando sobre pruebas que incluyen fechas: en el curso sobre Fitnesse, con pruebas funcionales, y con mis compañeros en UTI SIS con TDD.
Ambas conversaciones me hicieron repensar este tema, y aprovecho para volcar mi visión actual.

¿Por qué es especial la prueba que involucra a fechas?

Hay otras razones, pero en este post me centraré en la dependencia con la fecha del sistema. 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 pruebas que tengan dependencias sobre un elemento que no podemos controlar (en este caso el paso del tiempo), nuestras pruebas van a ser poco robustas (como pruebas unitarias).
Si quiero probar el sistema completo, me puede interesar explicitar el uso de las fechas de diferentes servidores. Estaría haciendo prueba de integración en vez de prueba unitaria.

¿Que alternativas tengo?

  1. 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.
  1. 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.
  1. 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.
  1. 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, muestra como 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 fin del curso). Los primeros 4 números 'datos' son días relativos al día de hoy.
La función __creaCurso traduce entre valores relativos de las fechas y los valores absolutos con que se quiere 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 se pueden poner fechas relativas (!today -1).

Alternativa 2

En este caso, la forma de cubrir esto es la Inversión de Control / Inyección de Dependencias. Se debe utilizar el servicio de obtención de día y hora actual a traves de una capa de abstración, de manera de poder reemplazarlo por una implementación controlada por las pruebas. Un ejemplo de esto se muestra en el capítulo 15 del libro FIT for Developing Software.
El SUT debe estar preparado (o debemos poder modificarlo para) para recibir la referencia al servicio.

Alternativa 3

En muchos casos el usuario pide funcionalidad que depende de la fecha actual, pero esa funcionalidad podría generalizarse para una fecha abitraria, con valor de negocio. Por ejemplo, cheque a depositar. Tiene sentido con fecha de hoy, pero si puedo poner fechas futuras, ayuda a la planificación.
Se puede evitar el aumento de la complejidad para el caso más usado con valores por defecto apropiados.

Alternativa 4

Puedo probar que un evento esté en intervalos temporales. Por ejemplo si quiero probar que un registro de auditoría es correcto, puedo almacenar el horario previo y posterior a la operación, y verificar que el registro esté dentro de ese intervalo.

viernes, 12 de agosto de 2011

Relación entre la frecuencia de entrega y los procesos

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.

miércoles, 29 de junio de 2011

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

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.
Foto del proyecto SCRUM cc/ @jgabardini  on Twitpic
!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.

jueves, 13 de enero de 2011

La mejor manera de probar, en Agiles@BsAs

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

<se perdió el video de Southworks :( >
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ú.