[06/02/2014] Hace unos días estuvo en Lima Hubert Smits, certificador de la metodología Scrum. Con él conversamos sobre las particularidades de esta forma de hacer software y nos ofreció una visión panorámica de lo que implica la metodología y las ventajas frente a otros enfoques.
Scrum es una metodología de desarrollo de software que se distingue por avanzar en su trabajo mediante iteraciones continuas e incrementales. Con ello se logra, de acuerdo a Smits, ofrecer resultados concretos a medida que se avanza, además de ofrecer la oportunidad de recoger la retroalimentación del cliente de forma continua.
Gracias a una invitación de
Belatrix Software, la firma consultora que trajo a Smits, pudimos tener una muy informativa charla sobre la metodología. En ella Smits nos dio más detalles sobre Scrum.
¿Cómo podría definir Scrum?
Creo que hay dos partes importantes en la definición. La parte más conocida es que en lugar de dar un solo gran paso, se realizan muchos pequeños pasos al momento de desarrollar. Cada dos semanas, una pequeña parte del software es finalizada y puede ser mostrada al cliente.
El rol del cliente es definir los requerimientos y qué características van a ser entregadas primero por el equipo. De esa forma, el enfoque Scrum crea una muy rápida retroalimentación, el cliente puede ver rápidamente qué es lo que se está construyendo y qué está bien o mal.
Entonces en lugar de ver los problemas luego de ocho meses y tener que renegociar el contrato y extender el plazo y gastar más dinero, se puede ver cada dos semanas un poco más del proyecto y luego de un mes o seis semanas se puede comenzar a señalar qué no está bien y cómo se tiene que corregir, qué falta o qué no es importante. De esta forma, el cliente tiene más influencia sobre el desarrollo del producto de software. Es lo que llamamos un desarrollo iterativo e incremental, donde cada semana se puede avanzar una parte.
¿Las partes que se entregan se encuentran listas para ser utilizadas?
Sí, y eso es importante. Si construimos software verdadero podemos ver cómo funciona. Si, por ejemplo, desarrollamos un sistemas bancario y hacemos un sistema de demostración, éste podría no funcionar en la vida real porque es más lento, o porque no hay ciertos datos disponibles. Si es software de verdad tiene que ser utilizable, porque eso da una retroalimentación real al cliente y también le da al cliente la oportunidad de comenzar a utilizar el producto antes de que finalice el proyecto. En un proyecto clásico tienes que esperar que pase todo el proyecto u ocho meses y entonces tienes resultados.
En Scrum tienes la oportunidad de llegar al mes cuatro y aunque no se haya finalizado, poder comenzar a utilizarlo. Siempre va a haber software que se pueda utilizar al final de cada paso, de cada sprint, como lo llamamos.
¿Y cuál es la diferencia entre Scrum y trabajar por módulos?
No tiene que ser diferente. Si una aplicación se construye por módulos podemos entregar módulo por módulo, en la medida en que cada uno de los módulos funcione y podamos demostrarlo al cliente. Es una forma de hacerlo. Pero si tenemos módulos grandes y módulos pequeños, donde los pequeños se hacen en días y los grandes en meses, hay una diferencia ya que Scrum siempre tiene una iteración en periodos de igual magnitud.
Nosotros generalmente trabajamos en base a dos semanas, así que si tenemos un módulo que nos tomaría seis semanas lo haríamos en tres sprints, porque eso incrementa la productividad del equipo de desarrollo de software. Esa sería la diferencia, pero definitivamente puedes trabajar de módulo en módulo.
¿Entonces el periodo de tiempo que se escoge tiene que ser calculado como para entregar algo que funcione?
Sí, todos los sprint deben tener un resultado con el que se pueda trabajar. Incluso si trabajamos con un módulo grande el primer paso, deberá tener una parte que el cliente pueda inspeccionar y pueda decir que está bien, que está mal o que se necesita modificar.
Entonces si se tiene un módulo grande, como por ejemplo, el de pagos de tarjeta de crédito, debemos dividirlo en pasos más pequeños. El primer paso puede ser el número de la tarjeta de crédito y su fecha de expiración; en el siguiente paso el balance del cliente y lo que puede pagar; y en el sprint final se puede entregar el pago en sí, junto con la impresión de recibos. De esa forma el módulo se encuentra completo, pero cada sprint tendrá software que ya está completado.
¿Existen grados o certificaciones en este enfoque?
La clase que estamos realizando en Lima es la clase de nivel de entrada, lo que se llama el Certified Scrum Master, este es el primer nivel, típicamente para desarrolladores. Hay una clase similar del mismo nivel, llamada Certified Scrum Product Owner en donde se da el mismo contenido pero dirigido a product managers, para los clientes. Ese es el primer nivel, tienen que estar en clases por dos días y luego pasan un examen y luego tienen la certificación.
El siguiente nivel es el de Certified Scrum Professional, es para las personas que han conseguido una de las certificaciones anteriores y muestran que tienen experiencia, que han estado trabajando en proyectos por un mínimo de dos años. Ellos pasan por un examen que es más complejo y requiere de más estudio. Esto muestra que las personas han trabajado con Scrum.
Si las personas quieren continuar su educación, pueden avanzar un nivel más y ser un Certified Scrum Trainer, que es precisamente lo que hago, puedo certificar personas; o también pueden convertirse en Certified Scrum Coach, lo cual significa que pueden trabajar con equipos o con compañías completas para ayudarlos en el uso de Scrum. Estas personas tienen cuatro o cinco años de experiencia.
¿Existe una entidad certificadora internacional?
La organización mundial se llama Scrum Alliance. Ésta comenzó hace unos 12 años y ahora son globales y se encargan de registrar las certificaciones de las personas de todo lugar, traducir los exámenes a muchos idiomas. Las personas que participan en Lima van a tomar el examen en español, y así con otras personas del mundo. Scrum Alliance es la organización global.
¿Desea agregar algo?
Como dije al inicio, existe una segunda parte importante de la definición de Scrum y es la que se refiere a que las personas son lo más importante, más que el cumplimiento de los procesos que están escritos en un libro. Nos preocupamos más en las personas, en la comunicación, en usar todas las habilidades de las personas.
Las estimaciones se hacen mejor si se hacen con todas las personas del equipo, el grupo estima mejor. Por otro lado, las estimaciones generalmente son erradas cuando pedimos absolutos. Por ejemplo, si le pido a alguien que estime cuántos centilitros caben en mi taza de café, cada una de las personas va a tener una respuesta diferente. Pero si pregunto sobre la capacidad de mi taza en comparación con un vaso de agua, el grupo va a responder que alrededor de dos tazas.
Las comparaciones funcionan mejor en las estimaciones que los absolutos. Entonces las estimaciones en Scrum -aunque también en otras técnicas modernas de estimación- se basan en estimaciones por comparaciones y en estimaciones realizadas por el equipo completo.
Si traducimos eso al software tenemos que, si el equipo estima los módulos que mencionaste al inicio, cada miembro del equipo va a ver la parte de la que se encarga y así se podrán ver todos los diferentes problemas que pueden haber con los módulos. Además, esto se va a hacer mediante comparaciones; es decir, el módulo de impresión de facturas puede requerir la mitad del tiempo que el módulo de pagos con la tarjeta de crédito. Si podemos saber cuánto tiempo toma el módulo de impresión podemos derivar cuánto nos va a tomar el otro módulo, y cuánto van a tomar los otros módulos porque las comparaciones nos permiten hacer esos cálculos.
¿Y los clientes aceptan este tipo de metodología, de estimaciones? ¿No prefieren las fechas?
Sí necesitamos producir estimados con fechas. Si tenemos 50 módulos que producir estimamos mejor comparándolos, y si calculamos que el primer módulo nos va a tomar cinco días y el segundo es el doble de difícil de producir nos tomará 10 días, podremos así calcular fechas reales.
Con respecto a la otra parte de la pregunta, no todos los clientes aceptan este tipo de estimados. Trabajar con Scrum, con las estimaciones, con los sprints es muy diferente, los clientes deben ser abiertos y estar dispuestos a hacer las cosas de una manera diferente. Generalmente están dispuestos a hacerlo cuando han tenido problemas con la forma anterior de trabajar. Pero sí es cierto que no todos los clientes se encuentran listos para trabajar con Scrum.
Jose Antonio Trujillo, CIO Perú