No tan ágiles, por favor.

Publicado por

Mozilla quiere una nueva versión de Firefox cada 5 semanas. No  tan ágiles por favor.

– Leido en noticias para desarrolladores- desarrolloweb.com

Mozilla Foundation plantea volver a cambiar su ciclo de lanzamientos (llamémosles Sprints 😉  )  y han planteado la posibilidad de reducir el tiempo entre versiones.

Hace 5 meses anunciaron un cambio drástico en su política de lanzamientos para recuperar la tendencia negativa que habían venido sufriendo desde el retraso de la llegada de Firefox 4. en ese momento, apuntaban como solución a la pérdida de usuarios de Firefox el lanzamiento de nuevas versiones cada 6 semanas.

3 versiones después, esta misma tarde , me ha saltado la actualización a Firefox 7.01, parece ser que la tendencia sigue siendo perder usuarios mes tras mes, pero los responsables de la fundación creen que este es el camino correcto para solucionar sus problemas de perdida de usuarios.

Leer esta noticia en desarrolloweb.com, me ha hecho reflexionar sobre la frecuencia de los Sprints en Scrum y compartir aqui algunas ideas.

¿Realmente la pérdida de usuarios se soluciona sacando continuas versiones?. O por el contrario,  ¿esto provoca una sensación de desasosiego en los usuarios que tiene que aprender continuamente nuevas funciones, que a veces  son de poco valor y muy poco significativas ?. En mi opinión, tanta versión puede hacer pensar en problemas de estabilidad y seguridad ,por no decir de frustación porque el «super-plugin» que te habías instalado, ahora ya no es compatible con la versión que te acabas de descargar.  Si las versiones son para corregir los problemas reportados por los usuarios de las versiones anteriores, totalmente de acuerdo, pero preguntémonos si las versiones anteriores entonces estaban verdaderamente maduras y estables para ver la luz o simplemente eran un intento de evitar la escalada de los competidores y al final son contraproducentes por que provocan más problemas y pérdidas de imagen que valor aportan al usuario.

¿Y qué decir de Facebook?. Igualmente no para de sacar novedades, de hacer entregas y completar «Sprints», pero al igual que en el caso de Firefox : ¿ están los usuarios preparados para absorver tanto cambio?. ¿No les marea esto un poco? ¿Cada pocos dias una cosa nueva?.

Extrapolando estas cuestiones de Firefox y Facebook a los proyectos que normalmente desarrollamos ( porque si uno que escribe tuviera como proyecto alguno de estos dos, seguro seguro que no estaría aqui y ahora 😉 ) es importante cuando estámos definiendo el Sprint Planning del proyecto, tener claro cual va a ser nuestra frecuencia basándonos en factores como tipo de proyecto, madurez del equipo, calidad de los requisitos, dependencias de otros equipos, solo por mencionar algunas de las cosas que determinarán cada cuanto tiempo tendremos listo el Sprint.

La frecuencia de los Sprints en un proyecto que se gestione bajo el modelo Ágil – Scrum , puede  ser   desde una semana hasta varios meses.

Entregas de una semana, la verdad es que con los tamaños de equipo de desarrollo habituales en proyectos Scrum, va a aportar muy poco contenido adicional sobre la versión anterior, luego salvo situaciones excepcionales, yo de partida lo descartaría para casi cualquier proyecto.  Tanta frecuencia y tanta «agilidad» por mucho que el equipo sea maduro,  va a provocar estres y probabilidades de fallo.

Entregas espaciadas tres meses ,puede que tampoco sean recomendables ya que el equipo necesita lo que en otro artículo sobre motivación he comentado :»exitos tempranos y resultados tangibles cada poco tiempo».  Puede haber proyectos que tengan un ciclo de desarrollo de las historias de usuario muy largo y complejo, y que eso nos lleve a Sprints cada tres meses. En este caso lo que recomiendo es descomponer esas historias de usuario en otras más cortas para conseguir una frecuencia de los Sprints mayor y asi ver resultados en menores plazos.

La frecuencia ideal es bajo mi punto de vista  de  dos semanas para proyectos de mantenimiento correctivo y evolutivo, en los que el equipo realiza tareas de corta duración que mejoran funcionalidades actuales o corrigen bugs, y cuando se trata de un proyecto de creación de un nuevo producto sistema, la frecuencia la establecería en un mes para cada Sprint, pues es un tiempo que considero razonable para que la entrega o Sprint aporte valor y compense el esfuerzo del equipo de preparar la implantación, probar , comunicar y demás actividades implicitadas de un despliegue en producción.

Dicho eso: medir las frecuencias de cada Sprint muy  bien para evitar riesgos segun el proyecto y pensemos en el esfuerzo que supone para el equipo una frecuencia muy alta de Sprints si no aportan valor  al negocio  y por favor, Facebook y Firefox: » No tan ágiles por favor».

Deja un comentario

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