Agile Open MDP 2014

Muy buen evento, con una concurrencia mayor a la prevista (o sea más de la mitad de los inscriptos), sin inconvenientes logísticos y un buen clima que nos saludaba desde afuera.

Notas de la sesión de retrospectivas

Algunas personas manifestaron que pese a tener las retrospectivas instaladas había una suerte de estancamiento, una de ellas sospechaba que podía ser por la presencia del PO.

Con respecto al estancamiento, conversamos acerca de usar recursos como ECVP (gracias a Sergio[1] por habérmelo enseñado en su momento y recordado ahora):

Cada uno dice como se siente:

• Explorador: viene a proponer soluciones, buscando formas novedosas de encarar los problemas.
• Comprador: no viene a proponer, pero si a escuchar ideas.
• Vacacionista: viene a la reunión porque prefiere estar acá que en otro lado.
• Prisionero: prefiere estar en otro lugar y no en esta reunión.

Con lo del PO se complica. Es para un equipo distribuido y el PO es english speaker y está todo bien, pero puede estar estorbando. Esto me produjo el primer premio de la jornada.

Pienso, la restrospectiva sirve para mejorar el producto y el proceso. El producto es del PO, obvio, pero ¿el proceso y los subproductos?

Por ejemplo, en Amazon el producto es el sistema de ventas. Pero para desarrollarlo generaron una serie de subproductos como AWS y sus amigos, de importancia comparable al sistema de ventas. Algo parecido con Netflix y ChaosMonkey [2].

Los PO o mejor aun quienes ponen el billete suelen tener, no sé como decirlo, el comportamiento por default de ciertos algoritmos de expresiones regulares: "greedy". Y uno puede tener una cierta reticencia a producir algo y que otro se lo apropie. Mm, no sé, quizás amerita otra entrada aparte.

Notas de la sesión de testing

Lo que resta de este bloque será salvajemente editado resultado de las conversaciones en foro-agiles[3]/agiles-argentina[4] (si no los conocés ¿qué esperás para subcribirte?). Antes de tildarme de desprolijo, recordá que lo perfecto es enemigo de lo bueno, si espero a tener este bloque bien, no lo termino jamás.


Nico Paez expuso algunos conceptos acerca de testing que espero desarrolle en su blog[4]. Tuvimos una discusión acerca de si el análisis estático de código forma parte del testing y para él la linea divisoria está dada por "la ejecución del código".



Dada mi posición actual, para mi no hay distinción, ya que para mi son todas vulnerabililidades (errores de seguridad) y pueden surgir por:

• testeo funcional black box (ethical hacking)
• revisión white box de código de modo manual o automático (static code analysis)
• intuición white box (me parece que esta vulnerabilidad está presente)
• divulgación de vulnerabilidades comunes, que no son de desarrollo propio, por ejemplo un error en un servidor web que se corrige actualizando, reconfigurando o implementando algún parche externo.

A esto le sumaríamos los resultantes de probar que la aplicación cumpla con lo que se supone que tiene que hacer.

Lo que veo del análisis estático, es que son tests pero no están aplicados a un caso de uso, un flujo, una clase o método en particular, sino al texto del código, por ejemplo, es un error que:

• halla una clase con más de ... lineas
• halla un método con más de ... lineas
• hallan nombres de clases, métodos o variables demasiado largos o cortos
• halla un nivel de anidamiento mayor a ...
• una referencia a un objeto pueda llegar a ser usada siendo null
• un dato proveniente del exterior, source, pueda llegar a ser utilizado, sink, sin pasar por un sanitizer

Si mi build se rompe por que no paso jUnit y se rompe tambien por Fortify/FindBugs, para mi es lo mismo, no me importa si el código se ejecutó o no.



No es mi situación actual, pero para mi las vulnerabilidades deben estar junto a los otros bugs, aunque con un tratamiento especial: a menos que el bug tracker/project management tool tenga un soporte completo de roles y permisos a nivel de entrada, no se puede poner la descripción ni ningún detalle, pues se está mostrando como afectar al sistema.

Para destacar

Liliana la decana de la Universidad Atlántica Argentina reiteró su ofrecimiento a la comunidad local de usar las instalaciones para los encuentros periódicos necesarios para su funcionamiento.

Disparadores

Me parece que se sembró la semilla de Agiles Argentina 2015 @mdp, para que germine va a hacer falta el apoyo de todos.


No se si es tarde para AA2014 pero podría ser factible para AA2015, sea donde sea, el Agile Micro/Hotel, supongo que contratar un micro/hotel lleno puede resultar significativamente más barato que viajar/alojarse individualmente.


[1] http://www.ideasagiles.com/

[2] http://blog.codinghorror.com/working-with-the-chaos-monkey/
[3] http://groups.yahoo.com/group/foro-agiles/
[4] http://groups.yahoo.com/group/agiles-argentina/


[5] http://nicopaez.wordpress.com/