7 Fallos habituales en una sprint review

Una sprint review parece sencilla. Pero como siempre, podemos caer en la dejadez, dejar de trabajar con rigor, cayendo en una serie de fallos habituales que os comento. Al final del post os dejo un vídeo que satiriza una sprint review. Pero empecemos con los 7 fallos habituales en una sprint review:

1.Expectativas de trabajo completado fuera del plan original.

Es muy típico esperar que se lleven a cabo tareas “extra”. Después de todo ¿no es eso ser ágil? Entonces, ¿porqué no incluir pequeños cambios o tareas adicionales, durante el sprint? Creo que todos ya sabemos que un sprint precisamente está pensado para acometer de la mejor manera posible, las historias de usuario planificadas. Nada menos, pero tampoco nada más.

2.Confundir estimaciones con compromisos.

Esto es también muy habitual. Una estimación no es más que eso. A veces las estimaciones son erróneas, y un sprint trata de acometer todo el trabajo planificado, pero a veces simplemente no es posible. Deja la historia de usuario sin completar para el próximo sprint, no sin antes asegurarte de ver porqué te equivocaste al estimar, no sea que en realidad haya más trabajo oculto del que creías.

3.Expectativas no realistas

Podemos tener expectativas no realistas de ausencia de errores, corrección de errores existentes, funcionalidades pretenciosas, hitos inalcanzables, etc.

4.El product owner que no actúa como tal.

El product owner puede que vea la funcionalidad por primera vez en la propia sprint review. Eso significa que no ha dado feedback durante su desarrollo, y que su labor de product owner no ha sido tal.

5.No mantener informado al equipo.

La comunicación y la información son claves. El equipo debe estar puntualmente informado de todo, pero especialmente de revisiones hechas sobre los objetivos del sprint.

6.Ver la review como una oportunidad para buscar culpables, en lugar de aprender y educar.

Esto es también muy típico en proyectos que se inician por primera vez en SCRUM u otras metodologías ágiles. Cuando algo falla, debemos investigar los motivos y buscar soluciones…no culpables.

7.Confundirlo con una retrospectiva.

Efectivamente, los conceptos de sprint review y sprint retrospective son bastante diferentes. Mejor dejaremos el detalle de su comparativa en un post dedicado a ellos y a sus diferencias.

Anuncios

Habilidades vs títulos (episodio 2)

dilbert-certification

Si hace poco hablába de la titulitis en el artículo “Habilidades vs títulos” (que ahora deberé renombrar añadiéndole “episodio 1”), ahora va el jefe de Recursos Humanos de Google y suelta la frase: “el expediente académico no sirve para nada“.

Y es que nos pongamos a la defensiva o no, se está demostrando cada día más que la postura de “yo valgo porque mi título es tal o cual”, ha muerto, y debería considerarse una postura conformista y obsoleta.

Por desgracia, todo cambia, y debemos adaptarnos. Ya nunca más el tener un título va a suponer una ventaja absoluta, y debemos mirar con otros ojos (y con el debido respeto profesional), a los que han elegido otras vías de formación. Debemos valorar por capacidades, no por títulos.

Tal y como afirma el jefe de RRHH de Google, lo que se enseña en la universidad es muy distinto de lo que se necesita en el mundo laboral. La paradoja, tal y como desarrolla en el artículo, es que la universidad enseña…a superar la universidad. Del mismo modo que el hacer muchos Test Psicológicos entrena a superarlos (no necesariamente desarrolla el intelecto, aunque aparentemente los resultados de tus test sean exponencialmente mejores). De ahí se deduce que una persona que saca muy buena puntuación en un test…sólo significa eso y nada más. Para resolver problemas reales…hay que enfrentarse a problemas reales.

En el artículo, es curioso como una de las preguntas favoritas del jefe de RRHH de Google es “Dame un ejemplo de cómo resolviste un problema analítico difícil”. Aquí empieza a verse la luz valorando la experiencia, al mismo tiempo que una mente inteligente.

 

