Falsos Profetas

Hace un tiempo me dieron un valioso consejo. En Argentina somos orgullosos y a veces los vocablos no son compatibles con lo que el cliente interpreta y quedamos muy poco serios cuando los gurúes, maestro o un genio los gurúes, los masters o los genios terminan siendo falsos profetas. Ya nos ha pasado y el cliente se nos río en la cara.

Cuando se habla con contactos de afuera, conviene llamarlos lideres técnicos, pero no mas que eso.

Un gurú en Silicon Valley es un Phd que invento algo o está a cargo de una amplía área de conocimiento con proyectos de volumen y experiencia world class.

Estamos inducidos a usar estas denominaciones, pero suena mucho mas profesional un mensaje si se expresa con terminología corriente.

Unit Tests en Etapas de Bugfixing

Continuando el artículo de Unit Tests que escribí unos años atrás, les dejo una lista muy simple de pasos para trabajar con Unit Tests cuando se corrigen bugs. Estos pasos deberían ser siempre los mismos:

1. Crear el test que comprueba el error. Este test TIENE que fallar.
2. Una vez demostrado que el error falla y SOLO entonces, se modifica el código para corregirlo.
3. Luego de corregirlo se ejecuta el test nuevamente y se verifica de que el problema este arreglado.
4. Este test se lo deja y se corre con la integración continua para verificar con cada build que el bug no volvió a aparecer.

Soft Skills

Las habilidades blandas (o Soft Skills) forman parte de las herramientas que tenemos para salir ilesos de un día laboral. Como el trabajo de PM requiere mucho contacto con personas, estas son mas que útiles. ¿Cuales son? Se las dejo a continuación:

Manejo de conflictos: la habilidad de resolver diferentes puntos de vista en forma constructiva. Sentar a dos personas con visiones opuestas y lograr que todos lleguen a un acuerdo.

Empatía: la capacidad de percibir y comprender los sentimientos y actitudes de otros. La empatía se explica muchas veces con la frase “Saber ponerse en los zapatos del otro”.

Resolución de problemas: la habilidad de identificar los componentes clave de un problema, formular una o varias soluciones y actuar en consecuencia. Conducir bien tu automóvil en una avenida con mucho tráfico es tener esta habilidad, lo mismo dar un buen pase en un partido de fútbol cuando estás rodeado de adversarios (”…identificar el problema, pensar en soluciones y actuar…”).

Responsabilidad por otros: la habilidad por tomar responsabilidades por las acciones de otras personas. Saber confiar. Comprender qué es delegar una tarea y simplemente confiar en el otro.

Inteligencia emocional: la habilidad para entender emociones propias y de otros, y comprender por qué una cierta emoción impulsa a actuar de una cierta manera a un individuo. Yo siempre explico esta habilidad blanda como la capacidad de ver un episodio de una novela latinoamericana en la TV y poder explicar qué pasó y por qué cada personaje actuó como actuó o dijo lo que dijo (admiro esta habilidad en las mujeres, ya que son mejores que nosotros en esto).

Fuente: IAAP

Being Geek: The Software Developer's Career Handbook

Finalmente terminé de leer Being Geek: The Software Developer's Career Handbook, de Michael Lopp. Este libro es el segundo del autor (el primero es Managing Humans) y realmente lo disfrute, aunque confieso que el primero me gusto más, ya que desde ese momento comencé a seguir el blog del autor y el libro esta armado con muchos de los artículos que el va escribiendo.

Sin embargo, este libro no tiene desperdicio. Desde el trailer que publiqué hace poco (ver!), surgieron tres artículos de revelaciones que quería compartir:

• Como evitar perder candidatos con la propuesta aceptada
• Trabajo en equipo
• Alejandonos del estanque (Trabajando remoto)

El libro es una guía de carrera para todos los que trabajamos en el área de informática. Tiene muchas historias y sugerencias para manejar tu carrera, desde como detectar que uno esta mal en el trabajo actual, hasta que tipos de trabajos le vienen mejor a uno para cada momento de la vida. Tiene el contenido justo de humor e informalidad que lo hacen muy ameno para leer. Altamente recomendado!

Scrum: Comprometiendo Nuevas Tareas a un Sprint en Curso

En Scrum es posible que tengan que comprometerse nuevas tareas al Sprint. Esto puede pasar cuando alguien del equipo termina sus tareas y no quedan otras tareas asignadas a otros miembros del equipo que esta persona se puede hacer. También pueden quedar tareas bloqueadas, pendiente de definición del cliente, aunque idealmente las tareas que se comprometen a un Sprint cumplen todas las precondiciones para poder completarse dentro del Sprint.

En este caso, lo que hay que hacer es ir al Backlog y tomar la historia de mayor prioridad que pueda tomar esta persona que quedo libre. Un criterio incorrecto que solía tomar era comprometer la tarea solo si podía llegar a cerrarse dentro del Sprint, esto es cumplir con el "Done Criteria" definido. Utilizando este criterio, no siempre se atacaban las tareas de mayor prioridad para el negocio, que es lo que el cliente prefirió hacer, aunque no se lleguen a terminar las tareas en el Sprint.

En cualquier situación, el gráfico de Burndown va a deformarse uno de esos días, ya que se le agregan horas de trabajo al Sprint, y si las tareas bloqueadas no se sacan del Sprint, nunca se va a llegar a cero. Sin embargo, es recomendable dejarlas para que se vea que se estuvo bloqueado.

Supongo que en mi cabeza hizo mas fuerza el concepto de un Sprint como algo cerrado, tratando de cumplir con el "Done Criteria" de todas las tareas, pero el cliente prefería que se avance con las tareas de mayor prioridad para el negocio, que es mas que comprensible. Lo importante en estos casos ambiguos, es charlarlo con el cliente y tomar una decisión conjunta del criterio a tomar.

Scrum: Como informar inconvenientes que afecten la velocidad del equipo

Cuando un equipo no puede desarrollar sus tareas normalmente, por ejemplo por experimentar errores aleatorios en el ambiente de trabajo, lo natural es sobrestimar las tareas de desarrollo para poder llegar a terminar las tareas. Menciono que es natural, porque sale instintivamente debido a que la mayoría de la gente estuvo en un proyecto con un proceso de desarrollo en cascada, y sobrestimar era la forma con que se trataba este problema.

En Scrum, en una reunión de planeamiento del sprint, cuando todas las historias ya tienen story points y hay que crear tareas y estimarlas en horas, la idea es tener en cuenta que se está trabajando en un ambiente ideal. Si se sufren problemas de ambiente de trabajo, hay dos formas de informar esto.

La primera es bajar la capacidad de los miembros del equipo afectados. Bajando la capacidad en un cierto porcentaje, se tienen menos horas por sprint para asignar tareas. Esto hay que informarlo insistentemente al cliente o a quien pueda ayudar a resolver este problema, ya que claramente queda evidenciado que el equipo puede dar más, pero debido a estos problemas se pueden asignar menos tareas, y entonces la velocidad del equipo se aleja de la ideal.

La segunda es no disminuir la capacidad, pero hacer un tracking de estos errores, teniendo una historia llamada "tareas no planeadas", y cargando tareas con un cierto tiempo para informar estos errores. Esto tal vez tenga mayor visibilidad para el cliente, pero insume mayor tiempo al equipo.

Resumiendo, la idea es dejar atrás el viejo paradigma de sobrestimar y mediante alguno de estos dos métodos, reflejar la realidad del trabajo del equipo para que se tomen acciones y se puedan resolver temas que afectan la velocidad.