El Test Garzás: evalúa en 3 minutos el nivel de tu empresa desarrollando software

Al igual que han hecho muchos otros antes de mi (por ejemplo aquí o aquí), arriesgándome a ello sin tener ni nombre ni apellido en inglés, quiero dejar mi aportación al mundo, sobre cómo, en 3 min., de manera muy simple, evaluar qué nivel tiene tu empresa desarrollando software.
No sabía que nombre darle al test, así que, demostrando mi poca originalidad, pero rapidez poniendo nombres, lo llamaré por ahora el Test Garzás.
Las preguntas del Test podrían ser centenares, pero las he dejado en 10, y esas 10 son las que son y han sido seleccionadas atendiendo a lo que después de pasar por un montón de empresas y proyectos (puedes complementar este post con aquel de después de pasar por 80 empresas… 4 experiencias) he visto que son las mayores ausentes, los grandes retos del día a día.
Cada pregunta se responde con un “sí” o un “no”, cada “sí” suma un punto. El orden de las preguntas y su numeración es indiferente en este test, lo que importa es la suma de «si» o «no».
Haz el Test, que son 3 min., y cuéntame en los comentarios que puntuación (número de “si”) has sacado. ¡Suerte!

1) ¿Se revisa la calidad del código (en los fuentes, no, o no sólo, en papel) de manera periódica?

Si han pasado meses desde la última revisión la respuesta es “no”. Si no se revisa código también “no”, recuerda aquello de que la verdadera calidad software la tienes que ver en los fuentes, en el código. No te fíes de nada más.

2) ¿Se prueba con “cabeza” y “maña”? (ya sabes más vale mañana que fuerza).

Responder a esta pregunta es fácil, si no tenéis otras pruebas más allá de las típicas funcionales que hace algún becario contra la interfaz y/o todas las pruebas son a mano… la respuesta es “no”. Si hay pruebas unitarias, exploratorias, BDD, smoke, etc., entonces la respuesta es “si”.

3) ¿Existe una estrategia de control de versiones?

Si no hay “tageos” y no hay ramas (salvo que uses razonadamente una sola línea con integración continua) y, por su puesto, si no hay ni una herramienta de control de versiones, la respuesta es “no”. Te dejo aquello de por qué siempre digo que la gestión de versiones es imprescindible. Una experiencia real ilustrativa. Ah, importante, si la respuesta aquí es “no” lo normal es que las dos anteriores también sean “no”… sino ¿qué pruebas y qué revisas?

4) ¿Está el entorno de trabajo preparado para fomentar la productividad?

Aquí me estoy refiriendo a parte de lo que hablamos en aunque muchos no las quieran reconocer, 8 cosas a tener claras si llevas un equipo de desarrollo. Pero resumidamente, si las interrupciones no se controlan (cada interrupción son 15 min. perdidos), hay ruido, desconcentración, la rotación es alta y/o la gente tiene muchas tareas abiertas sin control a la vez la respuesta es “no”.

5) ¿Son los equipos de menos de 10 personas?

Esta debería ser de las más fáciles responder, sólo es contar. Ciertamente, reconozco que hay sitios que el número es “ambiguo”, nadie lo sabe muy bien, en estos casos la respuesta es “no”. Equipos grandes son más costosos y no reducen tiempos de desarrollo, ya que se pierde el tiempo en comunicación y coordinación (recuerdo aquel equipo de desarrollo en que trabajé y éramos 25…). Si quieres apoyo te dejo lo de por qué los equipos con mucha gente (más de 7) son menos productivos.

6) ¿Se estima?

Me vale con que se dedique un rato en el proyecto a pensar cuánto van a durar las tareas y que ese rato tenga un método de estimación (hay decenas). Si sólo uno estima por su cuenta, sin saber nadie muy bien en base a qué ni cuando… la respuesta es “no”.

7) ¿Hay un ciclo de vida y un plan de proyecto?

No necesito, ni quiero, un documento pdf gigante contando cosas, ni Gantts (ojo, diagramas Gantt cómo arma de destrucción masiva de proyectos), nada, nada. Me vale con que te preguntes ¿qué ciclo de vida usáis? Si no lo sabes, respuesta “no”. ¿Qué fases tienen los proyectos, en que orden y de que duración recomendada? Si no lo sabes, la respuesta es “no”.

8) ¿Existen, se controlan y conocen los requisitos y las tareas a realizar?

