Equipo sin palabras
El beneficio de la duda puede ser un camino a la confianza.
Disfrutar de tu trabajo no es sólo disfrutar con la técnica, tampoco el aplicar metodologías que crees que son prácticas para conseguir un fin.
Ya comenté en un post la importancia de las personas en el agilismo, pero no siempre hemos tratado de ser ágiles. Por la razón que sea hemos descubierto una manera diferente de hacer las cosas, que nos ha motivado a provocar el cambio en organizaciones, en actitudes personales, en busca de la mejora y la excelencia.
Antes de la llegada de "agile", cuando teníamos que trabajar en un equipo y no conocíamos otra forma de hacerlo que waterfall trabajar con personas siempre ha tenido su importancia. Motivar a un grupo para convertirlo en un equipo siempre ha sido el objetivo de cualquier gestor o responsable de equipo que se precie. No nos olvidemos que vamos a trabajar, no a pasar la jornada en un ambiente marcial. Trabajas con un objetivo que complementa al objetivo de la empresa a la que prestas servicio, beneficio.
Para mi una de las grandes diferencias en el cambio es la forma da abordar cualquier problema. Entre mandar y acatar contra debatirlo y solucionarlo. Te hace sentir libre en tu trabajo, te hace sentir más partícipe de solución y fomentas la creatividad colectiva para resolver cualquier cosa. Al final, vuelvo al principio. Las personas y su actitud.
Puede ser más fácil evadir un problema que encararlo para solucionarlo. Claro, puede suponer un esfuerzo emocional que no todos pueden estar interesados en aceptar. Todo lo que se evita, seguirá estando ahí.
La autogestión puede ser una utopía para el líder de un equipo que prefiere obedecer ante colaborar.
Construir un equipo ante trabajar con un grupo de personas no es algo que dependa exclusivamente de una metodología, aunque en el agilismo se le de un valor significativo. Todo equipo pasa por una serie de dificultades, ya que al principio es un conjunto de personas con un objetivo. Sólo la forma de resolver las dificultades condiciona la construcción de un equipo y los resultados de su objetivo.
Siempre hablamos de equipos, de personas tal vez en algunos casos dando a entender que construir equipo es más importante que el objetivo que tiene un grupo de personas. Pero tenemos que dar por hecho que sin objetivo no existiría ninguna de las dos, ni grupo ni equipo. Otra cosa es que en el camino de conseguir el objetivo construyamos un equipo para que en el siguiente objetivo notemos una mejora sustancial, no sólo económica si no de estabilidad emocional y con la satisfacción de haber hecho las cosas mejor.
La satisfacción por los resultados de nuestro trabajo es la motivación que nos ayuda a buscar la mejora.
Objetivos 2012
Comenzamos el año con nuevos objetivos, tras haber repasado los del año anterior.
Proyectos personales
Symfony2 para mi es una revelación en PHP, así que estoy reescribiendo parte del código que tenía hecho en su versión anterior e intentando darle un giro a algunas ideas que tenía en mente para ambos proyectos, arreglamicarretera.com y gentebinaria.com.
De estos dos, por ahora el proyecto prioritario es del de arreglamicarretera.com que es el que más tiempo lleva en el TODO. Aunque tal y como han ido estos últimos meses creo que tendré una primera versión en breve.
Técnicas de desarrollo y artesanía del software
Clean Code, libro que he estado leyendo a capítulos sueltos. Antes de terminarlo, volver a repasar esos capítulos que me han parecido interesantes.
Java, seguir profundizando en este lenguaje que me ha fascinado.
Groovy, estoy participando en un proyecto colaborativo en este lenguaje. Tengo que poder sacar algo de tiempo par involucrarme más.
COBOL, si... lenguaje del pleistoceno fosilizado con actividad importante en transacciones bancarias 
Investigando por internet vi que había un framework de test para este lenguaje, algo probé, pero este año en estos 12 meses, estoy seguro que coincidiré con @jbeerdev y una kata en COBOL habrá que hacer. Todavía pongo de moda los lenguajes "retro" ^_^
XP, terminar el libro de Extreme Programming Installed para poder continuar con Extreme Programming Explained.
Las personas
Tener compañeros que llevan más tiempo que yo en esto del agilismo ayuda a perfilar el siguiente movimiento en el aprendizaje de este mundillo. @joserra_diaz es un buen compañero al que estimo, y el que en estos meses estoy "utilizando" en parte para que me guíe en este aprendizaje continuo.
@iturriozbeitia, @blas_i, @joserra_diaz, @olatzZamora, @sjimenezmateo, @jessi_aguado, @salorino trabajar con ellos ha sido una experiencia inolvidable. Las personas, que estén alineadas en una visión de mejora continua, no sólo trabaja la técnica, si no el espíritu de equipo. Por muy alineado que esté un equipo, siempre hay una posible mejora. La excelencia, se consigue trabajando con personas.
Agile retrospectives, creo que llego tarde a leer este libro, pero ya lo tengo entre manos.
Comunidad ágil
Open Space de clientes de software, Es una idea que llevo rumiando hace ya unos meses. A algunos de vosotros ya os la he comentado y estoy elavorando una propuesta para ver si consigo que se encuentre en un estado lo suficiente maduro para que alguien me haga caso, así que si quieres participar en ello y/o tienes alguna idea/sugerencia no dudes en ponerte en contacto conmigo.
Katayunos/Merendojos/Saraos, este año es el año de... participar en todo sarao que se ponga a tiro y exista disponibilidad para ello.
CodeRetreat, un code retreat al año no hace daño... asistir a uno de estos eventos ayuda a ver lo que has podido avanzar y/o progresar en el objetivo de mejorar tu técnica. Más de uno al año, puede ser duro ^_^
Otros
Otros pero no menos importantes:
Deporte para no fumar, sustituir la nicotina por endorfinas. La mejor técnica para dejar de fumar. Siempre que hago deporte siempre dejo el tabaco, lo malo... que cuando dejo el deporte el tabaco vuelve O_o! tendré que conseguir hacer deporte con mayor continuidad.
Atender más el blog, bloguear con más frecuencia. Este año pasado, ha sido el año que menos he publicado, así que a nada que me esfuerce ya mejoraré la frecuencia de publicación con respecto al año anterior.
A veces nos centramos tanto en aprender, en investigar que no nos damos cuenta que estamos "penalizado" el tiempo con nuestra familia. Este año, la prioridad será la familia sobre todo lo demás.
Repaso objetivos 2011
Siguiendo la tónica de estas fechas toca repasar los objetivos planteados el año pasado y comentar los que deseo perseguir este nuevo año 2012. En general el 2011 ha sido un año muy satisfactorio, donde he podido crecer como persona y como profesional.
Comencemos con el repaso del 2011
arreglamicarretera.com y gentebinaria.com
Este año ha sido tan ajetreado que esos proyectos personales que uno tiene en mente de abordarlos lo antes posible siguen estando en el TODO. Arreglamicarretera.com y GenteBinaria.com son proyectos que están en la cola que no tienen que caer en el baúl de los recuerdos. A veces es difícil dedicar tiempo para lanzar un proyecto cuando tienes la imperiosa necesidad de probar y aprender cosas nuevas, no siempre nos da el tiempo para todo. Suena a excusa lo se.
Así que estos objetivos para el 2011 no se cumplieron, aunque todos están empezados.
Técnicas de desarrollo y artesanía del software
En este punto, hablaba el año pasado de lo que me apasionó el descubrir técnicas de desarrollo que me motivaban a programar de mejor y disfrutando de ello. Y hacía mención a "Esto funciona señores, no es sólo teoría" y es cierto. Este año ha sido el año en el que se ha formado comunidad en la zona norte. Un año de compartir conocimiento y conocer gente afín a tu punto de vista hacia la profesión de informático loco que escribe cosas raras en la pantalla. El empuje y las ganas de todo el mundo de la comunidad de la zona empujaba y fomentaba el auto-aprendizaje para su divulgación y así fomentar la mejora continua entre los miembros que habitualmente nos solemos reunir.
No sólo eso, si no que estas técnicas que todo el mundo aprovechaba su tiempo libre para practicarlas con la intención de conocerlas y algún día poder aplicarlas en el trabajo, han ido calando y quien más y quien menos a lo largo del año ha ido dando un giro a su vida laboral en donde lo que era la "afición" se convertía en "profesión". Disfrutar trabajando, el mejor de los objetivos que creo que dentro de la comunidad que se ha formado en la zona norte se ha ido consiguiendo en conjunto y de forma individual.
Tecnologías
Vuelvo a empezar con "Soy LAMPero de vocación", aunque me encanta poder trabajar en otras tecnologías, PHP siempre tendrá un rincón en mi corazoncito tecnológico. Me gusta PHP pero sintácticamente es algo anticuado y dificil de escribir en compración con otros lenguajes que bien por su sintaxis o por los IDE's con los que se trabaja es mucho más práctico y cómodo desarrollar. Este año se publicó Symfony2 y desde entonces estoy probando este framework de desarrollo del cual estoy muy contento que exista algo tan interesante en esta tecnología que aporte tanto valor al programador.
Java, al que siempre le ponía ojitos, ese lenguaje con el que aprendí OOP ese lenguaje que siempre me pareció un referente... por fin no sólo no ha sido sólo un lenguaje con el que me gustaba practicar de vez en cuando. He tenido la posibilidad de poder estar en un equipo de trabajo de esta tecnología en el que he participado en un par de proyectos que me ha ayudado a disfrutar de él. No sólo eso, si no que también me ha hecho ver que la tecnología nunca es la barrera. Lo mejor del 2011, el trabajar con este lenguaje al que algunos programadores le tienen tirria, pero eso es porque todavía no han tenido que trabajar con PHP
Android SDK, este año poco he podido jugar con él. Aunque ha evolucionado mucho desde que comencé a trastear con android, pero me siento mucho más cómodo trabajando en un entorno java, así que este año tendré que recuperar un poco el poder trastear con este SDK.
Groovy, oooh si! groovy. He podido invertir tiempo lo suficiente, como para poder decir que no me importaría abordar un proyecto con esta tecnología. Aunque haya descubierto que me gusta mucho más mockito que la forma de testear en groovy.
Ruby, este lenguaje es una gozada. En vez de programar, es como escribir lo que quieres que haga ^_^, no he invertido el tiempo suficiente para poder probarlo de forma autónoma pero siempre que he tenido la posibilidad de verlo así lo he hecho, gracias a poder practicar pair en coderetreat/dojos/katayunos y con compañeros y amigos. No deja de sorprenderme, aunque no tengo claro hasta donde se puede llegar con él.
Python, sigue siendo por ahora una declaración de buenas intenciones. Este año no he practicado nada con Python.
COBOL, curiosamente este lenguaje ha salido de la chistera! La mujer trabaja con COBOL, y cuando hablamos de trabajo me gusta entender lo que me cuenta cuando habla de tecnología, así que poco a poco he ido aprendiendo y técnicamente alguna prueba ya hemos ido haciendo. Tengo una buena profesora ^_^. No me gustan los GO TO, me recuerdan a Clipper... Pendiente queda hacer una kata con COBOL en un reto que nos propusimos @jbeerdev en una desvariada conversación por twitter.
Resumen
He disfrutado mucho de la tecnología a lo largo del 2011, me ha divertido mucho aprender, probar y sobre todo practicar. Pero algo que nos pierde a los que tenemos formación técnica, es precisamente eso... la técnica. Este año, mientras mi preocupación era la tecnología me he ido dando cuenta que también he aprendido y le he dado más importancia a trabajar mejor con las personas. La técnica y las metodologías son importantes, pero sin personas que creen en ellas y las apliquen no sirven para nada. Ya no somos nuevos en el mundo laboral, y todos sabemos la importancia que tiene trabajar con personas, pero lo que he podido experimentar este año en uno de los equipos del cual he formado parte ha sido muy revelador, lo que me ha hecho crecer más como persona y profesional.
2011, color favorito: Azul, motivación: Ser feliz.
Objetivos
Finalmente no he participado en la organización del 2º CodeRetreat Donosti, pero si en la multitud de katayunos.com que se han ido haciendo a lo largo del año. Considero que este objetivo de organizar evento para mejorar nuestra técnica se ha visto cumplido.
AgileSpain, asistir al Agile Open Space, este año ha sido fácil. Aunque repita este año y los siguientes, este fue verdaderamente especial. Lástima ha sido no poder asistir este año a la CAS, objetivo para este año ^_^.
PHPConference, no fue posible. La prioridad de tecnología cambió a lo largo del año.
Idioma, ya puedo decir que me he leído más de un libro en inglés. No sólo eso, también lo he entendido me siento más cómodo con la lectura en este idioma. La mejora en este idioma me ha sido verificada cuando en unas vacaciones a Londres tuve que lidiar con el idioma, así que objetivo cumplido y en curso.
TDD, practicar, practicar y más practicar. Practicar en katas y por supuesto en el trabajo. Cuanto más tiempo se invierte, más te das cuenta de que hay que seguir aprendiendo y pracicando.
XP, este tipo de prácticas ya forman parte de mi manera de ver e intentar afrontar las tareas.
Retrospectivas, ya no son sólo pluses y deltas. El objetivo no es sólo hablar de lo ocurrido en la iteración. Este tipo de reuniones son las que aporta valor al proyecto, al equipo y a la persona. Es la reunión más importante en la que más conclusiones podemos obtener para mejorar, una buena retrospectiva ayuda y fomenta la mejora continua.
Deporte, claro! el reto de todos los años! como no va a faltar este! si si, este año también he practicado deporte. Unos 4 meses de deporte, hasta que llegó el otoño/invierno. MTB, mi último deporte de "chaval" y el que me ayuda a poder disfrutar de un buen descanso nocturno.
Topicos: todos, todos los he cumplido durante un periodo de tiempo en este pasado año, aunque no lo suficiente tiempo para que duraran todo el año.
Anexo
A lo largo del año he ido conociendo a mucha gente, bien en eventos o por twitter y en algunos de los eventos desvirtualizando a gente que sigo por twitter. De todos he aprendido, y me alegro de conocer a gente que comparte la misma visión de la profesión. Lamentablemente la memoria no es una de mis virtudes ^_^, así que me resultará difícil poder mencionar a todos. Pero tu lector que has llegado hasta aquí, y si me has conocido este año, da por hecho que me has aportado valor y lo seguirás haciendo ya que compartimos una visión muy alineada de nuestro sector y en el 2012 seguro que volveremos a vernos.
La importancia de las personas en el agilismo
El agilismo es algo que está renaciendo con fuerza y contagiando a la mayoría de esas personas que desean mejorar su forma de trabajar. Pero mucho se habla de las metodologías y técnicas que nos ayudan a afrontar este reto de transformar nuestra vieja forma de desarrollar software, para que nuestra entrega de software sea mejor y conseguir que el cliente realmente adquiera software que le sea de utilidad para su negocio.
En nuestra mano está el utilizar: Scrum, Kanban, "Scrumban", Extreme Programing... y técnicas de rendimiento personal como Pomodoros.
Para mi, lo más importante son las personas. Es cierto que estamos en un negocio, y lo más importante puede ser el producto que tiene que desarrollar el equipo, pero un equipo no comprometido, puede ser un equipo no productivo. Por lo tanto podríamos estar hablando de "la pescadilla que se muerde la cola" pero en este caso, primero tenemos que tener unas bases sólidas para poder afrontar retos y compromisos de manera segura, productiva y por lo tanto rentables.
La actitud de los miembros de un equipo lo vale todo para perseguir la mejora continua. La mejora personal, la excelencia técnica y rentabilidad. Cada uno de los miembros de un equipo tendrá sus virtudes y defectos. Pero la importancia de que sean capaces de mirarse el ombligo, opinar y aceptar opiniones es fundamental. Aquí pretendo mencionar los valores como personas: honestidad, humildad, madurez.
Honestidad, para poder decir lo que piensas.
Humildad, acepta lo que te digan, no siempre eres propietario de "la razón".
Madurez, analiza el porqué y aplica una solución.
Nada es tan importante en el uso de Scrum como la retrospectivas, donde las personas son las que deciden y trabajan el cambio.
El sumun del agilismo, personas que disfrutan de su trabajo. Personas que creen en lo que hacen. Personas que son capaces de probar cosas nuevas en busca de una mejora. Personas que creen en la mejora continua. Personas comprometidas. Personas...
Al final es una cuestión de actitud. Cuando la actitud es afín a todos los miembros de un equipo, este equipo comienza a obtener papeletas para convertirse en "El equipo ágil".
Ninguna cualidad técnica podrá sustituir una actitud de una persona.
Cuán difícil es conseguir un equipo con estas características. No todos nuestros compañeros de trabajo creen en la mejora continua, ni dedican su tiempo a mejorar para aportar en su trabajo, no todos tienen una profesión vocacional... Pero muchos aunque no crean en estos valores se pueden dejar llevar. Aunque sean escépticos, viendo los resultados pueden empezar a "creer".
Otras se dejan llevar y creen en que tendrán resultados. Y mientras tanto disfrutan en el camino para ser mejores profesionales.
"Todos enchufados, nos damos corriente!"
Aprendiendo a ser ágil
El camino para ser agilista está lleno de retos. El primer punto a tener en cuenta es el aprendizaje continuo y la predisposición a probar técnicas y métodos de trabajo diferentes para conseguir el mejor resultado. No recuerdo a quien le oí decir: "10 años haciendo lo mismo es 1 año de experiencia por 10", es como la famosa frase de "Si buscas resultados distintos, no hagas siempre lo mismo".
Utilizar scrum, kanban, TDD, XP... son técnicas que nos ayudan, pero no sólo aplicando las técnicas consigues ser ágil.
Lo que me ha parecido de muchísima importancia es pensar y mirar al cliente con otros ojos. El trabajo en cascada que obligaba a escudarse en acuerdos firmados de alcance y funcionalidad obligaba en parte a tener una actitud defensiva ante posibles cambios, al final es algo que nos va marcando en nuestra etapa profesional. El defender tu trabajo por encima de la necesidad del cliente, esto un error. Si no resuelves la necesidad del cliente, no tienes un cliente satisfecho.
Al final parece que en cualquier conversación sobre agile siempre salen "las palabras mágicas": Alcance, calidad, necesidad... Pero realmente es así.
La calidad no es negociable, pero ¿cuál es la calidad adecuada? La calidad percibida por el cliente, la calidad técnica... Yo entiendo que la calidad tiene que ajustarse para cada cliente y proyecto, pero en parte estaría incumpliendo con "la calidad no es negociable". ¿Tenemos que ser flexibles y adaptarnos?.
La necesidad de conocer el alcance de las historias antes de meterlas en el sprint es vital, el cambio de alcance en el transcurso de una iteración puede romper la sensación de avance. Pero ¿el Alcance puede variar en el transcurso de una iteración? ¿Hay que ser flexibles? ¿Tenemos que ser estrictos? A día de hoy, es una de las palabras que más me rondan la cabeza cuando pienso en Agile.
Pero no sólo el perseguir el cumplimiento de las técnicas y metodologías que nos ayudan a trabajar tiene que ser la única meta para ser ágil. En algún momento tenemos que cambiar el chip de lo que estamos haciendo, pensar en que estamos resolviendo necesidades del cliente y colaborar con él para que esté satisfecho con nuestro producto entregado. A veces nos pierde lo que nos gustaría hacer y no sabemos poner un "hasta aquí" cuando igual no estamos aportando valor al cliente.
Hay que trabajar más el cambio de mentalidad hacia el cliente, utilizar las técnicas y adaptarse a los cambios.
Aprender de la experiencia de los demás ayuda a no cometer los mismos errores. De la teoría a la práctica y la experiencia que ido obteniendo hace que ponga en duda como lo he estado haciendo hasta ahora. Debería leer más para resolver las dudas.
Desde luego, el camino está siendo divertido.
Coding Dojo Huesca
Bienaventurados los que kilómetros se comen para tirar unas líneas de código...
Cuando eventos en los que nos reunimos unos cuantos programadores para compartir experiencias y aprender unos de otros moviliza a personas de diferentes zonas geográficas, es que algo está pasando. Y desde luego la asistencia en el #codingdojohuesca así lo demuestra.
Este viernes 21 de Enero, @rubenbpv y yo nos movimos desde Pamplona a Huesca para asistir al #codingdojohuesca organizado por Frogtek con @carlosble.
Tras la 3.40h de trayecto llegamos justo a tiempo, gracias a google navigator 
aunque como no, como todo buen "viaje" perdimos 15 minutos al perdernos, momento en el que pusimos a funcionar el gps.
Bien, vamos al lío.
Antes de comenzar la primera iteración se tomó la decisión de que la primera pareja estuviera formada de manera que al menos uno hubiera practicado algo de TDD con anterioridad. La primera iteración fue la más larga, en donde aproveché para poner en marcha el entorno de PHP para el dojo. (tengo que llevar las cosas preparadas de casa, si no se pierde tiempo si hay problemas...)
Tuve el placer de compartir iteración con Manolo, Luis, David y Marco, las tres primeras las abordamos con PHP y la última con Java. En la primera iteración me costó centrarme en el foco del problema ya que no conocía muy bien la problemática a resolver. También me encontré en la situación de que teniendo poca experiencia con TDD, siendo novato y todavía aprendiz de la técnica, el explicar a mi compañero como utilizar TDD. Fue una pena que cuando por fin estábamos rodando se acabó la iteración.
Compartiendo iteraciones con desarrolladores java, les gustaba la facilidad de como resolver sintácticamente en php operaciones en que las que en java se tornaban algo espesas. No podía evitar pensar que siempre pongo ojitos a java cuando en php con POO no me permite hacer algo y me resultó grato el feedback de que veían a php con buenos ojos
La verdad, me gustaría volver a coincidir con estos desarrolladores en otros eventos para volver a tener la oportunidad de compartir una iteración una vez más, en especial con David que le debo una ^_^.
También tuvimos la oportunidad de ver a @carlosble en acción, un momento en que de repente el silencio invadió la sala y estábamos todos atónitos viendo como tiraba lineas de código en sus test rojo/verde adelante, siguiente refact... fue abrumador. Momento de "Super Programador", aunque no llevaba mallas ni la ropa interior por fuera y al finalizar nos desveló su secreto humildemente quitándose el antifaz.
Pero #codingdojohuesca tuvo más sorpresas! cuando @carlosble solicitó dos voluntarios "a dedo" (ya que nadie se animó) también fue impresionante el resultado. Los "voluntarios" @rubenbpv y @dani_latorre en un pair programing prácticamente mudo, apenas se les oía debatir como abordar una tarea parecían que estaban sincronizados. Fue un buen ejemplo de pair programing, hasta llegué a pensar que ya estaba preparado de lo bien que lo hicieron.
Pero esto no fue todo en #codingdojohuesca, también tuvimos una sesión de networking en una pausa para café, en donde pude conocer a los integrantes de Frogtek y charla de desvirtualización con @dani_latorre. Lamentablemente soy malo para los nombres, pero las charlas fueron interesantes.
Como todo evento que se precie, siempre existe un momento birras! y tras terminar el #codingdojohuesca unos pocos nos juntamos para charlar con unas birras en donde en un ambiente más distendido las charlas a nivel profesional y retos personales se cruzaban en la mesa. Claro está, al final no evitamos llegar a la cena.
Aunque al día siguiente @rubenbpv y yo teníamos que asistir al primer Katayuno en Donosti la noche se estiró y tras terminar la entrevista que @rubenbpv hizo a @carlosble convirtiendo al entrevistador en entrevistado para podgramando.es la noche terminó a las tantas de la madrugada, pero esto es otra historia...
Comenzando el 2011 persiguiendo objetivos + Mini-Balance 2010
Tras haber tenido abandonado el blog un par de meses volvemos a la carga, y como no hablando sobre los objetivos que intento perseguir para este año. Uno de los motivos de mi ausencia ha sido el nacimiento del proyecto de Gente Binaria, que aunque no ha consumido demasiado tiempo por ahora, si se ha llevado gran parte de mi poco tiempo libre. El cupo de proyectos personales están cerrados para el resto del año, junto con arreglamicarretera.com estaré bastante atareado.
arreglamicarretera.com
Es el proyecto con el que llevo más tiempo, y no precisamente por haber tirado infinitas lineas de código. Desde su creación hasta el día de hoy es una idea en la que creo y persigo fielmente. La dificultad de llevar a delante el proyecto no es necesariamente técnica, la implicación de diferentes entidades en él retrasan las decisiones. Es el proyecto que cuelga de mi pared, unos cuantos post-its con las tareas a realizar. Gracias a la experiencia profesional que he podido adquirir este último año intento Agilizar su desarrollo aplicando Scrum, pero por ahora me está siendo difícil seguir una planificación ya que muchas de las funcionalidades básicas hacen partícipes a los demás implicados con los que tengo que "negociar" y entender ciertos aspectos imprescindibles para la herramienta.
Aunque actualmente existe una versión publicada, no se aproxima demasiado a la que estoy desarrollando. Pero ya he aprendido la lección de "no esperar al producto final...", lanza lo que tengas y luego sigue trabajando!
Gente Binaria
Este proyecto es "cachondo", la creación de una comunidad de diferentes perfiles relacionados con la construcción de sitios web. Actualmente somos 11 miembros, y aunque tenemos un ligero parón por las fechas que acabamos de pasar hay mucha motivación por parte de todos. Las ganas de hacer las cosas bien e intentar ser un referente a la vez que fomentar el desarrollo de software libre es algo que nos inunda el teclado a la hora de colaborar en la lista de correo. Muchas de las decisiones que teníamos que ir tomando para ir arrancando ya han llegado a su fin, y cuando volvamos a retomar ya será para ir más a trapo que a la "palabrería"
Un proyecto con ideales, con referentes y con buenos profesionales de diferentes ubicaciones geográficas en ámbito nacional que estoy seguro que también será una buena oportunidad de aprender. No sólo en tocar nuevas tecnologías, si no que los compañeros que forman parte de esta recién nacida comunidad tendrán experiencias de las que seguro podré aprender de ellos y con ellos.
Técnicas de desarrollo y artesanía del software
Yeah! que bonito suena! Pero es cierto, antes de conocer este "rollo" de agilismo y de la artesanía del software siempre me he comparado con el artesano que construye cestas de mimbre. Persigue un buen acabado y fiabilidad. Algunos dicen que trabajamos con las manos, otros con la cabeza... o más bien a cabezazos! pero si te gusta la programación y llevas un tiempo trabajando en ello hay muchas cosas que se repiten, que te encabronan.... y sin querer buscarlo encuentras un movimiento!!! un movimiento de personas afines que tienen el mismo interés. Disfrutar de su trabajo mejorando la calidad y productividad.
Es cierto que mi entorno laboral afortunadamente es favorable para esta situación. Aprender a ser más ágil y productivo, utilizando para ello técnicas que para muchas otras entidades son "frikis". Esto funciona señores, no es sólo teoría!
Tras perseguir a @carlosble casi todo el año, al final en Noviembre pude estar en su curso de TDD, con el que acabé comprendiendo muchas cosas que mis compañeros que estuvieron en uno a principios de año intentaban aplicar y no lo acababa de ver claro. TDD hace que la programación sea más divertida. En el curso te lo pasas genial, sólo tienes pensamientos positivos hacia ello pero sólo hasta que te sientas por tu cuenta a practicarlo y WTF estoy bloquedo por donde tengo que continuar! Aplicar TDD no es sólo intentar seguir esas "reglas" hay que ir obteniendo experiencia e ir rodando.
Aprovechando que el curso de TDD fue antes que el #coderetreat de Donosti, me anime a asistir. Primera idea que se me pasó por la cabeza: "Puff... soy un paquete y me voy a juntar con gente que tiene más experiencia que yo..." si, fue cierto! pero así aprendes. Me iluminó un poco la experiencia, el conocer estas cosas hacen que uno se motive. En el #coderetreat tuve la oportunidad de desvirtualizar a @jmbeas @ecomba @kinisoftware @programania, conocer a más gente y como no... encontrarme con habituales ^_^
Cuanta más gente voy conociendo afín a esto, me doy cuenta que tengo mucho por aprender y la verdad... me gusta! Que sería de esta nuestra profesión sin la mejora y aprendizaje continuo.
Tecnologías
Tanto con que jugar y tan poco tiempo para practicar . Soy LAMPero de vocación, pero la tecnología no es algo que me frene a mirar al monitor de al lado. He trabajado con otros lenguajes, al final es tanto de lo mismo con las particularidades que pueda tener cada tecnología. A veces tengo esa sensación de estar hasta el gorro de trabajar con LAMP y al poco lo retomo con más ganas para intentar mejorar este lado oscuro. Cada vez veo más lejos que vuelva a tocar tecnología de M$ la verdad es que me siento muy cómodo con esos lenguajes "raros".
Este año me gustaría poder aprender:
- Java, profundizar más.
- Android SDK
- Groovy
- Ruby
- Python
Tal vez asistiendo a más #coderetreat o haciendo #katayunos pueda ir entrando poco a poco en esas diferentes tecnologías. Algunos pensarán... para que tantos lenguajes menudo follón... bueno, creo que si que lo es pero... Te gusta conducir? tienes un coche pero cuando tienes la oportunidad de conducir uno diferente lo haces, verdad? pues a mi me pasa lo mismo pero con la programación! Pero si que lo veo difícil, tengo que mantener un ritmo en los proyectos personales, pero las metas hay que ponerlas altas.
Resumen
Lo que hago me gusta, me divierte y me lo paso genial aprendiendo. He tenido la suerte en el 2010 de conocer a gente grande, que me ha hecho ver mi profesión desde otra perspectiva. La preocupación por la mejora continua mejora mi calidad.
Objetivos
- CodeRetreat: colaborar en organizar 2º CodeRetreat Donosti .
- AgileSpain: Este año no me lo tengo que perder.
- PHPConference: Intentaré asistir también a este evento.
- Idioma: Hasta ahora no me he visto con dificultad con el nivel de Inglés que tengo, pero no tengo el suficiente para poder empaparme cómodamente de esa documentación que aparece a borbotones. Así que uno de mis retos para este año será mejorar mi nivel de Inglés. Practicar ayuda, así que de vez en cuando le meto una patada al idioma en alguna frase que escribo por la Red ^_^
- TDD: Obtener experiencia en el desarrollo con TDD, al final a base de enfrentarte a los retos es como se aprende.
- XP: No creía demasiado en esto, pero mis compañeros de trabajo me están haciendo cambiar el punto de vista. Así que tengo que esforzarme más en aplicarlo.
- Retrospectivas: Intentar cambiar a enfoque positivo siempre que se me pase por la cabeza un comentario que pueda ser destructivo, un buen consejo de un compañero. Trabajar en equipo no es sólo trabajar en la mesa de al lado, ni tomarte unas birras con tus compañeros. Trabajar implica compromiso, y el mio será eliminar este año todo la ceniza que pueda tener alrededor.
- Deporte: Intentar hacer algo de deporte, si no me vuelvo a lesionar... ya que es la única forma que pueda descansar bien por las noches.
- Tópicos: Los tópicos de todo el mundo al inicio de año, hacer más deporte, operación biquini, dejar de fumar... a ver cual consigo cumplir de esos.
Bueno, esto es todo por hoy que no es poco 
Curso TDD con Carlos Ble
Desde que mis compañeros @tatai y @sharpbites estuvieron en el curso de TDD con @carlosble he estado como ya he escrito en otro post, persiguiendo la actividad de @carlosble por la zona norte, y tras el esfuerzo del curso de Donosti casi no lo consigo
El curso de Donosti es esta semana y he podido asistir al curso que impartió en Pamplona. Menos mal, ya que la agenda laboral me cambió las prioridades que tenía previstas.
Me estoy iniciando en todo esto del agilismo y las buenas prácticas de desarrollo, y aunque tengo pendiente la lectura del libro de Carlos, yo pensaba que el TDD tenía como objetivo el tener el proyecto con una cobertura de test pero estaba equivocado. El tener el proyecto con cobertura de test es una consecuencia de perseguir el objetivo principal, el conseguir un buen diseño y modelado de objetos. Acabas aplicando patrones de diseño de manera natural.
Lo bueno del curso:
- Compartir esas sesiones con gente que tiene la misma inquietud que tu.
- Mejorar tu calidad de código.
- No es un curso que resulte pesado.
- Las jornadas pasan volando a la vez que te entretiene.
- Te abstrae de tu tarea cotidiana y te hace ver la luz más allá de tus líneas de código.
- Ves claro el uso de TDD al terminar, pero lo importante es comenzar a aplicarlo lo antes posible para no perder el "ritmo".
La tecnología que se utilice para aprender TDD no es condicionante, así que espero que a nadie le frene el uso de una tecnología diferente a la que conoce para aprender TDD. Era uno de mis "miedos" en el curso de TDD, si al final me frenaría... pero no, es más el utilizar una tecnología diferente hasta me parece más entretenido.
Utilizar TDD en tus desarrollos, puede hacer que tu tarea diaria de "pikateclas" sea más divertida, un enfoque diferente a la hora de programar, consiguiendo un buen diseño de código y con el beneficio de tener cobertura de test en tu proyecto.
Siendo lo que en principio que creía que era el objetivo del TDD resulta que es la consecuencia.
Ahora a leer el libro de @carlosble y aquellos que ha recomendado como:
Curso recomendable 100%, y si tienes alguna de si asistir o no sólo tienes que leer este post.
Curso TDD en Donostia por Carlos Ble
Va para 8 meses aproximadamente, de que Carlos Ble impartiera un curso de TDD en la empresa en la que trabajo. Por motivos de fuerza mayor no pude asistir, pero desde entonces, he "perseguido" los movimientos de Carlos por la geografía Española a la espera de que en algún punto cercano pudiera formar parte de su alumnado. Finalmente y tras el interés de más programadores de la provincia hemos conseguido que Carlos se anime a impartir un curso en esta ciudad que como bien dice Luis Artola
..a veces nos sentimos en el borde exterior de la galaxia..
Razón no le falta, Donostia no es Madrid, pero tampoco tiene la actividad de Bilbao. La oportunidad de que Carlos Ble nos ofrezca un curso de libre inscripción es prácticamente única, y más teniendo en cuenta de que estamos hablando de Donosti
Así que ten en cuenta estos puntos si lees este post:
- Si eres programador y estás interesado en mejorar tu calidad de desarrollo no dudes en inscribirte.
- Si eres jefe de equipo de programadores, es interesante que des la paliza a los programadores para que asistan, así conseguirás mejorar la calidad de desarrollo de tu equipo.
- Si eres Director General, si tu jefe de equipo y tus programadores no están interesados en TDD preocúpate!!! la calidad de los desarrollos puede verse comprometida si el equipo no tiene interés por mejorar.
Los días 24 y 25 de Noviembre tendremos la oportunidad de recibir la formación, por lo que si estás interesado en inscribirte en el curso tienes que ponerte en contacto con: info [arroba] iexpertos.com
No sólo nos ofrecen la posibilidad de la formación de un curso abierto, también nos ofrecen un descuento en el curso en las 10 primeras plazas! en donde nos podemos ahorrar unos 100€ aproximadamente. Así que si estás interesado no tardes demasiado, ya que el curso tiene un máximo de asistentes.
Scrum: Ser ágil es ser rápido?
A relación a como terminé el post anterior sobre Scrum con la frase de:
Ser ágil, no significa ser rápido.
No hay nada mejor a que te hagan una pregunta en la que te contestas a ti mismo
Efectivamente el uso de la metodología hace que el equipo trabaje más rápido, ya que normalmente tendemos a las naves espaciales en los desarrollos y el uso de Scrum te hace acostumbrarte a atacar la necesidad inmediata de la funcionalidad en la que estás trabajando. A consecuencia de esta reacción por parte del desarrollador, las funcionalidades se van terminando antes y cuando necesiten un cambio por si interactúa con otra funcionalidad pues ya se hará cuando toque
Que me viniera a la cabeza la frase anteriormente mencionada al finalizar esa entrada en el blog, venía a cuento de que al endurecer los criterios de calidad de desarrollo hace que disminuyas la velocidad para alcanzar la funcionalidad (no puedo evitar recordar la metáfora del horno de las magdalenas) pero al disminuir la deuda técnica ¿realmente estamos cogiendo más o menos velocidad? un gran SI.
El disminuir al máximo la deuda técnica que te puede generar un proyecto es ganar en velocidad para atacar otro. Pero la sensación de alcance de funcionalidades en la iteración es menor en cuanto a velocidad. Tal vez esto venga dado por la falta de experiencia, a sabiendas de que tenemos que meter historias pequeñas para en el transcurso del sprint tengamos la sensación de ir avanzando y así ir aumentando la motivación del equipo.
Y la pregunta que desencadenó el post:
si ser Ágil no tiene que ver con la velocidad ¿por qué la única métrica que usamos es la velocidad?
Así que según respondía por Twitter me dí cuenta de lo que estaba diciendo, y no por velocidad si no que la sensación de velocidad al endurecer los criterios de calidad y manteniendo historias de mismo tamaño en iteración consigue que no tengamos la sensación de avanzar. Pero la velocidad al endurecer la calidad, aun teniendo esa sensación está en reducir al máximo la deuda técnica para poder comenzar un nuevo proyecto. En qué estaría pensando?