¿Debe saber programar un jefe de proyecto?

La eterna disputa. ¿Debe un jefe de proyecto ser sólo un gestor…o debe también saber programar? ¿O debe haber sido programador? ¿O no hace falta? Bueno, hoy creo que me voy a ganar enemistades por razonar en contra de la moda. Vayamos a ello.

Algunos puntos a favor:

  • Sí, debe saber programar para saber dirigir mejor a sus equipos.
  • Sí, porque así tiene empatía con su equipo.
  • Sí, porque así sabe de qué hablar al negociar un cambio.
  • Sí, porque así sabe llevar un lenguaje técnico durante las ventas.

Algunos puntos en contra:

  • No, porque la dirección de proyectos en realidad tiene que ver muy poco con la programación. Dirigir a los equipos no es enseñarles cómo hacer su trabajo. Eso se llama formación. Dirección consiste en dar directrices, pautas y restricciones (limitaciones, restricciones, requisitos variados, etc.). Dirigir consiste en facilitar el enfocarse en una dirección, no llevar físicamente el peso del equipo. También en entender e identificar las dificultades que van surgiendo, anticiparse (riesgos), resolverlas cuando se producen (problemas), etc.
  • No, porque aunque la empatía es útil para conectar con la gente, la empatía no se consigue programando. Puedes ser un buen programador y sin embargo (y de estos me he encontrado unos cuantos), ser incapaz de conectar con clientes, compañeros, etc.
  • No, porque al negociar un cambio, ser programador no es la clave. La clave es conocer el impacto en el código, documentación, y otros proyectos o trabajos en curso. Es una temeridad creer que aunque seamos técnicos, vamos a poder identificar, en medio de una negociación, si el cambio se acepta o no, y mucho menos llevarlo a cabo. Para identificar el impacto de un cambio son necesarios: una mente analítica, tener identificada la estructura del proyecto (aquí ayuda la documentación, algún modelo o arquitectura bien estructurada, etc.). Y por supuesto, ayuda la experiencia. Pero no experiencia en programar, sino experiencia en la dirección de proyectos y cómo sus cambios cuesta llevarlos a cabo.
  • Es un error pensar que las ventas han de hacerse en un lenguaje técnico. Las ventas han de hacerse pensando en el lenguaje de la persona que tenemos delante, que no tiene porqué ser técnica. Pensar sólo en lenguaje técnico, es como mínimo, una falta de respeto a quien tenemos delante. Somos nosotros quienes tenemos que escuchar al cliente, lo más importante, y no al revés.

La realidad nos dice, y de esto encontraréis múltiples artículos en la web hablando de ello (incluido nuestro querido Dilbert), que los buenos programadores, cuando son promovidos a categorías superiores de dirección de proyectos, se encuentran con que no están preparados para dirigir equipos y proyectos. Es duro encontrarse con que se deja de tocar código, y se enfrentan decisiones organizativas, operativas, planificaciones, estimaciones, etc. Cuántos jefes de proyecto recién promocionados se sienten perdidos y decepcionados, y por supuesto poco preparados.

Tampoco estoy de acuerdo con que un jefe de proyecto deba ignorar la tecnología. Más bien al revés. Sin embargo, el mero conocimiento técnico, no nos convierte en buenos gestores. Cuantas veces oigo eso de “yo dirijo equipos”, de personas que se limitan a decir a sus programadores lo que tienen que hacer, a “pasarles las tareas”. Eso no es ser un jefe de proyecto, ni dirigir un proyecto. Hay un salto cualitativo (por la complejidad) y cuantitativo (por el número de tareas) que debe realizar un buen jefe de proyecto. Por desgracia, hay tantos malos jefes de proyecto, que es habitual oír quejas de sus programadores en los términos que comento más arriba en el apartado “Algunos puntos a favor”.