Pregúntate lo siguiente, si en este preciso instante hubiese que sacar una foto de lo que hay que hacer… ¿la podríamos sacar? Si la respuesta es “no”… ya sabes. Si tienes un “product backlog”, o un repositorio de requisitos, o especificaciones de requisitos serias, o utilizas correctamente un gestor de tareas (redmine, trac, jira, etc.), la respuesta podría ser “si”. Si aquí respondes un “no” lo normal es que las dos anteriores, la 6 y la 7, también sea un “no”. Sino… ¿qué estimas y planificas?

9) Roles. ¿Están establecidas claramente las responsabilidades de cada rol en la empresa o proyecto? Comerciales, jefes de proyecto, desarrollo, QA, etc.

¿Cada uno sabe lo que tiene, y lo que no tiene, que hacer? Responsabilidades ambiguas, que se generan sobre la marcha o desconocidas… respuesta “no”. Esto es uno de esos temas que de no hacerse generan miedo, un peligro mayor que cualquier mala práctica de gestión software.

Y 10! ¿Se es plenamente consciente en la empresa de la importancia del papel humano en el desarrollo software?

Y sus especiales particularidades, diferentes de proyectos industriales, fábricas, etc. Ya sabes,  lo más determinante para el éxito, o fracaso, de un proyecto son las personas. Te concreto un poco más para que puedas responder, por ejemplo, si se añade gente a proyectos retrasados pensando que se van a reducir los tiempos y/o se trabaja en modo héroes es decir, hay dos o tres personas elegidas en la empresa que sólo ellos saben solucionar problemas, y/o no hay un mecanismo de selección razonado para incorporar a la mejor gente para el proyecto… respuesta “no”.
¿Qué puntación has sacado?

