Scrum – El valor esta en las personas

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.

15 comentarios en “Scrum – El valor esta en las personas”

  1. Algo que no me queda claro es: ¿Cómo maneja Scrum (y en general un metodología Ágil como XP) la documentación?, o sólo es una metodología de implementación, que asume que la documentación ya esta realizada?

    Saludos,

  2. Sergio, Scrum no dice como debes gestionar la documentación, en nuestro caso utilizamos Team System y la plantilla de conchago para utilizar scrum, en cada tarea adjuntamos los documentos necesarios para realizar proceso, podemos introducir gráficos, hojas de cálculo y todo lo necesario para realizar la tarea. Los bugs suelen llevar adjuntos el error que se produce. No se suele realizar una documentación exhaustiva a no ser que el proceso lo requiera realmente. La verdadera documentación esta en el código. Te recomiendo el articulo de Rodrigo que habla al respecto geeks.ms/…/exprimiendo-scrum-scrum-y-la-documentaci-243-n.aspx.

  3. Ma ha gustado mucho como lo has expuesto Juan.

    Puntos de vista coincidentes y muy claros sin duda. Se agradece mucho que se cuenten experiencias propias. 🙂

  4. Excelente post … nada mejor que comentar la experiencias personales para demostrar una idea (en este caso una realidad :D).

    Ahora bien, la pregunta de Sergio es clave, porque mucha gente todavía piensa que SCRUM = no Doc; y nada mas alejado de la realidad (y les juro que a esto lo sufro día a día, y mis pequeñas vicorias saben a grandes batallas).

    En todo momento la documentacion en un proyecto debe tener una audiencia clara y un objetivo concreto, no es lo mismo trabajar con tus compañeros hombro a hombro, que trabajar con un equipo distribuido geográficamente con más de 9 horas de diferencia horaria. En el primer caso, si el equipo es un equipo homogeneo, seguramente nos encontraremos con escenarios bien definidos y poco más ya que el dominio específico del negocio se puede “sentir dentro del equipo”.

    En el 2do caso, es necesario ser un poco más prudente y adaptar el proceso a un punto que el resultado permita que las decisiones puedan ser tomadas en entornos no presenciales. Pero siempre teniendo en claro, que la doc debe brindar un valor al proyecto, todo lo que se haga demás, es trabajo perdido.

    Saludos y congrats por el post de nuevo

  5. Mi pregunta iba más la fase de anáslis, cómo considera Scrum la fase de análisis?

    Un proyectillo de 4 o 5 meses. Primero, tengo que saber que quiere el cliente no?, es decir tengo que hacer análisis, que puede tomar un mes, menos o mas. En este tiempo que hago el análisis, Scrum no esta presente o sí? O Scrum asume, que el análisis ya esta realizado? A eso me refería como una metodología de implementación…

    Saludos,

  6. @Sergio. Desde luego Scrum no propone análisis exhaustivos, todo lo contrario, esto es así porque está probado que realizar este tipo de análisis no aporta mucho valor, sobre todo en proyectos de desarrollo de software en los que las necesidades y los requerimientos suelen ser factores muy cambiantes a lo largo de todo el proyecto, normalmente se ponen sobre la mesa todos los requisitos y se le asigna un orden de prioridad, para ello se utilizan técnicas de estimación como el Planning Poker. Scrum comienza desde el inicio, para mi incluso antes que el análisis, a mi juicio la metologia debe cambiar la forma en la que vendemos un proyecto como relato en el post:

    http://geeks.ms/blogs/jirigoyen/archive/2008/11/05/191-debemos-cambiar-la-forma-de-vender-software.aspx

    No tiene mucho sentido que te hable de análisis de requisitos, ya que Rodrigo y Juan Palacio lo relatan en sus blogs.

    Te recomiendo la lectura de los siguientes posts y sus correspondientes enlaces:

    geeks.ms/…/exprimiendo-scrum-scrum-y-la-gesti-243-n-de-requisitos.aspx

    geeks.ms/…/planning-poker-distribuido.aspx

    http://www.navegapolis.net/…/62

    http://www.navegapolis.net/…/58

    Espero haberte ayudado.Saludos.

  7. Que bueno Juan!!!
    Comentas que cada día te encuentras a mas empresas que adoptan metodologías por estrategias!!
    No tendrá nada que ver este comentario con nuestra última reunión??? 😉
    Esto es muy bueno siempre que la estrategia es mejorar y ofrecer un mejor servicio de calidad…
    El artículo me ha parecido sensacional!!! 😉

  8. Miguel, desde luego entiendo que vosotros buscáis una mejora a la hora de realizar vuestro trabajo, la metodología debe ser el medio, no el fin para conseguir vuestros objetivos, no es debido a última reunión con vosotros, la adopción de metologías tipo CMMI están siendo adoptadas por numerosas empresas debido al requerimiento de organismos oficiales y otros factores, no es mi intención desencadenar una guerra sobre cuál es la mejor metología a utilizar, entiendo que cada uno utiliza la que le parece más adecuada en base a sus necesidades y requerimientos y que desde luego es algo que conocéis mucho mejor que yo, ya que nunca he utilizado CMMI, tan solo he leído sobre ella, en mi opinión, CMMI es todo lo contrario a lo que propone Scrum, se centra en los procesos y no en las personas y genera una burocracia excesiva, si bien pueden existir puntos en común los puntos clave me parecen totalmente alejados. En cualquier caso, respeto vuestra elección y creo que estáis sobradamente capacitados para sacar valor a cualquier metología.

    Aprovecho para recordarte que esperamos tu post sobre CMMI.

    Agradezco mucho tus comentarios

    Saludos.

Deja un comentario

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