Estructuras rígidas

La sabiduría popular de la industria del software nos dicta las normas de la organización modelo, así siempre debemos de contar con un equipo enfocado en el desarrollo, un equipo al negocio, otro al producto, a soporte, etc. Esta es la estructura del 99% de las organizaciones que conocemos y en las que hemos crecido como profesionales.

El hecho es que no importa que una organización sea de dos personas, sus roles serán repartidos y cada miembro adquirirá unas bien definidas competencias. Si el equipo crece habrá que designar una persona con cualidades de manager que ejerza de interfaz, haga hueco para reuniones y tenga disponibilidad absoluta para atender emails.

Cuando nos movemos al mundo agile (la nueva sabiduría popular), aun no siendo corporate, encontraremos exactamente lo mismo: un miembro sera designado scrum master, otro product owner, están los stakeholders, el equipo de desarrollo…

El ámbito que me toca más de cerca es en el equipo de desarrollo de software. Defino equipo de desarrollo: un conjunto de personas que se encargan de comprender las características del negocio y traducirlo a un lenguaje que hasta un aparato sin conciencia puede entender. ¿Acaso es lógico que este conjunto de personas no hablen con un cliente, no participen en la definición de nuevas funcionalidades o en la toma de decisiones estratégicas? Y sin embargo los desarrolladores somos los primeros en querer delimitar con exactitud milimétrica donde empiezan y acaban nuestras responsabilidades.

No podemos negar que a todos nos ha chirriado esta organización muy al estilo militar-industrial en algún momento. En la vida cotidiana nuestros roles no están tan bien definidos, adoptamos distintos roles en función de la ocasión, que incluso tienen conflictos y contradicciones entre ellos: seremos hijos, padres, maestros, alumnos, amigos, vecinos a lo largo del mismo día… y esta conmutación de roles la tenemos asumida, no nos molesta en absoluto, es natural.

¿Cómo es que teniendo tal capacidad natural en un ámbito, nuestra vida cotidiana, nos aferramos a una organización militar en nuestro puesto de trabajo?

Hemos aprendido una manera de organizarnos en el trabajo en base a nuestra limitadísima experiencia en organizaciones, vemos antinatural y nos mofamos de cualquier otra forma de organización que no sea jerarquizada, industrial, militarizada.
Si en alguna ocasión nos involucramos en una organización con personas, completamente libres de adoptar la forma de organización que mejor convenga, tendemos a volver a elegir una organización tradicional, obviamente, es la única que conocemos (que existe para nosotros) Y al mismo tiempo nos quejamos de lo amargados que estamos al tener que ceñirnos a ello, de cómo esta rígida organización con sus reglas también impacta nuestra vida fuera del trabajo.

Quizás cuando empecemos a diluir las barreras de habilidades y conocimientos que nos autoimponemos en el trabajo y adoptamos formas más orgánicas para organizarnos, podremos exigir que se nos valore como lo que somos: individuos únicos.

Coding dojo 30 Enero

Coding Dojo beCode en Valencia

beCode y VlcTechHub convocan a todos los interesados al próximo Coding Dojo. Se trata de una reunión entre programadores para trabajar conjuntamente resolviendo problemas, y así aprender los unos de los otros.

Empezaremos a las 18:30 h, la idea es dedicar dos slots de 45 minutos a la kata y luego uno a comentar la jugada, así que durará más o menos hasta las 20:30 h.

Recordad que el Coding Dojo es una reunión abierta. Programadores, aprendices, interesados y curiosos, todos tienen un hueco. Abstenerse aquellos sin ganas de programar y divertirse haciéndolo.

Haremos la kata KataBankOCR, una kata que no hacemos desde hace un monton de tiempo y es muy divertida.

Para hacernos una idea de cuántos seremos, mandad un e-mail a xavi@becodemyfriend.com confirmando vuestra asistencia. Y si tenéis alguna duda o sugerencia, poneos también en contacto con nosotros en el mismo mail.

