Archivo de la etiqueta: Development

Autogestión en equipos dentro de consultoras – Novela corta de ciencia ficción

Amanece en la playa Muchavista, situado a media distancia entre la población de Campello y la ciudad de Alicante.  Ya se ve bastantes corredores aprovechando el buen tiempo para estirar las piernas a lo largo del paseo marítimo. Los barrenderos limpian los últimos restos y vasos de Mac Donalds dejados por los paseantes nocturnos antes de dar paso a un día que promete tener bastante ocupación de la playa.

Sin embargo, el verdadero movimiento no está precisamente en la arena. A pocos metros de la misma se ve un chico de 30 años, de pie mirando al mar y disfrutando de su café en una taza en la que se lee las palabras «Clean Code». Da los últimos sorbos, deja la taza en una mesa del jardin y estira sus brazos y piernas para despertarlos después de una noche de sueño reponedor. Javier y su equipo son miembros de una consultora internacional, HGY,  que da servicio a grandes corporaciones financieras. Son un equipo 100% autogestionado dentro de la compañía, y muy disputado entre los clientes de la misma.

Javier recoge la taza y se va al interior de la pequeña casa de dos plantas con vistas al mar.  Deja atrás el pequeño jardín algo dejado a su destino al que nadie presta atención. Atraviesa la cocina  y sube los escalones que dividen la casa entre la planta en la que Javier y sus compañeros de equipo descansan y comen de la planta donde trabajan. El clac, clac, clac de un teclado mecánico le devuelve a Javier a la realidad del trabajo, y le produce una sonrisa.

– Diego, ¿Cómo fue la revisión de lo que entregamos ayer por la tarde a Banco Palomo? ¿Tenemos ya algún comentario de Daniel, nuestro querido Product Owner? – Pregunta tirando  una pelota de malabares que había encima de una de las mesas a  Diego, un miembro del equipo que estaba revisando el tablero Kanban del proyecto.

– De momento no, hay que dejarles que respiren. La entrega de ayer por la mañana les encantó como bien nos dijeron. Un par de días más y creo que ya tendrán el producto que esperaban. Bueno el que ni siquiera se esperaban. – Responde Diego cogiendo la pelota al vuelo, para sorpresa de Javier.

Diego tiene un poco más de edad que Javier pero, al contrario que él, aún no se le asoma ninguna cana.  Es especialista en sistemas web y entre él y Raúl han desarrollado casi todos los interfaces de usuario del sistema Peer Loans, que permite al banco que sus clientes elijan a quién prestar el dinero de sus depósitos.

– ¿Sabemos algo de Héctor? Desde que cogió el avión a Tailandia con su novia Malai no hemos recibido ninguna de sus fotos empalagosas de parejita feliz. – Pregunta Raúl sin mover la cara del monitor de 32 pulgadas en el que va añadiendo pruebas automatizadas para empezar a desarrollar uno de los últimos módulos de Peer Loans. –  Eso me recuerda que tenemos que revisar a los últimos candidatos para reemplazarlo. –

Raúl es un chico de 33 años, experto en lenguajes web y siempre viste con camisetas de Dragon Ball. Lleva en el equipo 3 años y siempre le acompaña su mujer y sus dos hijas allí donde vayan a trabajar.

– A mi me gustaba Jesús, le da a los dos palos de back y front con la suficiente soltura como la que necesitamos. Además es un miembro respetado del Meetup Full Stack Dev Alicante. – Dice Eva acercandose al monitor de Raúl  – Podemos hacerle una visita o quedar en algún bar para hablar con él. Si le gusta el sueldo que le ofrecemos, que seguro que lo hará, estará con nosotros en un par de días. –

Eva es la chica  de QA, de casi 40 años, y en los últimos años ha hecho un gran trabajo inculcando conocimientos sobre casuísticas de tests a los miembros del equipo. Tiene facilidad de palabra y habla muchos idiomas, lo que le permite estar en comunicación constante con los clientes para prevenir todos los escenarios posibles.

– Raúl, no te olvides del buffer overrun en el tratamiento de este campo –  Le dice Eva a Raúl acercándose a su hombro – Por cierto, buen trabajo con estos escenarios. – Una sonrisa de satisfacción casi imperceptible asoma en el rostro de Raúl mientras ejecuta los tests. Una columna de puntos rojos de tests fallidos le indican que es momento de empezar a trabajar en ese trozo de código.

–  No olvidemos que en un par de semanas tendremos nuevo proyecto. A este le quedan sólo un par de coletadas.-  Recuerda Javier desde su puesto de trabajo abriendo la página de la tecnológica Dell y buscando un servidor nuevo para su sistema de integración continua- ¿Habéis revisado últimamente la lista de posibles proyectos? –

