Hay gente que te abre puertas, pero hay otros que te abren los ojos. En educación una de las personas que mas me ha marcado ha sido Yaacov Hecht al que tuve la suerte de conocer hace unos años en Madrid gracias mi amiga Marina de Aprendemos Todos.
La primera vez que escuche hablar de educación democrática pensé que no tenía sentido, probablemente lo mismo que estés pensando ahora si es la primera vez que lo lees.
Le he oído decir a Yaacov que el único objetivo del sistema educativo hasta los 15 o 16 años debería ser mantener la autoestima de los chavales a salvo. Y siempre me ha parecido clave, y que es sobre este principio sobre el que tendríamos que construir un nuevo sistema educativo que es la condición necesaria para construir una sociedad mejor.
Empiezo por dar las gracias de nuevo al equipo que organizo el AOS en Bilbao. Esto no es ni mucho menos una crítica a ellos, sino a todos nosotros que aceptamos muchas veces cosas sin darles la relevancia que tienen.
Todo empieza porque se me ocurre leer el código de conducta del AOS que no tiene nada de especial, hasta donde yo se fue una copia del código de conducta de otras conferencias parecidas. Hasta aquí nada que reseñar.
Yo no pensaba hacer ninguna de las cosas que «prohíbe» el código, así que no me afecta demasiado. Cuando estoy en sociedad procuro ser respetuoso con todo el mundo. Pero la tolerancia tiene un limite como explica muy bien Enrique Dans en su artículo sobre la paradoja de la tolerancia.
Mi crítica hacia el código es que acepta como intolerables algunos comportamientos, en especial todo lo que tiene que ver con el género y el sexo, pero se deja otros que no tiene en cuenta. A título de ejemplo el código de conducta no prohíbe quemar billetes de 500 € mientras el ponente se jacta de la miseria de muchos.
O permite a los ponentes usar fotos de gatitos que como todo el mundo sabe para muchas personas son un claro ataque a su libertad sexual y les coloca en situaciones incomodas.
Es decir, como resultado de una cultura muy mojigata (creo que la norteamericana) hemos decidido que la forma correcta de tratar temas sexuales es la suya, y que por tanto cualquier otra manera de verlo queda fuera.
Al mismo tiempo otras cosas abiertamente inmorales, para mi y puede que para mas gente, no quedan relegadas porque en la cultura mayoritaria son aceptables.
En la última y desternillante sesión de mindfulless , donde hicimos una parodia de muchas de las modas ágiles de hoy en día, estoy seguro de que alguien se podría haber sentido ofendido, pues estábamos riéndonos de cosas que para algunos son importantes. Pero no tienen derecho a prohibirnos hacerlo por el hecho de que les moleste u ofenda.
Mi queja al respecto tiene que ver con el control que se impone de los «ofendiditos» y como poco a poco vamos cediendo espacios de libertad. No podemos poner el límite de la libertad de expresión en que no debemos molestar a alguien, porque siempre hay alguien que se sentirá ofendido por otro, y yo creo que el limite a la libertad de expresión no podemos ponerlo en cuanto ofende al que lo escucha.
Si en una charla o ponencia alguien usa o dice algo que te ofende, es bien fácil, te levantas y te vas, pero no permitamos que se restrinja la libertad de expresarnos.
No pienso usar fotos de lo que la mayoría considera contenido sexual en mis presentaciones, pero nadie nunca me impedirá usar fotos de gatitos.
En primer lugar quiero empezar dando las gracias al equipo que ha organizado el AOS, muchas gracias por todo vuestro trabajo. Vuestro esfuerzo ha hecho posible que otros pasáramos un gran día. Muchas gracias.
Cada vez me gustan mas los Open Space y menos las conferencias. En las conferencias me suelo quedar en los pasillos, aquí pasan cosas en los pasillos pero en general las “charlas” son los pasillos. He aprendido, conocido gente nueva, confirmado algunas percepciones y descartado otras, espero haber aportado mis dos centavos, y me he reído mucho haciendo que no hacía mindfullless, y encima me he descertificado holísticamente. Me quedo con la frase de que las “silent retros” son como la homeopatía.
Me llevo de este AOS:
La confirmación de que hay mucho humo alrededor de ágil . Agil está de moda, y todo el mundo es ágil, pero me vuelvo con la confirmación de que mucho del humo tiene que ver con no adoptar los valores, sino sólo las prácticas. Y aunque las prácticas te pueden llevar a cambiar los valores, me temo que ese camino es difícil.
Hay mucha gente explicando a los demás como tienen que ser ágiles, muchas de las conversaciones no tenían que ver con como ser “mas ágiles”, sino en cómo hacer que otros sean ágiles. He visto mucha gente empeñada en que los demás sean ágiles, pero yo ya, si eso, otro día.
Hay un montón de gente peleando pro ser ágile en entornos muy difíciles, he conocido gente de Zara que está peleándolo o el equipo de la diputación de Álava. Enhorabuena luchan contra gigantes donde debe ser una batalla cada minuto.
Quizás lo que hace falta es mas VERDAD que dirían los taurinos. Yo creo que hace falta menos foco en las herramientas y los procesos, y mas en los valores.
Me quedo con la tarea de buscar formas de hacerle hueco a la VERDAD (no la mia, sino la taurina ) en el mercado. Creo que el riesgo de que el humo acabe ahogando los principios ágiles es real. Yo creo que muchas organizaciones van a fracasar por falta de verdad, y el mercado culpará a los valores.
Hay muchas prácticas en muchas empresas interesantes. Necesitamos mas espacios para compartir prácticas, no grandes transformaciones, si no cosas pequeñas a las que a veces no damos valor pero que pueden tenerlo para muchos.
El manifiesto se ha hecho mayor, pero sigue sirviendo. Es para muchas organizaciones todavía inalcanzable, pero para otras sigue siendo una guía para la mejora.
Necesitamos encontrar la manera de incorporar a espacios como el AOS a mas gente que trabaja de manera ágil, y un poco menos de gente que te explica como tienes que trabajar para ser ágil. Está bien contar con expertos, formadores, coaches, etc. Pero yo creo hace falta mas gente de los equipos que lo practican día a día.
Por último, esperaba oír algún mensaje del tipo lo que vosotros hacéis no es ágil, y con alegría he recibido mas la impresión de que a mucha gente le ha parecido que lo que hacemos es ágil aunque no contennos con todas las ceremonias o herramientas. Creo que está bien entender que ágil no es rígido (vaya obviedad). Me vuelvo mas convencido de lo que vine de que lo importante son los valores y los principios.
Ah, y una cosa mas: Gracias mil al equipo. Os debemos la experiencia estupenda que ha sido el AOS 2019.
Últimamente ando enfrascado en conversaciones interesantes sobre desarrollo de software, empezamos con la discusión sobre metodologías y frameworks, luego hablamos de tests.
En esa conversación uno de los principios ágiles que fue mencionado es:
«Continuous attention to technical excellence and good design enhances agility.»
El problema surge sobre lo que es la excelencia, quizás sobre esto tenemos visiones distintas.
Yo creo que la excelencia no es una propiedad del software aislado del contexto. Me explico, un sistema con triple cifrado más doble autenticación más 4 códigos de verificación de las integridad que está lleno de tests, y bien documentado. Que también sigue los mejores patrones de diseño y que ha sido refactorizado varias veces…. Puede ser una excelente pieza de software salvo que todo eso no fuera necesario.
Es verdad que el manifiesto dice que la entrega de software que funciona es la principal guía para el avance. Pero eso tiene que aportar valor de negocio.
No basta, además con aportar valor, hay que aportar más valor de los que cuesta producirlo. Parece una obviedad pero yo creo que a mucha gente ser le olvida. Por no hablar de qué es más importante el valor percibido que el aportado (otro post).
En ese contexto el artículo que recomendó:
El otro día @jmbeas decía que si el software no tiene tests se puede decir que no fue construido ágilmente, y yo discrepo un poquito: https://t.co/1Iy80MRu2p
Es claro que hacer mal software tiene coste as largo plazo, y no voy a ser yo quien lleve las contraria al Sr. Fowler. Pero en ese mismo artículo está bien claro que al principio del proyecto es más caro hacer el software «cómo dios manda».
Y también está claro que eso al final se paga. Pero yo creo que la solución no es perseguir la excelencia técnica de las primera línea de código.
Yo creo que en un proyecto que arranca los tests al principio son un cierto desperdicio. El proyecto en las primeras fases tiene un enorme nivel de incertidumbre, y creo que la mejor manera de resolverlo es salir a probar en real lo antes posible (Siempre que el coste del error lo permita #otropost 😉 ), y una vez el mercado te ha dicho si el proyecto está bien o no, entonces es el momento de invertir en tests.
Es decir, yo creo que el problema no es si debemos hacer tests o no, el problema es cuando debemos hacerlo, y yo creo que se debe invertir en tests y mejorar la calidad de tu código una vez el proyecto tiene un cierto grado de estabilidad.
Es verdad que no hacerlo deteriora la “excelencia” de tu código, pero creo que la excelencia tiene que ver con el contexto. Y en muchos proyectos la “excelencia” técnica es un lujo que un equipo con pocos recursos no se puede permitir.
La clave está en no olvidar que la deuda técnica que adquieres (y no escribir tests ayuda a que la deuda técnica crezca) hay que pagarla.
Siempre me ha gustado la metáfora de la deuda técnica, se parece mucho a la deuda de una empresa.
Todos pensamos que endeudarse es un error, y que sería mejor no hacerlo, pero en cuanto sabes un poco de finanzas entiendes que el nivel de endeudamiento es una de las magnitudes mas relevantes que se deben gestionar, e igual con la deuda técnica, endeudarse por las razones equivocadas es un error, igual que lo es no recurrir a la deuda porque endeudarse es malo.
Yo creo que no está mal que un proyecto arranque generando deuda técnica, a veces no tienes dinero para no hacerlo. Y por lo tanto la deuda técnica hay que gestionarla y ser conscientes de que lo que estás haciendo te va a costar ( y puede que no te guste el tipo de interés).
El error es no tener en cuenta la deuda técnica, ignorar que el software que no persigue la excelencia es mas caro a largo plazo y pensar que da igual 8 que 80.
Te podría decir si no fue construido ágilmente. Si no tiene tests, si hay código repetido, si hay muchas dependencias, si los tests no indican funcionalidades orientadas al usuario, si hay funcionalidades a medio construir (p.ej. esperando al backend o al frontend)…
De lo que se puede deducir que si no tiene test el software no fue construido ágilmente. Y yo no estoy de acuerdo, pero 140 dan para lo que dan, así que intentaré explicarme un poco mejor aquí.
No es discutible que ante dos bases de código iguales es mejor la que tiene tests que la que no lo tiene.
Tampoco es discutible que uno de los principios del manifiesto ágil es:
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
Por lo tanto si el software no tiene tests no ha sido construido ágil mente por que se aleja de la excelencia técnica.
El problema surge a la hora de definir excelencia técnica. Yo estudiaba de pequeño una definición de calidad que siempre me gusto: «Una aplicación de calidad es aquella que satisface los requisitos del cliente». No necesariamente la mejor aplicación desde el punto de vista del puro diseño es una aplicación de calidad.
Y IMHO a veces los requisitos del cliente exigen velocidad, y creo que nadie discutirá que en muchos contextos, en mi caso en todos los proyectos en los que he estado, escribir tests tiene coste, a veces solo en dinero, pero muchas veces también en tiempo.
También el manifiesto hace hincapié en «working software» y una aplicación llena de tests que no hace nada, es muchas cosas, pero no hay «working software».
En alguna de las primeras conferencias Rails, algunos defensores del TDD, famosos muchos de ellos, me decían que yo estaba en el siglo XIX por pensar así, pero luego cuando montaron su propio proyecto el TDD quedó para los clientes.
Yo creo que los tests tienen valor, pero no siempre el valor supera al coste. Y os puedo asegurar que es muy difícil convencer a un cliente de que pague por algo que, sin duda tiene valor, pero el cliente no percibe. En ASPgems insistimos en dotar a las aplicaciones de tests, pro en el momento adecuado, no desde el principio del proyecto.
En NeuroK tenemos una buena cobertura de tests de la aplicación, y procuramos cuidarla y mantenerla, pero el nivel de cobertura cambia con el tiempo, y en los primeros meses de vida de la aplicación el nivel de cobertura era muy bajo.
Como decía un amigo:
En teoría las cosas son iguales en la teoría y en la práctica, pero en la práctica NO.
La reputación no siempre coincide con la realidad, y yo tengo la imagen en el sector de que la imagen y la experiencia de usuario no son cosas que me importen. Los que me conocen dirán que me he ganado esa reputación a pulso. Pero no es que no me importe.
Es cierto, el diseño no está entre mis prioridades y tampoco la experiencia de usuario.
He explicado muchas veces el porqué. Yo creo que un buen diseño y una gran experiencia de usuario son claves para el éxito de un producto o servicio digital, pero que en mi experiencia en proyectos con poco dinero no son objetivos alcanzables. Conseguirlos requiere una enorme inversión que no está alcance de todo el mundo. La calidad de tu producto no crece de manera lineal con tu inversión, sino que pasar de un 80% ok a un 90% ok puede suponer pasar tu inversión de un 20% a un 90%, vamos un “pareto” de libro.
No voy a intentar cambiar mi reputación, al fin y al cabo son muchos años y me la he ganado a pulso 😉
Después de muchos años en ASPgems contamos con un buen producto del que me siento mas que orgulloso, neurok.es . Con los recursos de los que disponemos tiene una interfaz que no se interpone en el uso de la aplicación. Yo diría que tiene una buena interfaz, que la hace suficientemente fácil de usar. Hemos hecho cursos hasta con 600 alumnos y no hemos recibido en nuestro equipo de soporte mas de una o dos consultas o preguntas de usabilidad.
Es cierto que muchos usuarios al principio están desorientados, pero IMHO eso no tiene que ver con la interfaz. Tiene que ver con qué NeuroK propone un nuevo modelo pedagógico.
NeuroK propone una nueva metodología que está soportada por una plataforma tecnológica. Cuando el usuario no conoce los conceptos o abstracciones que utilizas en tu producto es difícil que sea fácil de entender y utilizar. Cuando el usuario no conoce esos conceptos su reacción suele ser hacer responsable a la usabilidad de la aplicación. Por lo que la respuesta fácil es decir que el problema se resuelve mejorando la usabilidad y aquí es donde yo voy a discrepar.
Quizás la compañía más reconocida por su inversión en foco en usabilidad y el diseño sea Apple, sus productos tienen un excelente diseño y han dedicado millones de € a hacerlos usables. A pesar de eso, hay millones de usuarios (sobre todo los que no los usan a diario) que se quejan de que la usabilidad de SU aplicación (la que el usuario usa) es mejor, que no saben hacer cosas en iOS y que no les resulta intuitiva o fácil de usar, pero claro ¿quién se atreve a decir que los productos de apple no son usables?, casi nadie.
Cuando un usuario tiene dificultades para usar un producto digital puede ser por dos razones:
A) El usuario es un “patán” y no lo sabe hacer, o
B) La aplicación es mala y no está bien diseñada
Nuestro cerebro rechaza las cosas que no nos gustan y más las que atacan nuestra auto-estima, y por lo tanto cuando el usuario tiene que explicar porqué le cuesta usar una aplicación va a tender a decir que es culpa de la aplicación, salvo en el caso en que la aplicación sea muy muy popular.
Nadie se atreve a decir que WhatsApp o Slack sean difíciles de usar. Al fin y al cabo lo usan millones de personas a diario, si tu no lo sabes usar es culpa tuya, obviamente no de la aplicación. Y este mismo razonamiento se aplica si tu aplicación no es tan popular ni tu marca tan potente, y si encima el producto está relacionado conmigo (con la reputación que tengo y habiendo dado una charla en el UXSpain que se titulaba “El UX es como la homeopatía” que por cierto fue bien acogida por los asistentes), pues todavía más.
Muchos colegas del sector se acercan a NeuroK y, como no conocen los conceptos con los que queremos cambiar la educación, no se sienten cómodos en la plataforma y no encuentran lo que esperan, sobre todo porque lo que esperan no está. Cuando tienen que explicar su “incapacidad” o su “incomodidad” en el uso de la plataforma entonces su cerebro opta por culpar a la aplicación.
Es cierto que nosotros tenemos que trabajar más y mejor para mejorar esa percepción y conseguir eliminar la fricción en el uso de la aplicación por primera vez, es nuestra responsabilidad. Seguiremos trabajando en mejorar el diseño y la experiencia de usuario de NeuroK, pero yo no creo que los problemas que experimentan los usuarios la primera vez que lo usan sean por causa del diseño o el UX.
Estoy convencido que si NeuroK hubiera sido creado por una marca de prestigio (o un diseñador de prestigio), probablemente los problemas de fricción al principio de uso de un producto serían los mismos o muy parecidos, pero muchos “expertos” no se atreverían a decir que tiene un problema de diseño o usabilidad.
Y se lio un poco en twitter, así que debe ser que el tema tiene interés, ya demás llevaba tiempo rondándome la idea de escribir un poco sobre el tema.
El mundo del falso agile es algo que me preocupa, así que igual este es un buen punto de arranque para empezar a hablar del tema.
Mi amigo Javier me pregunto que cual era en mi opinión la diferencia. En primer lugar las palabras Metodología y Framework son lo que algunos llaman (gracias @lsmntr ) «significados flotantes», es decir, palabras a las que cada uno da un significado diferente.
Para mi, y esto es solo mi opinión, una metodología impone una serie de procesos, ceremonias, documentos, estándares, etc. Con un cierto nivel de rigidez. Las personas hemos creado metodologías con objeto de poder darle escalabilidad a los procesos y asegurar la calidad del resultado siempre y cuando se sigan los pasos marcados por la metodología. Por el contrario un framework es mas laxo, te da una serie de pautas, roles, artefactos, ceremonias etc que debes usar como guía. Seguro que esta definición no le vale a todo el mundo, pero creo que da una pista de lo que quiero decir.
IMHO no existen «metodologías ágiles». Para mi ágil tiene que ver con valores, y no estoy hablando de valores éticos (o igual si), si no de que prefieres cuando tienes que tomar una decisión.
El manifiesto ágil habla de valores y principio, yo no he leído nada de metodología.
Hay valor en que el software esté documentado, pero si tengo que elegir entre software que funciona y una buena documentación, yo me prefiero dedicar mi dinero al software y no a la documentación. De esto estoy hablando cuando hablo de valores.
Por muchas razones se ha puesto de moda el agilismo, (igual es que funciona), tal vez el hecho de vivir en un mundo donde es mas importante adaptarse al cambio que seguir un plan, donde la colaboración con el cliente prima sobre los contratos, o que las personas sean mas importantes que los procesos, el caso es que se ha puesto de moda.
Pero como siempre con la moda viene la simplificación, y en muchas organizaciones,libros, debates, tweets, etc., la simplificación ha hecho que se olviden los valores y nos centremos en aquello que es más fácil de medir, explicar y cambiar, que son los procesos, las ceremonias, las herramientas, etc.
Por eso decía lo de los gatitos, porque cuando se nos llena la boca de palabras y procesos que se han puesto de moda, lo que estamos haciendo es caminar hacia el fracaso porque nos hemos olvidado de los valores, y muchos que no tienen los valores que definen a un agilista, se han disfrazado de metodología. Y por eso surge el dolor, el fracaso y el humo.
Yo no voy a decidir quien es ágil y quien no, quien sigue o no una metodología, lo que si puedo ver son los valores de alguien. Porque los valores no se miden por lo que dices sino por lo que haces.
Es muy fácil hablar de metodologías, marcos de trabajo, roles, artefactos. El problema surge cuando tienes que decidir y entonces si te preocupa mas el contrato, o no te preocupas por las personas, o no buscas la mejora continua porque cuesta dinero, o no sigues los principios del manifiesto ágil entonces no me cuentes rollos. Te mola el discurso pero se te nota que no es lo tuyo.
Por cierto te lo dice un tipo ágil que pesa mas de 140Kg ;-).
La semana pasada mi amigo Pedro me invito a dar una charla a su equipo que llame «Trasformación digital desde el cerebro» pasmos un gran rato, por lo menos yo ;-), y el me dijo que también. Me ha pedido que le pasara la lista de libros de los que hablé en la charla y he pensado que mejro compartirlo aquí por si le resulta útil a alguien mas:
Y por últimmo hablando de neruoeducación os dejo dos enlaces:
Yo soy de los que piensa que vamos camino de la desaparición de la privacidad, en unos años aprenderemos a vivir siendo todo lo que hacemos público, otra cosa es que sea interesante o relevante.
Mi abuela me contaba que oía contar a su padre que iban a las paradas del tranvía para ver el tobillo de las señoras la bajar. Hoy nadie da ninguna relevancia a un tobillo.
A pesar de un montón de leyes para proteger los tobillos, hoy no queda nada de aquello, los tobillos hoy son publico, siguen teniendo valor, pero no por el hecho de estar protegidos.
Con nuestros datos pasa igual, hoy nos preocupan sobre todo porque no los sabemos gestionar, porque no entendemos lo que hacemos con ellos y por lo tanto nos asustamos con lo que se puede hacer con ellos.
Las leyes de protección de datos, en teoría vienen a ayudarnos con nuestros derechos sobre los datos, pero IMHO no sirven para nada mas que para generar problemas.
No sirven porque:
Los datos son míos, y por tanto se los doy a quien quiero, la ley no debe limitar lo que hago con mis datos, y por eso
Ya se ocuparán los “chorizos” de los datos de firmar contratos que nadie leerá para quedarse con tus datos, que al fin y al cabo entregas si quieres acceder a una plataforma o recibir un servicio.
La solución no está en las leyes, está en el cambio social necesarios en la dirección de no dar relevancia a la privacidad a la vez que mejoramos a quien y como cedemos nuestros datos.
El spam y el abuso de los datos va a seguir viniendo de sitios donde la ley no llega, internet no tiene frontera.
Solo generan problemas:
Una agencia de protección de datos que impide la innovación y hace mas difícil operar cualquier pequeña empresa que quiere lanzar un servicio .
Un montón de despachos de protección de datos que “extorsionan” a sus clientes con el miedo a las inspecciones de la agencia, dos ejemplos:
Una consultora que nos llama para ofrecernos el servicio, y que cuando pregunto de donde saca los datos me dice que de la Agencia de protección de datos, que los datos de tratadores de ficheros son públicos.
Clientes de nuestro SaaS (Facturagem 9€/mes ) que quieren que firmes un contrato con ellos de 5 páginas que les ha pasado su asesoría. Seguro que Google tiene miles de peticiones como esa (sic !) .
IMHO la solución no son leyes como la actual donde se obliga a todos PYMES y autónomos incluidos a gastar un montón de dinero inútilmente.
SI mi voz vale para algo , los reglamentos y leyes de protección de datos sobran.
Ayer me invitaron a una tertulia para hablar de educación, Hablamos sobre unos vídeos, libros y documentos que dejo aquí recogidos porque me parecen mas que recomendables y aquí son mas fáciles de encontrar:
![The Paradox of Choice: Why More Is Less, Revised Edition (English Edition) de [Schwartz, Barry]](https://images-eu.ssl-images-amazon.com/images/I/41M211eZbvL.jpg)