Recordad, el día 30 de enero a las 18:30 en La Cueva. Os esperamos no faltará la bebida, el buen ambiente y la discusión sana.

Cinco semanas de Carretera y manta

Ya ha pasado más de un mes desde que llegamos de nuestra aventura en la carretera. Ahora tenemos una mejor perspectiva de qué hicimos, porqué lo hicimos y de para qué nos ha servido.

Ha sido un ejercicio duro. Intenso tanto física como mentalmente. Cada día dormíamos en un sitio diferente, comíamos lo primero que pillábamos y conducíamos largas distancias. Afrontamos nuevos retos, dimos cursos y charlas, e intercambiamos impresiones con un montón de gente que nos hizo reflexionar y cuestionar muchas de las cosas que nos han modelado en los últimos años.

Cada uno de nosotros tiene sus propias conclusiones del viaje, pero los tres coincidimos en que el tiempo compartido con quienes hemos visitado y quienes hemos conocido ha sido lo más valioso y satisfactorio. Han sido Cinco semanas de Carretera y manta que inmortalizamos en nuestra memoria con sus alegrías y sus penas, con los sitios que visitamos y las personicas con quien estuvimos, con los días de trabajo y los de juerga… Todo ello hace que lo que vivimos en octubre marque un antes y un después.

Hemos barajado la opción de hacer una crónica… Empecé a escribirla, pero sólo había rememorado cinco días y… ¡ya llevaba dos páginas escritas! Iba a ser un buen ladrillaco.

Será mucho más auténtico recordarlo cuando volvamos a estar con vosotros en la barra del bar, cuando vengáis a Valencia u os visitemos de nuevo, en el AOS el año que viene o cuando le contéis a alguien que tres taraos rodaron 4.500 km. por España en un mes haciendo el ganso.

Fue a nosotros a quienes se nos fue la olla y nos lanzamos al asfalto, pero sin vuestra hospitalidad y apoyo no hubiese tenido ningún sentido. ¡Muchas gracias a todos!

A la Rosa y l’Amadeu por sus cenas en Miravet,

a @zigiella y @jaumejornet por estar siempre metidos en líos,

a @CarlosTheSailor porque sí,

a @jgomezz por sacarnos a cenar y comer por ahí,

a @Toni_Campos_85 por entendernos,

a @merybere porque nos comimos todas las papas que había en su casa,

a @dani_latorre y @mike_tnt por sacarnos de bares y recoger los pedazos,

a @LauraLacarra por el cachirulo,

a @pablojimeno por aguantar a los tres anteriores,

a @diegocenzano por abrirnos las puertas de @biko2,

a @biko2 por ser tan pamplonicas,

a @ujue y @sharpbites por hacernos sentir como en casa,

a @atostarra por el patxaran,

a @cramtirolf por ser un exaltado,

a @jrhuerta por (no) invitarnos a chuletón,

a @CarlosTheSailor (otra vez) y @tolivern por querer ponernos una furgo nueva para acabar el viaje,

a Juan el taxista por traernos de vuelta a Valencia desde Bilbao,

a @lounaticalou por dejarnos su bólido,

a @elmendalerenda por sus “Zas! En toda la boca!”,

a @marinavidiago por apostar por lo local,

a @DanielCoontigo por descubrirnos Somiedo,

a @pepellou por acompañarnos un rato,

a @amaliahern, @semurat y @minisemurat por cuidarnos,

a @jezis y @execyl por recibirnos siempre con los brazos abiertos,

a @gogomca por querer que pasásemos por su tierra a toda costa,

a @raultm y @kmur48 por hacernos sentir parte de sus familias,

a @robermorales, @robergd y el resto del comando extremeño por ser tan auténticos,

a @markitosco porque es todo corazón,

a @agileando por confiar en nosotros,

a @pasku1 por no dejar de sorprendernos,

P.S.: Seguro que a alguien me dejo… :-/

