Nueva vida: semana 3

Esta semana ha tenido también sus altibajos: lunes con medio equipo, martes festivo pero trabajando (también con parte del equipo para dar soporte a las posibles incidencias urgentes que pudieran surgir en producción), miércoles entrega en producción de un paquete de cambios que se llevaban postergando desde hacía muchísimas semanas, jueves de resaca de la entrega y viernes de retrospectiva. El resumen: energético a tope pero, como siempre, la realidad me hace evitar la autoindulgencia. Tenemos mucho camino aún que recorrer. Para ayudarme en este camino, y aprovechando que Amazon está de rebajas en los gastos de envío, me he pedido (entre otros) el último libro de Mike Cohn (“Succeeding with Agile”).

Desgraciadamente he olvidado las notas de la retrospectiva, pero lo cierto es que fue MUY BIEN. Recordatorio: hacer las retrospectivas los viernes porque te vas de subidón el fin de semana. Bueno, eso si te vas enseguida, porque si no te puede pasar como a mi y a unos de los chicos, que lo tuve enmarronado y SIN COMER hasta las 5 de la tarde. Pido perdón públicamente (sobre todo porque no es la primera vez que lo hago). Eso sí, para el pase a producción que hicimos fuera del horario de trabajo habitual, los chicos de Kotasoft al menos, cobrarán sus horas extras. Lógicamente.

Pero el cliente necesitaba un informe de producción. Un informe que llevamos con él desde antes de que yo llegara. Hay problemas de rendimiento, confusiones con la información que necesitan que aparezca, un tamaño que cada día que pasa crece más y más porque parece que piden toda la información generada desde el principio de los tiempos. Conclusión, estuvimos un buen rato correo pa’rriba, correo pa’bajo, generando un informe que nos tarda una eternidad y cuyo código es un verdadero infierno, hasta que por fin decidí darles mi número de teléfono y darles la oportunidad de que me llamaran. Parece mentira lo que hace hablar (aunque sea a través de un intermediario, porque el tema del inglés no es deficitario sólo en España). Hablando con el cliente (recordemos aquello de “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor”) me enteré de que resulta que este informe al que nadie parece darle importancia (porque es un c*ñ*z*) es la única herramienta que tienen para conocer el estado el negocio. Vaya. Si resulta que era no sólo importante, sino lo más importante. Así que está claro que el backlog está muy mal priorizado, está priorizado por emergencias y no por importancias. He quedado con las personas adecuadas para resolver esta historia de usuario el lunes a primera hora y hasta que esté terminado a satisfacción del cliente. Porque si no es así, volveremos a perder tiempo y esfuerzos en algo que debemos hacer bien y darlo por acabado de una vez por todas.

El pase a producción del miércoles fue un éxito porque ha servido para relajar muchas tensiones. La “gente de arriba” ha podido comprobar que el equipo está comprometido con el proyecto. El equipo ha podido comprobar que se le escucha porque poner en producción todos estos cambios serios era una reclamación suya de hacía mucho tiempo y que les estaba haciendo dar vueltas alrededor de problemas de una manera bastante absurda: “no puedo resolver esta tontería en producción porque no he podido pasar a producción cambios más serios”. El propio cliente ha podido ver que se está retomando el control. Aunque esté doliendo un poco. En general, creo que este hito ha servido para alinear un poco a todos alrededor del éxito del proyecto.

Desafortunadamente, nos queda aún mucho por trabajar en muchos temas. Especialmente en el de conseguir enfocarnos. Eso salió en la retrospectiva, por supuesto, y se evidenció que era necesario trabajar los tablones, que son nuestra principal herramienta de comunicación y gestión de las prioridades. Así que me fui a un Workcenter que hay cerca y me he comprado una pizarra y un tablón de cartón pluma (que tuve que pedir que cortaran en dos porque no cabía en mi coche). Je, je, vaya FAIL. 😀

Voy a hacer 3 tablones: uno para el product backlog (hay que ver las prioridades a medio plazo, eso es algo que todos queremos ver siempre), uno para el sprint backlog (que ahora mismo está “manga por hombro”) y otro para lo que voy a llamar “Soporte a la Producción” y que espero que algún día podamos pasar a un equipo creado “ad hoc”. No sé si ya os he comentado que este proyecto ya está en producción, que los productos financieros a los que damos soporte se están comercializando ya y que no todo está automatizado, así que hay muchas tareas manuales que deben hacerse para dar “soporte a la producción”. El problema es que no hay un equipo dedicado a ello sino que estas tareas recaen sobre el equipo de desarrollo. En la retrospectiva ha surgido una idea para tratar de ayudar a paliar mucho del ruido que se genera por no tener canales de comunicación claros. Yo también quiero trabajar este asunto evidenciando los procesos de negocio usando alguna herramienta gráfica (he pensado en el BizAgi Process Modeler). Me ha dicho mi jefa que está trabajando en poder tener ese equipo de “atención al cliente” y “soporte a la producción” pero que no hay gente en la organización para ello, así que habrá que esperar y vivir con ello. 🙁

