miércoles, 18 de junio de 2014

AgileOpenCartagena (Failfast - Arquitecturas ágiles)

El pasado sábado 7 de junio se desarrolló en Cartagena en la Universidad del Sinú, la segunda versión del AgileOpenCartagena, en la cual tuve el placer de participar. Tuvimos una serie de actividades relacionadas con ágil y un conjunto de técnicas que resultaron muy interesantes.

Como se aprecia en la facilitación gráfica (@Claumsandoval - @GabrielMorrisS) de arquitecturas ágiles, implementamos una charla en la cual compartimos ideas acerca de dónde implementar estas actividades en procesos ágiles. Fue bastante interesante intercambiar ideas con diferentes personas acerca de dónde se deben implementar dichas labores.

Hubo afirmaciones interesantes como: 
  • "Las buenas inspecciones se realizan a través de pruebas automatizadas de los atributos de calidad definidos".
  • "El equipo en conjunto con roles de arquitectura definen los diseños de alto nivel que se implementarán".
  • "Hay que definir las abstracciones siguiendo los principios de diseño clásicos para desacoplar y cohesionar los componentes que se implementen: principios de paquetización, abierto-cerrado, liskov, interfaz, (boundary-control-entity) etc."
  • "Las arquitecturas deben ser evolutivas y estar listas para el cambio. Si es necesario se deben re escribir".
Fue una actividad con bastante participación en la cual se intercambiaron ideas al respecto y en la que participaron entre otros: @luismulato, César, y quien escribe.

Hubo un tema que le facilité a @luismulato, FAILFAST; La verdad me parece muy útil dejar el temor al fallo, a la equivocación, al señalamiento.


Este tema es algo que se relaciona directamente con la elaboración de componentes de software en las iteraciones SPRINTS; los ciclos cortos ayudan a encontrar fallos rápidamente a través de los puntos de revisión y las retrospectivas. Sin embargo, si tuviéramos pruebas automatizadas de aspectos no funcionales detectaríamos rápidamente malos diseños o malas implementaciones que podrán rápidamente corregirse en el siguiente ciclo.

Los escenarios de fallo deben considerarse siempre, pues detectarán rápidamente los puntos de quiebre. Estos se deberían implementar con el tratamiento de excepciones y siguiendo un manejo de aserciones para garantizar que se cumplen las premisas.

¡Estuvo bueno el OpenSpace!

2 comentarios:

  1. Excelente post Gabriel y aportes de Luis, que bueno es leer avances, y experiencias en este sentido.

    Quedo atento para el próximo.

    Saludos.

    ResponderEliminar
    Respuestas
    1. No te pierdas el próximo ... la mayéutica aplicada en estas charlas... jajajaaja.
      Saludos,

      Eliminar