Qué no es la agilidad


Creo que está bastante aceptado dentro de la industria de desarrollo de software que la forma en la que se obtienen mejores resultados es siendo ágil, aplicando metodologías ágiles que permitan obtener software lo más cercano posible a las necesidades y que el proceso de desarrollo sea lo más sostenible posible.

En muchas empresas la alta dirección acepta el concepto de agilidad pero no tienen claro lo que es ser ágil y mucho menos, lo que no es ser ágil.

Creo que todos tenemos claro que desarrollar software no es un proceso industrial, proceso tipo con el que se ha querido comparar durante varias décadas, es algo diferente. Los actores son diferentes, el resultado es diferente, la manera de obtener el resultado es diferente.

No soy la persona más adecuada para decir qué es la agilidad, para eso hay gente muy buena divulgando sobre ello como Javier Garzás al que sigo desde hace tiempo, pero si quiero listar una serie de cosas que, bajo mi punto de vista, muchas veces llevan a confusión y que mucha gente cree que tienen que ver con la agilidad y no es así. Esta confusión es mayor entre la alta dirección que no está estrechamente ligada con el desarrollo de software:

  • No hay que documentar. Quizá la confusión viene porque en proyectos en cascada hay mucha documentación y en contraprestación mucha gente cree que en metodologías ágiles no se documenta. Nada más lejos de la realidad. Hay que documentar igualmente aunque otras cosas o de otra manera. Los epics deben tener una descripción suficiente, las historias de usuario necesitan estar documentadas, incluso el definition of ready o el definition of done debería estar documentado para no tener lugar a dudas. Es importante tener claro que ser ágil no es sinónimo de sentar a cuatro o cinco personas alrededor de una mesa a desarrollar lo que a uno de ellos se le acaba de ocurrir, sin estructura ni análisis previo.
  • El alcance se puede cambiar en cualquier momento. Es cierto que las metodologías ágiles nos separan de un desarrollo en cascada en que el alcance no tiene que estar cerrado ni firmado a fuego antes de empezar, pretenden tener un proceso más iterativo que permita que el resultado sea lo más cercano posible a lo que necesito. Pero de ahí a cambiar el contenido de un sprint en curso, cambiar la visión del producto o símplemente dejar de hacer lo que se tenía previsto para hacer lo que a un iluminado se le ha ocurrido hoy, hay un paso muy grande. Sí a tener un proceso iterativo vivo; no a ir como pollos sin cabeza.
  • No hay fechas. Es uno de los errores más comunes. Hay gente que piensa que porque esté usando metodologías ágiles no tiene que comprometer una fecha. Se puede y se debe comprometer una fecha. Lo que no está cerrado es la lista de funcionalidades que se entregará en una fecha o el detalle de cada funcionalidad. Eso está vivo y cambiarlo depende de muchos factores (daría para hablar mucho sobre esos factores) pero poner una fecha yo creo que es sano.
  • No hay managers, no hace falta gestión. Este es quizá el punto más controvertido. Cuando hablamos de equipos ágiles hablamos de equipos autogestionados. Por definición son equipos que no necesitan la figura de un manager ya que todo el mundo sabe lo que tiene que hacer y el propio equipo busca el mejor resultado por si mismo, con una dinámica siempre positiva. Este modelo puede funcionar en equipos donde todo el mundo es bastante senior, ya ha trabajado con metodologías ágiles anteriormente y el tamaño del equipo no es demasiado grande (3-6 personas). El problema viene cuando no se cumplen estos puntos. Es decir, hay personas más junior que necesitan de gestión y supervisión técnica, alguien tiene que ser su mentor. También cuando el equipo trabaja en un subproducto de un producto grande. En este caso hay que mantener una estrategia y táctica tecnológica común entre todos los equipos de subproducto y por tanto hay un marco de decisión más amplio que el del propio equipo. Por último, la gestión es necesaria cuando se quiere escalar los equipos ágiles, cuando hace falta ser más rápidos y se requiere de más gente trabajando. Pasar de un equipo de 6 personas a un equipo de 40 trabajando en un producto no es nada fácil y eso se tiene que hacer de manera ordenada y bien gestionada para evitar que sea un caos. En este caso hace falta una gestión y liderazgo compartido entre todos los equipos.

 

