Posts Tagged inglés

Nueva vida: semana 5

La semana pasada ha sido una semana un poco rara. Hemos puesto en producción la versión 1.3.0, después de poner en un entorno nuevo (DEMO) la 1.3.0-RC1 el lunes por la noche y la 1.3.0-RC2 el martes por la noche. La negociación para lo que debía entrar en la 1.3.0-FINAL creo que tuvo más que ver con que no tenemos aún rodado este nuevo proceso con la falta de confianza que da el estado actual de una de las funcionalidades que queremos poner en producción para liberarnos de procesos manuales. Así que tuvimos un poco de ruido de fondo. El equipo estuvo “casi” trabajando sin verse afectado. Pero yo tuve discusiones por teléfono con nuestros ¿dueños de producto?. Mi inglés a nivel negociación deja algo que desear, pero mi inglés a nivel defensa creo que no está mal.

La puesta en producción fue “casi fina”. Se nos olvidó ejecutar un script que actualizaba unos datos y eso nos provocó un poco de desasosiego al principio de la mañana. Lo resolvimos bien, aunque debemos aprender para el futuro a tener mucho más controlado lo que hay que hacer para los pasos a producción.

Pero la ley de Murphy es implacable y, tras el paso a producción, un par de problemas sin conexión alguna con el nuevo código hicieron que el viernes tuvieramos a medio equipo dedicado a encontrar qué estaba pasando. Sólo puedo decir que, efectivamente, es una cagada importante que nos va a impactar bastante, pero bueno, hay que vivir con estas cosas. “El mundo real” creo que le llaman algunos. ;-)

Además de este ruido, inherente al pasado y presente del proyecto, tuvimos una visita de quien yo diría que es lo más parecido a nuestro dueño del producto. Estuvimos todo el día haciéndole preguntas, tratando de averiguar cuáles son las verdaderas prioridades (aparte de los compromisos que algunos tengan en forma de project plan) y, sobre todo, haciéndole entender la esencia del nuevo proceso. Yo, en mi linea de sinceridad “estilo House” (la verdad aunque te duela), me la desayuné diciéndole que el proyecto estaba medio muerto, que soy el quinto jefe de proyecto que pasa por aquí, que el código está muy mal, que hay funcionalidades sobre las que no tenemos el control y que no podía comprometerme ahora mismo con ninguna fecha porque no tenía ni idea de cuánto podíamos tardar en hacer una funcionalidad cualquiera. La cara de esta buena señora fue pasando del rosa pálido al blanco mortecino. Me preguntó: “¿Tienes un plan?”. Je, je. Me encantan esas preguntas. “¿Un plan con fechas? No. Pero tengo un plan: el equipo va a entregar todas las semanas un poco. Y siempre lo más importante.” Bueno, creo que llegados a ese punto, no era suficiente. Le enseñé ufano mis tablones. (No están del todo bien, pero ya me valían para lo que quería enseñarle). Le dije: “¿Ves?” Mmmm. Creo que tampoco la convencieron. Hasta que recurrí a las metáforas. ¡Benditas metáforas que todo lo pueden!

Quiero que el equipo sea como un ciclista. Quiero que empiece a pedalear. Primero pedaleará un poco despacio, pero a medida que se vaya encontrando cómodo irá pedaleando mejor y más rápido. Sin cansarse. Todo lo que haga falta. Así, si vamos pidiéndole pequeños esfuerzos todas las semanas, los podrá ir consiguiendo.

Le expliqué lo importante que es para nosotros, ahora mismo, enfocarnos en las tareas y tener claro lo que se considera “acabado-acabado”. Por eso le expliqué lo interesado que estoy en que seamos capaces de entregar a su equipo de QA pequeñas funcionalidades para recibir feedback lo antes posible y poder revisar lo que estamos haciendo para no propagar malentendidos por toda la aplicación. Y parece que, entre mi machaque metodológico y de sinceridad brutal, que “los chavales” la acribillaron a preguntas sobre dos o tres funcionalidades que no estaban claras, y que le enseñamos la generación de un informe que antes tardaba cerca de una hora y ahora apenas unos segundos… sus defensas bajaron. (Bueno, también tuvo que ver que la tuvimos sin desayunar y la llevé a comer bastante tarde, pero resulta menos literario). :-)