Por cierto, el jueves estuve haciendo una entrevista a un javero para este proyecto. Si te has leido “Implementation Patterns”, “Clean Code” o “Refactoring” y estás dispuesto a sufrir de lo lindo… ponte en contacto conmigo. ¡Diversión garantizada!

PS:

Que me quedo con un cierto regusto de no citar el resumen en tres partes que Alfredo Casado hizo en su momento sobre Clean Code:

aunque el que he incluido más arriba de Justo Aguilar incorpora esos videos de UncleBob que no tienen precio. 🙂

PS2:

Tenía intención de enlazar a un artículo sobre Retrospectivas, pero no he podido encontrar ninguno que realmente me guste. Si me aconsejáis alguno lo incluiré en el futuro, si no, tendré que escribir uno. 🙂

  • Muy buena elección el nuevo libro de Mike Cohn, no he tenido oportunidad de leerlo completo pero los capítulos que me he leído me han parecido interesantes. Me gusta mucho como escribe, aunque claro esa es solo mi opinión 🙂

    Buen trabajo y a seguir así que parece que el proyecto empieza a tomar un rumbo muy interesante.

    Un saludo

    • jmbeas

      Sí, Yeray, el proyecto parece que se empieza a enderezar. Pero no nos podemos relajar. Ahora viene lo más difícil: hay que conseguir el ritmo sostenible.

  • Pingback: Tweets that mention Se hace camino al andar… » Blog Archive » Nueva vida: semana 3 -- Topsy.com()

  • Ricardo

    Hola,

    Me ha parecido muy interesante el tema que has introducido acerca de los “equipos de producción”.

    En nuestro equipo, somos un número fijo de programadores y queremos crear este tipo de “servicio” de cara al cliente. ¿Es razonable sacrificar a un par de personas para este cometido? ¿Es mejor hacer una rotación del equipo para asumir este tipo de tareas “non gratas”?

    Está claro que lo ideal sería contratar a más personal para este fin, pero en caso de que no se consiga, ¿Cual piensas que sería la estrategia que menos dañara al equipo?

    El otro dia escuchando un podcast de Software Engineering Radio sobre Agile Testing, la ponente comentaba que ellos rotaban en cada spring y así nadie se agobiaba mucho tiempo con estas tareas.

    Un saludo,
    Ricardo

    • jmbeas

      Sí, Ricardo, en realidad todo tiene que ver con el concepto de producto. En este caso, como casi siempre, se desliga la construcción de la aplicación del resto del producto. De esta manera, se producen desalineamientos muy malos para todos. Los técnicos no saben para qué están trabajando, sus managers pierden la noción de la importancia de los procesos de negocio para los que se quiere hacer una herramienta (la aplicación) que ayude en ellos, y los que venden el producto (en nuestro caso productos financieros con implicaciones legales, fechas a cumplir, reglamentos, etc) no entienden que no se puedan cumplir estos requisitos tan importantes. Pero bueno, ésta sería la raíz del problema.

      En un post anterior, “reemplazable” decía que rotaran. La idea está muy bien, pero implementarla no es tan fácil porque son equipos que van a velocidades diferentes. El equipo de desarrollo va (irá) a un ritmo sostenible mientras que el otro va guiado por las prioridades del momento. Mi intención es no tener siempre a los mismos haciendo este trabajo, pero tengo también que buscar una cierta estabilidad en sus actividades. Probaré a ir cambiando a uno cada dos semanas (una iteración). Es un equipo de tres, así que el tiempo máximo será de 6 semanas. Eso si no puedo acabar con este equipo antes bien porque hemos automatizado todo (no lo creo) o bien porque finalmente hay un equipo de “helpdesk” como es debido.

  • Leches, eso de backlog priorizado por urgencia y no por importancia me suena… Al final dejas de lado las tareas importantes para apagar incendios y un dia todo te explota en la cara. Yo creo que la diferencia entre importante y urgente es de lo más difícil de captar para la gente en general.
    En fin parece que levantais cabeza, enhorabuena y como dices, no bajes la guardia.

    • jmbeas

      Gracias Enrique. El problema fundamental para no tener bien priorizado el backlog es la falta de un dueño de producto. No sé quien dijo que “si no tienes dueño de producto no haces scrum”. Es una verdad como un templo.

  • SQA

    Hola buenas, hacia tiempo que no me conectaba a tu blog.
    Respecto a lo que comentastes de Hudson, si vuestra aplicación cuenta con un CVS y no trabajais con otras aplicaciones en un mismo repositorio en el que hay subidas constantes por varios integrantes de vuestro proyecto y otros proyectos no veo utilidad a Hudson, queda muy bonito decir que lo tienes pero si vais tan mal de tiempo como comentas igual no es una buena idea haber perdido tiempo en su instalación. Como lo veis los demás gurus??
    Un saludo a todos!

    • jmbeas

      Estimado SQA (mira que algunos tenéis nombres raros para preservar vuestra intimidad),

      Te voy a contestar con un “motto” muy conocido: “¡En mi PC funciona!”. ¿Realmente crees no merece la pena el tiempo invertido en tener un sistema de integración continua, que se encarga de bajar el código en un entorno limpio, donde sólo hay lo que se espera que haya y nada de “es que se me olvidó subir tal” o “es que con la configuración de mi Eclipse”? Ha merecido todos y cada uno de los minutos empleados en tener el control sobre el software que estamos desarrollando. De esta manera sólo tenemos una fuente única de certidumbre entre nosotros y el entorno de producción. Hoy le decía a un compañero que nuestro trabajo, entre otras cosas, es proporcionar certidumbres. (Algo lejos de la realidad demasiado a menudo). 🙁

      Gracias por leerme y aportar con tus preguntas.

  • SQA

    Hola jmbeas,
    Respecto a la intimidad, aunque ponga mi nombre seguiras sin conocerme, por lo que estariamos en las mismas, jeje

    La única ventaja que os aportaría Hudson en vuestro caso, es que si algo no compila os mandaría un correo de error, pero insisto que el CVS ya se encarga de ver si algo no compila por el motivo que sea, si a alguien se le olvida subir algo, etc.
    Me parece, como te ponía en el post anterior, que es algo “mu chulo” eso de instalar Hudson, pero en vuestro caso de único equipo con su propio repositorio, me parece matar moscas a cañonazos (me encanta este dicho).
    La integración continua se debería utilizar cuando varios equipos de desarrollo están integrando código a una “aplicación de aplicaciones” por llamarmo de alguna forma.

    La otra utilidad de Hudson que dudo mucho que podais explotar por lo que cuentas de tiempos (tiempo para hacer las cosas), es que os pase los test automáticamente, porque entiendo que no podreis ni realizar dichos test.

    Me mantengo en mi modesta opinión que Hudson no es necesario en vuestro proyecto aunque más adelante si cambia la tipología del proyecto si os pueda servir, pero de momento….

    Un saludo!

  • jmbeas

    Para mi, el tener una máquina aislada donde puedo descargar el código que hay en SVN y realizar el build sin preocuparme del efecto “en mi PC funciona” justifica por sí mismo el tener Hudson (o cualquier otro sistema, pero Hudson es el más fácil de instalar y usar y el más flexible y potente para el futuro).

  • SQA

    Si no le funciona a alguien el código en el PC, por mucho Hudson que tengas, al que no le funcione va a tener que hacer porque funcione en su PC, haciendo varios builds, cerrando y abriendo el proyecto, limpiando cache, reiniciando windows (este es broma, porque como sirve para todo, jeje) por lo que si te funciona bien, pero si no te funciona te tienes que tomar ciertas molestias en hacerlo funcionar tengas o no Hudson.

    Lo de tener una máquina aislada donde descargar el código… pues, creo que no aporta nada nuevo que no puedas hacer con CVS entiendo yo.

    Lo dicho como bien apuntas al final del tu post y era lo que yo decia en mis post: “potente para el futuro” donde tire vuestros JUnit, podais realizar Reports, el objetivo de integración continua entre varias aplicaciones y por supuesto el innumerable juego de plugins que tiene, que tiene más que el baul de la piqué, para mi el más imprescindible el de Chuck Norris, que no veas que cabreos se pilla cuando no compila algo (este es para frikis, seguro que te mola ;))

    Un saludo!!