Para ser buenos los programadores, hemos de conocer los estándares de programación. Lenguajes, buenas prácticas, arquitecturas, frameworks, patrones…

Igualmente, para ser buenos gestores, hemos de conocer los estándares de gestión (PMBOK, PRINCE, ITIL,…), cómo adaptarlos a distintos proyectos, entender los riesgos que se corren con los cambios, establecer planificaciones (bien con un Gantt de los requisitos, una secuencia de sprints o iteraciones de historias de usuario, etc).

Mi conclusión, por tanto, es que sí y no. Un buen jefe de proyecto puede beneficiarse mucho de venir del área de desarrollo, y haber sido programador, analista, etc. Pero aún con toda esa experiencia, sólo con empatía, y saber hablar con los programadores, no se enfrentan y solucionan los problemas organizativos de un proyecto. Un marinero experto no es suficiente para ser un gran capitán. Aunque todo buen capitán, es fácil que haya sido antes marinero experto.

El uso correcto de las plantillas…está en el contenido

Hola, de nuevo colaboro en el arranque de un proyecto, desde mi área de calidad. Y de nuevo, ayudo en la adaptación de las plantillas y procesos para que el proyecto se adapte a lo que el cliente necesita, cumpliendo al mismo tiempo los más altos estándares de calidad.

Acabo de recibir una felicitación porque el conjunto de plantillas y documentación para el proyecto, ha sido percibido por el cliente como excelente. Y sí, para no mentir, son las cosas que te llevas a casa tras un día de duro trabajo que te animan. Las cosas que te animan a seguir luchando por mejorar, por buscar la excelencia, por no apoltronarse sentados en la autocomplacencia.

Pero claro, como buen culo inquieto, quiero más. Y me pongo a pensar que efectivamente, las plantillas, con sus guías, ejemplos y bien pensada estructura, cubren todas las necesidades…¿o no? Pero…¿qué pasa con el contenido?

En algún momento,  todas esas plantillas se convertirán en documentación real, en contenidos que reflejen la realidad del proyecto en un cierto momento y sus objetivos, suposiciones y carencias. Y sin embargo, aquí es donde realmente empieza el valor aportado al cliente. Es como si al cliente le hubiéramos dado un puente. Y sí, el puente está bien. Pero el cliente no quiere un puente. Quiere cruzar el río. Del mismo modo, lo que necesita el cliente no es las plantillas. De hecho, no quiere ni la documentación. Sino el seguro, la garantía que proporciona el tener un adecuado control del proyecto.

La documentación me recuerda al seguro de la vivienda o del coche. Los programadores no quieren oir hablar de la documentación. Esto ya lo comentaba en mi artículo “Nos gusta programar, pero no documentar“. Tampoco nadie quiere un seguro de coche o vivienda. Pero es algo necesario, ya que no podemos circular por ahí, sin convertirnos en “bombas en potencia”. Del mismo modo, un proyecto sin adecuada documentación se convierte en una bomba en potencia, ya que ante el más mínimo problema, empezamos todos a correr como pollos sin cabeza, apagando el fuego como si fuéramos bomberos.

Y es importante recordar, que podemos ser muy buenos creando código super-optimizado, clases y estructuras de información super-funcionales y cumpliendo los más modernos estándares…Pero sin una adecuada documentación, no sirve. Eso me recuerda a los ofuscadores de código. Conozco  gente que no lo necesitaba: su código era auto-ofuscado.

En fin, espero que el equipo de los proyectos sigan trabajando bien, y sobre todo, documentando adecuadamente (evitando la “documentitis”, por supuesto).

Windows 10 y la gestión de pruebas beta

Hola a todos,
Supongo que muchos ya conoceréis el concepto de Alfa y Beta en el mundo del software. Pero es importante destacar, y en ello ISTQB lo diferencia claramente:

  • Pruebas Beta es un software que se da a probar al cliente en su casa. Vamos, que se lo lleva a su casa, o su oficina, y lo prueba.
  • Pruebas Alfa es un software por el contrario, que se prueba en un entorno controlado por el equipo fabricante, en las instalaciones del fabricante.