Después de comer (por cierto, Ramón, pagué yo) nos pusimos a escribir tarjetitas. Resulta que su prioridad es muy parecida a la nuestra: tener el control sobre lo que está en producción y luego ser capaces de tener para fin de año funcionalidades que deben estar “sí o sí” porque son obligaciones legales. Así que estuvimos escribiendo historias de usuario (bueno, lo más parecido que pudimos) para tratar de tener más claro que ahora que lo que está en producción actualmente es correcto. Si comprobamos todo eso junto a uno de sus compañeros, que va a estar con nosotros esta próxima semana, y sacamos las dos o tres tarjetas que el cliente final-final está esperando:

Eso sí, hemos escrito un montón de tarjetas nuevas pero no hemos negociado qué otras cosas se quedarán fuera de esta iteración: .

También se nos ha quedado en el tintero escribir (aunque sea por encima) las tarjetas de las otras prioridades importantes (aunque no urgentes). Así que me toca hacerlo a mi. :-(

Con tanto ruido el viernes, alguien (creo que fue Victor, el ScrumMaster en prácticas) me preguntó: “¿vamos a hacer la retrospectiva?” Diossss, ¡ni me acordaba! La verdad es que como coach y como scrummaster dejo mucho que desear. Bueno, total, puse en la balanza los beneficios de hacer la retrospectiva el viernes o dejarla para otro día. Ganó el dejarla para otro día. No sabría si considerarlo un . Un poco sí, porque rompemos el ritmo (que aún no tenemos), pero creo que los beneficios de estar trabajando con nuestra “dueña de producto” eran más interesantes.

Por cierto, que no se me olvide. Uno de los “javeros”, que resulta ser el pistolero más rápido al Oeste del Pecos (ya sabéis, es de los que dispara y después pregunta), se ha llevado el libro de TDD de Carlos Blé y el Implementation Patterns de Beck. Sé que el segundo no se lo leerá a pesar de las dos semanas de vacaciones que se lleva. ¡El inglés, esa gran barrera! Pero tengo muchas esperanzas en él y no descansaré hasta que, como mínimo, sea capaz de hacer un “extract method” (aunque no tenga tests) <– ¿He dicho yo eso?

Y por último, un poco de autobombo y autocomplacencia: mi jefa me presentó como “il grande mago”. Por suerte, el equipo tiene los pies en la tierra y en la anterior retrospectiva ya habló de que, de momento, contamos con el efecto “cambio de jefe de proyecto” pero que no podemos caer en pensar que hemos conseguido nada. Ea, a acostarse que mañana hay mucho que hacer. Hemos cambiado un poco la fecha de releases porque esta semana hemos tenido un día menos y nuestros QA no querían tener menos tiempo para probar. No es grave. Seguimos buscando nuestro ritmo sostenible.

Actualización:

Se me olvidaba. Esta semana también se incorporó un nuevo compañero. Debo agradecerle su comprensión porque mi falta de previsión me ha hecho tenerle prácticamente abandonado y sin ni siquiera un ordenador con el que trabajar. Ya tengo planes para él. Los pondremos en común y a ver cómo los podemos poner en práctica. :-)

Tags: , , , , , , , , ,

Introducción a m2eclipse

Por fin he conseguido terminar la traducción del artículo “Introduction to m2eclipse” que comenté hace unas semanas. Espero que os sea de ayuda. Me gustaría también complementarlo con otro material en español que he encontrado en la red:

Para los que queráis ahondar en el tema (en inglés) os recomiendo el wiki del proyecto m2eclipse.

Tags: , ,

¿Maven + Eclipse = m2eclipse?

Bueno, parece que últimamente me estoy especializando en traducciones del inglés al español porque estoy traduciendo (con permiso de los autores) un artículo sobre el plugin m2eclipse que apareció este verano en TheServerSide. Espero que nadie que sea experto en traducciones lea las mías porque podrá sacarme los colores fácilmente.

