¿Está TDD muerto? Resumen del videodebate

Mientras hacen subtitulos para el Hangout entre David Heinemeier Hansson, Kent Beck y Martin Fowler, voy a escribir un poco lo que han hablado para que los que no entiendan el inglés, o no tienen los 30 minutos para verlo entero, puedan quedarse con las claves. En mi anterior artículo hablo de los artículos y tweets que empezaron la discusión.

El link al video es éste.

Empieza David hablando de los 3 problemas que ve al TDD: la insistencia en que los tests tienen que correr en milisegundos, que termina creando un diseño feo y complejo y que el bucle de rojo-verde-refactor es poco natural para el programador.

Kent cuenta que el TDD le da la confianza que necesita a la hora de dar un desarrollo por completado y funcionando. Sin TDD, uno se va a casa sin la seguridad de que el código que ha escrito funcione bien. Además le ayuda a pensar primero en el problema. Cuando no se tienen especificaciones concretas TDD sirve para empezar de lo más concreto (ejemplos en los tests) a la implementación más genérica.

David entiende en que Kent piense en la seguridad como un factor de felicidad del programador. Él mismo dice que le da prioridad a la felicidad del programador cuando empezó Ruby on Rails. Sin embargo, la seguridad de que todo va a funcionar es sólo un factor de felicidad del programador pero hay otros. El tener que cambiar el flujo de pensamiento a pensar primero el test antes de empezar lo ve como una forma de confundir al programador y no dejarle crear del modo que le es más natural. Además dice que la seguridad de que el código funciona no debería venir unicamente del TDD

Ante un ejemplo reciente de Kent sobre un uso idoneo del TDD, David responde que en los desarrollos que él hace no es normal tener un código tan aislado como el que Kent comenta. Que para poder conseguir un codigo perfecto testeable típico de un input consigue un output tiene que separar capas y capas y crear muchos mocks. Que tiene que hacer un gran sacrificio para conseguir ese código perfecto para TDD.

Kent afirma que en todo esto tiene que haber un balance. Hay que tener en cuenta el coste de aislarlo todo para testearlo de manera independiente y su beneficio. Que no hace falta hacer mocks de todo. Si tienes unos tests de objetos que usan otros objetos reales o un sistema real y se es capaz de tener así la prueba de si va o no va, es suficiente. Cuenta que mucha gente se queja de que el Unit Test no le deja refactorizar. Esto ocurre porque sus tests complejos que tienen mocks que devuelven mocks y como fruto estos tests están muy acoplados a la implementación.

Segun David, el problema está en la definicion de TDD segun algunos sectores del desarrollo. Estos sectores afirman cosas como que cualquier test tiene que estar basado en mocks y que si no usas TDD no eres buen profesional. Incluso que si el diseño del programa no está dirigido por tests, no es buen diseño. Para David es al contrario, TDD fuerza a tener un diseño no natural.

Martin Fowler, quedandose un poco en medio y actuando un poco como arbitro del debate, también dando su opinión más pragmática. Dice que hay en la calle muchas definiciones de TDD. Algunas de ellas dicen que todo tiene que estar con mocks. Sin embargo la realidad es que si no usa mocks y el test es util, perfecto. Dice que el TDD y el Unit test son dos cosas aisladas y hay que tratarlas como tal. Se puede hacer TDD sin que todo el codigo testeado esté aislado. Para él, como ya dijo en su artículo, lo importante es que el código sea autotesteable, que haya un botón que pueda probar todo el código. TDD está bien porque ofrece esto como uno de sus beneficios.  Está de acuerdo en que en ocasiones no se puede usar TDD, cosa que le apena ya que dice que es una herramienta que le gusta. También opina que incluso hay que separar conceptualmente el Unit testing aislado y el no aislado.

El debate termina barajando un posible futuro debate hablando unicamente de si el TDD crea un buen diseño o no.

 

 

 

Negocios sin mentiras