Y digo esto porque es muy típico confundir con el concepto de pruebas Alfa y Beta con la versión Beta y la versión Alfa (o pre-Beta) de un software.

Me acabo de acordar porque precisamente estos días, me he instalado Windows 10 en versión Beta, a través del Microsoft Insider Program.

Desde el punto de vista de la gestión de proyectos software, es muy interesante este concepto, ya que permitiría, bien llevado, a llevar el agilismo a extremos insospechados. Un cliente puede usar una aplicación (o en este caso, el sistema operativo), y a través del análisis de su uso del software, se podrían detectar funcionalidades mejorables, funcionalidades más usadas, etc. Por supuesto, en el caso de Windows 10, tenemos el caso del feedback tipo “esta aplicación no me ha funcionado”, o “esta página web no se ha visto bien”.

No digo que Microsoft esté haciendo Windows 10 añadiendo funcionalidades ad-hoc a nuestros gustos. Simplemente, que estamos cada vez más, ante una forma de trabajar adaptativa (ágil), permitiendo a posibles usuarios/clientes el ver prototipos tempranos, más o menos terminados.

Otro caso, también de Microsoft, es Windows 10 para móviles. Todos los usuarios de algunos modelos seleccionados, pueden instalarse una versión bastante avanzada (pero aún no terminada), para obtener feedback del uso, pulir defectos, detectar incompatibilidades, etc.

Por supuesto que todo esto ya existe, y tenemos aplicaciones web (recordemos que GMail ha sido una gran parte de su historia una versión Beta: más exactamente algo más de 5 años entre 2004 y 2009) que se ofrecen a los usuarios de manera muy temprana. Sin embargo, la aproximación que ha tomado este fabricante me parece valiente, y a la vez arriesgada, ya que una mala gestión del modelo de betas podría afectar gravemente a su imagen, si por ejemplo todos los ordenadores o todos los móviles dejasen de funcionar, o si los móviles comenzasen a hacer llamadas de forma autónoma y arbitraria.

Aquí desde el punto de vista de las pruebas y de la ingeniería del software, vemos como se presenta una disyuntiva, y hay que buscar un equilibrio entre la estabilidad del producto (por muy beta que sea), y la necesidad de hacerlo probar a un público lo mayor posible para obtener feedback. Desde luego, es necesario tener un gran control de las pruebas realizadas, y obtener métricas que nos permitan estimar (de forma aproximada, claro), el número de defectos y su gravedad en caso de liberar nuestro producto inacabado.

¿Y vosotros? ¿Os atreveríais a hacer público un software inacabado siguiendo un modelo de pruebas Beta? ¿Cómo gestionaríais los riesgos de hacer público un producto sin terminar?

ITIL – Introducción

Tenía bastante abandonado el blog. Es lo que tiene estar en plena certificación CMMI nivel 3 y alguna cosa más. Es lo que tiene, que no te aburres.

Como tenía pocas cosas en marcha, me he certificado recientemente en ITIL Foundations, y ya tengo el certificado en mi poder.

Aprovecho un momento de no-descanso, y haré una breve introducción a ITIL. Me sorprende ver cómo hay mucha confusión en estos marcos de trabajo. Empecemos.

¿Qué es ITIL?

Es un conjunto de buenas prácticas para la gestión de los servicios que prestan las tecnologías de la información. Es decir, ITIL no es una metodología, como mucha gente tiende a llamar.

ITIL son las siglas de “Information Technology Infrastructure Library”, una biblioteca de infraestructura para las tecnologías de la información.
Está pensada para ayudar a definir cómo trabajar en una empresa que preste servicios TI: software, hardware, consultoría…servicios IT en general.