Refactorizando una estructura if-else

Hace unos días dediqué un rato a programar junto con Xavi en una sesión de refactor para mejorar una pieza de código similar a la que expondré a lo largo de post. La idea principal era sustituir una estructura if-else por algo más legible, mantenible, elegante y más alineado con los principios SOLID. El entramado de if-else al que nos enfrentábamos era más grande que el que expongo, lo cual hacía la necesidad de refactor aún más latente.

Digamos que tenemos una estructura parecida a esta:

En función de ciertas condiciones sobre “item1″ e “item2″ se devolvía un procesador que realizaría determinadas operaciones sobre ellos. Además algún procesador necesitaba de “collaborator” para sus operaciones.

Pues bien, en primer lugar lo que hicimos fue “aplanar” la estructura if-else para que tuviese solo un nivel y que fuese más fácil de seguir el flujo de condiciones y resultados.

Además vimos que no era necesaria la parte de los else ya que si cada condición se cumplía se hacía return. Así que también lo eliminamos.

En este momento la idea fué eliminar la cadena de ifs construyendo una serie de objectos que encapsulasen la lógica de conocer si se cumplen ciertas condiciones sobre los parámetros de entrada y saber el procesador concreto a devolver. Todos implementarán una interfaz de manera que podamos agruparlos en una estructura que se pueda recorrer buscando el procesador concreto en función de los parámetros. Empezamos con la primera rama de if. En ella vemos que no se necesita item2, pero lo pasamos de todos modos para cumplir con la interfaz Creator.

La idea es que la factoría de procesadores contenga un conjunto de objectos que conozcan la condición necesario para devolver un procesador concreto. De esa manera el método getConcreteProcessor recorrerá dicha lista hasta encontrar el primer objecto que le devuelva un procesador.
Continuamos con el resto de condiciones y procesadores.

En este punto hay que resaltar un par de asuntos. Uno de ellos es que necesitamos pasar al ConcreteProcessor3Creator el parámetro “collaborator” a pesar de que no se utiliza, pero lo hacemos para que pueda cumplir la interfaz. Es un mal menor y probablemente señal de que todavía se podría iterar más sobre este código para ver de dónde surge esta necesidad. Por otro lado, hemos introducido algo de duplicación al tener el método “condition1″ en dos clases anónimas diferentes. Así que dándole otra vuelta más vimos que podríamos crear un objeto que englobase Item1 e Item2, ya que parece que son dos objetos que van bastante unidos en este flujo. De esta manera además de reducir el número de parámetros podemos agrupar todos los métodos “condition” dentro de esa especie de “wrapper”.

De esta manera hemos englobado toda la lógica que tiene que ver con condiciones sobre los objetos “item1″ e “item2″ en una sóla clase y hemos eliminado la duplicación del método “condition1″. Además, por último, el método “getConcreteProcessor” sería llamado directamente con el objeto “extendedItem” ya construido. Un parámetro menos.

Ahora toca reflexionar. Recuerdo que le preguntaba a Xavi “y de verdad merece la pena todo ‘este pitote’ para deshacernos de un if?”. La respuesta, por supuesto, era que sí. Sobre todo porque nuestro if era más grande y con posibilidades de crecer aún más.
- Hemos distribuido mejor las responsabilidades, el código está mucho más limpio y es más fácil de entender.
- Se pueden añadir otros procesadores en base a otras condiciones de manera más sencilla, sin necesidad de extender aún más la estructura if-else.
- El método “getConcreteProcessor” es mucho más pequeño y ya no necesita conocer nada sobre las clases Item1 e Item2 ni sobre condiciones que aplican sobre ellas.

Otra de mis preguntas era si debíamos sacar cada una de esas inner clases a sus propios ficheros, siendo la respuesta que no, ya que están directamente ligadas a la propia factoría.

Casi se me olvida! Esto es muy “de Xavi”! Invertir las condiciones en los creator para que quede más en modo cláusula de guarda cuando no haya que devolver procesador.

