Programación Cotidiana #01: Qué ciclo de vida respetar?

softwareLifeCycle_6 Si estas por iniciar un proyecto, qué es lo primero que preguntas? 
Posiblemente nos vendrá a la mente una respuesta relacionada a lo que necesita el cliente, lo que debe cumplir el sistema, lo que le dará valor a tu trabajo, a tu desarrollo.

Luego de considerar lo que muchos conocemos como requisitos o requerimientos se pasa por un proceso que incluye por decirlo de manera simple, un desglose de cada requerimiento a cumplir.

En este punto es donde voy a detenerme, pues es obvio que vamos a recordar el ciclo de vida tradicional (vamos muchachos repitan conmigo… analisis, diseño, desarrollo y todo lo demas!).
Es broma, no se molesten (en serio, hay lectores que se molestan… hola!)

Y es mas que probable que al menos uno de mis amigos tengan ya en mente bromas del tipo “como siempre, todo en cascada!”, mencionando entre lineas o muy directamente la aplicación de conocimientos “menos convencionales” como  los son el uso de metodologías ágiles, favor notar las comillas, ya que hace mucho que dejó de ser poco convencional.

La discusión bizantina que surge cada cierto tiempo es:
Debería cambiar el método convencional por algo menos… convencional?

Personalmente hablando, les puedo decir, usen ninguna, no sean extremos (en ese sentido, claro está)
 
Independientemente de la decision a tomar, recordemos que existen aspectos como:
– Donde nos encontremos trabajando,
– Con quienes estemos trabajando,
– Las maneras de pensar y los paradigmas relacionados,
– Las directivas gerenciales, internas y del cliente,
– Otros temas en general.

De acuerdo a esto y por ejemplo si decidimos trabajar en cascada, pues hagamos la siguientes preguntas:
– Debemos esperar al final para conversar con el usuario sobre lo avanzado?
– Es conveniente tanta burocracia y tanto documento?
– Es conveniente la burocracia documental?
– Depende? de qué o quiénes?

Ya en este punto todo indicará que deberiamos evitar el uso de waterfall y continuar con algo mas dinámico, algo mas… ágil.
Pues no!

Por favor no cometamos ese error, al menos no de la manera como suele suceder en las primeras implementaciones.
A pesar de esto ultimo, decidimos que la mejor opción para nuestro proyecto sea usar una metodología ágil, entonces, veamos las siguientes interrogantes:
– Todos estan de acuerdo en trabajar bajo revisión en pares? que no decir, de la programación en pares?
– Si todos pueden ser responsables del proyecto o de una tarea en particular, cómo se mide el indicador de responsablidad, logros o avances por persona?
– Cuántas objeciones se tienen con las reuniones diarias y el valor de las mismas?
– Cómo se ha lidiado con el hecho de ser iterativo e incremental y que el proyecto se terminará dependiendo de la velocidad del equipo. Es decir, que la fecha de entrega depende completamente del equipo.
– Y cómo se hace cuando se tiene una fecha de cierre pactada bajo contrato?
– Han despedido a personas que no estaban de acuerdo con la implementación?
– Cuántas veces lo harian?

Qué sucede aqui?
En realidad algunas de esas preguntas no tienen mucho que ver con ser o implementar software bajo alternativas agiles, y es posible que haya mas de una respuesta ante esto, son constantes que salen cuando se tienen generalmente en las primeras implementaciones y raras veces cuando se va madurando agilmente en cada proyecto que nos encontremos.

Si hablamos de problemas en metodologías, creo que asi como Waterfall es tradicional, lo son tambien sus problemas, es decir, nos remontaremos a las preguntas tipo “por que fracasan los proyectos?” y es mas que conocido que tiene mucho que ver con demoras, malentendidos, insatisfacción y presupuestos desbordantes.

Pero la agilidad tambien tiene problemas:
– Pues por un lado tenemos a los puristas agiles, que consideran todo como regla de vida y que si quieres encontrar el Shangri-La de los proyectos, pues debes cumplir con lo que dicta el libro o normas agiles, entre ellas el Manifesto Agil (tan bueno y lamentablemente, algunas veces, base de algunas confusiones)
– En menor cuantia, a nivel religioso o de creencia, nos encontramos con los académicos, que en su mayoria consideran ser agiles luego de haber leido un libro o haber tenido una certificación, lamento decir que generalmente es ese tan bueno, titulado Scrum desde las trincheras.
– Con estos académicos uno de los problemas que se he podido identificar es que a pesar de no ser aun tan puristas, estan en camino.
– Pues no, no solo es el libro o la certificación, ellas solo son el inicio, y solo eso.
– Otro aspecto a considerar es que el equipo no está preparado para el cambio (preparación es el 50% de la respuesta) o simplemente no desea el cambio (un problema algo complicado, no?).
– Posiblemente estemos pecando con una implementación muda, debido a que nuestro cliente no conoce como es que estamos respondiendo a sus necesidades.
– Y asi como estan nuestros clientes, tambien podrían estar algunos de nuestros jefes… y de ser asi, pues cuidado.
– Y si se trabaja en el gobierno, que tan factible sería esto?

En el caso de la agilidad queda la posibilidad de arriesgar un poco y confiar de que todo va salir bien, pero en realidad no solo depende de eso, recuerden lo mas importante, el equipo! Pero, están realmente preparados para eso?

Quizá no he sido muy claro pero si me vuelven a hacer la pregunta de que usar como metodología de implemetación, pues seguiría diciendo ninguna, pero a nivel simbólico, pues ser ágil es el inicio de la respuesta, pero solo eso.

De que manera?
– Debemos recordar que tal como dice una de las mejores partes (a mi parecer) del manifiesto agil, mas que los procesos, las personas. Muchas veces ser agil se puede convertir en un proceso si es que no somos blandos al implementar los requerimientos.
– Asi como se menciona involucrar al cliente, este debe conocer y estar de acuerdo con los conceptos de velocidad o reuniones diarias/semanales ya que muchas veces aluden no comprender como es que avanza el equipo o como es que se pierde el tiempo en reuniones de ese tipo.
– Lo mismo sucede con los niveles superiores de nuestro proyecto, es decir, nuestros jefes.
– Al considerar un equipo de trabajo no solo se debe concluir que preparación es dictar un curso de Scrum, programacion extrema o la técnica que consideren necesaria. Ya que existen aspectos a considerar, las cuales van desde limitaciones técnicas hasta capacidades emocionales que mucho tienen que ver con el avance de un proyecto.
– Cuando hablamos de responsabilidades, por mas que el libro diga que todos somos responsables, eso dependiendo del contexto, implica que posiblemente no haya ningun responsable.
– Asi como hay responsabilidades claras, y equipos definidos, debe primar un equilibrio entre expertos y académicos en el buen sentido de la palabra, es decir, personas con poca experiencia en proyectos.
– No importando donde se encuentren o como esten implementando su proyectos, siempre se tiene que realizar un analisis y diseño (asi se haga en papel, lo estas haciendo!), un desarrollo (obvio, sino no sobrevivimos) y claro probar (este punto muchas veces, tan olvidado) y desplegar (hay reglas para esto?).
– Usar solo una metodología ya no es la solución (es por ello que hay tantas alternativas, variantes y combinaciones), combinen, pero lo mas importante, consulten con el equipo.

Personalmente hablando y ya para cerrar, les puedo decir, usen lo mejor de cada una, no se amarren a un solo concepto, no sean duros en sus decisiones, trabajen con y para el equipo.

Saludos
Jersson