Es muy posible que esté equivocado en algún punto o que alguien no comparta mi visión. Por favor, no dudéis en comentar el post y darme vuestro punto de vista al respecto.

Por qué corro


Como algunos ya sabéis porque de vez en cuando doy el coñazo por Twitter publicando mis sesiones de entrenamiento, una de las actividades que hago habitualmente es correr. El otro día iba haciendo una tirada de 15km y estaba tan a gusto y disfrutando que me di cuenta que las razones por las que corro actualmente nada tienen que ver con las razones por las que empecé a correr hace dos años.

Cuando empecé a correr buscaba una actividad que pudiera hacer a medio día, que fuera flexible a nivel de horarios y de días de práctica y me permitiera estar un poco en forma y perder algo de peso. No nos engañemos, el peso es como el paso de los años: va creciendo poco a poco y sin darnos cuenta, sin cambiar nada, cada año que pasa la báscula marca algún kilo de más que es dificil de perder. Si eso ocurre durante varios años te encuentras rozando los 40 y bastante lejos de tu peso ideal, lo que afecta principalmente a nivel de salud.

Aprovechando que en Fon tenemos duchas en la oficina y que estamos en Las Tablas (Madrid) que es una zona más o menos abierta, pensé que correr me podía ayudar a perder peso y recuperar la forma, además de ser una actividad que cumplía los requisitos que he mencionado anteriormente.

Pero actualmente la motiviación para salir a correr no tiene que ver con mantenerme en forma o perder peso. Tras dos años corriendo dos o tres días a la semana he conseguido que me guste correr, disfrutar durante el tiempo que estoy practicando esa actividad, sentirme como si algo me falta si una semana corro dos o menos días y, para mi los más importante, poder estar ese tiempo sólo con mis pensamientos.

A lo mencionado anteriormente hay que unir uno de los puntos principales: cuando corro por Boadilla del Monte, localidad de Madrid donde resido, lo puedo hacer por el monte y eso me da la oportunidad de estar en contacto con la naturaleza, de poder disfrutar el aire limpio, un paisaje impresionante, un cúmulo de olores frescos, etc… en definitiva, reforzar la sensación de bienestar que me proporciona correr.

Poder disfrutar de hacer una actividad física al aire libre y en el monte ha sido una de las razones por las que he empezado a salir con la bici de montaña. De la mano de mi amigo y compañero Javier, he empezado a practicar otro deporte que me proporciona similares sensaciones y bienestar que correr. Intento salir una mañana del fin de semana con la bicicleta y siempre buscando rutas que vayan por monte. Poder estar en contacto con la naturaleza me aporta mucha energía positiva y me permite recargar las pilas.

Mucha gente piensa que correr es aburrido y no puedo negar que al principio a mi también me lo parecía y tenía que buscar la motivación para salir a correr en mis ganas de bajar de peso pero a día de hoy no necesito buscar una motivación externa. Es necesario ser constrante durante algo de tiempo pero si se le dedica ese tiempo, merece la pena.

Os animo a todos a hacer deporte y si puede ser en contacto con la naturaleza, mucho mejor.

Retomo el blog


Joder, hace mucho que tengo el blog olvidado. De hecho la última entrada era de cuando trabajaba en etece y desde entonces ha llovido mucho.

En septiembre de 2.014 dejé etece y me incorporé a Fon como director de desarrollo de software. Puedo decir que aquí he encontrado mi casa profesional por muchos motivos pero lo principal sería porque Fon tiene lo bueno de una empresa pequeña como estar constantemente haciendo cosas nuevas, nuevos productos, nuevos desarrollos, un ambiente cercano y familiar, etc… Pero también tiene algunas cosas buenas de una empresa grande como un negocio rentable y estable, trabajar en un entorno multinacional con los mejores clientes, sentirte arropado con una gran familia de más de 150 miembros…

A partir de ahora voy a retomar el blog y voy a volver a escribir habitualmente. Mi idea es tratar temas profesionales de tecnología pero también algunos de opinión personal.

Los primeros que tengo en mente son deuda técnica oculta, transformación hacia devops, cómo usamos AWS en Fon, cómo intentamos ser ágiles en Fon, el stack tecnológico de Fon…

Si hay algún tema que os interese especialmente o alguna sugerencia, no dudéis en añadir un comentario y hacermelo saber.