En el libro “La Máquina de la Verdad” de Jams L. Halperin (conseguir) habla de una máquina de la verdad 100% fiable. Empieza usándose en ámbitos como juicios, en el gobierno y acaba siendo una tecnología que todo el mundo lleva encima como si fuera un reloj. Este detector de mentiras portable consigue erradicar la mentira de todos los ámbitos incluso en los negocios. Las empresas cuando hacen negocios entre ellas sólo se dicen qué necesitan de forma sincera y llegan a la mejor solución para ambos.

¿Qué ocurriría en el mundo de los negocios sin la mentira? ¿Que ocurriría si siempre dos partes que hablen entre sí buscasen la mejor manera de ayudarse y no de sacar el máximo provecho sin pensar en el otro?

La confianza es muy importante si se quiere conseguir la mayor eficiencia. En el manifiesto ágil se le dá una gran importancia. El 50% del manifiesto de hecho habla sobre ella.

Individuos e interacciones sobre procesos (Confianza en la gente con la que se trabaja)
Colaboración con el cliente sobre negociación contractual (Confianza cliente – proveedor)

Cuanta menos confianza, más trabajo extra se hace en contratos, controles, seguimientos,… que no dan valor directo al cliente y que son realmente un lastre para el equipo de desarrollo y la empresa en general. Ten más confianza con la gente con la que  trabajas y consigue que tengan más confianza en ti. Esto sí que será un WIN-WIN.

En Toyota la confianza se consigue con relaciones a largo plazo y colaboración mutua. Con los proveedores se colabora para que consigan entregar en menor plazo posible y con menor coste. No se rompe relaciones simplemente porque otro proveedor ofrezca un precio más bajo sino que la ayuda a que llegue a ese precio siendo más eficiente. La confianza del equipo se consigue también con una relación a largo plazo. Todos los trabajadores de Toyota son casi de por vida. El sueldo va aumentando año tras año de trabajo con ellos y los puestos avanzados se consiguen también después de haber trabajado mucho con ellos. De este modo se consigue que cada trabajador entienda la cultura de la empresa y sea una parte inseparable. Cada trabajador de linea tiene el poder de parar la cadena de producción en cuando ve un problema de calidad que no es capaz de arreglar hasta que pasa a la siguiente fase. Esto sólo se puede hacer cuando se tiene mucha confianza en todas y cada una de los personas con las que se trabaja.

Pregunta a tus clientes qué es lo que realmente quieren, no dejes que un contrato os ate  tanto a ti como a ellos. Satisface sus necesidades y, no solo conseguirás recompensa económica por el servicio, también conseguirás que vuelva a hacer negocios contigo. Ataros con un contrato blindado y, ni el cliente podrá ajustar su pedido a sus necesidades ni tu podrás salirte ni una coma aunque ello pueda dar más valor.

To TDD or not to TDD. That is the question

Menuda guerra ha ocurrido esta semana. Cómo decía un compañero, parecía una discusión de Salvame Deluxe pero en el mundo del desarrollo.

Todo empezó cuando David Heinemeier Hansson, padre del Ruby on Rails,  escribió un artículo sobre los problemas de usar TDD. David afirma que hacer TDD no es conveniente, que obliga a separar demasiados intefaces  y que es mejor hacer tests de integración más lentos que de todos modos, con paralelización y test en la nube se pueden hacer muchos a la vez.

Al poco, Bob Martin (Uncle Bob) respondió en su blog que unicamente cuando se aplica TDD se consigue reducir el tiempo de depuración, una documentación unequivoca en los tests y un desacoplamiento entre clases muy valioso por sí mismo. Poco después volvió a escribir explicando un poco más dónde no se puede usar TDD y dónde sí. De este modo respondía a las críticas que suelen surgir sobre la falta de aplicabilidad en algunos entornos.

El propio  Kent Beck, padre del TDD, escribió en facebook un supuesta nota postuma sobre el TDD, echando de menos la técnica y rogando poder encontrar otra que le diera la misma seguridad a la hora de escribir, la misma documentación y enfoque a la hora de escribir.

