Archivo de la categoría: Uncategorized

Calidad

Dentro del mundo del desarrollo y de la gestión de proyectos, se habla mucho del “triángulo de hierro”, de las tres dimensiones con las que podemos manejar en un proyecto: tiempo, alcance y coste. A menudo se habla también de otra dimensión oculta que es la calidad.

Desde algunos puntos de vista, la calidad es algo a lo que no se puede renunciar, porque a largo plazo se vuelve contra tuya. Si descuidas este aspecto, a largo plazo tu base de código se volverá difícil de interpretar y de extender, los errores se multiplicarán y serán más difíciles de solucionar… Lo sé porque he estado ahí muchas veces.

En Plain Concepts apostamos mucho por asegurar la calidad del software que escribimos, y estas son algunas cosas que hacemos para intentar mejorarla:

  • Trabajar en equipo (I). Eso significa que las decisiones importantes, las estructura de las soluciones, las arquitecturas, se deciden en común, dentro del equipo. Esto lleva a un debate que pensamos redunda en mejores soluciones que las que puedes pensar tú solo, por muy listo que sea.
  • Trabajar en equipo (II). Trabajar en equipo también significa que cuando tienes un problema, puedes recurrir al equipo para desatascarlo de la mejor manera posible (una vez más mejor solución que pensándola tú solo).
  • Pruebas automáticas. Una de las variables hablando de calidad son los errores; evidentemente cuantos menos mejor, y desde un punto de vista de sostenibilidad, esto no se puede hacer con pruebas manuales, porque llegaríamos a un punto de pasar más tiempo probando que desarrollando. Por eso apostamos por las pruebas automáticas, sin obsesionarnos con el 100% de cobertura.
  • Demo con cliente. Trabajamos en sprints, así que entregamos software funcionando al final de cada ciclo. Esto significa que el cliente puede y debe probarlo y reportar errores. Esto no es siempre así (y habría que mejorarlo) pero de todas maneras el sprint siempre culmina con una demo con cliente en la que enseñamos y probamos ese software funcionando.
  • Demos internas. Para asegurar (entre otras cosas) que esa demo con cliente va bien hacemos una demo interna anterior a la demo con el cliente, de manera que tenemos un pequeño margen de mejora por si algo no sale todo lo bien que debiera. En esta demo también se tratan y discuten otros aspectos del proyecto.
  • Desarrollar en pareja. El “Pair programming” es un mundo en sí mismo, y quizá no es para todo el mundo ni para todas las ocasiones, pero nos ayuda a tomar mejores decisiones.
  • Revisión de historias. Cada historia finalizada se valida con otro miembro del equipo y contra una “Definición de hecho” que repasamos para ver si todo está en orden. Esta lista incluye cosas como validar en un entorno de integración, revisión de código, pruebas automáticas…

En algunas ocasiones, nos hemos encontrado con proyectos que se desvían del estandar de calidad que consideramos apropiado, así que estamos barajando alguna medida más.

  • Revisiones de código. Las revisiones de código que hacemos centradas en una historia a veces no te dan una visión general del proyecto, o igual no es el momento de revisar cosas como la congruencia de las decisiones tomadas a lo largo del proyecto, con lo que necesitamos otros momentos en los que revisar estos aspectos. Le estamos dando forma como revisiones de proyecto, que se convocan periódicamente.
  • Evitar los proyectos “monopersona”. Es complicado en algunas situaciones con proyectos pequeños, pero en la medida de lo posible sería deseable evitar este tipo de proyectos, para poder contar con al menos otro punto de vista a la hora de tomar decisiones y evitar que sean demasiado individuales.

 

Gremios y metaforas

Uno de los problemas que tenemos dentro de nuestro gremio es que tenemos muchos problemas para describir que es lo que hacemos. Los que nos dedicamos a hacer software lidiamos con algo tan hetéreo, tan diferente de como se comportan el resto de elementos físicos con los que interactuamos en el día a día que se nos hace muy difícil describir apropiadamente que es lo que hacemos en general, y cuales son los condicionantes que nos encontramos para resolver cada problema concreto.

Para intentar superar esto, hemos utilizado metáforas por encima de nuestras posibilidades. Somos como artesanos, como arquitectos, como jardineros, como médicos, como calibradores de pollos… casi casi de todo. Y la última metáfora que he oido viene de Joel Spolsky. Un grande entre los grandes (construir Trello está bien, pero hacer Excel es la pera). Habla en un pequeño manual sobre desarrollo que esto es como… ¡¡conducir un taxi!! pero a veces cuando giras el volante este no responde porque tienes una persona con camiseta a rallas montado, y otras veces… no es que quiera llevarle la contraria a Joel, nada más lejos de mi intención, pero creo que ya basta de metáforas.