Un saludo

Nuevo diseño de etece.es


Hoy hemos subido a producción el nuevo diseño de etece.es. Con este rediseño no sólo queremos darle un lavado de cara a la web, que falta hacía, si no que perseguimos dos objetivos principales:

  1. mejorar la comprensión y experiencia de los nuevos usuarios que aterrizan en nuestra web
  2. mejorar el posicionamiento orgánico

diseño_etece

El primer objetivo, el de mejorar la comprensión de nuestro modelo y mejorar la experiencia de nuevos usuarios, estamos convencidos de alcanzarlo ya que el rediseño se ha hecho en base a los resultados de un test de usuarios que hicimos hace dos meses y donde aprendimos cómo usan nuestra web los nuevos usuarios, qué entienden de nuestro modelo y qué y dónde esperan encontrarlo.

El segundo objetivo, el de mejorar el posicionamiento orgánico, lo pretendemos conseguir mediante la inclusión de más contenido que trabaje de manera natural nuestras palabras clave. Este es más complicado porque nunca sabes a ciencia cierta si los cambios van a ser a mejor, pero estamos confiados de ver los resultados en un plazo de seis meses.

Espero que os guste el nuevo diseño y, como siempre, cualquier crítica constructiva es bienvenida.

El diseño responsive no siempre es lo mejor


Últimamente todo el mundo apuesta por el diseño responsive y tiene sentido. Con un único diseño que se adapta a los diferentes tamaños de pantalla estoy dando a mi usuario la mejor experiencia en mi web. Pero no siempre es la mejor alternativa si tenemos en cuenta las diferentes condiciones que rodean a la navegación desde diferentes dispositivos. Un smartphone puede acceder a Internet a través de WIFI o a través de la red móvil, mucho más lenta. Lo mismo pasa con las tablets aunque en este caso el porcentaje de accesos a través de WIFI es mucho mayor que a través de la red móvil. Esta sutil diferencia puede suponer que la experiencia de un usuario sea completamente diferente en función de cómo esté accediendo a Internet.

Veamos dos ejemplos diferentes:

  • etece.es
    • diseño responsive: no
    • versión web móvil: si
    • peso de la home de escritorio: 477,5 KB
    • peso de la home móvil: 140,2 KB
  • otogami.com (espero que los camaradas del metal no les importe que la coja como ejemplo)
    • diseño responsive: si
    • versión web móvil: no porque ya tienen el diseño responsive
    • peso de la home en tamaño escritorio: 478,5 KB
    • peso de la home en tamaño móvil: 473,5 KB

Como podéis ver, aunque lo esté viendo en un tamaño mucho más pequeño, el diseño responsive necesita cargar la mayoría de los elementos que existen en una versión web de escritorio y por tanto el peso de la home es prácticamente el mismo.

Si tenemos en cuenta que una conexión 3G media en España está en torno a los 1,5Mbps (fuente adslzone.net) , esto supone unos 192 KB por segundo. Es deir, la home de etece en un móvil por 3G se cargará en menos de un segundo mientras que la de otogami tardará 2,5 segundos. A lo mejor esa diferencia de tiempo no supone un cambio en la experiencia de usuario en algunos casos, aunque en algunos otros puede ser la diferencia entre que el usuario se quede en mi web y acabe convirtiendo o que el usuario abandone.

Además de las razones que tienen que ver con experiencia de usuario, hay otras razones técnicas por las cuales el diseño responsive no siempre es la mejor opción. Si consideramos que un hilo de Apache está ocupado durante todo el tiempo que dura la descarga de lo que esté subiendo, con diseño responsive estaré consumiendo 2,5 veces más tiempo que con una versión móvil específica. Eso supone recursos de mi servidor o lo que es lo mismo, podré soportar más usuarios concurrentes desde dispositivos móviles con el mismo hardware si uso una versión móvil específica frente a un diseño responsive.

Durante todo el post estoy diciendo que el diseño responsive no es siempre la mejor opción lo que quiere decir que hay veces que si que lo es. Cuando el peso de una página es bastante bajo, no merece la pena hacer una versión web y es mucho mejor tener un diseño responsive. Soy especialmente fan de los diseños responsive en webs de contenidos muy sencillas tipo wordpress y similar.