Por cierto, el artículo lo estoy traduciendo a ratitos y surgió como consecuencia de una pregunta que hice en la lista “ecosistemas-software” (que aprovecho para recomendar) en la que encuestaba sobre las alternativas para usar Maven en Eclipse: m2eclipse y Q4E.

Cuando tenga terminada toda la traducción os lo haré saber.

Editado:
He cambiado la dirección donde he publicado la traducción. Espero que si hay errores en la traducción me lo hagáis saber para corregirlos, gracias.

Tags: , ,

Hablar inglés es fácil… si sabes cómo

Hay toda una serie de palabras que empleamos en nuestra vida diaria y sobre las que no solemos hacer reflexión alguna porque forman parte de nuestro bagaje cultural común: el español. Sin embargo, en nuestra profesión solemos leer e incluso utilizar palabras de otros idiomas sin esa reflexión implícita o explícita. Voy a tratar de poner mi granito de arena en este asunto: modestamente y reconociendo de antemano que ni soy filólogo ni nada por el estilo.

Para ello a comenzar una serie de entradas en las que pretendo discutir sobre un término en particular y sobre el que, probablemente, algunos tengáis una opinión diferente. Os propongo realizar esa reflexión sobre el uso de esas palabras en público para así enriquecer nuestros propios puntos de vista.

Accountability

From the WordReference Supplement © 2008 WordReference.com:


accountability:

accountability nf responsabilidad

Esta palabra es el título del capítulo 2 del libro “Analysis Patterns” de Martin Fowler. Asimismo, es una palabra clave en el resumen del perfil de Kent Beck en LinkedIn:

My goal is to program well on teams and to encourage improvement in my
profession. I am actively working on becoming more transparent and
accountable in my work and improving my skills designing incrementally
and interacting with people.

Quería comenzar por esta palabra (y no por otras que puedan resultar más evidentes, como “feedback” o “refactor”) porque también quiero que sirva de declaración de intenciones: ésta es una palabra que no solemos usar (ni en inglés ni en español) pero cuyo significado es muy profundo y tiene que ver con otras palabras que usamos con cierta ligereza, como calidad o profesionalidad. También es una excusa para comentar que (¡¡POR FIN!!) he comenzado a leerme el “Analysis Patterns” de Fowler y que me parece probablemente el libro técnico más recomendable que he leido jamás.

Accountability significa responsabilidad, pero en el sentido de compromiso, es decir, según el DRAE (Diccionario de la Real Academia Española):

responsabilidad.

1. f. Cualidad de responsable.

2. f.
Deuda, obligación de reparar y satisfacer, por sí o por otra persona, a
consecuencia de un delito, de una culpa o de otra causa legal.

3. f. Cargo u obligación moral que resulta para alguien del posible yerro en cosa o asunto determinado.

4. f. Der.
Capacidad existente en todo sujeto activo de derecho para reconocer y
aceptar las consecuencias de un hecho realizado libremente.

Real Academia Española © Todos los derechos reservados

responsable.

(Del lat. responsum, supino de respondĕre, responder).

1. adj. Obligado a responder de algo o por alguien. U. t. c. s.

2. adj. Dicho de una persona: Que pone cuidado y atención en lo que hace o decide.

3. com. Persona que tiene a su cargo la dirección y vigilancia del trabajo en fábricas, establecimientos, oficinas, inmuebles, etc.

Real Academia Española © Todos los derechos reservados


En mi opinión, tanto Fowler como Beck usan “accountability” y por tanto “responsabilidad” en el sentido de “Cualidad de responsable“.

Fowler habla de los objetos y las responsabilidades que asumen dentro
de un modelo, mientras que Beck habla de sí mismo como profesional
dentro de un equipo de desarrollo. Fowler aplica la primera acepción del DRAE (Obligado a responder de algo o por alguien) mientras que Kent se refiere a sí mismo y por tanto debemos aplicar la segunda acepción (Dicho de una persona: Que pone cuidado y atención en lo que hace o decide).

Tags: ,