Reflexión: Metodología ágil SCRUM en Pymes

elad . viernes 24 de septiembre de 2010. a las 09:50

Antes de aplicar en SCRUM es bueno reflexionar sobre lo aprendido, así que en este post vamos a contar la experiencia actual en nitsnets | studios y cómo se organizan en nuestra empresa los equipos de desarrollo.

Veremos cómo nos va a ayudar SCRUM y lanzaremos unas preguntas para expertos de SCRUM tales como ¿es SCRUM aplicable a pymes que sólo tienen un equipo de trabajo y muchos proyectos pequeños?

Primero, quería poneros en contexto con una explicación sobre cómo funcionan actualmente los procesos de desarrollo en nitsnets | studios. ¿Utilizamos SCRUM y no lo sabíamos? ¿Al ser pequeños lo aplicábamos de forma intuitiva después de muchos desarrollos? Realmente no pero aún así existen muchas similitudes. Supongo que esta forma de trabajar es similar a la vuestra:

  • 1. Briefing/especificación del cliente.
  • 2. Análisis del proyecto por el jefe de proyecto.

    Con estos dos puntos tendríamos un Product Backlog pero en versión light, ya que sólo el director de proyecto y cliente lo tocan, no todo el equipo.
    Los tiempos los especifica el director del proyecto las tareas se desacoplan en el sentido de que en ciertas situaciones parte del equipo no sabe lo que hace el otro. Si no se llega al tiempo quizás pueda ser problema de la especificación y no del desarrollador, que además carece de una visión global del proyecto. Aquí creo que es donde esta el mayor problema y con SCRUM se puede solucionar!

  • 3. Desarrollo. Perfiles.

    Aquí el perfil es prácticamente el mismo: Product Owner sería nuestro Director o el que habla con cliente (en grandes empresas, sobretodo de publicidad, este perfil se denomina Cuentas), el ScrumMaster seria nuestro jefe de proyecto (o product manager) y el Team serían los desarrolladores. Sucede en proyectos pequeños que el jefe de proyecto también es desarrollador e incluso en los muy pequeños se encarga una única persona de ser un auténtico ScrumMaster++ (Product Owner + ScrumMaster + Team) todo en uno…

  • 4. Desarrollo. Reuniones.

    Al inicio del proyecto y cuando surge alguna dificultad. Obviamente aquí no lo aplicamos bien y solucionaría muchos de los problemas planteados en los puntos 1 y 2. Hay personal que lo soluciona todo con reuniones y más reuniones, yo no creo tanto en eso ya que se interrumpe constantemente el workflow… pero como reuniones breves como plantea SCRUM creo que puede ser un acierto.

  • 5. Desarrollo. Sprints

    Las entregas finales siempre tienen dos fechas: beta y producción. El tema es que solemos partir las funcionalidades en tareas y con el gestor de tareas / emails con las tareas / partes de trabajo, los jefes de proyecto hacemos un seguimiento continuo y casi diario de cómo va todo. Esto hace que no haya tareas de más de 2 días. Es como el SCRUM pero encarrilado, hace trabajar demasiado a nuestro jefe de proyecto y el desarrollador muchas veces va «ciego» al no tener una visión global del proyecto. Nuevamente parece que SCRUM lo mejorará.

Lo curioso del tema es que muchas empresas grandes (incluso las que tienen departamento de desarrollo online) contratan a pymes como nosotros para realizar desarrollos, formando así equipos de desarrollo conformados por grupos pequeños de personas. Con lo cual me lleva a pensar: ¿Seremos su forma de aplicar metodología ágil SCRUM? ¿Y por eso funcionan tan bien las subcontratas?

¿Que pensáis? ¿Trabajáis con SCRUM? ¿o al menos os recuerda a vuestra forma de trabajo?

Y otras cuestiones que rondan mi mente: ¿es posible utilizar SCRUM en equipos de trabajo pequeños que lleven unos pocos proyectos a la vez y muchos más en mantenimiento? Obviamente eso entorpece los sprints. ¿Tal vez es que SCRUM directamente no es aplicable a Pymes pequeñas de entre 3-10 empleados que tienen multiples proyectos a la vez? Adelante SCRUM Masters! 😉

