martes, 16 de septiembre de 2014

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/

sábado, 9 de agosto de 2014

Propuesta de sesión Seguridad vs Agile en Agiles Argentina 2014

Por si no tenés sintonizado el canal Agile y no llegaste desde el listado de temas propuestos, voy a tener que contarte que el viernes 26 y sábado 27 haremos Agiles Argentina 2014, las primeras jornadas nacionales de metodologías ágiles, en el espacio gentilmente provisto por la Universidad de Belgrano.

Será puro Open Space, tan puro que hasta la comida será autoorganizada. No voy a repetir lo que ya dice en el sitio[1], sólo le voy a dar un poco de cuerpo a la propuesta de sesión[2] que quizás te trajo acá.

Mi idea es enunciar una lista de tensiones que noto tanto a nivel intuitivo como en la práctica misma a modo de punto de partida y que luego compartamos nuestras experiencias e intentemos arreglar el mundo.

Por supuesto, lo más seguro es que no bien termine de decir "en esta sesión veremos el conflicto existente entre seguridad y agile..." todos nos avalancemos sobre el tema como niños al volcar el camión de los helados, pero bueno, hay gente que necesita saber de antemano a donde piensa que va a ir.

  • Tensión entre "need to know" y "collective ownership"
  • Mínimo privilegio y mínimo conocimiento vs segregación de funciones.
  • El típico waterfall de segurida vs "timely tests", roi temprano,
  • Agile desde la gestión de riesgos a la luz de maturiy.

No faltés, es gratis, en horario de trabajo un día si y otro no. Si tu jefe te aprecia, que faltés te deprecia, mostráselo como inversión. Si tu familia te necesita, venir mejora tu futuro profesional. Si sos hombre, vas a tener que hacer tarea del hogar como deberías hacer de todos modos. Si sos mujer, no tendrías que justificar nada, velo como un bien merecido descanso.

Si no se entendió el párrafo anterior, pensalo bien antes de pegarme, repensalo y luego pegame.

[1] http://aa2014.agiles.org/
[2] http://agilesargentina.uservoice.com/forums/261590-%C3%81giles-argentina-2014-26-y-27-sept-en-buenos-aire/suggestions/6275665-agilidad-vs-seguridad