Como las abstracciones, todas las metáforas fugan. Reflejan un aspecto y no otro, como los modelos que todos son incorrectos pero algunos son útiles… y el problema es que en el fondo, ni nosotros mismos sabemos como funciona esto, y por eso acudimos a metáforas más o menos afortunadas para intentar explicarlo. Verás, esto es como si tal pero cual y además le añadimos que no se puede tocar y no se derrumba, pero a la vez es muy endeble… todo esto para explicar porque demonios no somos capaces como industria de hacer software robusto, de calidad que no se rompa cada dos por tres por algún lado de manera totalmente inesperada.

2016

De nuevo llega el final del año, de nuevo toca evaluarlo en unas pocas líneas. el año pasado me propuse:

  • Consolidar el cambio (profesional). Ha sido un año ¿complicado? No sé si es exactamente el adjetivo, pero no ha sido fácil. El otro día hablabamos de la zona de confort, yo llevo fuera 16 meses, con contadas excepciones. Igual ahora me empiezo a enterar bien de que va esto, pero toca seguir trabajándolo.
  • Seguir corriendo. He hecho una maraton en 4:18, más despacio de lo que esperaba pero digna. No es para mí, al menos en este momento supone demasiada dedicación, sobre todo en horas de entrenamientos. Me quedo con la media que es una alternativa mucho más sostenible en el tiempo.
  • Dibujar más. Cumplido a medias, he hecho algo y además alguno en directo, como en la CAS 2016. Todavía me sorprendo cuando la gente lo ve y me dice que se dibujar, cuando claramente esto es otra cosa distinta (y no se dibujar). A trabajar más en el futuro, a ver si aprendo.
  • Seguir haciendo compatible mi vida personal con la profesional. Creo que lo he cumplido, en gran parte porque mi empresa me da mucha manga ancha a la hora de organizar horarios, trabajamos más por objetivos.

Mención aparte para la organización de la CAS 2016, que sin estar en los planes iniciales ha consumido bastante tiempo en este 2016.

Me encanta el efecto de esta entrada anual, todos los años me parece que me tengo que aclarar a la hora de pensar en el futuro, va a ser que es una constante que hay que aceptar y ya está (No hay cuchara). A nivel laboral Plain Concepts Bilbao es un gran sitio para trabajar: te valoran profesionalmente, te dan libertad, se persigue la calidad y la maestría en lo que hacemos, y son equipo de personas excepcionales… pero hacemos consultoría y desarrollo a medida, y a veces unos proyectos molan más que otros.

Feliz 2017

CAS 2016

Después de casi 10 meses desde que se comenzó a organizar, la CAS 2016 ha sido una realidad los pasados 1 y 2 de diciembre. Esto no quiere decir que haya terminado, al menos no para la organización (escribo esto un domingo a las 19:21 y en el chat de la orga se cruzan varios temas: facturas, evaluación, videos…) porque aún quedan cosas sin cerrar. Pero en otros aspectos ya está todo hecho.

Han sido tres días intensos (si, empezó el miércoles para varias personas), que han dado para mucho. Lo primero, agradecer a los patrocinadores su apoyo, y en mi caso especialmente al Ayuntamiento de Vitoria-Gasteiz que ha sido mi casa durante muchos años su ayuda para organizarlo. El Palacio Europa ha sido una sede realmente excepcional, que creo que ha gustado mucho (habrá que ver la evaluación).

Lo segundo, agradecer a todos los asistentes todo el amor que nos han transmitido. Organizar es un trabajo para la comunidad que se ve sobradamente compensado por el soporte que está te brinda. Aunque varias cosas han ido distinto de bien (la comida del jueves, las camisetas, algún ordenador saboteando ponentes), la respuesta ha sido estupenda ante los problemas encontrados.

Lo tercero, gracias a los ponentes por su labor. La conferencia no sería posible sin ellos, y para mi las nuevas ideas y el punto de contraste que encuentro en estas charlas es muy enriquecedor y motivador, a pesar que este año me quedan demasiados videos para repasar por no haber asistido a todas las sesiones que me hubiera gustado.