En unos meses os contaremos nuestras experiencias sobre estos métodos (esperamos que) bien aplicados en nuestro proyecto estrella. #gogogo

Etiquetas: , ,

6 Comentarios
» Feed RSS de los Comentarios

  1. Marcos dice:

    Joder acabo de leer este post y veo que te planteas prácticamente las preguntas que puse como comentario al anterior post… XD Entiendo que vamos por la misma onda. La metodología por cierto que llevamos en [Q] es muy pareciada a la vuestra 🙂

    Ya me contarás de qué va ese proyecto estrella! 🙂

  2. Marcos dice:

    Tios instalar el puto plugin… vais a ganar muchas visitas XDD Quiero estar al tanto de los contraataques de mis comentarios!!! XD

  3. Jose Manuel Pérez dice:

    Dada mi experiencia en TeralcoTI y ahora en DinamicLab, pienso que sí es aplicable en una pyme de 3-10 empleados.
    En TeralcoTI llevábamos 4 proyectos grandes a la vez un grupo de sólo 6 personas y la calidad de los mismos cambió radicalmente a mejor.
    El hecho de tener roles, trabajar con historias de usuario, reuniones diarias y reuniones de planificación de sprint donde TODOS participábamos e incluso realizábamos estimaciones de tiempo, hizo que nos sintiéramos mucho más integrados y motivados en los proyectos.
    Actualmente en DinamicLab tenemos varios proyectos abiertos y hemos empezado desde 0 a realizar SCRUM en un proyecto nuevo. Después de un primer sprint todos coincidimos en que usando esta metodología la forma de trabajar ha ido a mejor.
    Otro detalle que destacaría son las reuniones de retrospectiva de sprint donde se analizan todos los detalles de dicho sprint. En una reunión de 2-4 horas, todos hablan de qué ha ido bien, que podría mejorar y que debería hacerse de forma diferente. Creo que ese feedback es muy importante para el grupo, para el Product Manager y para el Scrum Master.
    Por último, destacar que SCRUM da más importancia a la respuesta al cambio que al seguimiento de un plan. Si sabemos que el desarrollo web es cambiante, usando este tipo de metodologías “debería” de mejorar la calidad del desarrollo de nuestras aplicaciones. Aunque claro, SCRUM no es la panacea, por lo que todo depende de la experiencia de cada uno.
    Yo no lo cambio por otra metodología, como mucho, lo adaptaría a mis necesidades..

  4. elad dice:

    Buenas Jose, gracias por la aportación! Muy interesante si señor!

    Es importante conocer de primera mano las experiencias de utilizar esta metodología en ambientes similares al nuestro! Gracias.

  5. Luiggi dice:

    Buenas ante todo felicidades por el site y el post. Yo trabajo en una empresa que usamos ScrumBan (Scrum+Kanban), y desde mi experiència les digo mi punto de vista. En mi equipo llevamos 3 productos grandes y aparte mucho mantenimiento. Eso entorpece la velocidad de los Sprints y poder desarrolar aplicaciones para nuestros productos.

    Desde mi punto de vista habría que crear un Equipo con sistema Kanban y así no se interferiria en el desarrollo de los productos.

    Ya que recuerdo que si entra un Kanban Blocker, automáticamente se para todo y atender a la incidencia.

    Luiggi – @ElTruxi

  6. elad dice:

    Gracias por el comentario positivo sobre el blog, trabajamos día a día por mejorarlo.

    Nosotros no hemos trabajado aún con Kanban así que nos parece muy interesante la opinión y valoración de un profesional en la materia.
    Seguro que vamos a estudiarlo, gracias 😉

    Como referencia ponemos enlaces a lo que vamos a ir mirando:
    http://es.wikipedia.org/wiki/Kanban
    http://en.wikipedia.org/wiki/Scrum_(development)#Scrum-ban

Enviar comentario