Coding dojo 7 de Noviembre

Coding Dojo beCode en Valencia

beCode y VlcTechHub convocan a todos los interesados al próximo Coding Dojo. Se trata de una reunión entre programadores para trabajar conjuntamente resolviendo problemas, y así aprender los unos de los otros.

Empezaremos a las 18:30 h, la idea es dedicar dos slots de 45 minutos a la kata y luego uno a comentar la jugada, así que durará más o menos hasta las 20:30 h.

Recordad que el Coding Dojo es una reunión abierta. Programadores, aprendices, interesados y curiosos, todos tienen un hueco. Abstenerse aquellos sin ganas de programar y divertirse haciéndolo.

Haremos la kata KataTennis, una kata sencilla pero que nos dará juego para reforzar el TDD y usar varias aproximaciones.

Para hacernos una idea de cuántos seremos, mandad un e-mail a sergi@becodemyfriend.com confirmando vuestra asistencia. Y si tenéis alguna duda o sugerencia, poneos también en contacto con nosotros en el mismo mail.

Recordad, el día 7 de noviembre a las 18:30 en La Cueva. Os esperamos no faltará la bebida, el buen ambiente y la discusión sana.

Curso Design Patterns Madrid 31 Octubre

Para esta edición de nuestro  ’Curso de desarrollo ágil‘  tuve que preparar un módulo sobre ‘Design Patterns’ y llegué a algunas conclusiones.

La primera es que el libro, con perdón del GoF, es una castaña importante. Demasiado académico, con ejemplos muy particulares, difícil de leer y de entender.

La segunda es que aunque todo el mundo parece conocer los patrones, la realidad es que sólo se conocen unos pocos y no demasiado bien.

La tercera es que resulta incluso peor que se conozcan porque casi siempre es a través de las implementaciones más o menos folclóricas que pueblan los distintos frameworks de desarrollo.

Dicho esto, esta es mi propuesta:

Un curso de 5 horas el día 31 de Octubre de 15 a 20 horas. En “La nave nodriza” para mas señas.

El curso NO LO PUEDES PAGAR CON DINERO.

Puedes hacerme un trueque, estamos en pleno Carretera y Manta y buscamos donde dormir a nuestro paso por Madrid, tambien puedes ofrecerte a colaborar en alguno de nuestros proyectos un numero de horas (minimo 8 pomodoros). Los hay de caracter social como WikiWheeelChair o software OpenSource como este.

No es razonable esperar salir de un curso de 5 horas sabiendo aplicar patrones, ese no es el objetivo. Os contaré cómo yo los aplico y en qué escenarios, analizaremos posibles usos y abundaremos en algunos que son ninguneados tradicionalmente y pasaremos por encima alguno de los mas populares.

Tras el curso se abrirá una comunidad en Google+ para que podáis plantear más preguntas, solicitar información y recursos, postear código de implementación, recibir feedback… Es algo que estamos haciendo en todos nuestros cursos y que da muy buen resultado.

Hay solo 10 plazas disponibles. Para apuntarse escribidme a xavi@becodemyfriend.com y os enviare instrucciones .Salud!!

Curso de Design Patterns en Zaragoza 2 Octubre

Para esta edición de nuestro  ’Curso de desarrollo ágil‘  tuve que preparar un módulo sobre ‘Design Patterns’ y llegué a algunas conclusiones.

La primera es que el libro, con perdón del GoF, es una castaña importante. Demasiado académico, con ejemplos muy particulares, difícil de leer y de entender.

La segunda es que aunque todo el mundo parece conocer los patrones, la realidad es que sólo se conocen unos pocos y no demasiado bien.

La tercera es que resulta incluso peor que se conozcan porque casi siempre es a través de las implementaciones más o menos folclóricas que pueblan los distintos frameworks de desarrollo.

Dicho esto, esta es mi propuesta:

Un curso de 5 horas el día 2 de Octubre de 15 a 20 horas. En BSSC ZARAGOZA para mas señas.

El curso cuesta 60 Euros.

Puedes hacerme un trueque, estamos en pleno Carretera y Manta y buscamos donde dormir a nuestro paso por Zaragoza, tambien puedes ofrecerte a hacer servicios comunitarios, o a colaborar en alguno de nuestros proyectos.

No es razonable esperar salir de un curso de 5 horas sabiendo aplicar patrones, ese no es el objetivo. Os contaré cómo yo los aplico y en qué escenarios, analizaremos posibles usos y abundaremos en algunos que son ninguneados tradicionalmente y pasaremos por encima alguno de los mas populares.

Tras el curso se abrirá una comunidad en Google+ para que podáis plantear más preguntas, solicitar información y recursos, postear código de implementación, recibir feedback… Es algo que estamos haciendo en todos nuestros cursos y que da muy buen resultado.

Hay 15 plazas disponibles. Para apuntarse escribidme a xavi@becodemyfriend.com y os enviare instrucciones de pago.

Si alguien quiere ir al curso y no puede pagarlo (por el motivo que sea) que me escriba y encontraremos la forma de arreglarlo con un trueque de algún tipo.

Salud!!

Curso Refactoring en Barcelona días 30 septiembre y 1 octubre

Para esta edición de nuestro “Curso de desarrollo ágil”  tuve que preparar un módulo sobre “Refactoring”. Ya he realizado este curso en varios formatos, tanto presenciales como online y este verano en Miravet lo usamos para refinar nuestra técnica de Story mapping y encontramos el que creo es el mejor formato.

El próximo día 28 de octubre comienza nuestro “Carretera y manta” y la primera parada es Barcelona y es una estupenda oportunidad para probarlo.

Dicho esto, esta es mi propuesta:

Un curso de 8 horas dividido en las tardes del día 30 de septiembre y 1 de octubre. Todavía no tengo cerrada el aula, pero será en algún sitio céntrico y con metro.

El curso cuesta 130 € y sólo voy a sacar 10 plazas.

No es razonable esperar salir de un curso de 8 horas convertido en un “joven dios del refactoring”, no es ese el objetivo. El curso consta de una parte teórica donde analizamos qué es y porqué hacerlo, después repasaremos los principales olores en el código y os daré algunos pequeños trucos sobre cómo detectarlos y tratarlos. En la siguiente sesión, más practica, veremos una selección de los patrones de refactoring más comunes y útiles y haremos algunos ejercicios en Javascript.

Tras el curso se abrirá una comunidad en Google+ para que podáis plantear más preguntas, solicitar información y recursos, postear código de implementación, recibir feedback… Es algo que estamos haciendo en todos nuestros cursos y que da muy buen resultado.

Hay 10 plazas disponibles. Para apuntarse escribidme a xavi@becodemyfriend.com y os enviaré instrucciones de pago.

Aunque hay 10 plazas disponibles, me reservo 5 plazas para que pueda asistir quien no pueda pagar el curso. Escribidme y lo apañamos ;)

Salud!!

Coding dojo 25 de Septiembre

Coding Dojo beCode en Valencia

beCode y VlcTechHub convocan a todos los interesados al próximo Coding Dojo. Se trata de una reunión entre programadores para trabajar conjuntamente resolviendo problemas, y así aprender los unos de los otros.

Empezaremos a las 18:30 h, la idea es dedicar dos slots de 45 minutos a la kata y luego uno a comentar la jugada, así que durará más o menos hasta las 20:30 h.

Recordad que el Coding Dojo es una reunión abierta. Programadores, aprendices, interesados y curiosos, todos tienen un hueco. Abstenerse aquellos sin ganas de programar y divertirse haciéndolo.

Haremos la kata Poker Hands, una kata sencilla pero que nos dará juego para reforzar el TDD y usar varias aproximaciones.

