"El lado humano del software"

SCRUM metodología del “martirio y del estrés”

Las metodologías ágiles (SCRUM) sirven en teoría “para que seamos más eficaces” y aunque esto sea cierto a priori, también son una terrible soga para el cuello del programador, o al menos así lo sentimos una inmensa mayoría de programadores.

Para los profanos una metodología ágil no es más que una forma de hacer las cosas sin un planteamiento o guion estrictos. Podemos aplicar la metodología ágil a la programación como a la vida. Una de las más famosas es SCRUM. Entre sus características se trata de dividir la realización de los productos en “sprints”.

Lo cierto es que al final, el cliente es quien paga, y si él quiere, selecciona las tecnologías, los lenguajes de programación, etc. Al no tener claro lo que necesitan, suelen irse a por metodologías ágiles, que les permiten ir viendo resultados sobre la marcha.

 

Según la liturgia popular SCRUM es una mimosa buena forma de producir para todos

Según las metodologías ágiles no debemos ver esto como algo odioso, simplemente como una forma de producir, y en ningún caso, se debe culpabilizar al cliente, somos nosotros los que debemos solucionar la problemática, con profesionalidad, haciendo un símil, debemos buscar la cura sin culpabilizar al enfermo (cliente en este caso) de su enfermedad. Esto según la liturgia es “aportar valor al cliente”, y no quejas. Esta es una afirmación que no por aceptada sea cierta. Las mentiras por repetirlas terminan apareciendo verdades. Las ágiles se emplean  para que el cliente no haga su parte del trabajo.

No somos bobos, el cliente final no es una persona inculta o de fuera del sector, suelen ser multinacionales que saben muy bien de lo que trata la informática, no es un enfermo “pobrecito” que no sabe lo que le ocurre, existe la intencionalidad de traspasar la responsabilidades muy conscientemente. ¿El motivo? El pensamiento erróneo a de que al traspasar la responsabilidad el proyecto será más dinámico.

El cordero sospecha que se la están colando, pero no termina de saber el cómo, en las AGILES tienes la respuesta

He escuchado tantas veces a los expertos en scrum master decir que “las metodologías ágiles benefician a todos”, y dan a entender que pensar lo contrario es por desconocimiento. Pues va a ser que no. Así la venden para que nos la comamos y como estamos acostumbrados, nos tragamos otra píldora, total las ágiles son sólo un paso más del lógico “avance de la productividad”.

El sprint es en teoría una forma de conceptualizar entregas factibles y no irse por las ramas. La idea es en teoría que “cada persona que ejecuta cada sprint sea práctica siendo consciente de las limitaciones del tiempo”. Por desgracia, gran parte de las empresas creen que por estresar constantemente van a lograr una mayor productividad.

 

Las empresas han llegado a tal obsesión para que los sprint produzcan resultados directos tangibles, que suelen minimizan los sprint de planificación. Por más que dividas el desarrollo en incrementos, la vida en extremos de blanco o negro no suele producir buenos resultados.

La definición de Wikipedia actualizada el 6 mayo 2017 :

Scrum (desarrollo de software)

“Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto”.

SCRUM suele ser para nosotros stress puro y duro. Una forma en la que nos sentimos constantemente vigilados

Esto implica una forma distinta de programar al vuelo, muy distinta del estilo estático, cuestión que podemos ver en el artículo “Cómo hacer el código para que se adapte al caos de las metodologías agiles”.

Para nosotros los programadores es un sufrimiento que nos metan en un proyecto con metodologías ágiles cambiando las tecnologías que conocemos. El responsable debería asegurarse del nivel de cada uno, y si es necesario introducir un ciclo de aprendizaje, pero en la práctica no se hace.

 

 

Wikipedia añade:

“Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.”

Eso del “el reconocimiento que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan” implica toda una forma y una filosofía a la hora de crear el software, que es cruel e injusta para gran parte de los programadores. Tener una aproximación a los objetivos finales del software requiere de un mayor conocimiento de la ingeniería del software, cosa que el cliente final no quiere para evadir su responsabilidad, y de este modo la porquería se la pasan a los programadores.

Sigamos con la definición

“Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos auto organizados, que en la calidad de los procesos empleados

Muy cierto y conveniente, por desgracia se suele confundir con eliminar o minimizar las pruebas del software, que es todo un mundo de por sí, y tan importantes como la propia programación.

 

“Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o en cascada”

OK, pero ojo, el solapamiento suele incurrir muy frecuentemente en una sola persona, produciendo más retrasos que beneficios por efecto de la dispersión.

¡Suscríbete para ser un Profesional WuaUP!

Para nuestra desgracia, los que venden SCRUM no tienen este aspecto para cazarlos rápidamente. Ellos van con sus verdades parciales

Según la filosofía Ágil que nos han vendido, “cuando arranca un proyecto y se hace un diseño muy completo al principio, no se ven las realidades tangibles y el equipo de producción se pierde por las ramas en las utopías de no estar materializando en la práctica”.

