Agilidad… piensa diferente, pon las cosas al revés, rompe viejos esquemas

Si hay algo que me llama la atención, y te mentiría si te dijera que no me divierte, es cuando tengo alguna conversación en algún lugar muy tradicional, de los de gestión de proyectos software de toda la vida, sobre alguna de las ideas que hoy hemos metido bajo el paraguas ágil (si eso lee Nadie sabe lo que significa agilidad o ese de Agilidad… ¿Algo novedoso? ¿Estás seguro?) es cuando pones las cosas inamovibles de toda la vida, estructuras e ideas “milenarias”… al revés. Te pongo algunos ejemplos.
En lo que refiere al Testing hay un montón. Lo normal, “de toda la vida”, era ese Testing clásicote al final del ciclo de vida, muchos meses después de empezar, que solía estar para cumplir, que todo el mundo quería saltarse, etc. Pensemos al revés… ¿Y si testing se hace al principio en vez de al final? Chiiii Crujido mental.

Otra de Testing. “De toda la vida”, el Testing tenía que estar lo más lejos de desarrollo, para tener un juez, un policía… ¿y si testing está con desarrollo? ¿son todos parte de un único equipo? ¿No acelerarías todo el proceso?
Pero es más, el Testing de siempre era una fase… ¿fase? ¿y si no hacemos una fase de Testing? ¿Y si hacemos tareas de Testing de manera muy frecuente? ¿Y si esas tareas las pueden hacer gente de Testing o Desarrollo? Uff –que dice este hombre, se le ha ido la cabeza, se ha vuelto loco-.
Sí, no me extiendo, hablamos de ello en ¿Cuándo se hace el Testing en un proyecto ágil? ¿Todo el Testing se hace dentro del Sprint?, y en No se puede ser ágil si se prueba en cascada (aunque uses Scrum, iteraciones o Sprints). A esto algunos le llaman ATDD, BDD, etc., de los cuales ya te dejamos varios post.
Con operaciones, pasos a producción, explotación o como quieras llamarle salen otras cuantas. Igualmente, esa era un área aislada del mundo del desarrollo, separada, lejana, un castillo inexpugnable.
En la época clásica de la lentitud, del no cambio, la de trabajar a la defensiva, la de me importa un pito si la aplicación es lo mejor para el usuario pero que a mí no me explote, el área de operaciones era una caja negra para desarrollo y la única con la potestad para poner cosas en producción. Y así pasaba, todo se ralentizaba, descoordinación entre desarrollo y operaciones, sobre cargas en operaciones, “ventanas” temporales para pasar a producción, problemas y… tiempos y tiempos muertos.
Al igual que en Testing… ¿y si no hacemos una fase de paso a producción? ¿Y si hacemos tareas de paso a producción? ¿Y si esas tareas las pueden hacer gente de desarrollo o operaciones dentro de un único equipo multifuncional? Algunos a esto le llaman DevOps.
Bueno y… ¿Proyecto? ¿Por qué proyectos? Los proyectos son peligrosos, nos llevan a fijarnos sólo en cumplir tiempos, presupuestos, a encajar todo en calendarios y lo peor a crear planes inamovibles y requisitos no cambiantes, lo que llevar al verdadero problema: productos que no cumplen con las necesidades de los usuarios y “no se venden”. Matemos los proyectos, hay equipos multifuncionales muy potentes que van dando valor a productos.
Más… ¿jefes de proyecto? ¿por qué debe recaer en una única persona toda la gestión de un “proyecto”, ejem? ¿Y si la gestión es de todo el equipo y si nos auto-organizamos y hacemos responsables todos de la gestión? Lo que sería feedback constante, auto-organización, transparencia y visibilidad.
Podría seguir y seguir, pero hay que ir cortando que esto se alarga… ¿Estimar? ¿seguro que es imprescindible y lo más clave de un “proyecto”, ejem? ¿Y si #noestimate? ¿Documentar? ¿De verdad es lo único que te da seguridad? ¿Y por qué no pedir buenos diseños y calidad software?
No tienes porque poner todo al revés, o sí, pero piensa, si algo no te funciona, piensa diferente, estás haciendo negocios (ideas) basados en software (ideas), prueba, cambia.
 
 

Deja un comentario

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

Share This
Ir arriba