Lo tercero, amor infinito a los componentes de la organización. Desde las personas que han participado en la selección de contenidos (Aritz, Jerónimo, José, Luis y Ujue), la gente de la UPV capitaneados por Anaje Armendariz, la empresa No Problem que nos ha apoyado en la organización hasta Iñaki, Jorge, Joserra, Vicenç y Xabi (el propio comité organizador). Para estos últimos también gracias infinitas por haber podido colaborar y aprender con ellos, y por poder disfrutar de su amistad, ha sido un placer.

Hay varias cosas sobre las que tenemos que pensar un poco dentro de la comunidad después de esta conferencia. Llegar a 450 personas sin publicar la agenda en una ciudad como Vitoria-Gasteiz es un éxito de asistencia rotundo, pero hay que plantearse si queremos conferencias de 800 personas, por lo complicada que se hace todo con estos volúmenes (organización y logística, relación entre participantes…). Personalmente me gustaría quedarme en estas cifras, porque creo que la experiencia de la conferencia por encima de esos números es muy diferente, y bajo y punto de vista, peor.

Por otro lado, está empezando a tener un tamaño difícilmente manejable desde el voluntariado, o al menos no al 100%. Si el apoyo de una empresa externa hay muchas cosas a las que no hubiéramos llegado, y aún así se ha trabajado lo suyo. La experiencia es positiva, pero no sé si es extrapolable. Sevilla por ejemplo está muy lejos para que sea la misma empresa.

En cuanto a contenidos, creo que estábamos perdiendo a cierta parte del sector que debería estar involucrada en la CAS, la parte técnica. En esta CAS hemos visto un enfoque de como conecta la parte técnica con la gestión y el negocio que por las reacciones que he escuchado me hace pensar que algo ha hecho bien el equipo de contenidos: gente muy involucrada en la parte técnica está satisfecha con lo que se ha hablado dentro de la CAS. También es verdad que otra parte aún no, y se han echado en falta charlas más técnicas. Personalmente siempre he creído que esto va de aproximar a la gente de negocio y de desarrollo para hacer el mejor producto posible, así que no concibo una parte sin la otra, y creo que se importante que sigan estando representadas dentro de la CAS.

Qué funciona haciendo software y por qué

En la pasada CAS hubo una keynote en la que se hablaba de estudios relacionados con el desarrollo de sofware, y de su “relativa” validez. Estoy muy de acuerdo en que algunos de estos estudios dan un poco de risa, y de hecho ya hice ese ejercicio de analizar dichos estudios hace unos años. No estoy muy de acuerdo con el mensaje, que se reducía IMHO a “No te fíes de nada, prueba con todo a ver si a ti te funciona” utilizando los mismos argumentos y estrategias que se critican cometiendo algunos errores de bulto, pero es no es la cuestión principal.
La cuestión cuando llegamos aquí es: ¿es posible medir los beneficios de determinadas prácticas desarrollando software?  San Martin de Fowler habla de la evidencia anecdótica para referirse a prácticas que funcionan en un caso como algo útil en ausencia de datos objetivos (dado que opina que no podemos medir la productividad). Efectivamente los equipos de software son sistemas muy complejos en los que es muy difícil medir como una práctica determinada influye en nuestro rendimiento más allá de sensaciones, no tenemos la regla de medir la productividad y así poder decir al finalizar una iteración que, por ejemplo, hacer programación por parejas a aumentado/disminuido nuestra productividad en un x%. Bajo mi punto de vista esto tiene varios problemas:
  • En primer lugar no tenemos esa regla para medir productividad. Normalmente funcionamos más por sensaciones, por lo que nos parece que funciona, que con datos objetivos, por lo que nos quedamos siempre en el terreno de lo discutible (y ahí seguimos, discutiendo).
  • Digamos que podemos medir la productividad en historias/puntos/loQueSea, siempre tendremos una medida relativa que para cada equipo y que sólo funciona para ese equipo, lo que limita mucho la validez y generalización de estas medidas. Eso suponiendo que funcione algo para ese equipo, porque en muchas ocasiones esas métricas no existen.
  • Aunque encontráramos esa manera de medir la productividad, si algo está demostrado es que el esfuerzo dedicado a mantener un software es mayor que el esfuerzo dedicado a su desarrollo inicial, por lo que habría que medir también la “mantenibilidad” de dicho software, lo que bajo mi punto de vista es aún más complicado.
