En mis primeros años de desarrollo estaba solo, habitualmente desarrollaba mis proyectos como quería, con el paso del tiempo y el aumento de las funcionalidades de los programas y de los avances en los lenguajes de programación, empecé a darme cuenta que pronto no iba a poder desarrollar sistemas de cierto nivel yo solo, en ese momento comencé un nuevo proyecto y me anime con unos amigos a conformar una pequeña empresa dedicada a ofrecer todo tipo de servicios informáticos, hacíamos de todo, desde vender equipos e instalarlos hasta desarrollar pequeñas aplicaciones y algunas páginas web, cuando la empresa fue prosperando necesitamos incorporar más gente al equipo de desarrollo, habitualmente cada uno se iba dedicando a un proyecto de forma individual, observaba a unos desarrolladores que les gustaba el trabajo que hacían y otros que solo trabajaban, digamos, para subsistir, los que verdaderamente aportaban valor eran aquellos que veían su trabajo como un hobbie, a partir de entonces, cuando seleccionaba a alguien, me importaba mas si verdaderamente le gustaba el trabajo que iba a realizar, que las titulaciones y los conocimientos técnicos que tenía. Para mi estaba claro, el valor estaba en las personas que tenían interés por su trabajo. Normalmente los programas no eran muy grandes, hacíamos pequeños análisis y desarrollábamos los proyectos, cuando procedíamos a su instalación el cliente nos hacia observaciones y correcciones, que de forma inmediata se iban resolviendo para adaptarlo completamente a sus especificaciones. El cliente no solamente se limitaba a hacerme correcciones, sino que me proporcionaba ideas para mejorar mis desarrollos, el problema era que esto normalmente lo hacia al final de la implantación y muchas veces tenia que rehacer gran parte de los proyectos asumiendo el coste originado. Habitualmente nos reuníamos con los desarrolladores y hablábamos de cómo realizar el trabajo, ellos proponían sus ideas y compartíamos diferentes puntos de vistas, como dice el refrán “dos ojos ven más que uno”, otras veces me sentaba con algún programador e intentábamos
corregir un error. Para gestionar los proyectos solíamos utilizar excel, project o la lista de tareas de outlook, estas se escribían y se iban tachando a medida que se iban completando.
Cuando comencé a trabajar en equipo, empezaron a aflorar una serie de problemas, los desarrolladores que tenían un nivel más bajo, demandaban de forma constante mi ayuda, y me interrumpían constantemente cuando trabajaba, observaba que dedicaba mucho tiempo a enseñar, corregir e indicar como tenían que realizarse los desarrollos, cuando me preguntaban ¿como vais?, yo estaba totalmente descolocado, en mi caso, conocía la velocidad del trabajo que realizaba, pero no sabía cuánto podrían tardar las personas que tenían otros conocimientos y habilidades. El número de tareas creció mucho mas y su gestión me llevaba mucho tiempo. Me encontraba perdido, porque mis estimaciones fallaban constantemente.
Buscando una solución para estos problemas y gracias a Miguel Jimenez comencé a interesarme por nuevas tendencias en el área del desarrollo de software, empecé a leer sobre desarrollo ágil, en concreto me gustaron las que hablaban de programación extrema o XP, en las que se hablaba de pruebas unitarias, programación en parejas, priorización en la corrección de errores, entregas frecuentes, refactorización, integración del cliente como parte fundamental del equipo, propiedad de código compartida y simplicidad, alguna de las prácticas que se recomendaban eran utilizadas por mi desde hacia tiempo, así que me gustaron especialmente y comencé a estudiarlas un poco más en detalle.
Fue en este momento cuando me tropecé con Scrum y CMMI, buscando información me encontré con el magnífico trabajo realizado en Navegapolis por Juan Palacio y por supuesto, con los post de Rodrigo Corral.
Cuando conocí Scrum, observe que alguno de los factores que me habían llevado a realizar proyectos exitosos estaban ahí, y que además, me proporcionaba una solución para aquellos problemas que estaba tratando de resolver, mejoras en la planificación y la estimación, evitar las constantes interrupciones, mejorar la comunicación con el equipo, involucrar más a las personas, etc.
Las constantes reuniones diarias son la base de la metodología y nos proporcionaban varias ventajas:
- Muchas veces ocurría que cuando hablabas con un desarrollador al cabo un tiempo observaba que llevaba unos días desarrollando de forma incorrecta algún modulo. La falta de comunicación hacia que los retrasos por estas causas aumentasen, con la reunión diaria evitabas enterarte de esto al cabo de un tiempo, reduciendo retrasos y errores en la planificación. Estos se identificaban al principio y permitían mantener el ritmo de desarrollo.
- Al realizar la reunión diaria podías atender todas las dudas y consultas del equipo de desarrollo en ese periodo, con lo que las constantes interrupciones se evitaban, cuando un desarrollador preguntaba algo, se le decía: "eso se atenderá en la reunión de Scrum."
- El equipo tenía constancia del trabajo que realizaban los demás, redundando en un mejor conocimiento de la aplicación. Ocurría muchas veces que los desarrolladores que realizaban un determinado módulo desconocían el trabajo de los demás, cuando se intentaban enlazar dos módulos aparecían problemas que no se habían tenido en cuenta por falta de información.
- El equipo aporta valor, ya no era el único que resolvía las dudas o decía como tenían que realizarse las cosas, los propios integrantes del equipo ayudaban a sus compañeros a resolver sus problemas y a mí, aportándome ideas y otros puntos de vista sobre cómo llegar a soluciones más óptimas. Esto mejoraba la relación del equipo y el desarrollo del proyecto.
- Resultaba ser una eficaz herramienta de control, como sabéis en la reunión de Scrum se responde a tres preguntas.
¿Qué hicistes desde el último Scrum Diario respecto al proyecto?
¿Qué harás desde ahora y hasta el próximo Scrum Diario?
¿Qué te está impidiendo hacer tu trabajo lo mejor posible o que necesidades tienes para realizar el desarrollo?
La reunión permite conocer el trabajo de cada desarrollador, las dudas y los impedimentos que tienen para realizar su trabajo ademas de la evaluación continua de su trabajo diario. Es como cuando íbamos al colegio y nos preguntaban por la tarea del día anterior, desde luego no hacer la tarea es un riesgo, ya que todo el equipo sabe que nos has realizado tu cometido. Se mejora la productividad, al tener una presión inconsciente por el hecho de tener que pararse frente al resto del equipo y contar en lo que se estuvo trabajando.
Como sabéis en Scrum se planifican los llamados "sprints" que tienen una duración de entre 20-40 días, en ellos de definen las tareas que vamos a ser capaces de realizar en el periodo determinado. La planificación de cada uno marcaba una dirección clara para el equipo, todos conocen los objetivos y saben que van a obtener al final de cada sprint. En la conformación de los sprints cada miembro del equipo realiza la
estimación y gestión de sus tareas, ellos son los mejores conocedores
de su velocidad, esto hace que el control sea relativamente sencillo de
realizar. En un equipo realizar este proceso era muy complicado, ya que
los desarrolladores no tenían el mismo nivel, por otra parte, un
desarrollador no programa siempre igual, la adopción de nuevas
tecnologías, el progreso y las habilidades de cada uno, hacen que este
sea un factor muy cambiante. Es el desarrollador el que se impone la
tarea y el periodo determinado para desarrollarla, este hecho aporta
gran valor, pues solo se le exige aquello que se ha comprometido a
realizar. Aqui radica una de las premisas de Scrum, la confianza en las
personas es una de las bases de la metologia, si bien puedes ayudar en
las estimaciones al final el desarrollador es el que se compromete.
Posteriormente la evaluación en el sprint review nos permitía
corregir aquello que se había realizado mal en el sprint anterior
evitando incurrir en errores mas de una vez.
Las constantes entregas permiten al cliente evaluar el trabajo realizado, como se intentan desarrollar módulos "independientes", estos se pueden comenzar a amortizar la aplicación mucho antes de finalizarla.
El feedback del cliente permite realizar cambios mucho mas temprano, evitando rehacer gran parte del proyecto.
Cuando analizaba procesos, comencé a darme cuenta de que la mayoría de los problemas que detectaba, habitualmente, estaban derivados directamente de las relaciones interpersonales, la mayor parte de los responsables desconocía cómo había que trabajar en equipo, esto derivaba en consecuencias verdaderamente catastróficas, normalmente acostumbraban a dar órdenes y eran los únicos que aglutinaban la información de cómo se debían ejecutar los procesos. Cuando hablabas con las personas que realizaban el trabajo, te dabas cuenta de que sus jefes carecían de mucha de la información que ellos manejaban y consecuentemente no podían tomar las decisiones adecuadas, si la comunicación no era fluida entre el responsable y su equipo de trabajo, nunca podrían llegar a mejorar los procesos en los cuales trabajaban. Esto generaba un malestar general entre el equipo que sentía como sus valoraciones no eran escuchadas y redundaba en la bajada de la autoestima y consecuentemente en su rendimiento. Desgraciadamente todavía son muchos, incluidos los jefes de proyecto y las empresas de desarrollo los que no ven a las “personas” como su principal valor. Piensan que las infraestructuras, las máquinas, los procesos y ciertas "certificaciones" son la base de sus negocios. Me cuesta entender que a día de hoy, una gran mayoría de empresas sigan aplicando el método dirigir y controlar o el de Economia 101 tal y como cuenta Joel Spolsky.
Por otra parte, cada día encuentro mas empresas que adoptan una metología simplemente por estrategia, para vender software a terceros que tienen esa exigencia o por disponer de una certificación que avala lo bien que trabajan, recuerdo cuando se puso de moda la Iso 9001...., no estoy diciendo que no aporten cierto valor, pero creo que tienen un precio muy alto que pagar.
Scrum proporciona un método sencillo para estimar, controlar y dirigir proyectos minimizando la burocracia, centrándose y adaptándose a las necesidades de cada momento.
En Scrum se trabaja en equipo, todos tienen voz y voto, sus opiniones se toman en cuenta y pasan a formar parte del proyecto. Para todos aquellos que crean que su principal valor esta en las "personas", Scrum será una excelente metología.