22 comentarios en “El Test Garzás: evalúa en 3 minutos el nivel de tu empresa desarrollando software”

  1. Trabajo en Alemania y no sabes como me gustaría que mi equipo de desarrollo pudiera leer tus posts.
    El día menos pensado te hago un blog paralelo traduciéndote al inglés o al alemán.
    Yo no digo nuestra nota que me da vergüenza :S

  2. Me avergüenzo de ello pero… en el cliente donde trabajo sólo llegamos al 4 y siendo generosos. Por acabar antes diré que somos un equipo de 5 personas, tenemos control de código fuente con integración continua, un back-log de tareas y todos tenemos claro que tenemos que hacer de todo… (Aquí está la generosidad, siendo estrictos debería haber contestado «no» a la pregunta 9)
    En fin, intentaremos que nuestros «mayores» vean la situación y se decidan a permitirnos mejorar…

  3. En mi empresa hemos sacado un 1. Creo que necesitamos ayuda.
    Tenemos un CEO que no nos escucha y la empresa está dividida en 3 oficinas de distintos países que llevan el mismo o los mismos proyectos.
    No hay roles definidos, el CEO introduce las tareas sin conocer riesgos ni planificar, ni siquiera delega en las cosas más específicas en las que no conoce y los que saben hacer su trabajo se frustran por las imposiciones de bombero que se les encargan.
    Sinceramente, ya no sé qué hacer para cambiar esta situación.
    Un saludo me encanta tu blog.

  4. Gracias Javier por el mensaje de este blog. Me falta mucho por mejorar.
    Con mucho orgullo sacamos un 1. Lo estupendo de tu blog es que me dice cual es la ruta que debo seguir, con lo cual podré pasar a mejorar para acercarme a un 10. Manos a la obra.
    Saludos,
    Desde nuestro sueño magico El Salvador en C.A.

  5. Bueno, aunque nuestro resultado es un orgulloso 8 he de reconocer que el sistema binario de puntuación me lo ha puesto un poco difícil, eché de menos el comodín del «estamos trabajando en ello» o «progresa adecuadamente» que permita indicar los puntos que están en marcha pero requieren mejorar.
    En cualquier caso, veamos lo que nos lleva al 8:
    1) Si. Nuestra política general es revisar todo cambio que sube a producción. Si es un cambio importante, además la revisión implica el análisis de métricas como la complejidad ciclomática, tamaño de los métodos, análisis estático de código, etc… para ver si el cambio introducido interfiere en la calidad.
    2)No. En realidad utilizaría un comodín de «estamos trabajando en ello» pero como nos encontramos más lejos de donde quiero llegar que del punto de partida lo dejamos en cero. No tenemos una cobertura de test unitarios «adecuada», los de aceptación automatizados están en proyectos simbólicos y hemos arrancado sin éxito (de momento) algún intento de TDD. Aun así, la aceptación la realiza siempre un desarrollador distinto del que programa.
    3)Si. Tema superado con CI y un pipeline de CD hasta entorno de testing.
    4)Si. Aquí Kanban nos ayuda a controlar la tan temida multitarea…
    5)Si. Esta era fácil, sólo contar 😉
    6)Si. Todo trabajo que entra se estima con Planning Poker. La estrategia es dejar estimado todo el trabajo que ha entrado en la jornada antes de irnos a casa y NUNCA comenzar un trabajo que no intuyes cuánto puede durar.
    7)Si. Más ágiles en el día a día (atendiendo a la estimación del punto anterior y a las políticas de nuestro tablero) y algún Gantt de alto nivel/hitos si es necesario presentar a la jerarquía superior.
    8) Si. Entrada única de solicitudes: nuestro CAU de desarrollo. Aun así para evitar que «se pierdan» algunas tareas hemos realizado una integración desde el correo electrónico que facilita la creación de tareas en el Backlog del tablero virtual. Gracias a los smartphones se pueden crear desde las salas de reuniones, pasillos o donde quiera que «nace» la solicitud.
    9) Si. Tema superado.
    10) Agua. Sin comentarios…
    Total, un 8 sobre 10 que creo está muy bien aunque nos encontremos muy lejos de donde nos gustaría estar…
    Según lo veo yo, debes trabajar duro para obtener al menos un notable en el test Garzas. Con un notable «tal vez» dispongas de una «maquinaria» aceptable, y a partir de ahí, empieza lo mas interesante, la mejora continua que te lleve a ser cada semana algo mejor… en un ciclo sin fin…
    Gracias por el test Javier, buen aporte!

  6. Está genial Javier! Me ha salido un 9.5. Me he puesto 0,5 en la 4 porque aunque hay bastante ruido todo lo demás se cumple (hay foco y rotación bajisima). De todas formas se lo paso a los compañeros y lo ponemos en común.
    Aprovecho para sugerirte nuevos apartados:
    -Automatización: ¿Se puede generar una release de forma automática?
    – Trazabilidad: ¿Existe trazabilidad entre los fuentes y las tareas o requisitos?
    – Comunicación: Existen sistemas de comunicación propios del equipo (foro, lista de correo, wiki, etc.)
    – Mejora continua: ¿Se aprende de los errores?
    – Innovación: ¿Se comparten con el equipo articulos, tecnologias, investigaciones, etc.?
    – Trabajo en equipo: ¿Los compañeros se ayudan unos a otros? ¿Comparten lo que saben de forma abierta? ¿Existe transparencia?
    Un saludo desde Murcia, crack!
    Julio.

  7. A mi también me sale un 9.5, pero tengo un problema con esta escala, y es que cada uno de los puntos solo cuenta como uno.
    Me explico, el punto 10 y el 4 los considero fundamentales, si la empresa en la que trabajas te trata como a un recurso de mierda, te hace fichar, te hace trabajar en un garaje sin ventanas, despiden a alguien de forma aleatoria cada mes y sabes que hay una lista negra con los candidatos a irse a la puta calle…
    Pues que haya un proceso de revisión de código no va a mejorar mucho, ni que haya un tablero de Kanban por ahí…
    Te propongo la escala Garzas-Aspiazu, en la que el punto 4 y el 10 valen por 3 puntos cada uno, y el resto suman 0.5
    🙂

  8. Ni al 4 llega en la que trabajo… Y eso que uno es regalado porque ser menos de 10 en una consultora pequeña es fácil (de hecho pocos superan las dos personas).

  9. Un 8.
    Hice el test de la empresa donde laboro, siendo un tester, el de pruebas. En números diría que es bueno, pero de manera cualitativa, diría que los 8 puntos no se hacen a conciencia. Se hacen para cumplir cosas, un CMMI y una que otra norma, pero no con el compromiso que se requiere, no como cultura.

  10. Gracias por esta lista, La estoy usando para entrar a leer más sobre cada punto en tu blog y es de gran ayuda. Estoy intentando ver que puntos tenemos y no salimos muy bien parados.
    Me surge duda sobre el punto de estimación y posteriores artículos que estoy viendo acerca de si se debe estimar o no … desde mi punto de vista estimar es llamar a la puerta de Gannt y no estimar es sacrilegio desde el punto de vista financiero dado que las facturas no se cobran en base a puntos de historia sin una fecha de compromiso. ¿Alguna idea o artículo al respecto?
    Gracias!!!

  11. Logramos 7, afortunadamente ya estamos planeando para implementar reSharper a TeamCity que ya lo manejamos hace 2 años (gracias al Humber) también para implementar pruebas unitarias.
    Esto es que nos falla el punto 1 y 2.
    Bien decía alguien más arriba y por seguir a Joel Spolsky desde el 2000 logramos 7 !
    They Joelon es mi gurú !
    Saludos

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba