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...

Resumen Clean Coders capitulo 6: TDD Parte 2 (III) Conclusiones

Continuamos con el resumen del Capitulo 6 Parte 2. En este caso finalizamos con las conclusiones.
Si no lo has hecho, puedes leer los anteriores posts sobre el capitulo (parte 1  parte 2).

Conclusiones

• El código se pudre porque tenemos miedo a cambiarlo
• Para mantenerlo limpio tenemos que eliminar el miedo a cambiarlo
• Sólo con una batería de tests en la que confiamos se elimina el miedo a cambiar el código
• Reglas del TDD
• No se puede escribir código de producción excepto para pasar un test que está fallando
• Escribe solo lo suficiente de un test para demostrar el fallo (no compilar es un fallo)
• Escribe solo lo suficiente del código en producción como para pasar el test fallando
• Siguiendo estas reglas de TDD se consigue:
• Menos defectos
• Tiempos de depuración más bajos
• Documentación de bajo nivel confiable y detallada
• Código altamente desacoplado
• Y una batería de tests en la que puedes confiar
• TDD te hace ir más rápido
• Los desarrolladores profesionales debemos esperar que el departamento de QA no encuentre ningún defecto (ese es el objetivo)

Con este post concluimos el resumen de este interesante capitulo de clean coders 

Review Agile product management with scrum

Agile product management with scrum creating products that customers love

Este es uno de los pocos libros dedicados al rol de Product Owner que he visto... Es un rol, que aun siendo fundamental, es muy difícil hacerlo bien y no cuenta con tanta literatura como el rol de Scrum Master o como las prácticas de desarrollo de software que debe usar cualquier equipo de desarrollo ágil.

El libro se centra en entender el rol de product owner, crear la visión general del producto, trabajar con el backlog, planificar las versiones (releases), y cómo introducir el rol de product owner en empresas que no estén acostumbradas a ese tipo de rol.

La parte que más me ha gustado es la que se centra en crear la visión general del producto y el trabajo con el backlog. En estas partes, da bastantes herramientas y trucos para ayudarnos en el proceso creativo y en la toma de decisiones.

Enlace a goodreading