El arte del patadon pa'lante / Postponer decisiones técnicas

24/6/2013 Actualización de formato y añadidas referencias

Este post contiene la esencia de lo que estamos haciendo en Alea Soluciones para postponer en todo lo posible las decisiones técnicas. Vamos a usar este post como base para compartir nuestras experiencias al respecto en el AOS2013

Comenzamos:

Nuestro contexto

• Hacemos productos en entorno de telecomunicaciones
• Equipo Extreme Programming
• Deploy continuo / Entrega continua

A qué nos referimos

Postponer todas las decisiones técnicas hasta el último momento responsable

Que no postponemos

• La forma en qué hemos decidido trabajar (de forma ágil, deploy continuo, extreme programming)
• El lenguaje base de desarrollo  de cada componente... python...
• Buenas prácticas de OO

Por qué queremos postponer / Beneficios conseguidos

• Cuanto más tarde tomemos una decisión más conocimiento tendremos del negocio y del entorno técnico
• Soluciones más simples/sencillas
• Soluciones más pequeñas
• Trabajar menos :-)
• Más probabilidades de no hacer nada que no aporte valor real ahora
• Más probabilidades de no hacer sobre ingeniería
• Menos esfuerzo en rehacer trabajo si es necesario
• Nuestro objetivo es tener mucho juego de cintura... reaccionar bien y rápido a cualquier cosa... y sin echarnos las manos a la cabeza
• Cuanto más postponemos, menos llenamos la mochila.... es más dificil coger lastre y tendemos a viajar ligeros.... añadimos menos cosas innecesarias.
• Todos sabemos que una mudanza se hace fácil si tenemos pocas cosas
• Una buena arquitectura nos permite postergar decisiones importantes, esto no significa que estemos obligados a hacerlo. Sin embargo, al poder postergarlas tenemos muchísima flexibilidad.

Esta forma de actuar está alineada con los principios lean de eliminar el desperdicio y los principios ágiles de post poner hasta el último momento responsable y es una  de las forma de actuar que mas puede ayudar  a la creación de un arquitectura limpia. A su vez una arquitectura limpia hace que sea mas fácil post poner otras decisiones.

Cómo lo hacemos

• Postergamos las decisiones de forma consciente y meditada
• Consideramos una decisión como buena cuando:
• nos compromete lo mínimo posible
• nos permite postponer otras decisiones
• Es fácilmente cambiable
• Ataca un problema actual (no futuro)
• Suficientemente bueno (sin sobreingenieria, ni nuestra ni de otra gente)
• Prohibido Megaconstrucciones
• Reusamos librerías pero no Frameworks (vamos no dejamos que nos usen a nosotros)
• Consideramos qué todo se puede cambiar (código / diseño / proceso)
• Cuanto vamos a afrontar un sprint o un grupo de funcionalidades nos centramos en identificar qué tenemos que cambiar en nuestra arquitectura y nuestro entendimiento del dominio / lenguaje ubicuo.
• y lo que se decidió era lo correcto en ese momento y en ese contexto y si hay que cambiarlo, no pasa nada, manos a la obra...
• Método Hamburguesa descomposición de PBIs grandes.
• Clean Code
• DDD (u otra variante que permita que la arquitectura no se centre en las herramientas BD, GUI, etc)

Qué necesitamos para hacer fácil postponer.

• seguridad/confidence
• Feedback temprano
• TDD
• Refactor continuo
• Todo se pueda cambiar

Dividimos cambios medios/grandes en cambios pequeños, incluso duplicando código y duplicando datos... todo con el objetivo de poder postponer decisiones, no impedir deploy y hacer cambios incrementales, pequeños y seguros.

Código no es un snapshot, es algo en movimiento

Siempre puedes iterar... iterar/refactorizar es fácil sin miedo y con red... TDD, BDD...

Problemas/Sensaciones que genera postponer decisiones...

• Incertidumbre
• Ansiedad
• Conflicto (como ingenieros)

Postponer... hasta el infinito y más allá...

Hasta el último momento responsable!!!!

Referencias:

• Método Hamburguesa para descomposición de historias de usuario http://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/
• Articulo relacionado recomendado Real options enhance agility http://www.infoq.com/articles/real-options-enhance-agility  Gracias Marcin
• Domain Driven Design http://www.domaindrivendesign.org/
• Clean Architecture http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html 
• Hexagonal Architecture http://alistair.cockburn.us/Hexagonal+architecture

Anfitriones desk-surfing (una vez más)