Dicho esto, retomo la pregunta, ¿es posible medir los beneficios de determinadas prácticas? Parece complicado, y aunque existen muchos estudios de todo tipo, no hay conclusiones claras, o al menos y no las conozco. Es difícil aislar un estudio de todos los factores externos que hemos comentado, pero eso no quiere decir que sea imposible. Quizá no hemos encontrado la manera correcta de hacerlos, o quizá realmente no nos interesa contar con esos datos como industria, y preferimos movernos en el terreno de la incertidumbre, y seguir vendiendo humo que parece que funciona bien.
Hay personas en este mundo que han construido un acelerador de partículas para acelerar átomos a velocidad absurda para durante un tiempo infinitesimal podar visualizar elementos cuánticos como el Bosson de Higgs, y resulta que la industria del software no es capaz de comprobar si dos personas en el mismo ordenador programando rinden mejor que una. Francamente me resulta desolador, pero si existen intentos de llevar esta experimentación un poco más allá: https://vimeo.com/9270320 ( vía un tweet de @javisantana).

2015

Otro año más que termina. En 2015 he tenido otro cambio laboral, el anterior proyecto en el participaba dejo de motivarme por distintas razones; la principal es que básicamente no me lo creía. Una pena, la verdad, porque era un grupo de personas estupendo, pero opté por pasar página. En setiembre empecé en Plain Concepts, nueva empresa, nuevos compañeros, nuevo rol, nuevas tecnologías… todo muy nuevo. Entre otras cosas he empezado con .NET, he arrancado un IIS, utilizo Outlook y todo lo que sea Ms. Como con todo, cosas mejores y peores, pero eso es otra entrada que no se si sucederá. De momento (a falta de evaluación oficial), parece que más o menos encajo con equipo y no he hecho el ridículo en las cuestiones en las que he estado involucrado; de todas maneras, aunque progreso adecuadamente necesito mejorar, y veo que me cuesta meter horas para hacerlo. Decía Chad Fowler que hay que ser el peor saxofonista de la banda para progresar; lo de progresar no sé pero ser el peor me ha salido estupendamente.

Me está saliendo una entrada de recapitulación anual, así que vamos con los objetivos:

  • Consolidar el cambio. Encontrar mi sitio y mi papel en Plain para que sea una alternativa sostenible en el tiempo.
  • Seguir corriendo 🙂 Después de una media maratón, me queda la maratón completa. No tengo claro si tengo el tiempo y la motivación necesarios, lo iremos viendo.
  • Dibujar más. Últimamente he hecho bastante sketchnoting de ese, y me apetece desarrollarlo un poco más.
  • Seguir haciendo compatible mi vida personal con la profesional 🙂 suena a perogrullo pero a veces se me va la olla.

Urte berri on!!

Primera semana

Esta semana he empezado una nueva andadura en Plain Concepts, después de salir de Init buscaba algo que fuera a la vez un sitio donde aportar y aprender mucho. He aterrizado en un entorno a la vez conocido y desconocido. Conocido por la parte ágil, Plain ha sido referente en la comunidad desde siempre y su apuesta por este tipo de enfoque es clara; desconocido porque no estoy nada familiarizado con el entorno de trabajo, desde Windows hasta la plataforma .NET. Por alguna razón que se me escapa han decidido que es un obstáculo superable y en ello estamos.

Ha sido una semana de aprender un montón de cosas, de hacer muchas que no pensaba que sucederían (instalar Windows 8, Windows 10, Visual Studio, arrancar un IIS, arrancar una apliación en ese IIS, desplegar en Azure, estrenar un ordenador muy muy feo aunque muy potente…) y de situarme en dónde puedo aportar algo. En fin, espero que sea la primera semana de muchas 🙂

2014