Personalmente el TDD es una herramienta que vale la pena conocer bien. Entiendo sus dificultades. En más dificil hacerlo bien que cualquier framework, IDE o incluso lenguaje. Requiere que el desarrollador dedique tiempo no a crear, que es lo que más le gusta, sino a poner redes de seguridad a lo que aún no ha empezado a escribir. En VSN no lo hacemos el 100% de las veces. Tenemos “sólo” un 40% de cobertura que nos ofrece ya una gran seguridad a la hora de añadir nuevas funcionalidades o refactorizar. Sin embargo, nada no nos impide intentar tener cada vez más cobertura y usar TDD cada vez en más ocasiones. Como alguien me dijo una vez, si intentas saltar tan alto como para tocar la luna lo más seguro es que nunca lo consigas, pero llegarás muchísimo más alto que si nunca lo hubieses intentado.

Motores, lastres y minas en retrospectivas

¿Cuánto tiempo tardas en ir de casa al trabajo? Normalmente ese tiempo varía un poco cada día. Por ejemplo un día tardas 20 minutos, otro 23, otro 19, 20,… Esa variación de tiempo que ya tienes asumida se llama “Variación de causa común“. Ahora piensa en la última vez que llegaste tarde. Pudo ser por un problema de tráfico, tu hijo estaba enfermo y hubo que llevarlo a casa de la abuela… Esa vez tardaste 40 minutos. Ese tipo de variación se llama “Variación de causa asignable“. Es asignable porque puedes asignarle una razón (o una excusa).

En VSN trabajamos desde hace unos meses  la retrospectiva con la analogía de la lancha. El equipo es una lancha en la que los motores representan aquellas cosas que nos hacen ir rápidos y con calidad.  Los lastres atados son las cosas que nos hacen ir más lentos. Desde hoy tenemos un elemento nuevo. Ahora identificamos también las minas con las que se encuentra esta lancha por el camino. Estas minas representan esos problemas de causa asignable, esos problemas ocasionales que han ocurrido y pueden volver a ocurrir, o no.

20140411_145919_pq

Cuando trabajamos estas retrospectivas, el equipo escribe en los Post-It amarillos los elementos a destacar del sprint: los motores, los lastres y ahora las minas. Una vez están todas las etiquetas en la pizarra las organizamos juntando las comunes y las analizamos. Primero buscamos soluciones para los lastres, después confirmamos que los motores que tenemos siguen siendo útiles y debemos seguir usandolos y por último analizamos las minas para ver cómo actuar cuando nos las volvamos a encontrar.

Primero indicamos la posibilidad de encontrarnosla. Podría ser eventual, esto quiere decir que el problema ha ocurrido y ya está, que es raro que vuelva a ocurrir.Podría ser frecuente, una vez cada sprint o cada pocos sprints. Si es un problema constante lo más normal es que se encuentre en la parte de lastres.  Despues recordamos el efecto que ha causado en el equipo. En qué nos ha afectado. Ha sido una molestia o ha sido un gran trauma. Por último definimos el plan de defensa, qué hacer con la mina la próxima vez que nos la encontremos. Aquí tenemos 3 opciones:

  1. Preparar contramedida para destruir la mina la próxima vez. Se piensa cómo eliminar el riesgo para que no vuelva a afectar lo más mínimo al equipo.
  2. Mitigar el daño cuando ocurra el choque. Podría ser que lo mejor es que cuando el problema ocurra de nuevo estar preparado para que afecte lo menos posible.
  3. Ignorar la mina. Cerrar los ojos, apretar el culo y sencillamente aceptarla tal cual llega. Esto se decide así cuando las consecuencias de tener un plan de acción podrían sobrepasan el efecto de la propia mina.

Los planes que se hacen con las minas las vamos a recoger en un documento accesible por todo el equipo. Cuando en un análisis de sprint, de historia o en algún Daily asome la sospecha de que se nos acerca una mina conocida, sabremos cómo actuar. Con esta sencilla analogía de las minas vamos a tener  lo que se llama en gestión de proyectos tradicional, Gestión de Riesgos. Sin embargo lo hacemos de una manera Ágil. Primero porque lo hace el propio equipo y segundo porque se minimiza el tiempo gestionando este nuevo artefacto respecto a la mejora en el equipo que esperamos que produzca.