Para hacernos una idea de cuántos seremos, mandad un e-mail a sergi@becodemyfriend.com confirmando vuestra asistencia. Y si tenéis alguna duda o sugerencia, poneos también en contacto con nosotros en el mismo mail.

Recordad, el día 25 de Septiembre a las 18:30 en La Cueva. Os esperamos no faltará la bebida, el buen ambiente y la discusión sana.

Impact mapping con Pablo Jimeno en Miravet

Nuestros últimos invitados en Miravet fueron un par de maños. Bueno, en realidad uno y medio. @dani_latorre y @pablojimeno se dejaron caer por allí en nuestros últimos días de retiro. Entre cerveza y cerveza, mucha conversación y alguna que otra bajada al bar de l’Amadeu, aún sacamos un rato para que Pablo nos explicase qué es eso de Impact mapping.

Desde que sabemos de la existencia de Impact mapping, nos parece muy interesante. Nos ayuda a definir las acciones para alcanzar un objetivo buscando la respuesta a cuatro preguntas:

¿Por qué?

Es el objetivo factible y orientado a negocio que queremos alcanzar. Definirlo no es fácil y ha de estar fundamentado. Para ello, buscamos que sea un objetivo SMART, es decir, Specific, Measurable, Achievable, Realistic & Timeboxed. A partir de aquí planteamos todos los posibles caminos para alcanzarlo y elegimos el más corto, el menos costoso o el que más nos convenga en ese momento. Hay que tener en cuenta que, muchas veces, este objetivo es una hipótesis a comprobar y cuanto antes o más barato la comprobemos, mejor.

¿Quién?

Son los actores que pueden influenciar el resultado; que alcancemos o no nuestro objetivo. Hay varios tipos de actores. Desde los directamente implicados, como las personas que desarrollan el producto o quienes obtienen un valor de él, hasta agentes externos como proveedores de servicios, aliados estratégicos o quienes se benefician indirectamente de nuestra actividad. También hay varios niveles de definición de estos actores que van de más a menos específico.

¿Cómo?

Son los impactos que queremos crear. Cómo un actor podría contribuir a alcanzar el objetivo o a alejarse de él dependiendo de la forma en que interactúa con nuestro producto. Teniendo en cuenta que sólo nos interesan los impactos que nos llevan directamente a alcanzar nuestro objetivo y que además están alineados con el negocio.

¿Qué?

Nuestras acciones. Todo aquello que podemos hacer para crear los impactos sobre los actores para alcanzar el objetivo inicial. Desde aquí podemos recorrer el mapa hacia arriba y ver qué debemos hacer para llegar a ese porqué, pasando por quién está implicado y cómo nos va a ayudar.

Impact mapping poster

Es una técnica sencilla que da resultados inmediatos. Simplemente hay que seguir las consideraciones del libro, ser críticos durante el proceso y tener claro que NO estamos descubriendo producto, sino planificando y definiendo un roadmap.

Impact mapping con Pablo Jimeno en Miravet

Algo que nos gusta mucho de Gojko Adzic, el “creador” de Impact mapping, es que no pretende cubrir con su técnica todo el espectro de la definición y desarrollo de un producto. Asume que esto es planificación estratégica y no sale de su parcela. Al final, esta técnica combinada con otras como Story mapping, User stories o Inception es lo que nos permite llevar un producto a buen puerto.

Durante nuestro viaje intentaremos facilitar algunas sesiones de Impact mapping y así ayudar a alcanzar objetivos. Es una exploración que viene bien si estás estancado en algún área, para probar un nuevo modelo de negocio o captar un nuevo público, para consolidar y enfocar un equipo sobre sus objetivos y los del negocio

Podéis seguir leyendo sobre Impact mapping en su web o comprar el libro también desde allí. Nosotros seguiremos investigando, usándolo y contando las conclusiones.

Muchas gracias a @pablojimeno por su paciencia ;)