Ya llevo un par de años evaluando el año en menos de 25 líneas 🙂 Este 2014 ha estado sin duda marcado por un cambio laboral. Estoy con un grupo de personas estupendas, pero aún tenemos mucho trabajo por hacer en muchos ámbitos:

  • Construir equipo. Hace 7 meses cuando empecé aquello era una banda, no un equipo. He descubierto que se pueden hacer un montón de cosas al respecto no haciendo. Sólo con estar, como el Cid, vamos. Por lo que me dicen, de alguna manera mi campo de fuerza ha contrarestado el de otras personas y el equipo se ha sentido más a gusto para tomar sus decisiones.
  • A nivel económico, necesitamos un poco más de margen para estar más cómodos. Es evidente, pero el bienestar económico te permite hacer un montón de cosas que de otra manera no puedes (ver punto siguiente). Y con esto me refiero a pagar a proveedores, gastos a los trabajadores, ajustar las nóminas a la valía e incluso el dinero que nos gastamos en un ordenador, un curso o un libro.
  • Respirar. Desde que llegué, no dejo de repetirme que para trabajar en una consultora al uso me voy a mi casa. Mi objetivo personal es trabajar poco, ganar mucho y pasarlo bien en el proceso. Si tenemos tanto trabajo que no podemos pararnos a pensar que hacemos bien y como mejorarlo, nunca voy a cumplir mi objetivo. Así que es necesario respirar, y pensar que por dejarnos dos horas en una retrospectiva el mundo no se acaba.
  • En otro orden de cosas, me he hecho runner que está de moda. Ya he corrido hasta 16 kms del tirón, igual llego hasta una media maratón en algún momento, aunque el objetivo no es haces distancia ni carreras, sino estar en forma.
  • Ya había leído que al trabajar con horario flexible el problema es trabajar demasiado, y es verdad. Hay que encontrar el balance entre trabajo y vida personal, por mucho que te guste tu trabajo. Otro objetivo para este año.

Feliz 2015

Mina

Ayer fuimos a cenar al restaurante Mina. No suelo comentar este tipo de cosas por aquí, pero es que fue una experiencia excepcional, tanto en lo culinario (apecto en el que no voy a entrar) como a nivel de trabajo en equipo. Tienen una modalidad de cena que consiste en cenar en la barra del bar, viendo como trabajan en la cocina, que es totalmente abierta. Y la verdad es un placer verles trabajar:

  •  Cero prisas en todo momento. Limitan el aforo del local a 25 comensales, que es el número que han visto que manejan bien, o mejor dicho, muy bien. Calidad sobre cantidad.
  • Esa ausencia de urgencia les permite cuidar el detalle a todos los niveles. Presentación de los platos, explicación de los mismos… Mucho que aprender de como no trabajar demasiado permite a la larga trabajar más y mejor, porque evitas el trabajar dos veces.
  •  Cero indicaciones. Todo el mundo sabe lo que tiene que hacer en todo momento, como mucho se susurran al oído.
  •  Coordinación visual. Tienen un tablero en el que recogen la información de como va cada mesa, lo que han servido… el menu degustación tiene 10 platos, así que más nos vale saber donde vamos en cada momento.
  • Punto extra ver al chef y propietario fregar la cocina al terminar junto con toda la brigada.
  • Colaboración, colaboración, colaboración… todo funciona con un mecanismo bien engrasado, como si estuviera coreografiada toda la actuación.

En resumen, quiero que mi equipo trabaje como estas personas, como Alvaro mismo dice, “no tengo un equipo, tenemos un comando“, un sitio en el que evolucionar y mejorar. Amén.

¿Que voy a hacer mañana? Lo mismo que ayer, seguir trabajando.

Contrastes

Siempre que acudo a una conferencia, evento o socialización con otros profesionales (de mi gremio o de otros), lo que me gusta encontrar son contrastes. Espejos en los que mirarte, para no verte reflejado, o al menos no completamente. Que te devuelvan una imagen nueva de ti mismo, de lo que deberías ser, o al menos tender hacia ello. Que te hagan pensar sobre ti, lo que haces y como lo haces. Que te movilicen, en definitiva.

Estos días encontré un reflejo diferente de mi mismo. Alguien que dejo un trabajo buscando ser más feliz. Me suena un poco. Y evidentemente me vi reflejado, pero distinto. Me obligo a la retrospectiva de tres semanas de trabajo en un minuto. La verdad que que ya la tenía hecha, porque he aterrizado tan de golpe en un campo de batalla donde se libra una guerra feroz, que en principio vamos perdiendo, que se me ha olvidado (un poco) porque vine. Y como terapia voy recordármelo.

Vine a ser más feliz trabajando. Vine a trabajar en un equipo autoorganizado de alto rendimiento. Vine a buscar la excelencia técnica que nos permitiera ser más efectivos desarrollando el software maximice el valor que aportamos al cliente. Vine a enderezar el rumbo de una nave que se estaba desviando, intentado transformar o al menos contribuir en ese cambio hacia equipos autoorganizados intraemprendedores. Vine a ser ágil, con TODO lo que significa.

No vine a una consultora normal, y no quiero estar en una consultora normal. Así que hagámosla especial. Un poco cada día. Empezando hoy.

Gracias, #aos2k14