Apr 02
Debido a la cantidad de spam que recibo a través de este wordpress, las pocas ganas que tengo de mirar como evitarlo y que quiero meter algo más de información debido a mi nueva situación laboral, he decidido desarrollarme desde cero el site. Por eso, y mientras desarrollo este nuevo site, desactivo los comentarios para evitar el spam.
Espero que tengáis noticias mías en los próximos días 
Nov 09
Metodologías ágiles, Otros, Saraos 4 Comments
En el último mes he asistido a 2 eventos que me han hecho darme cuenta, más aún de lo que ya sabía, lo importante que es que un grupo esté unido, tiren todos en la misma dirección y tengan muchas ganas de sacar el producto adelante. En eso se sustenta todo este rollo del agilismo, porque si el equipo no funciona, ya puedes hacer iteraciones, retrospectivas, TDD o lo que quieras que el producto resultante no será ni de lejos el que el cliente espera.
El primero de estos 2 eventazos ha sido la CAS2011 (de la que ya hablé) organizado por Emma, Raquel, Amalia, Miguel Ángel, Ricardo, y más que seguramente me deje… perdón por adelantado.
El segundo ha sido más reciente, el TEDxZaragoza organizado por Teresa[1], Sir Calvo con Barba, Pablo y más gente de la que no se ni nombre ni enlace, otra vez, perdón por adelantado.
Ambos eventos tienen un denominador común, y es que se nota que han creado su producto (el evento) pensando en su cliente (nosotros, los asistentes). Y lo han creado sin que nadie les dijera lo que tenían que hacer, de forma autoorganizada, con autodisciplina y queriendo hacer EL evento, buscando la perfección (y cerca se han quedado). Pero por encima de todo eso lo han hecho con un cariño fuera de lo común. Al grupo del TEDxZaragoza les conozco menos, pero no hay más que ver como salió todo y como están de pletóricos después de que TEDxZaragoza cerrara por este año, para darse cuenta del curro y la ilusión que han metido ahí. O estar 15 días después de que terminarse la CAS2011 con Emma, Raquel y Amalia y ver como siguen pensando en su producto, como siguen pensando en lo que se podría mejorar, en lo que salió bien, lo que salió mal… y como las 3 valoran hoy muchísimo más que hace 6 meses lo que es el trabajo en equipo. Todos ellos han invertido muchas horas de sus vidas, sus familias, sus hobbies, su descanso e incluso su trabajo, para que su producto saliera perfecto.
Y el secreto para que estos 2 eventos salieran así de bien en cuanto a organización se refiere, está resumido en un Tweet de Pablo:
Don’t try to make your event more pro, try to make it more warm. For humans, by humans.
Si en los equipos de desarrollo tradicionales fuéramos una décima parte de EQUIPO que han sido estos 2 y si hiciéramos nuestros productos más “warm” y menos “pro” [2], nuestro sector estaría en un sitio muy distinto en el que está ahora.
Si todos fuéramos igual de autoorganizados, autodisciplinados, autoexigentes y le pusiéramos el mismo cariño a nuestros productos como nos han mostrado toda esta gente que es posible, no tendrían cabida las consultoras que viven de los mantenimientos, ni las personas que pasan su vida haciendo horas extras, ni los jefes que su único trabajo es contabilizar las horas que pasas con tu culo en la silla y si tienes la osadía de salir de día de tu puesto, ni los malos rollos con el cliente con el “yo te dije, tu me dijiste, esto pone en el contrato”,…
Oh wait!! ¿Te imaginas que bonito sería?
[1] No os perdais el post de Teresa, si no lo habéis leído ya, relacionado con este tema de equipos.
[2] No digo que no haya que ser profesional, sino que hay que pensar más en que nuestros clientes son “humans” y que nosotros también somos “humans”… es decir, “for humans, by humans”.
Oct 23
Metodologías ágiles, Saraos 7 Comments
No tenía muy claro si escribir sobre mi opinión de la CAS2011 o no, pero ya que me lo han pedido me termino de decidir a hacerlo. Tengo mucho en la cabeza sobre esta conferencia así que voy a resumirlo mucho para no ser muy pesado. Pensaba hacer retros de cada sesión, pero como están grabadas, cuando se cuelguen que cada opine lo que sea de cada sesión y ya comenté (o comentaré) con los ponentes de las sesiones a las que fui lo que me habían parecido. Voy a tratar de ir a lo más general.
Si no aguantas la crítica, aquí termina hasta donde debes leer. Si sigues es bajo tu responsabilidad, ya que lo bueno y lo malo iré mezclando y quizás no te guste ni el fondo ni la forma, pero este es mi sitio personal y hago lo que quiero con él
Lo primero que resalto de la conferencia es la organización, ha sido espectacular!!! Se el trabajo y el cariño que le han puesto. Se lo que les importaba hacer EL evento y no uno más. Por supuesto que ha habido fallos, para mi alguno bastante importante y aunque ya lo he hablado con ellos y ellas, irá saliendo por aquí.
Una cosa que me llamó la atención y me gustó es la cantidad de veces que salió la palabra “persona” dentro de las charlas. Nos hemos preocupado mucho hasta ahora de técnicas, tecnologías, dar valor, post-it y restrospectivas… olvidando un poco que detrás de todo esto hay personas. No me gustó nada la frase de Enrique Comba de “Prefiero la palabra esclavo a recurso humano, porque al menos en lo primero se da la condición de ser humano”. Me parece frivolizar con un tema muy serio y además no estoy de acuerdo con la afirmación. (EDIT: Mirar comentario donde explico esto un poco más)
Otra cosa positiva fue ver a gente que por primera vez se arrancó a ser ponentes. También fue la primera vez para mi en una conferencia, aunque yo jugaba con ventaja, una iniciación a Agile, con poca gente… no podía nada salir mal!! Pero gente como Vanesa Tejada y Javi Acero se lanzaron y con todo el nerviosismo del mundo (recuerdo como a Javi le temblaba la mano del micrófono) nos contaron cosas interesantes. Seguramente mejorable en el fondo y en la forma, pero hay que lanzarse!
No gustó nada la retrospectiva. Ya lancé un tweet, que no se debió de entender porque me fueron preguntando después, donde decía que yo debí de estar en otro evento porque en la retrospectiva no escuché más que (en mi opinión y generalizando mucho) sandeces, tonterías, falsedades y cosas no del todo ciertas… Me fui antes de que terminara porque no me gustaba nada lo que estaba oyendo. Si participaste en la retro y no aceptas que critique lo que dijiste, deja de leer… por el bien de todos!
En general las sesiones me han vuelto a parecer más de lo mismo, poca novedad, poca calidad… y eso es culpa de todos! de los que presentaron y de los que no presentaron. Creo que es un punto que hay que mejorar y mucho.
La mesa redonda fue infumable. No me gusta el rollo “estrellas del rock” y ya que se hace, al menos que salgan cosas interesantes… Disculpo al 100% a JB Rainsberger porque hizo un esfuerzo enorme por tratar de participar aunque fuera en Español. En mi retro personal de esta sesión sólo puse un “+”, seguido de las palabras “Jorge Uriarte“. Me pareció un sesión lenta, densa, poco dinámica, sin casi información novedosa… incluso con algún ponente que no se que hacía ahí.
Y ahora el palo a la organización, que saben que lo hago con todo el cariño del mundo y ya está hablado con ellos. No se deberían sacar unas entradas a un evento sin saber el programa, hay que adelantar la publicación del programa a la venta de entradas y para eso hay que adelantar el call for sessions. Quizás las fechas no se lo permitió, pero hay que hacer algo, pedir las sesiones con mucha más antelación, cambiar de fecha la conferencia, lo que sea…
Creo que dieron un paso demasiado grande, organizando cosas que requieren mucho tiempo (como la reserva de hotel) y descuidaron cosas más importantes como lo que comento en el párrafo anterior. Creo que la conferencia ha de mejorar primero en lo importante, las sesiones y luego en todo lo que la rodea. Quizás en modo de revisión es mejorable, como que se permita que los revisores den feedback al ponente y que éste pueda modificarla antes de ser aceptada o rechazada. Es decir, que un revisor pueda escribir al ponente y decirle “oye, y si en vez de orientarlo por ese lado, le das una vuelta y lo orientas por este otro y le introduces esto que será más novedoso?”, y que el ponente, si le parece bien, lo cambio y vuelva a enviar la sesión.
El warm-up se puso excesivamente tarde! No se puede decir que el miércoles por la tarde habrá cosas y publicarlo 2 o 3 días antes… La gente ya tiene sus planes de viajes e incluso billetes comprados, hoteles reservados… creo que esto restó asistencia al warm-up.
Me dejo mucho en el tintero, pero esto ya es excesivamente largo!!! No he puesto prácticamente ninguna “acción a hacer” aunque ya se hablaron entre algunos o las tengo en la cabeza… iremos hablando de ellas si quereis
Sep 04
Metodologías ágiles, Otros, Saraos Comments Off
Ayer asistí al Visual Management Open Space un evento organizado por Raquel Laina en las oficinas de Decide, aprovechando la estancia en Madrid de uno de los grandes en esto de montar paneles y gestionar todo lo relacionado con un proyecto de una forma muy visual, Xavier Quesada. Como nos suele tener acostumbrados Raquel, organización de 10, y desde aquí otro aplauso más 
A este Open Space fui sin tener nada claro qué íbamos a hacer, de que se hablaría, si habría sesiones suficientes para todo un día… y como suele pasar, las dudas se disiparon en cuanto se empezó a montar el panel. Salieron alrededor de 25 temas, de los cuales “sólo” unos 15 entraron en el panel, dejando el resto para unas lightning talks en tiempos “muertos”.
Una de las sesiones que más me llamó la atención y que más interés en mi despertó fue una propuesta por Xavier Quesada sobre Personal Kanban. En ella Xavier contó cómo él gestiona el panel de las tareas personales, en las que está únicamente él involucrado. Por supuesto esta forma no es válida para todo el mundo, sólo nos contó como lo hacía él, además de explicar que el refinamiento de este método le había costado 2 años.
El panel visual estaría divido en 3 partes: Tareas pendientes de hacer, tareas para hoy y tareas para mañana (o para hoy si sobra tiempo). Las tareas de hoy las metía dentro de un rectángulo rojo, las de mañana en otro rectángulo igual pero de otro color (no recuerdo si azul, amarillo… es lo de menos!) y las tareas pendientes las tenía separadas por categorías en columnas. Las tareas hechas simplemente las tira porque como bien explicó, el tener de forma visual las tareas “done” es como comunicación al resto de compañeros, y como aquí no hay compañeros… Tampoco diferenciaba la tarea en la que estaba trabajando por el mismo motivo y porque utiliza un WIP de 1, es decir, no trabaja en más de una tarea a la vez. Si alguna tarea empezada está bloqueada porque necesita alguna cosa que no puede tener en ese momento (espera de contestación de alguien, etc), le pone un pequeño post-it encima donde indica que está bloqueada.
Saliendo un poco del tema visual, comentó que sus herramientas de trabajo eran Gmail y Google Calendar. La idea es mantener el Inbox Zero, teniendo en la bandeja de entrada únicamente las tareas pendientes. Cuando una tarea está completada (¿o cuando pasa a tarjeta dentro del tablón? no recuerdo esto…) pasa a archivado y sale de la bandeja de entrada.
Otra cosa que comentó fueron los “estudios” que ha ido haciendo para adaptar este modelo de trabajo. Miró por ejemplo de donde le venían las tareas, donde se dio cuenta que el 80% era por email, lo que ayudó a la decisión de usar Gmail como herramienta de trabajo. Durante un tiempo estudió el número de tareas que era capaz de hacer en un día, para poder hacer planificaciones más realistas de las tareas que planifica cada día.
Creo que más o menos esto es lo que él comentó que hacía. Además, gente como Marcin Gryszko y Vanesa Tejada entre otros, comentaban que usan las tareas de Google, se comentó el tema de separar las tareas en los diferentes contextos aunque a la hora de coger las “tareas para hoy” no centrarse en uno de los contextos sino coger lo más prioritario de cada uno de ellos y salió el nombre de David Seah y sus herramientas de ayuda a la productividad personal.
Si alguien que lea esto se acuerda de algo más o me quiere corregir en algo, estaré agradecido! ya que se me olvidó llevarme cuaderno para tomar notas y mi memoria no es la cualidad de la que esté más orgulloso
Ahora me toca buscar mi propio método, que cuando lo tenga mínimamente rodado, volveré a escribir unas líneas
Jul 03
Por diferentes conversaciones que he tenido ultimamente, llevo unos días dándole vueltas al tema de la autocrítica y a lo poco que la usamos.
Hace unos días estuve hablando sobre el movimiento 15M y la falta de autocrítica que hubo en ese movimiento. Se culpaba de la situación actual a banqueros, al gobierno, a los mercados, etc… pero nadie decía “me metí en una hipoteca que en cuanto me subieran un € no podía pagar”, “conseguí que me tasaran el piso un poco más de su precio real para poder comprarme un coche también” o “no ahorré ni un € por si venían mal dadas, prefería gastarme todo lo que ganaba en vacaciones, salir a cenar fuera y de compras”. Realmente los bancos, gobiernos, etc tienen mucha culpa de todo lo que está pasando y movimientos tipo 15M (para mi con algunos cambios, pero ese es otro tema) me parecen imprescindibles, pero igual de imprescindible creo que es que la gente haga autocrítica y la gente que está pasando problemas económicos ahora mismo (que tienen todo mi apoyo, por supuesto) piensen en qué fallaron ellos para no volverlo a repetir en el futuro.
Ayer estuve en el open space llamado “la esencia de Scrum”, donde la idea era hablar sobre los valores que hay por debajo de Scrum y también sobre el propio Scrum. En una de las sesiones, propuesta por Emma y Raquel, se empezó hablando de qué es mejora contínua, por qué la queremos, si hay que apostar por ella o comprometerse con ella, etc. Una conversación muy interesante que acabó con una conclusión (entre otras muchas) y es que la empresa limita la mejora de los trabajadores. En cada sesión tratábamos de en los últimos 5 min decir con qué nos quedábamos de la sesión para escribir unos post-it y pegarlos sobre el tablón para que los demás que habían ido a otra sesión pudieran ver más o menos de qué se habló. En ese momento yo dije que lo que sacaba de la sesión es que no había visto ningún tipo de autocrítica, porque seguimos buscando excusas externas a problemas internos. Traté de explicar en la propia sesión por qué para mi el decir que la empresa me limita es una excusa más, pero creo que no supe explicarlo y acabó pareciendo que quería decir que ya era perfecto y que no tenía como mejorar… A ver si ahora lo puedo explicar mejor
Para mi una empresa puede facilitar o no el crecimiento personal y profesional de una persona, su aprendizaje, etc, pero no limitarlo. Haciendo un simil con el camino de Santiago, estoy en Roncesvalles y quiero ir hasta Santiago, todo andando como buen peregrino. La empresa podrá darme un buen material deportivo, podrá poner en cada km del camino una botella de agua para que beba si tengo sed e incluso si estoy muy mal podrá poner a una persona que me lleve a hombros unos kms. O la empresa podrá ponerme una mochila con ladrillos y dejarme a mi aire a ver si llego. Es decir, la empresa me podrá facilitar las cosas o podrá ponérmelo más difícil, pero si quiero llegar hasta Santiago llegaré, con más o menos esfuerzo.
En resumen, la empresa podrá crearme el ecosistema perfecto para que mi mejora contínua sea más sencilla, más rápida y mucho más provechosa para todos, o podrá ponerme trabas, pero si quiero que mi mejora contínua sea tal, podré hacerlo mientras yo quiera. Puede que llegue un momento en que no sepa como mejorar (por aquí venía mi lío que hizo que pareciera que estaba diciendo que yo soy perfecto…) porque dentro de mi empresa no tenga nadie que me apoye o me ayude a dirigir mi mejora, pero para eso se organizan una serie de eventos donde conocer gente nueva y que te dirija un poco. Puede que como equipo dentro de la empresa no sepais como mejorar (lo mismo, hay otras formas fuera del trabajo para ello) o que por ejemplo la empresa no te permita mejorar tu proceso (te puede decir que eso de Scrum para la gente de Rugby) y tengas que buscarte la vida para mejorar por otro lado, pero no habrá empresa que te diga que no intentes hacer cada vez mejor software, que no aprendas un poquito más sobre el lenguaje que estás usando, que no aprendas más sobre patrones, o sobre BD, o sobre lo que se te ocurra… Y además, tienes más horas en el día aparte del trabajo para aprender y practicar lo que te de la gana.
Alguien me dijo un vez: “estoy cansado de escuchar a gente decir que hay cosas imposibles para no hacer cosas que son muy difíciles”. Por lo tanto, más trabajo si tu empresa “no te permite” mejorar y más autocrítica para no culparla de seguir igual que hace 6 meses.
He dicho!! (y ahora podeis discutirme lo que querais )
Jun 24
Metodologías ágiles, Saraos 14 Comments
Llevo unos días leyendo diagonalmente todos los post que llegan hasta mi TL del Twitter sobre el Agile Open Spain 2011 (aka AOS2011). El título de este es porque no quiero desanimar a esa gente que salió encantada del evento, pero quiero dar mi visión. Creo que determinadas circunstancias, algunas personales, me han hecho tener una visión muy distinta sobre el evento, sobretodo muy distinta a aquellos que iban por primera vez. Con todo lo que diré en este post no quiero que nadie de los que salieron enormemente contentos cambien su visión, esto no es más que un pensamiento en alto que igual está (o no) equivocado. Además, hablaré de lo que para mi han sido errores pero no quiero señalar a nadie y quiero señalar a todos, ¡¡¡a mi el primero!!!
Hace un año contaba que habíamos madurado y que las metodologías ágiles estaban para quedarse. El mismo post del año pasado podía haberlo escrito este. Eso que parece bueno pero para mi no lo es, porque significa que hemos avanzado poco. Sí, estoy de acuerdo con JMBeas en que hemos llegado a un punto que dejamos de hablar de lo que hemos leído y hablamos de lo que vivimos en el día a día en nuestra empresa, pero para mi el AOS2010 y el AOS2011 los podríamos haber invertido (a los paneles me refiero) y a nadie le hubiese extrañado. Dicho de otro modo, creo que el año pasado podríamos haber hecho el mismo tablón de este año y no nos parecería nada fuera de lo común. Esto para mi es un síntoma de que o no hemos mejorado lo suficiente o tenemos una falta de imaginación preocupante. Imaginación en cuanto a hacer que un AOS sea lo suficientemente distinto al anterior como para que siga resultando igual (o más) atractivo. Hasta de comer solomillo se cansa uno si lo come muy a menudo.
Con el paso de los días voy viendo las cosas un poco más claras y veo algunas que me faltaron. Me faltó autocrítica dentro del agilismo, y por ejemplo si mañana fuera el AOS2012 propondría una sesión llamada “¿Firmarías un proyecto hecho con metodologías ágiles?”. Y con firmar me refiero a asumir la responsabilidad que tiene, por ejemplo, un médico o un arquitecto. Me gustaría ver si realmente nos creemos lo que hacemos. Me faltó debate, vi en general un consenso bastante importante (no estuve en muchas sesiones, yo hablo en las que fui). Me faltan casos de fracaso con las metodologías ágiles! no me creo que funcionen el 100% de los proyectos, y estaría bien saber si valen para todo y si se aplican bien. Otra que quizás propondría sería “Vale, ya soy ágil, ¿y ahora qué?” donde se debatiera sobre cuales son los siguientes pasos a dar, si es que hay alguno. En resumen, me faltó la parte negativa de las cosas de las cuales aprender para mejorar.
Sí hubo una sesión que esperaba pero que no era yo el más indicado para proponerla, y era algo que me relacionara el mundo del emprendimiento con las metodologías ágiles. No soy yo el apropiado porque no soy emprendedor ni a corto plazo lo seré, pero creo que es el siguiente paso. Creo que el post-it de “hacer las cosas bien en la empresa” podemos ir poniéndolo a “done” (quien no se haya subido al carro ya, será difícil que lo haga y no debemos esperarlas para dar el siguiente paso), así que ahora iría a por la siguiente historia de usuario, “hacer empresas que hagan las cosas bien”. Había allí gente que podría haber dado su visión desde “dentro” del emprendimiento y nos hubiese enriquecido a todos.
En la retrospectiva del evento salieron varias cosas y estoy de acuerdo sobretodo en una que para mi una fundamental, y es que la gente que se quiere introducir en todo este rollo del agilismo está completamente fuera de eventos como estos y les cuesta horrores entender determinado vocabulario que a los que nos movemos en estos ambientes nos resulta normal, pero que a los que están conociendo este mundo les resultan complicados. Más que complicados, es que nadie se las ha explicado. Rodrigo Corral propuso una charla de iniciación y como sólo obtuvo 5 votos no se puso dentro del panel, lo cual me parece un error monumental. Si una sesión así tiene aunque sea un sólo voto, debería estar en el panel y a primera hora.
Para que no sea todo malo, también diré que hubo cosas buenas. Para empezar el sitio muy bueno y la organización de 10. Las salas, la “zona de pensar” (o mal llamada zona de lectura xD), la cafetería… todo perfecto! Además, creo que se dio un paso que creo que ha pasado más o menos desapercibido y que para mi es importante, se han reducido, por ejemplo, el número de cafés que se dan por la cara y que lo que consiguen es encarecer un evento que debería tratar de reducir su coste al máximo para tener que depender menos de los patrocinadores de lo que lo hace actualmente (no porque me molesten, sino por si mañana no están poder seguir haciéndolo). Si quieres un café tienes una cafetería al lado que te pondrá uno por un precio que podrás pagar. Además, se redujeron el número de “juegos” del principio, que para mi son innecesarios, pero esto es una opinión (como todo lo dicho) muy muy personal.
Además, destacar una iniciativa que salió de la sesión que propuso Emma sobre Internship (término que hay que cambiar…). De ahí salió la idea de hacer una web donde dar información y facilitar en la medida de lo posible los intercambios de profesionales entre empresas o entre empresa-profesional, donde tengo el placer de estar participando mientras no me echen por pesado, y de la que espero que tengáis noticias en unos pocos días.
Nos vemos en el AOS2012!!!
May 08
Formación, Metodologías ágiles, Saraos Comments Off
Este fin de semana he estado en un Code Retreat facilitado por Enrique Comba.
¿Qué es un Code Retreat? Es un formato creado por Corey Haines donde unos cuantos programadores locos con mucho vicio (locos que madrugan un sábado para programar…) y muchas granas de mejorar, se juntan durante un día entero para desarrollar en iteraciones de 45 minutos el Juego de la Vida, en cualquier lenguaje. Se desarrolla siempre en parejas, haciendo TDD y en cada iteración hay que cambiar de pareja y borrar el código que hemos hecho antes.
Al principio suena un poco raro, pero acaba sorprendiendo lo mucho que se puede llegar a aprender realizando siempre el mismo problema. La idea es que como no tenemos la presión de tiempos, de clientes, de jefes ni nada parecido, nos centramos en hacer las cosas bien y aprender de los puntos de vista y modos de trabajo de la pareja con la que estamos en el momento.
En esta ocasión hicimos la friolera de 8 iteraciones, despertando la admiración de otros code retreats. Porque además este ha sido un día especial en este tipo de eventos, ya que se realizaron 6 simultaneamente, uno en UK, otro en Bélgica, dos en Rumanía, uno en EEUU y el nuestro. Pudimos comunicar vía Skype con el de UK, el de Bélgica y uno de Rumanía. Además de que teníamos en pantalla grande una web que mostraba todo lo que se estaba diciendo en Twitter con el tag #coderetreat, lo cual hacía que vieras lo que estaban diciendo en otras partes del mundo sobre lo mismo que estabas haciendo tu.
Compartí iteraciones con @semurat, @amaliahern, @ArturoHerrero, @eduferrandez, @mariotux, @kinisoftware, @isidromerayo y otro (con el que hice la iteración de refuctoring) que si lee esto me diga su nombre porque soy taaaan desastre que no lo se 
Cosas interesantes en todas y cada una de las iteraciones. Programar en PHP o Groovy y no tener ningún problema, atacar el problema de diferentes formas (aunque eso suponga volver loca a mi pareja), que en la última iteración Enrique diga “ahora lo vamos a hacer con orientación a objetos de verdad” cuando llevas 7 iteraciones (y varios años) intentándolo o “todavía no he visto un código limpio” o que en la sesión de refuctoring (hacer el peor código que podamos) diga “no es tan diferente el código de ahora al que he visto antes”, ver que el TDD as if you meant it (hacer todo el código en el propio test y sólo sacarlo a método cuando se repita, y luego si hay métodos que huelan a clase sacarlos) es una práctica tan difícil y dura como interesante. Y en resumen, 8 iteraciones donde aprender mucho pero ver que todavía te falta mucho más por aprender de lo que pensabas.
Mi retrospectiva personal sobre el code retreat de ayer la resumo en 2 puntos:
Mucho que agradecer a:
Apr 07
Formación, Java, Metodologías ágiles 4 Comments
Hace ya casi un mes que he empezado a trabajar en IPSA y ya en este tiempo he visto la diferencia que tiene la forma de trabajar con respecto a las otras tantas consultoras por las que he pasado. Lo primero es que aquí se hace producto, no se hace software a medida. Esto en sí no es mejor ni peor, es sólo un modelo de negocio.
Lo primero que sorprende a alguien como yo acostumbrado a la vorágine de las consultoras, es que aquí llevo 4 semanas haciendo pair programming. Esta me parece la mejor forma de hacer que alguien que entra nuevo aprenda más rapidamente. Estaba acostumbrado a que el “arquitecto” de turno me soltara una charla de 20 minutos sobre como está todo, y en seguida ponerme a desarrollar. Por supuesto solía ser una aplicación que tiene un diseño chusquero y los test automáticos es de esas cosas que haremos al final si da tiempo y que nunca daba tiempo porque ya íbamos con semanas/meses/años (sí sí, años!!) de retraso.
En estas semanas en IPSA he confirmado junto a Alfredo (y Xavi Gost en la semana que pasé con él) mis sospechas de que haciendo test automáticos todo es mucho más sencillo. Da igual si quito esto, si pongo esto otro aquí o si cambio esta línea por esta otra, tengo una batería de unos 3000 test (si no recuerdo mal) que respaldan que no estoy rompiendo nada. Y claro, por cada cambio que hago no voy a pasar yo a mano todos esos test, para algo está algo llamado servidor de integración contínua. En este caso usamos Hudson, pero da igual cuál de las herramientas elegir, lo importante es tener algo que nos de la tranquilidad de que si hemos roto algo con un cambio nos enteremos como mucho con 1 día de diferencia, y no a los 6 meses cuando instalemos en producción.
Otro avance importante es Scrum. Entré justo a trabajar el día de una demo de final de sprint y me sirvió para ver un poco de qué iba la herramienta. Sólo vi una parte pequeña, pero al menos me sirvió para hacerme alguna idea general. Mucho mejor una demo que el jefe de proyecto de turno te cuente durante 2 interminables horas lo que están haciendo. Además la reunión diaria ayuda para ver que está haciendo cada uno con lo que también te das cuenta de hacia donde avanza el proyecto.
Las prisas son malas consejeras. En este último sprint no entró una historia que había planificada porque faltaba por hacer una tarea de 2 puntos. Corriendo se podría haber hecho pero, ¿para qué? ¿para hacerlo corriendo y arriesgarnos a hacerlo mal?
TDD me ayuda a centrar lo que quiero hacer. Ya pensar el nombre que le voy a dar el test me obliga a tener muy claro qué es lo que quiero hacer. Si no lo tengo claro (y muchas muchas veces he empezado a desarrollar algo sin saber exactamente lo que tengo a hacer) me será imposible elegir nombre. Y lo mismo para hacer el código de ese test.
En resumen, si quieres que la gente nueva que entra en tu equipo sea productiva más rapidamente, dales el entorno adecuado para que aprendan lo más rápido posible. Si quieres que no te rompan nada mientras aprenden ten toda la aplicación a prueba de manazas como yo con test automáticos de todo lo que sea posible. Si quieres que se hagan las cosas bien, no quieras las cosas para ayer, desarrollar algo en condiciones lleva su tiempo. Y si quieres irte a casa y dormir tranquilamente, pon un Hudson (o similares) en tu vida.
Mar 11
Formación, Metodologías ágiles 2 Comments
Acabo de llegar de pasar una semana con el gran Xavi Gost en BeCode. A la gente no metida en estos mundillos me cuesta explicarles qué he hecho. No entienden como puedes coger una maleta para unos días, comprar unos billetes de tren e irte a otra ciudad distinta de la tuya a “trabajar” gratis. Yo trato de explicarlo de la siguiente forma: “¿cuánto cuesta un curso? Pues en vez de pagar ese dinero, yo me pago una estancia en donde sea y aprendo mucho más en vivo y en directo, porque aprender a hacer tu trabajo se consigue trabajando”. Y qué mejor que aprender a ser un buen profesional, trabajando codo a codo con grandes profesionales.
Por desgracia Xavi ha estado muy liado con otras cosas y no he podido sacarle todo el jugo que me hubiese gustado, pero me traigo un montón de cosas distintas que he aprendido:
En resumen, me traigo semillas de muchas cosas y ahora me toca a mi regarla para que salga la flor. No quiero hablar demasiado de proyecto, tecnologías y cosas más concretas porque me parece mucho más importante todo lo demás que decir si he trabajado con el framework X o el lenguaje Y.
La experiencia de un internship es algo que merece y mucho la pena y creo que repetiré de vez en cuando. Y por supuesto se lo aconsejo a todo el mundo, sobretodo a la gente que no se ha movido mucho de trabajo y lleve años haciendo lo mismo en el mismo sitio de la misma manera. Es una bocanada de aire fresco que viene muy bien.
Feb 09
Llevo unos días “discutiendo” en el foro de alumnos de la universidad donde estudié. Esta discusión empezó con un alumno que está buscando una beca para empezar en este mundillo y pedía opiniones de diferentes empresas. La opinión de este futuro profesional (esperemos) era que él no quería “estar picando teclas”, que para esto “están los de FP”, que “como Ingeniero nosotros tenemos que hacer cosas más de gestión de proyectos” y que por eso “le llamaba mucho más una beca donde le ofrecían hacer labores más de gestión y que no tocaría código”. Voy a ir comentando cada una de estas malas ideas que nos meten (al menos fue mi caso) en la cabeza los profesores de la universidad (no es una crítica al alumno en cuestión, yo salí con la misma idea de la universidad):
Colaboración en gestión de proyectos de Tecnologias de la Información y las Comunicaciones, participando en actividades de: – Soporte a los Jefes de Proyecto en la elaboración de ofertas técnicas, en el diseño y planificación de los proyectos en relación a las especificaciones y requisitos técnicos definidos, y posterior seguimiento de proyectos (SLA´s, hitos, plazos…). – Soporte en la instalación y configuración de servidores y aplicaciones. – Soporte en la elaboración de informes de seguimiento de proyectos, incidencias y estado de sistemas. – Apoyo en la relación con fabricantes de tecnología, partners y proveedores.
Elaboración de ofertas técnicas? diseño y planificación? Seguimiento? Todo esto un becario? De verdad? Y sí, lo mejor que puede hacer un becario es llevar la relación con partners y proveedores… “oye mira, soy el becario de la empresa X, que me dice mi jefe que para cuando me vais a tener listo esto… es que le corre un poco de prisa, ¿sabes? me ha dicho que os insista mucho mucho, hasta que me lo tengáis listo. ¿Hola? ¿Hay alguien ahí? Vaya, otro que me cuelga…”.
Da mucha pena lo que hay en las universidades. Luego, los mismos que dicen todas estas cosas son las que están dando palmas con las orejas de que se acabe de crear el Excelentísimo y Real Colegio de Super Ingenieros Informáticos Molones, porque van a luchar por nuestros derechos y por fin todos los males de esta profesión se van a acabar, ya que sólo podremos trabajar informáticos en un proyecto de software.
No culpo a los alumnos… culpo a ese entorno nocivo y poco informado que hay entre una parte del profesorado (al menos el que yo conozco, y con muy honrosas excepciones), que son funcionarios acomodados que la última vez que programaron lo hacían en tarjetas microperforadas. ¿Esa gente es la que está preparando a nuestros futuros profesionales? ¿A esos profesionales que seguirán haciendo software que nos facilitará nuestra vida? Al menos es la que les está mal formando y les está metiendo ideas tan equivocadas como peligrosas.
Qué Uncle Bob nos pille confesados….
PD: Soy Ingeniero Informático, por si hay dudas.
RSS