SCRUM en los proyectos Mobile

Seguro que a muchos os ha ocurrido que cuando realizasteis un proyecto con una empresa, os han entregado un producto que no era exactamente lo que queríais o necesitabais. También seguramente, si tienen una empresa o han sido proveedores también han recibido alguna aclaración de un cliente de que el producto que entregaron no era exactamente el que querían y le hayan pedido algunas correcciones sin alterar el presupuesto. ¿Por qué ocurre esto? Básicamente dos motivos: El primero es por una falta de comunicación cliente-equipo de desarrollo y el segundo es que como clientes no siempre sabemos qué es lo que necesitamos para solucionar nuestro problema.


El motivo por el que se presentan estas dos razones es por la metodología que se usa habitualmente para desarrollar proyectos. El comercial habla con el cliente y toma nota de sus necesidades. Traslada esta información a un Project Manager el cual elabora un extenso documento de requisitos funcionales, el cliente aprueba este documento (incluso algunas empresas se saltan este paso) y se les envía al equipo de desarrollo para que construyan la solución completa, la prueben (testing) y el comercial pueda entregársela finalizada al cliente. Este flujo es el que empeora la comunicación de lo que el cliente quiere o necesita en realidad y el que hace que el cliente sólo pueda probar su producto una vez esté terminado.


La solución a estos problemas es un cambio de la metodología tradicional de proyectos a una metodología de desarrollo ágil. Existen varias metodologías, pero en este post os voy a hablar de la que más está en auge actualmente: SCRUM.


Scrum se divide en varias fases que iré describiendo una por una para facilitar al lector su aprendizaje.


HISTORIAS DE USUARIO. Scrum afirma que la comunicación con el cliente elaborando documentos extensos de requisitos funcionales no es efectiva. Los desarrolladores deben de conocer en todo momento qué es lo que realmente necesita el cliente. Para ello se utilizan las llamadas “Historias de Usuario” en las que el Product Owner (representante del cliente), que por lo general es el comercial formado en la metodología Scrum, es el encargado de elaborarlas.


En estas historias lo que se pretende es separar las funcionalidades que el cliente necesita. Para ello podemos usar un post-it, una tarjeta o un medio digital en la que escribimos la necesidad del cliente. Una sentencia típica en las historias de usuario suele ser: “Como [ROL] quiero hacer [FUNCIONALIDAD] con el objetivo de [BENEFICIO]“. Por lo que traducido a un ejemplo podría ser: “Como ADMINISTRADOR quiero poder ELIMINAR USUARIOS de mi app con el objetivo de NO DAR ACCESO a clientes que no me han pagado 2 mensualidades”. De esta forma elaboraremos todas las historias de usuario y le pediremos al cliente que valore qué funcionalidades son más críticas en su proyecto. Cuales son absolutamente necesarias y cuales son más secundarias. Después trasmitiremos todas las necesidades del cliente al Scrum Máster (Project Manager conocedor de las metodologías SCRUM).


PRODUCT BACKLOG. Una vez dispongamos de todas las historias de usuario, el Scrum Máster convocará una reunión para analizarlas. En este caso todo el equipo de desarrollo conoce las necesidades del cliente de primera mano y no un documento de requisitos funcionales para empezar a programar o diseñar. La primera parte de la reunión, será para analizar si la funcionalidad pedida por el cliente es la que realmente cumple el objetivo que busca o existe otra mejor. Si queremos una relación duradera con los clientes, es importante que nos centremos en darles lo que necesitan para solucionarles sus problemas. Siguiendo con el ejemplo anterior, el cliente pedía la funcionalidad de borrar usuarios para denegar el acceso a aquellos que lleven 2 meses de retraso. En la conversación del equipo es posible que salga la idea de que la funcionalidad más adecuada sería desactivar temporalmente a los usuarios y no borrarlos definitivamente de la base de datos, ya que si luego vuelven a pagar o a apuntarse se reactivarían de una forma más sencilla para el cliente.


Se realizaría esto con todas las historias de usuario se estimaría un tiempo de desarrollo (y presupuesto) para cada una. El Product Owner, confirmará con el cliente las correcciones propuestas y por fin tendremos una “pila” de Historias de Usuario con una valoración de importancia y un tiempo de desarrollo. A esta pila en Scrum, se le conoce por el nombre de Product Backlog.


SPRINT BACKLOG. Scrum es una metodología basada en sprints, se realizan desarrollos parciales (como máximo de 2-3 semanas) y entregas al cliente de cada desarrollo para realizar el testing junto a él. El Sprint Backlog es la planificación del sprint. Hay que seleccionar las historias adecuadas para el primer desarrollo y dividirlas en tareas entre el equipo técnico. Las tareas nunca han de sobre pasar las 16 horas de trabajo, en ese caso la tarea se deberá de dividir en subtareas.


REUNIÓN DE PLANIFICACIÓN DEL SPRINT. El Scrum Máster asignará a cada miembro de su equipo las tareas encomendadas para el sprint actual. De esta manera cada miembro del equipo tendrá claro qué funcionalidades tiene que desarrollar y qué tiempo se ha asignado para ellas.


DAYLY SCRUM. Es el nombre que recibe las reuniones diarias del equipo Scrum. Cada día se realizará una breve reunión (10-15 minutos) dirigida por el Scrum Máster en la que cada miembro del equipo debe de decir: Qué ha realizado el día anterior, qué va a realizar hasta la reunión de mañana y si ha tenido algún problema que le haya impedido alcanzar su objetivo. Estas breves reuniones quitan muy poco tiempo al equipo y permiten un control absoluto del proyecto por parte del Scrum Máster. Si este ve que se ha producido un desajuste en la planificación del sprint podrá reajustarlo a tiempo y evitar sustos futuros.


SPRINT REVIEW. Una vez finalice el sprint se realizará una reunión denominada Sprint Review Meeting, en la que cada miembro del equipo podrá exponer su trabajo y las dificultades surgidas en el sprint realizado. El Product Owner entregará la “demo” realizada en el sprint al cliente para que pueda probarla y realizar feedback. De esta forma conseguimos realizar un producto acorde a las funcionalidades que el cliente pidió, pero aquí no termina todo ya que como os comentaba antes, el cliente no siempre sabe qué es lo que necesita realmente. El probar y testar con la demo le permitirá ver si eso es lo que necesitaba en realidad. En caso de no serlo, siguiendo esta metodología nos daremos cuenta mucho antes y podremos corregirlo por un precio menor al que sería cambiar todo el proyecto una vez terminado, por lo que beneficia tanto a la empresa que desarrolla como al cliente.


SPRINT RETROSPECTIVE. A continuación del Sprint Review, el equipo analizará los problemas que han tenido y cada miembro propondrá posibles mejoras para los siguientes sprints.


ENTREGA DEL PRODUCTO. Con la consecución de los pasos anteriores iremos realizando entregas parciales al cliente, recibiendo su feedback y el de nuestro equipo de desarrollo, y podremos finalizar la entrega de un producto que realmente aporte valor al cliente de una forma ágil y minimizando los costes.


En Tactel Mobile, apostamos por el uso de metodologías ágiles cuando el cliente lo desee, por lo que si quieres desarrollar un proyecto mobile utilizando Scrum no dudes en contactarnos. También puedes preguntarnos cualquier tipo de duda por Twitter en @tactel_mobile.


No hay comentarios

Agregar comentario