Hace unos días, Yamila Moreno, de Kaleidos ha tenido la gentileza de visitarnos y trabajar con nosotros un día... y no sólo eso, además ha tenido la paciencia de escribir un post al respecto... :-)

http://kaleidos.net/blog/desk-surfing-en-alea-soluciones/

Anfitriones desk surfing en Alea Soluciones

Hace unos días, el equipo de desarrollo "Bifer", en Alea Soluciones,  tuvimos nuestra primera experiencia como equipo con un desk-surfing.

Fuimos anfitriones de la visita de Enrique Amodeo que vino a compartir con nosotros dos días de trabajo, ver cómo trabajamos y a compartir su forma de hacer las cosas...

El primer día después de contarle un poco a que nos dedicábamos, intentamos tener una día de trabajo lo más normal posible. Como era un viernes, teníamos demo, y a algunas reuniones, por lo que realmente no pudimos compartir mucho tiempo de programación. Pero entiendo que también es muy importante ver otras partes del proceso de desarrollo.

El lunes sin embargo teníamos funcionalidades preparadas para desarrollar por lo que porque pudimos programar la mayor parte del día. Nos organizamos por parejas como solemos hacer normalmente y Enrique fue rotando de compañero a compañero para que tuviese la oportunidad trabajar con todos.

Desde el punto de vista de equipo creo que fue una gran experiencia.  Pudimos compartir enfoques muy diferentes sobre cómo solucionar ciertos problemas lo que siempre enriquece y aparecieron nuevos puntos de vista para algunos diseños...  Por otro lado también surgieron buenas aportaciones sobre las prácticas de desarrollo que usamos (TDD, programmación en parejas, etc...)

Por otro lado fue muy interesante ver como el hecho de estar una persona externa equipo, no sólo no nos retrasó, sino que incluso creo que nos organizamos mejor.

En la siguiente retrospectiva de equipo, estuvimos todos de acuerdo en que había sido una experiencia muy enriquecedora y que teníamos que instaurarlo como algo a realizar de forma periódica.  Vamos una experiencia fantástica...

Por otro lado, Enrique nos comento lo siguiente:

¿Sugerencias? No se me ocurre ninguna, hacer pair programming fue genial, y ciertamente vuestro dominio me sacó fuera de mi zona de comfort (y he de reconocer que python un poquito también). Quizás hacer un par de fotos de la ocasión podría haber estado bien, pero a mi ni se me ocurrió. Al menos pude aportar un buen par de refactors interesantes.

Para la siguiente, no se nos olvida hacer unas cuantas fotos...


Repetiremos como anfitriones.
Intentaremos salir a otras empresas a conocerlas y aprender.

Gracias Enrique por venir y por compartir con nosotros estos dos días, y gracias Guillermo por ponernos en contacto con Enrique.

Fantástico, otro paso como equipo ágil y equipo de Extreme Programming

Felicidades a Todos.... Happy NewYear++

Para los ateos: Felices días de Vacaciones.
Para los cristianos: Felices Navidades.
Para los satánicos: Lo siento tios.... a soportar otras Navidades
Para el resto: Felicidades sin especificar.

Introspección en Python mediante inspect

Mediante el módulo inspect podemos de una forma sencilla obtener todos los símbolos (funciones, variables, classes, etc) de un módulo. Para ello debemos usar la función inspect.getmembers que nos devuelve todos los símbolos del módulo.
Una vez de que disponemos del símbolo podemos usar las funciones ismodule, isfunction, ismethod y similares para clasificar el símbolo.

El siguiente ejemplo podemos ver cómo se obtienen todas las clases y todas las funciones de un módulo:

Ejemplo introspección con inspect

Esta técnica se usa por ejemplo en el boscli-oss-core para una vez cargado un módulo de forma dinámica identificar todas las funciones cuyo nombre cumple un formato concreto (https://github.com/eferro/boscli-oss-core/blob/master/src/boscli/boscli.py#L515).

Ejemplo uso importlib carga dinámica de módulos por nombre

En muchas ocasiones es bastante útil poder cargar módulos o acceder a símbolos usando como entrada una cadena. Esto permite cargar de forma dinámica código, por ejemplo si estamos desarrollando un sistema de plugins.

En versiones de python anteriores a la 2.7 se solía usar  la función __import__, pero a partir de la 2.7, tenemos disponible el módulo importlib que recubre la función  __import__ dándonos un api algo más elegante.

Podemos ver un ejemplo de uso en el siguiente snippet de código: https://gist.github.com/3928018

Importer Class (importlib wrapper)

Tests for importer module

Espero que este pequeño ejemplo de código le puesa ser útil a alguien...