ITIL se creó en los años 80, y a día de hoy es uno de los estándares más conocidos para la gestión de servicios IT.

La última versión de ITIL, no es la v3, aunque es la versión más popular. La última versión es la Edición 2011, que es una revisión de la v3 (no debía parecer interesante llamarla v3.1, ni v4).

¿Qué contiene ITIL?

ITIL no es una novela, y sin embargo consiste en 5 libros. Estos 5 libros definen la infraestructura de ITIL. Los títulos de esos 5 libros:

  • Estrategia del Servicio.
  • Diseño del Servicio.
  • Transición del servicio.
  • Operación del Servicio.
  • Mejora continua del Servicio.

¿Qué es la certificación ITIL?

Hay una serie de certificaciones relacionadas con ITIL. Son certificaciones a nivel personal. Es decir, se supera un examen y se obtiene una acreditación. Pero no existe una acreditación ITIL para empresas. Para ello, existe un equivalente en la ISO 20000, que acredita empresas en un marco similar a ITIL (y que por contra, no tiene una acreditación para personas que pueda obtenerse con un examen).

Hay varios niveles. El nivel “Foundations” es el nivel más básico, y puede obtenerse mediante un examen de 40 preguntas tipo test en alguno de los centros oficiales acreditados. Existen niveles intermedios, y un nivel avanzado. Los distintos niveles, por encima del “Foundations”, se logran aprobando exámenes que proporcionan créditos o puntos, distintos según el tipo de examen. Con suficientes puntos, se obtienen las distintas acreditaciones de forma incremental. En realidad, lograr las acreditaciones superiores es algo más complicado, pero no entraremos hoy en ello.

La certificación ITIL Foundations no es cara (de hecho, me parece uno de los certificados más baratos, para el nivel de demanda que tiene).

Para aprobar la certificación ITIL Foundations, es suficiente con estudiar por tu cuenta, aunque recomiendo los cursos de 3 o 4 días que suelen ir acompañados del derecho a realizar un examen. Si quieres trucos, recomendaciones, o un mayor detalle de ITIL, o cómo aplicarlo en tu empresa…lo dejaremos para un próximo post.

Otras entradas relacionadas en este Blog:

ITIL – Cómo aprobar el examen Foundations

–Update 19/02/2014: corregida una errata. Aclarar que ITIL NO certifica empresas sino personas. Para empresas está la ISO 20000. Disculpad el gazapo.

La oportunidad de los becarios

La oportunidad de los becarios.

Se supone que los becarios se quedan a solas en verano: al frente del trabajo, ya que el resto de trabajadores (no becarios), han cogido todos vacaciones. Y claro, a los únicos que no les dejan coger vacaciones son a “los últimos en llegar”.
Esto, que acabo de leer en un conocido suplemento dominical de prensa, es un mito, y en cualquier caso no siempre es así. Los becarios exigen tiempo y esfuerzo para desarrollar sus capacidades, pero…¿realmente les estamos dando lo que necesitan para brillar?

La presión.

La presión suele ser el primer escollo. Siente que le vigilan, que le están evaluando de forma constante. El truco está en verlo como una motivación, una oportunidad.
Es una fuente de aprendizaje. La beca es así, y con ello, hemos de verlo en positivo. Salvo que estemos en una de esas empresas en las que los becarios se limitan a llevar cafés (por suerte, en mi empresa jamás he visto eso a un becario).
La presión hay que volverla en nuestro favor, que nos motive y nos dirija, no que nos bloquee y nos impida llegar a nuestros objetivos.
Otra forma de aliviar la presión es mediante  un tutor. En mi empresa existe la figura del counsellor, que viene a ser lo mismo. Y si bien es una gran idea, el problema viene dado cuando el tutor no se toma su trabajo en serio.

Cuando el tutor no dedica el necesario tiempo al becario.