Diego se acerca jugueteando con la pelota de malabares a su puesto. Pulsando un botón de su portátil pone en iluminacion su gran monitor así como los leds de su teclado y ratón. Sin sentarse coge el ratón y abre la lista de proyectos que los clientes de HGY les ha enviado. Su éxito con la nueva herramienta de Banco Palomo ha hecho que sean uno de los equipos más solicitados de toda la consultora y prácticamente de toda Europa.  Los honorarios que ellos mismos solicitan son altos pero hay muchos clientes a los que no le importa gastar un poco más para tener a estos chicos a su disposición.

– Ja, ja, ja. ¿A que no adivinais quién nos pide volver a trabajar con ellos? – Suelta Diego riéndose con las manos detrás de la nuca.

Eva y Javier se acercan a su monitor y se unen a Diego en las risas.

– ¿Podemos reirnos todos? – Suelta socarronamente Raúl sin levantar la mirada del monitor y sin dejar de teclear.

Eva, apoyada en la espalda de Diego, se vuelve a Raúl y le dice con una gran sonrisa – Nuestro «amigo» Financial Bureau quiere que le hagamos el sistema de banca con Realidad Aumentada igual al que le hicimos a Banco Marsella. –

–  ¡ Ni de coña ! – Suelta tajantemente Raúl mientras vuelve a ejecutar la lista de tests.  Ahora una columna de puntos verdes remplaza a los rojos, indicando que su cambio ha funcionado a la perfección. Aprovecha para girarse y mirar al resto del equipo. – ¿Os acordáis de lo impertinente que fue el CIO? Nos obligaba a trabajar a través de su entorno virtual. Como si nuestro entorno de red cifrada no fuera menos seguro que el suyo.  Quiere velocidad y calidad y nos da un martillo y un cincel para escribir código.  ¿Hay algun proyecto en Tailandia?  –

– Tú lo que quieres es intentar que Héctor vuelva con nosotros. Si encontramos una oficina cerca de donde van a montar la Startup estarías visitándole a todas horas. – Le dice Eva mirando la lista de posibles clientes.

– No. Es que allí tiene la oficina central Jurgen Fowler, el experto en EcmaScript 11, y que lideró su definición. – Responde Raúl, con media sonrisa –  He estado en comunicación con él últimamente y creo que nos puede preparar un curso intensivo al menos unos días si estamos por allí. El precio que pone es asequible y algunos lo necesitáis bastante… –

– Venga, me apetece empezar a codificar ya. ¿Qué os parece que hagamos una ronda de 3 pomodoros? – Sugiere Diego dirigiéndose a su silla. Esta idea hace que Javier y Eva también vayan corriendo a sus sillas y Raúl haga crujir sus dedos preparándose para una sesión intensa. – Pongo el crono de 25 minutos en marcha.  Empezamos en  3,2,1… –

El sol ya está iluminando con fuerza la arena y los primeros bañistas entran en las aguas de la playa Muchavista. Javier y su equipo están ya concentrados trabajando el resto día para terminar lo poco que le queda de su asignación actual. En un par de semanas, en la fachada de la casa colgará un cartel de «Se alquila». El equipo se habrá desplazado a un lugar algo más montañoso, por sugerencia de Eva. Sólo ellos mismos saben cual será el siguiente proyecto y lugar en el que trabajen. Son dueños de su propio destino.

FIN

Esta historia, que es naturalmente una historia de ficción, representa una imagen que a día de hoy parece imposible de conseguir en equipos que trabajan para consultoras. Hemos visto algunos ejemplos de decisiones en manos en un equipo totalmente autogestionado, aunque puede haber más. Estos equipos:

  • Deciden quién entra y quién se va de su equipo
  • Deciden su sueldo
  • Deciden su proyecto
  • Deciden dónde trabajan fisicamente
  • Deciden sus herramientas
  • Deciden su formación
  • Deciden cuándo toman vacaciones

Cuando un equipo llega a estos niveles de autonomía, logran una gran motivación y eficacia, lo cual les convierte en un equipo de alto rendimiento y para los clientes se traduce en productos de gran calidad e innovación. Sin embargo para llegar a estos niveles hace falta que tanto los miembros de los equipos como los directivos de las organizaciones tengan como meta conjunta esa autogestión. Los directivos y cargos intermedios tienen que aprender a delegar aunque suponga que al principio cometerán errores. Pero también cada miembro del equipo debe responsabilizarse del poder que se le da y saber dar el paso adelante para tomar esas decisiones. Aunque no lo parezca, tan difícil es lo uno como lo otro. Pero ¿quién sabe?, la ciencia ficción a veces se convierte en realidad. Todo camino empieza por un primer paso ¿Qué tal si empezamos por que los miembros de tu equipo puedan  autoasigarse las tareas?

 

 