Me encantaría que este post abriera un debate y espero no quedarme solo defendiendo las versiones web móviles específicas.

¿Usarías un navegador desarrollado por Facebook?


Seguramente la respuesta fuera NO. En mi caso, sin duda, la respuesta sería no. No, porque siempre tendríamos la duda de qué uso haría Facebook de mis datos en su propio beneficio, como por ejemplo publicidad.  Igual que es la respuesta a la pregunta ¿usarías un navegador desarrollado por Google?

Vaya por delante que utilizo a diario muchos de los productos y servicios de Google. Uso Gmail tanto a nivel particular como a nivel personal, uso Drive y Gdocs, utilizo de vez en cuando Google+ para compartir contenido, tengo un móvil con sistema operativo Android, etc… Es decir, Google ya tiene muchísimos datos sobre mi vida. Pero, pudiendo elegir, no quiero que tengan mis datos de navegación. No porque esté permanentemente navegando por páginas porno o por sitios que no quiera que se sepa si no porque prefiero que esos datos estén en manos de una fundación como Mozilla que me despierta mucha más simpatía. Por eso uso Firefox, tanto en el móvil como en el PC tanto en Ubuntu como en Windows.

Está claro que hoy en día es imposible tener privacidad digital. Nuestros datos, emails, fotos, comentarios, etc… están en la red y es imposible que no lleguen a manos de las empresas. Después entramos en la disyuntiva de qué hacen esas empresas con los datos. Igual hacen como Google y firman un acuerdo con la NSA o igual los protegen como oro en paño, cosa que dudo.

Tengo la sensación de que el navegador más usado por la comunidad de profesionales técnicos y de Internet es Google Chrome. Esa misma comunidad cada vez usa menos Facebook y cada vez es más cuidadosa con lo que comparte de su vida personal en las redes sociales. No obstante, usa Chrome con la sesión de Gmail iniciada, para que no quede duda de quién es y Google pueda tener información de primera mano del uso que hace del que es, posiblemente, el software más usado en un PC, en navegador de Internet. Si Firefox no me gustara o fuera una mierda de navegador como lo es Internet Explorer, también usaría Chrome, igual que si la fundación Mozilla tuviera un webmail tan bueno o casi tan bueno como Gmail, también lo usaría en detrimentro de éste último.

Habrá mucha gente que diga que Chrome es el mejor navegador que hay, opinión que respeto y que llevaría a abrir un debate sin fin. No es el objetivo de este post. Símplemente, si no te importa, por favor, dime qué navegador utilizas y así podré confirmar o desmentir mi sensación de que los más técnicos son los que más datos de su vida le dan a Google:

Pacto de socios: estructura y cláusulas


Ayer leí un artículo interesante de Iñaki Arrola, no todo vale, donde comenta las prácticas que no son aceptables de un VC cuando invierte en una startup. Ese post tiene una serie de comentarios que merece la pena leer y donde se hace especial mención al hecho de que un emprendedor es responsable de lo que firma y en qué condiciones, con lo que estoy totalmente de acuerdo.

Tras leer y reflexionar sobre el artículo, me ha venido de nuevo a la mente lo importante que es tener un pacto de socios correcto, sencillo y que permita fácilmente que nuevos socios lo suscriban. No soy experto en pactos de socios y sólo he visto los de las empresas en los que soy fundador. Cualquier business angel tiene más experiencia y conocimiento que yo pero espero que pueda ser útil.

En etece tenemos un pacto bastante bueno y sencillo pero no tengo el visto bueno de los socios para publicarlo. No obstante, en tagUin también teníamos uno bastante bien atado y ese si que puedo, como poco, publicarlo sin datos concretos y comentar la estructura que sigue.

Como todo contrato, debe tener los diferentes apartados de primer nivel:

  1. Reunidos: donde se deben detallar todos los datos de los firmantes del pacto de socios. Si son particulares debe aparecer nombre y apellidos, domicilio, DNI y el estado civil. En caso de estar casado en régimen de gananciales, deben apareceder los datos del cónyuge. Si el firmante es una empresa, deben aparecer los datos fiscales como razón social, domicilio y CIF.
  2. Comparecen: es normal la frase “todos en su propio nombre y derecho” aunque en el caso de empresas, debe aparecer los datos del firmante representante de la empresa con nombre, apellidos y DNI. Es normal terminar este apartado con “Todos los comparecientes se reconocen mutuamente con capacidad jurídica necesaria para suscribir el presente documento. “.
  3. Manifiestan: en el caso de tagUin, aprovechamos este apartado para distinguir entre socios fundadores y socios inversores, ya que algunas cláusulas sólo aplicarán a los fundadores y así queda hecha la descripción de los grupos y a quién aplica.
  4. Condiciones: este es el punto clave. A continuación os detalle las condiciones que teníamos en nuestro pacto:
    1. Permanencia. En este puto regulamos la obligación de permanencia de los socios fundadores durante el tiempo pactado y el salario que percibirán.
    2. Competencia. Se acuerda que los socios fundadores no pueden trabajar para otras empresas del sector durante su periodo de trabajo en la empresa y durante un tiempo después. Se podría hacer extensivo, en parte, a los inversores aunque me parecería algo exagerado.
    3. Actividades paralelas. Se pretende regular cualquier tipo de actividad profesional, externa a la empresa y por la que los socios fundadores reciban remuneración. En este caso había compromiso de comunicación al resto de socios de dicha actividad y se dejaba a los socios no fundadores la posibilidad de vetar dicha actividad. Añadimos una excepción que correspondía al caso en que la empresa no pudiera pagar los salarios indicados en el punto de permanencia.
    4. Confidencialidad. Típica cláusula de no difusión de información tanto cualitativa como cuantivativa de la empresa.
    5. Salida forzada de la compañía. En caso de incumplimiento de los puntos 1,2,3 o 4 o en caso de despido procedente por causas objetivas, en este punto se regula cómo se debe proceder, cuántas particpaciones y a qué precio debe vender y a quién el despedido. A priori pensamos que todo va a ir bien pero hay que tener en cuenta que en la vida de una startup pueden pasar muchas cosas y a veces hay que tomar decisiones dolorosas.
    6. Salida acordada de la compañía. Es el caso en que todas las partes acuerdan la salida de un socio fundador. Es parecido al punto anterior aunque menos restrictivo ya que la salida es por acuerdo mutuo.
    7. Transmisión de participaciones. En este punto se acuerda que cuando hay una trasmisión de participaciones causada por el punto 5 o 6, los socios no fundadores renuncian a su derecho de adquisición preferente para que sean los socios fundadores quienes compren las participaciones de socio fundador saliente.
    8. Convocatorias. Se acuerda que las convocatorias y comunicaciones se harán por email, evitando así tener que convocar las juntas por correo certificado.
    9. Comunicación de venta. Obligación de comunicar al resto de socios cualquier intención u oferta para venta o compra de participaciones.
    10. Tag along. Este es uno de los puntos importantes del pacto. Este punto indica que, ante una oferta para adquirir participaciones, cualquier socio se puede unir a dicha operación, teniendo que comprar proporcionalmente a la oferta las participaciones a todos los que se hayan unido a la operación. Esto permite a socios minoritarios no quedarse “colgados” dentro de la empresa si hay una oferta para comprar parte de las participaciones.
    11. Drag along. Este es el otro punto importante. En él se indica la posibilidad por parte de los socios minoritarios de arrastrar al resto de socios a vender, siempre que haya una oferta para tomar el control de la compañía o por el 100%. Este punto permite a los socios inversores forzar una venta en contra de los fundadores siempre que la oferta cumpla unas condiciones. Está bien para el caso en que los fundadores están cómodos en la empresa, con buen sueldo, pero hay interés de los socios inversores, que no tiene el control de la compañía, en venderla. Nosotros en este punto pusimos dos escenarios: una oferta por el 51% o el control de la compañía; 100% de la compañía.
    12. Órgano de gobierno. Aunque es un punto que debe aparecer en las escrituras de la compañía, aquí se puede regular, en caso de haber un consejo de administración, cuántos cosejeros hay, quién los nombra y cómo se resuelven hipotéticos casos de empate.

Aquí os dejo un enlace al documento para que podáis ver la redacción exacta de cada punto.

Cualquier comentario o corrección es bienvenido, así podemos, entre todos, ir haciendo un modelo de pacto de socios que podamos reutilizar.