Cuando el manager se convierte en un lastre para el equipo

En nuestro equipo de desarrollo hacemos una retrospectiva al final de cada sprint (como se debe). Nosotros usamos la técnica del barco. Dibujo un barco en la pizarra con un espacio de motores que simboliza los lo que nos hace ir a buena velocidad y unos lastres atados que simboliza problemas que nos dificultan ir a mayor velocidad.

En la retrospectiva anterior que celebramos ocurrió algo que no había pasado y el que ocurriera me llenó de orgullo. Me dijeron que YO era un lastre cuando tocaba código de producción. Ocurrió que para intentar hacer una historia de usuario que parecía que no iba a entrar decidí hacerla yo por mi cuenta. Al final produjo unos problemas que les hizo perder el tiempo arreglándolo 😛

Por un lado, como me gusta tanto programar fue en parte una lástima pero como facilitador de equipo me encantó. De hecho di las gracias personalmente después de la reunión a quien me lo dijo y explico por qué.

1.- Decir algo así a quien en principio “es tu jefe” requiere cierto grado de valentía. No debe ser fácil. Por lo tanto veo que hay CONFIANZA por su parte.
2.- Yo, que me esfuerzo en que el equipo vaya cada vez más rápido y con mejor calidad, si en lugar de tener que hacer algo para ello tengo que dejar de hacerlo, para mi es más sencillo.
3.-  Me hace ver que hay el clima de sinceridad en las retrospectivas que es muy necesario para mejorar sprint tras sprint.

Por lo tanto, no tengáis miedo si un día os dicen que habéis hecho algo que se considera un lastre para el equipo, u os habéis equivocado. Es el mejor indicador de que el trabajo de uno es importante y que el resto de cosas se hacen bien, ya que si no fuera así alguien se lo diría para mejorarlo.

En VSN buscamos C++ developer. Lo que no nos cabe en Infojobs

EN VSN estamos contratando. Necesitamos bastante urgentemente dos programadores C++. Quisiera ampliar aquí lo que no nos ha cabido en la oferta de Infojobs.

Analista/Programador Senior C++  – Programador Junior C++
Dos puestos, uno junior y otro aguerrido, un C++ Black Belt que mapee mentalmente el heap y stack sin siquiera levantar la ceja.

Empresa: Video Stream Networks S.L.
Nos dedicamos a hacer software para cadenas de televisión. Tenemos muchos clientes “pequeños” como televisiones locales y últimamente hacemos muchos clientes grandes como la productora Telson/Turner o Dorna, los que retransmiten el MOTOGP. Tenemos oficinas en varias partes del mundo y clientes en casi todos los lados. Nos falta el Ártico y algún rincón más.

Provincia:
Alicante – España

Concretamente en San Juan de Alicante. Hay facilidades de aparcamiento por ser un pueblo, acceso facil desde la autovía y tiendas cercanas de casi todo. Sólo nos echamos de menos un FNAC.

Perfil del Candidato:
Titulado en Ingeniería, preferiblemente en Informática o Telecomunicaciones o Licenciado en Ciencias (Físicas, Matemáticas)
Usamos regularmente conceptos avanzados cómo muestreo de señal digital, algorítmia avanzada, las capas de la comunicación TCP. Necesitamos que tengas una buena base de conocimientos técnicos y una mente bien entrenada.

Analista Programador – Programador C++ con al menos tres años de experiencia.
Te vamos a meter a saco a mantener un programa complejo y sacarlo adelante por lo que necesitamos que le des caña desde el primer día.

Capacidad para asimilar grandes proyectos y entender su código fuente rápidamente.
Como vas a mantener un programa que ya existe, debes tener facilidad en entender el por qué lo que hace. Nosotros te ayudaremos pero eres tú el que debes darnos la mayoría de respuestas. Si te mola bajarte proyectos del Github por el mero hecho de leerlos para ti esto será pan comido.

Buena capacidad comunicativa tanto hablada como escrita para el trabajo en equipo.
El C++ déjalo para el compilador. Tus compañeros necesitamos entenderte bien, y no digamos ya los que trabajan en otros departamentos.

Must have:

C++.
Como segunda (o primera) lengua madre

Aplicaciones visuales (GUI) sobre plataforma Windows (preferiblemente con MFC/Win32).
Crear botones, grids, ponerles textos comprensibles, elementos alineaditos…

Multihilos/Concurrencia/Tiempo real
Tengo que ser sincero. Te vas a tener que pelear con semáforos y sincronía de hilos.  La aplicación que vas a mantener necesita comunicarse continuamente con otros elementos y no puede pararse a pensar ni 40 milisegundos.

TCP / IP, Sockets.
Crear server, crear cliente, conectar, send buffer, receive buffer… ese tipo de cosas

SO Windows.
Entender bien cómo funcionan los hilos y sistema de ficheros en Windows sobre todo. Leer y escribir en registro y otras cosillas que tan poco gusta a los linuxeros.

Microsoft Visual Studio.
Esta será tu herramienta. Si ya la sabes manejar, y conoces sus secretos sabemos que serás más productivo desde el principio que si nunca lo has tocado.

INGLÉS
Esta claro que si sabes bien programar es muy probable que sepas inglés escrito. Sin embargo esperamos que te desenvuelvas bien también en el oral para poder contar contigo en todo tipo de situaciones. En ocasiones hay que llamar a algún cliente, a algun compañero que vive en otro continente, recibir formación en otro pais,….

Good to have:
(Lo que ya nos emocionará si lo tienes)

* Git, Subversion.
Tenemos la mitad de proyectos en Subversion pero los que mantendrás al empezar estan en GIT. Hacer PULL, PUSH, CLONE… Pero cuidado que yo odio los Feature Branches por lo que voy a estar muy atento de cómo lo usas.

* WxWidgets
Como objetivo de que sea multiplatarforma está hecho en xwWidgets… Lo sentimos

* Boost, STL
Esas herramientas que hacen del C++ un mundo mejor en el que vivir

* ActiveX, OCX, Interfaces COM.
CoCreateInstances y QueryIntefaces. Si te suenan nos harás tilín en la entrevista

* Conocimientos en los estándares, codecs y protocolos de streaming de video.
No sólo el DIVX, piratilla. En las teles usan muchos codecs distintos. Si no los conoces ya te irás familiarizando aqui.

* Java, C#.
Sobretodo el C# que es en lo que estamos basando los nuevos productos aunque el Java también nos será útil

* MS SQL Server, diseño de BD, procedimientos almacenados.
Todo necesita su persistencia y nosotros usamos SQL Server. Tendrás que crearte las tablas y lo que necesites tú mismo.

* Conocimientos sobre servicios REST, SOA.
Es a lo que estamos tendiendo, todo basado en servicios web con REST. Si sabes de qué hablamos cuando te lo preguntemos empezaremos con buen pié.

* ActiveMQ
(sigh)

* TDD, Refactoring, Código Limpio.
Es posible que en la entrevista hagas un kata con TDD. En VSN llevamos muchos años perfeccionando el cómo generar test y cómo hacer código limpio y estructurado. ¡ Muestranos lo que sabes y por lo menos a mí me tendrás en el bolsillo !

* Haber trabajado en un proyecto Open Source
Esto es propuesta mia.  Je, je. Si eres friki del desarrollo, sientete orgulloso y hablanos de cómo has pasado sabados por la noche peleandote con el código sólo por gusto.

Ofrecemos:

* Participar en las decisiones de diseño e implementación de los productos.
Desde el primer día. Pensamos que no existe idea mala y queremos oir tu voz en todas las reuniones.

* 6 Meses + 6 Meses + Contrato Indefinido e incorporación a proyecto estable.
Es un puesto que necesitamos y necesitaremos por lo que si lo haces bien tienes tu sitio asegurado.

* Salario en función de la experiencia aportada por el candidato/a.
No es confirmado pero puedes esperar algo entre 25000 y 30000 euros brutos al año. Pensamos que es un buen sueldo para empezar y pero también que el sueldo no debería ser la única motivación para trabajar con nosotros.

* Facilidades para combinar la vida familiar
Para nosotros es muy importante que estés en la oficina en el mismo horario que el resto de compañeros, sobre todo para trabajar en equipo. Sin embargo si necesitas dejar a tus hijos en el cole y llegar algo más tarde no hay problema. Hay facilidades para ajustar el horario un poco hacia los lados.

* Formar parte de una plantilla con el mejor ambiente de trabajo, participando en proyectos de gran envergadura.
Formarás parte de un equipo muy motivado en el que trabajar con intensidad no está reñido con estar de buen humor.

* Gran colaboración entre miembros del equipo de trabajo.
El departamento de desarrollo forma una especie de círculo alargado y siempre vamos moviéndonos en la sillas de un puesto a otro ayudando a quien lo necesite.

* Trabajos colaborativos en grandes proyectos.
Hay algunos proyectos que llevamos entre varias personas.  Así mejoramos la velocidad y disminuimos el riesgo por si alguno se pone malito o tiene algún compromiso.

* Trabajar en un entorno ágil en el que se valora el talento y las ideas de los miembros del equipo.
Hacemos standup dailies reales(menos de 15 min.), tenemos un buen sistema de integración continua, el testing está integrado en el equipo de desarrollo, vamos mejorando retrospectiva tras retrospectiva,… No hacemos SCRUM sino que es más parecido a FDD aunque hacemos entregas oficiales cada 3 semanas.

* Un puesto rotativo de desarrollo de pié para estirar de vez en cuando las piernas
En VSN cuidamos de tu salud. Si necesitas estirar las piernas puedes pasarte un rato a un puesto de desarrollo en el que podrás trabajar de pié y ver las cosas desde otro ángulo.

Experiencia:
3-5 años
Lo sentimos. No necesitamos un newby esta vez

Datos del Puesto:

* El candidato liderará la evolución del producto,siendo apoyado e instruido por un miembro del equipo de desarrollo actual, proponiendo mejoras a la arquitectura actual del sistema, así como las tecnologías y herramientas más apropiadas para la tarea.
Raro pero no tengo nada que añadir.

Nivel Profesional:
Empleado.
A cuenta ajena, claro.

Jornada:
Jornada completa (L-J 9:00-14:00  15:00 – 18:30, V-9:00 15:00)

Si vives cerca y prefieres y a comer allí podrás comer de 14 a 15:30 y después salir a las 19. El salir los viernes a las 15 es una PASADA…

Tipo de contrato:
Indefinido

Creo que ya hemos hablado de esto. Si ambas partes estamos contentas puede que te jubiles con nosotros, sea el que sea el lenguaje de programación que se use entonces.

Funciones:
Analista Programador – Programador

¡Ups!. Esto no me había dado cuenta, que fallo. Para mí el puesto es de DESARROLLADOR en mayúsculas. Olvídate de las funciones típicas. En VSN cortamos, pegamos y coloreamos todo lo que hace falta para sacar el producto con calidad.

Tecnología:
C++,Video, MultiHilo, Concurrencia, TCP/IP,Sockets,Windows,HTTP,Visual Studio,GIT,
Esperamos que no te asuste todo esto.

Si no lo ha hecho, saca brillo a tu currículum y envíamelo a jmuria en el dominio vsn.es. Tus propios compañeros lo leerán y colaborarán en tu selección.

El sabor de la buena UX

Los programas de TV de moda van cambiando año tras año. Reality shows, concursos de talento de canto, de baile, de salto en trampolín (sigh!). Ahora estan de moda los concursos de cocina como Master Chef, Top Chef y otros…