Ten un Maestro Elodin en el equipo de desarrollo

“Words are pale shadows of forgotten names. As names have power, words have power. Words can light fires in the minds of men. Words can wring tears from the hardest hearts.” 
Patrick Rothfuss, The Name of the Wind

En VSN hemos contratado hace unas semanas a un escritor técnico. Su misión principal es escribir los manuales que incluiremos y estarán enlazados desde nuestro software para consultar rápidamente.  Pero su colaboración hacia el equipo de desarrollo está yendo mucho más allá.

«Every time you write a comment, you should grimace and feel the failure of your ability of expression.»
Bob Martin, Clean Code 

Muchas veces es difícil encontrar la palabra adecuada para esa variable, método o clase cuando estamos desarrollando. Para no quedarnos parados indefinidamente pensando acabamos añadiendo un comentario que explica su uso.

En el caso de manuales ocurre lo mismo respecto al software que documentan, existen por la incapacidad del software de ser autoexplicativo. Para que no hiciera falta manual, cada botón, etiqueta y elemento del interfaz debería indicar por sí mismo y de modo preciso qué es y para qué sirve sin tener que consultarlo en un manual. Esto implica que el equipo de desarrollo debe encontrar el nombre perfecto en cada ocasión, lo cual es una tarea nada fácil. En los libros de Rothfuss el encontrar el nombre perfecto de las cosas es la habilidad de los llamados maestros nominadores, como el Maestro Elodin.

Ahora tenemos la suerte de que David Branco, nuestro escritor técnico, esta cumpliendo este rol. Siempre tiene para nosotros la palabra precisa que necesitamos para poner el nombre a un nuevo tipo de almacenamiento, el texto de una etiqueta o del botón que estamos añadiendo para que exprese de modo preciso su misión. Ya tenemos nuestro Maestro Elodin.

Wastes o desperdicios en desarrollo de software

Me he propuesto hacer el ejercicio de identificar qué desperdicio Lean está asociado a cada lastre de una retrospectiva y cual se elimina o reduce en cada motor. Para saber de qué estoy hablando con motores y lastres entra aquí

Para que no vayas buscando en la wiki o páginas aparte cada lastre voy a resumir cuales son los 7 +1 wastes en desarrollo de software

1. Esperas. Esperas por recibir un detalle de un requerimiento, esperas para tener un build completo, esperas a que se completen los tests, esperas hasta que lo que has desarrollado lo prueba el cliente y te dice si es lo que quería, esperas a que un compañero te resuelva una pregunta que no te deja continuar…

2. Sobreproducción. Hacer programas que nadie necesita y nadie usará nunca.

3. Sobreingeniería. Es parecido al anterior. Desarrollar funcionalidades que no se han pedido sólo por aprovechar el tiempo en algo. Por ejemplo, preparar un sistema para millones de usuarios cuando es una panadería local.

4. Stock. Sí, en desarrollo también existe el stock. Stock de análisis de historias que nunca llegan a desarrollarse, stock de desarrollo que nunca se completa o se prueba, stock de funcionalidades que nunca llegan a deploy. Cada uno de estos stocks ocupan espacio en complejidad, y hace más difícil nuevos desarrollos sin que haya dado valor.

5. Transporte. En desarrollo de software el transporte está relacionado con el cambio de contexto. Cada vez que tienes que pasar contenido de la memoria a largo plazo a  la de corto plazo hay trasaporte. Ejemplos son cambios de historias en el mismo día, cambios de lenguajes de programación, cambios de rol del programador.

6. Movimiento. Es movimiento de personas tanto en espacio físico (para preguntar, pasar a otro ordenador, etc..) como movimientos virtuales (entrar en una ruta de directorios compleja, muchos clics para resolver un problema o hacer una acción)

7. Defectos. No creo que haya discusión en esto. Cualquier defecto en diseño, desarrollo o test provoca trabajo extra. Cuanto más se retrasa el momento del defecto a su descubrimiento y resolución, mayor suele ser ese trabajo extra o coste.

y el +1. Talento. Cada vez que uno realiza un trabajo que puede hacer otro, desaprovechando el talento o conocimientos que nadie más tiene, es un desperdicio.  Muchas veces ocurre por aliviar un cuello de botella pero hay que evaluar el sobrecoste de ese desperdicio de talento para buscar otras formas de gestionarlo.

¿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.

 

 

 

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.