“Que cuanto antes pase nuestro producto de teorías al mundo real mucho mejor, pues antes tendremos el feedback de los usuarios y los inversores se tranquilizarán al ver realidades con su dinero”. “Empleando una metodología ágil, según ese mismo teorema, antes saldrán a la luz las partes viciadas del proyecto”.

 

Para diseñar software no hace falta largos tiempos de análisis rígido como nos venden, puede ser algo dinámico e incluso divertido

La realidad es justo la contraria, las ágiles hacen que la basura pase a los programadores. Un buen profesional no necesita las ágiles porque puede diseñar el producto, conceptualizar e imaginar desde su inicio.

Un diseño desde el principio favorece una lógica común de base, que hubiera simplificado todo extraordinariamente… es más, los productos más brillantes y de mejor cumplimiento de plazos, a lo largo de mi vida, siempre han sido por el descubrimiento de una lógica común de base, que luego con permutaciones ha permitido la realización de gran parte del producto. Esto exige un pequeño tiempo de aclarar las ideas y de diseño que por culpa de las metodologías ágiles no se concede.

SCRUM se está comiendo en la práctica a las buena programación orientada a objeto que durante tantos años ha dado tan buen resultado

Es cierto, que cuando empiezas en un proyecto suele ser difícil saber si vas a alcanzar el éxito con un código base casi universal, es más, su implementación supone un riesgo.

Mi consejo, es que dado los enormes beneficios que este puede aportar, merece la pena su valoración, ¡pero cuidado con querer hacer ese super código general, puede ser tu perdición!

Debes de intentar generalizar, pero parar en el punto en el que sientas que la generalización te está suponiendo más una pérdida de tiempo o un riesgo excesivo, o incluso que te está llevando realmente a un producto comercial que no era tu intención o la idea del cliente: a veces la solución es a medias, es decir un código generalista pero que tampoco pretende hacer mucho, e ir implementado a mano cada funcionalidad concreta.

Dicen que las ágiles te ejercitan y que haces que subas constantemente a producción, lo cierto es que puedes hacer esto mismo con una metodología tradicional. Yo subiría por norma una vez a la semana sin metodologías ágiles.

En lo personal, lo que más me gusta, es un equilibrio entre las metodologías tradicionales y las ágiles, pues creo que es importante buscar desde el principio ese funcionamiento común de todo el aplicativo, aunque luego una vez encontrado, inclinar la balanza ligeramente hacia las ágiles, pero no en exceso. A cada apartado en particular hay que intentar ayudar al cliente a definir al máximo posible lo que quiere.

Las ágiles también tienen sus cosas buenas, lástima que se suelan usar a menudo en el sentido que sólo favorece a quienes ya sabemos. Pensar en todos haría mejorar la integración, la productividad y la felicidad de todo el equipo

En conclusión, las metodologías ágiles tipo SCRUM tiene como positivo que dinamiza el propio trabajo y hace que se tenga mejor conciencia del paso del tiempo para ser más práctico. Por el contrario, son un arma perfecta para que te puedas sentir explotado (esto difícilmente te lo van a reconocer en el lado de la empresa, es más, es que ni lo ven, están enfrascados en “su mundo,  en sus mil problemas“).

Para emplearlas se debe tener al equipo fuertemente motivado, es casi un chiste: suele ser justo lo contrario, pues suelen preocuparse de los avances de los proyectos como hitos, dejando lo humano fuera.

Mezcla un poquito de todo… si es que te dejan…

Metodologías ágiles –> (Las metodologías de los mártires)

“Methodologies of martyrs”

4 comentarios en “SCRUM metodología del “martirio y del estrés”

    • Gracias por tu comentario, he tardado un poco en responder porque para no variar andaba liado en un proyecto.

      “No culpes de tus errores a las metodologías. La decisión de hacer bien (o no) las cosas, siempre será tuya.”
      es una de las cosas que trata precisamente este blog, evitar que usen las metodologías ágiles y la presión constante (siempre la amenaza velada del despido) para que vivamos con estres y tirando en una huida hacia adelante: Se responsables si, sufrir no

      Sólo desde esta predisposicion emocial y de la actitud que explico en el artículo podremos dejar de sentir la angustia y hacer bien nuestro trabajo. En la programación, hacer buen código es un placer.

      Cordiales Saludos

  1. Creo que es uno de los mejores análisis que he leído sobre metodologías ágiles y no puedo estar más de acuerdo con todo lo que dices. El fracaso de las metodologías de planificación es el fracaso de los jefes de proyecto y analistas que no saben estimar o no tienen habilidades para conseguir unos requerimientos completos del cliente que permitan definir un alcance completo y hacer un buen diseño. En vez de buscar buenos profesionales en este sentido, ahora le han pasado a los programadores todo el marrón de ir re-haciendo su trabajo las veces que haga falta, total… ¿de que hablamos? ¿del trabajo de alguien o de cuatro pringados que son los que menos cobran de la empresa? que tiren lo que han hecho y empiecen otra vez las veces que haga falta, y de la calidad del código y del producto final ni hablemos…

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.