Tengo que admitir que a estos últimos sí estoy algo enganchado porque me siento identificado con los concursantes en los momentos en los que los jueces van a probar el plato, lo miran, lo prueban y lo juzgan. Todo lo aprendido por el cocinero antes de esa elaboración junto con la suerte y pericia en el momento de la elaboración se plasman en el plato.

Sé que es la enésima analogía del desarrollo de software, pero me vais a permitir usarla. Voy a analizar las tres partes de un software bien desarrollado.

La receta es la historia de usuario.
Cuando se define la historia de usuario es cuando el cocinero piensa qué va a cocinar. Puede ser lomo de atún, muslos de pollo a la pimienta o pastel de boniato con cintas de chocolate. El cocinero piensa qué es lo que le va a gustar al cliente y pasa a su ejecución. Igualmente un equipo de trabajo se enfrenta con una historia de usuario. La definición de esa historia indica cómo va a dar valor al cliente.

La presentación del plato es la estética del software
Tanto cuando se presenta un plato como cuando el cliente va a usar el software, el producto tiene que entrar por los ojos.  En cocina es muy importante aspectos el corte de los ingredientes, su color, cómo están alineados en el plato,… . En software igualmente hay que prestar atención a las fuentes que se usan, los bordes, los colores, los iconos,… Todo tiene que tener un aspecto cuidado.

Y para terminar…
El sabor es la Experiencia de Usuario, la UX
Aqui es donde el cocinero y el equipo de software más se la juegan. En cocina un plato puede estar bien planificado y con una cuidadisima estética pero pueden pasar cosas como una textura de un ingrediente que no es la que te habías imaginado, como algo que cruje y no debería, una combinación de sabores que no encajan,… Cuando el usuario usa la característica desarrollada pueden sucederle cosas muy parecidas: información que falta y hace que no sepa usarla, tener que hacer muchos clicks, tener que ir abriendo y cerrando interfaces, tener elementos de interfaz muy pequeños o muy grandes,…

Me faltan dos páginas para terminar el libro de Lean UX (mi mente ya no procesaba letra escrita). En breve hablaré un poco cómo se trabajan esos dos aspectos, la estética y la experiencia de usuario. En un equipo Ágil se trabajan de forma completamente distinta y en momentos distintos. Lo veremos.

Algo llamado “Declaración de Interdependencia”

De nuevo en el libro de David J Anderson, descubrí algo llamado “Declaration of Interdependence” DOI. En español, Declaración de Interdependencia. Esto fue una redefinición del manifiesto Agil pero centrado solamente en la gestión de proyectos. Sus autores forman la creme de la creme en gestión de proyectos ágiles con nombres como el propio David J Anderson, Alistar Cockburn o Mike Cohn.

Sus puntos son:

Incrementamos el retorno de la inversión (ROI) centrándonos en un flujo contínuo de valor.
Habla de dar valor al cliente de forma más continua posible. Mejor iteraciones de 2 semanas que de 3. Mejor aportaciones diarias que cada 2 semanas. Lo que necesita de forma más rápida posible desde el momento que lo necesita.

Entregamos resultados fiables haciendo participes a los clientes en interacciones frecuentes y compartiendo la propiedad.
El cliente debe formar parte activa del resultado. Cuando más participe en la definición de producto y en su revisión frecuente mejor adaptado estará a sus necesidades.

Esperamos lo inesperado y lo gestionamos mediante iteraciones, anticipación y adaptación.
El mundo es caotico por naturaleza. Lo que es cierto por la mañana deja de serlo por la tarde. Los procedimientos de trabajo tiene que ser flexibles y con ciclos cortos para poder seguir dando valor en estas condiciones.

Damos rienda suelta a la creatividad y la innovación reconociendo que los individuos son la fuente última de valor, y creando un entorno en el que puedan diferenciarse.
Los desarrolladores son los que crean. Cárgalos de stress en un entorno de trabajo restringido y obtendrás resultados mediocres.  Déjalos que disfruten con lo que hacen y dales los medios oportunos y crearán grandezas.

