Scrumízate
Todos los que nos dedicamos al desarrollo de software sabemos que los requisitos pueden cambiar. No sólo los requisitos son mutantes sino que pueden entrar en conflicto o contradicción entre ellos. Los motivos por los que esto puede suceder son variados: cambios de realidad del cliente, poca información inicial, mala definición de requisitos... Vivimos un mundo que cambia rápidamente y las personas, también las empresas, deben adaptarse a estos cambios. Cosas que funcionan de toda la vida pueden dejar de ser válidas mañana. Adaptarse o morir. En este sentido los proyectos de desarrollo (o cualquier otro tipo de proyecto) necesitan, para ser útiles, adaptarse.
Podemos hacer un ejercicio de imaginación, vamos a suponer que nos han contratado para hacer un proyecto de software. Inicialmente hemos definido el proyecto y acordado todas las funcionalidades con el cliente. El proyecto cuenta con una fase piloto durante el primer año y la aplicación total en el segundo. Durante este tiempo, la realidad del cliente cambia, ya no se relaciona y comunica igual, utiliza un software distinto o nuevo en algún punto, son más (o quizás menos) empleados... Todos estos puntos empiezan a suponer algunos cambios de requisitos y de las funcionalidades, pero no estaban acordados en el punto inicial y no existe la comunicación suficiente con el cliente, de modo que no se llevan estos cambios al software. El software entregado no será suficientemente útil al cliente y el proyecto puede tener problemas para salir de la fase piloto.
Tradicionalmente hemos tenido un sistema diseñado para negar a las personas (sobretodo clientes) lo que realmente quieren. Es un sistema que limita el aprendizaje, la innovación y la creatividad. A veces se puede dar el caso de que el cliente pagaría por algunas cosas que ya no necesita y no podría añadir hasta mucho más tarde en el tiempo, previo pago, de puntos mucho más importantes a día de hoy. No tiene sentido alguno.
Scrum nos permite solucionar el problema: cambios gratis. No, no nos hemos vuelto locos, Scrum sugiere un sistema que permite al cliente las modificaciones que desee mediante una dinámica de trabajo conjunta.
En la definición del proyecto se escriben las historias de usuario (puedes ver como escribir historias de usuario aquí). Estas historias de usuario se añaden al backlog. Todas las historias de usuario tienen un valor en puntos asociados, calculados mediante poker plan. Cada sprint termina con una demo o entrega piloto al cliente. El encargado de presentar el trabajo del sprint es el product owner. Durante la entrega el product owner recoge el feedback directo del cliente. El product owner es quien tiene el poder sobre el backlog, de modo que puede modificar el orden de prioridad.
En las metodologías ágiles, también en Scrum, es muy importante la implicación del equipo en el proyecto. Trabajar usando historias de usuario para definir el trabajo y plantearlas colectivamente es ideal para aumentar la implicación del equipo. Puedes leer acerca de las ventajas para el equipo de organizarse en historias de usuario en este post.
Que pasa ante las nuevas funcionalidades? Y los cambios de requisitos? O cambios concretos en una funcionalidad? El proyecto consiste en firmar un número de puntos, a cada cambio se le asigna un valor y hablando con el cliente sacaremos alguna historia de usuario con la misma puntuación. De este modo en todo momento estaremos trabajando en los puntos más importantes para el cliente y dejando de lado las cosas que no son tan importantes.
En este punto aparece la cláusula Scrum: El cliente puede rescindir el contrato en cualquier momento (el software hace todo lo que desea el cliente) pero deberá pagar el 20% del valor del resto del contrato. Vamos a ver un ejemplo real de aplicación de esta cláusula que aparece en el libro Scrum de Jeff Sutherland:
Una empresa consigue un contrato de 10 millones de dólares para construir un software para una importante empresa constructora, fijando un plazo de 20 meses. La empresa de desarrollo de software realizaba sprints mensuales. Firmaron la cláusula Scrum. Al completar el tercer sprint, la empresa constructora, muy satisfecha con el software desarrollado, decide rescindir el contrato, ya cumplía todas sus expectativas. Todos ganan:
La empresa constructora pensaba pagar 10 millones y acaba pagando 3.2 millones: 3 meses de desarrollo son 1.5 millones i el 20% de los 8.5 restantes son 1.7 millones.
La empresa de desarrollo de software había hecho un contrato con un margen del 15%. Gastaron 1.3 millones durante estos 3 meses y cobraron 3.2. Habían planificado un margen de 200.000$ y consiguieron un margen de 1.9 millones, el margen subió del 15% al 60%.
Esto fue posible gracias a la ley del 80/20 del software: el 80% del valor radica en el 20% de las características. Debemos pues, hacer primero este 20%.
Te ha gustado el post? Ayúdanos a dar a conocer Scrumízate i comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