El tutor no está para decir al becario lo que tiene que hacer. O al menos no de una forma paternalista. Debe guiar al becario impidiendo que cometa errores demasiado graves. Pero el aprendizaje incluye equivocarse. Cometer pequeños errores controlados. Aquí es donde el tutor entra en acción en su doble objetivo: que el becario aprenda, pero que la empresa no corra peligro.
La libertad del becario ha de ser proporcional a su responsabilidad: es decir, limitada. Pero no tan limitada que no pueda explorar su espacio y cometer esos pequeños errores controlados por su tutor.

Comportamientos a evitar

A continuación, revisamos algunos comportamientos a evitar por parte del becario:

  • Individualismo. El excesivo individualismo, y el hambre de prosperar en la empresa, son explotadas por algunas empresas. Por desgracia, a medio y largo plazo los resultados suelen ser nefastos para la empresa. A veces, incluso a corto plazo.
  • Impuntualidad. Aunque es complicado, es bueno combinar respeto y disciplina. Entrar a trabajar cinco minutos antes. Nunca después. Y nunca salir de trabajar antes de la hora, pero tampoco es necesario quedarse a trabajar  porque sí. Algún día revisaremos este punto en profundidad.
  • Pereza. La pereza es terrible. El no empezar las tareas inmediatamente, el postergar lo importante por lo urgente.
  • Problemático. Es una buena práctica el evitar problemas y confrontaciones. La energía generada en situaciones de conflicto está para ser utilizada a nuestro favor, no para embarcarse en disputas nimias que no van a resolver nada.
  • Competitivo. La competitividad es buena, pero ha de ser una cualidad secundaria. No es bueno en general presentarse cada mañana pensando en “superar a éste” o “ser más que aquél”. Sí es bueno marcarse metas, pero no es bueno dichas metas pasen por ser más que otros. Porque al final, el camino fácil se presenta: si no puedo ser mejor que los demás…quizás sea hora de hacer que los demás sean peor que yo (y aquí es donde la zancadilla fácil, el extender falsas afirmaciones, etc., hacen que el competitivo haga su agosto).
  • Pelota. El pelota prefiere halagar en todo momento a sus superiores, o a cualquiera de quien pueda sacar provecho. Suele estar relacionado con un espíritu individualista y competitivo.
  • Arrogancia. La arrogancia es uno de los peores males. A pesar de parecer menos agresiva que la competitividad o el individualismo, la arrogancia es difícil de erradicar. Está basada en una creencia profunda en las propias capacidades, y por desgracia, no suele estar alineada con la realidad. Cuántos recién titulados me he encontrado que se creían los reyes del mundo, dueños de la absoluta verdad, e incapaces de dialogar y llegar al mínimo consenso. Su título universitario les convierte en Dioses, o ellos así lo creen. Y por desgracia, yo hace muchos años que aprendí que mi título no está para esgrimirlo en absurdas disputas. El título está para dar soporte a la curiosidad, al esfuerzo, y a la capacidad de ir más allá de las apariencias. Capacidad de aprender, porque más que nos pese, no llegamos el primer día de trabajo con  todo aprendido.

Comportamientos a seguir.

  • Aprender
  • Jugar en equipo.
  • Respeto.
  • Atrevimiento.
  • Planificación.
  • Organización.
  • Socialización: conseguir contactos y establecer relaciones.
  • Disfrutar.

Sí: disfrutar. Disfruta, suéltate y siéntete cómodo. Que no parezca que estés ahí cada día por un sueldo miserable. Madruga. Llega pronto. Haz las cosas con ilusión. Contagia esa ilusión. Yo personalmente prefiero a gente ilusionada, antes que a un crack, al típico fenómeno tecnológico en cualquier tema pero que lo hace con desgana. Y la desgana se contagia. Y esa desgana se ve en la documentación, en el código…

Y tú, ¿cómo prefieres llevar tu beca?

Fuente: este artículo está inspirado en un artículo que leí hace un tiempo en el periódico dominical de La Vanguardia.