Disparamos el rendimiento mediante la responsabilidad  común sobre los resultados y sobre la propia efectividad del equipo.
No hay equipo más eficiente que aquel que está motivado y se le dan las herramientas para que ellos mismos hagan su trabajo más rápido y con mejor calidad.

Mejoramos la efectividad y la fiabilidad mediante estrategias, procesos y prácticas especificas para cada situación.
Existen muchas metodologías pero no hay una sola que funcione para todos los entornos. Hay que probar, medir y adaptar hasta encontrar el sistema que mejor funcione (mientras funcione).

Estos son los 6 puntos que habla la DOI. Puntos para reflexionar e interiorizar poco a poco. Puntos muy importante para quien quiere agilizar el desarrollo de software pero… David tiene razón.¡ Qué pena de nombre !.

Programa sinvergüenza!

Cuando uno empieza la carrera de Ingeniería en Informática, nos dicen que estudiamos la carrera para ser jefes de proyecto, no programadores. ¡Tonterías!

Cierto es que la vida de programador es difícil, dura y aburrida cuando uno termina la carrera. Salen bugs por doquier, se escribe un código horrible y se pasan horas y horas haciendo que todo “medio funcione”.  La cosa cambia cuando se empieza a controlar el Código Limpio, a usar bien los tests unitarios y usar herramientas como la integración contínua. En ese momento se empieza a disfrutar programando como nunca, creando nuevas características con nuevas tecnologías prácticamente sin errores y en un ambiente de trabajo distendido que te permite ir a casa a una hora razonable.

En ese momento tu papel tiene que cambiar y te toca llevar un equipo.

Cuando se lleva un equipo de trabajo la mayoría de gente piensa que ya no debe programar, que te tienes que centrar en quitar bloqueos al equipo y proveer del mayor valor posible al cliente a tiempo. ¡ Qué pena!, ¿no?

En el libro “Lessons in Agile Managment: On the Road to Kanban“, David J Anderson habla que un jefe de equipo no tiene por qué dejar de programar. De hecho la mejor manera de inculcar las buenas prácticas es mediante el ejemplo. Yo tengo que aportar una cosa más. Tambien puede programar si el objetivo de ese software es evitarles interrupciones y/o mejorar su productividad. Un jefe de equipo puede practicar sus artes haciendo esa herramienta que viene perfecta a los de operaciones para obtener información de qué hacer sin tener que llamar a desarrollo, o esa herramienta para gestionar las dependencias de los proyectos. Esto tambien es gestionar.

Trivial Interno de empresa

Como buen seguidor de David Bonilla, este ultimo domingo le leí su Bonilista. Hablaba de hacer un Fred Wilson, es decir, escribir un post cada día aunque sólo sea para comentar un vídeo de Youtube que has encontrado.

Yo sé que no voy a poder escribir un post cada día pero sí que voy a intentar escribir un poco más aunque sea corto. Este primero se llama:

Trivial Interno de empresa

Hace tiempo que detectaba que no todo el mundo en la empresa conocía bien los productos que desarrollamos. Hace falta que todos: comerciales, marketing, operaciones, soporte,… sepan bien todo lo que hacen y todo lo que NO hacen.

Para ello, y como buen conocedor de Gamification, ideé una pregunta diaría que lanzaría a la empresa usando Salesforce. Cada día creo una encuesta de Salesforce con una pregunta y 4 o 5 respuestas. Al día siguiente escribo como comentarios la respuesta correcta felicitando a los ganadores.

Llevo ya tres semanas y de momento no se me han acabado las ideas. Las mejoras preguntas son las que despejan dudas recurrentes que su ignorancia pueden llevar a un problema mayor. Sobre todo está funcionando muy bien al crear todos los días un pequeño debate y por la curiosidad que crea.

Como mejoras estoy pensando usar otro sistema web de preguntas en las que pueda ver quien ha respondido. De este modo hacer un sistema de Gamification con cara y ojos. Tabla de puntos con lider por departamento, recompensas,… De momento estoy contento con el resultado porque el objetivo que tenía lo he cumplido. Mejorar el conocimiento interno de los productos.