Ya hemos hablado en un par de ocasiones del sprint backlog.
Por un lado, durante la planificación del sprint, tenemos que confeccionar el sprint backlog, y por otro lado, durante el daily scrum, hay que ir actualizando su contenido.

La teoría la sabemos, pero... ¿cómo confeccionamos y actualizamos en Unkasoft este sprint backlog?

Nosotros nos basamos en la plantilla para sprints de SCRUM que publicó hace tiempo Juan Palacio (con algún retoque nuestro).
Estuvimos evaluando otras plantillas, pero no nos han convencido por ser demasiado complejas (y porque apostamos por los productos nacionales :)

En esencia, la plantilla de sprint que usamos nos hace las funciones de tablón virtual donde vamos dejando tarjetas de las tareas a completar y las vamos moviendo de sitio cuando están terminadas.
Durante el daily scrum, actualizamos cada tarea, apuntando las horas que quedan para completarla, y la propia plantilla nos saca gráficas de esfuerzo (que los ingleses llaman burndown charts).

Basicamente, la plantilla tiene tres secciones:

Configuración:
Damos varios datos del sprint que vamos a realizar, como el número de días que dedicaremos, número de horas de trabajo al día, tipos de tareas a realizar (codificación, reunión, pruebas, documentación, etc.), estados de cada tarea, integrantes del equipo o días festivos que tendremos durante el sprint.

Datos:
Aquí apuntamos las tareas que hemos ido extrayendo durante la planificación del sprint, apuntando la estimación en horas, el tipo de tarea.
Por cada tarea, a la derecha tenemos las horas que faltan para completarse en cada uno de los días del sprint. Así, si no se avanza en una tarea, veremos como sus horas no disminuyen, lo cual es una cosa mala.
Basándonos en ese total de horas y en la velocidad de desarrollo (un factor entre 0 y 1 que hemos añadido), podemos calcular la fecha estimada de cierre, distinta para cada día del sprint, para así ver si vamos a buen ritmo o llevamos retraso.
Otra cosa que hemos añadido es una columna con las horas reales dedicadas a cada tarea, que rellenamos cuando la tarea se termina. Aunque SCRUM no habla nada del control horas estimadas-reales (sólo controla las reales), nosotros lo necesitamos por temas de presupuestos, costes, etc.

Gráficos:
Por último, basándonos en los datos de esfuerzo de cada tarea, podemos sacar el famoso gráfico de esfuerzo (burndown chart) y otros gráficos para ver la evolución de las tareas, cómo fluctúa la fecha de cierre, o la carga de trabajo asignada a cada programador.

Sobre cómo interpretar estos gráficos, hay mucho que hablar. Aquí cuenta mucho la experiencia y la intuición (como en todo gráfico que se precie), aunque os recomiendo que leáis este post sobre los cinco signos de problemas durante una iteración. Nosotros creo que ya los hemos sufrido todos (:
También existen gráficos más complejos para gestionar de forma correcta las tareas introducidas a mitad del sprint.

Bien, esto poco a poco va llegando a su fin.
El próximo día hablaremos un poco sobre cómo combinamos eXtreme Programming con SCRUM.

Etiquetas: agile, SCRUM

El otro día estuvimos hablando de cómo podemos organizar los sprints de SCRUM, dejando en el aire el tema de las reuniones diarias (llamadas daily meeting)

Antes de entrar en harina, tenemos que presentar a la figura del Scrum Master.
SCRUM propone los roles de "product owner", "equipo de desarrollo" y "Scrum Master".
El Scrum Master es la persona que conoce la filosofía y el modo de aplicar SCRUM en una empresa. No se trata del clásico "jefe de proyecto", sino que es uno más del equipo, al mismo nivel que los demás, aunque con tareas distintas.
Como ya hemos dicho, en los proyectos típicos de SCRUM se trata de una persona que compagina esta actividad con otras (puede ser habitual que el Scrum Master sea también el "product owner", o un programador más), aunque en proyectos grandes quizá pueda haber un Scrum Master a tiempo completo.
Es importante que el Scrum Master sea una persona con cierta capacidad de decisión en la empresa, más que nada porque quizá tenga que tomar algunas decisiones difíciles para que el proyecto llegue a buen puerto.

Bien, hechas las presentaciones, podemos decir que el corazón de SCRUM es la reunión diaria, (también llamada "scrum" en referencia al movimiento típico de rugby). La reunión es un momento en que todo el equipo de desarrollo pone en común sus avances, sus dudas, pide ayuda, etc. Con una reunión diaria nos evitamos las desagradables sorpresas a punto de cerrar la versión, ya que se va viendo el avance (o el "no-avance") día a día.

En varios equipos de desarrollo que conozco desde dentro, el jefe de proyecto va mesa por mesa preguntando el típico "¿cómo vas?", o el programador avisa al jefe cuando ha terminado una tarea.
Recordemos que en SCRUM, no existe ese concepto de "el jefe revisa", sino que, como estamos hablando de equipos autogestionados, es el equipo al completo (programadores como tú y como yo) los que van revisando el trabajo de los demás.
Además es importante que el equipo vaya viendo los avances del proyecto al completo, y no sólo de su parte. Esto crea un sentimiento de pertenencia e identificación, y este sentimiento podemos decir que es la gasolina de la metodología SCRUM. Sin sentirse identificado, el proyecto SCRUM al final se parará igual que un coche se para sin gasolina.
Todo esto me lleva a recordaros una vez más la regla de oro: no intentes aplicar SCRUM en cualquier empresa y en cualquier equipo. Elige muy bien la gente y el ambiente de trabajo.

La reunión diaria no debe durar más de 10-15 minutos, para evitar las típicas reuniones interminables, donde nunca se saca nada en claro. En nuestro caso la reunión es muy informal y dura 2 minutos (: ya que sólo estamos dos programadores en el proyecto.
Así que no hay excusas del estilo: "no tengo tiempo para reunirme", porque seguro que estás perdiendo más tiempo leyendo esta página.

SCRUM define un modus-operandi más o menos establecido. Durante la reunión, cada integrante tiene que contestar tres cuestiones:

1. ¿Que hiciste ayer?
2. ¿Que vas a hacer hoy?
3. ¿Que necesitas para seguir?

En el blog del Jeff Sutherland (uno de los creadores de SCRUM), explica con detalle el porqué de estas preguntas:

¿Qué hiciste ayer?
Con esta pregunta se pretenden dos cosas:

1. Que todo el mundo este trabajando en las tareas que él mismo se asignó. Como ya hemos dicho, SCRUM no funciona del modo tradicional en que el jefe de proyecto dice: "Fulanito, para la semana que viene tienes que tener terminada la tarea X", sino que cada desarrollador se asigna las tareas que cree que puede hacer mejor. Es posible que alguien "se invente" lo que ha estado haciendo. Sinceramente: es su problema. Cuando llegue el fin del sprint quedará en evidencia al verse que sus tareas no están terminadas y se verá que ha estado mitiendo durante todas las reuniones.
2. Que todo el equipo vea como avanza el proyecto. Siempre viene bien para la moral ver como tus compañeros avanzan a buen ritmo en sus tareas, y el equipo se mueve a un ritmo constante hacia un objetivo común. Esto ayuda a que los rezagados se den más prisa y que los desmotivados se auto-motiven. Ojo, hay que distinguir cuando un programador está por debajo de su capacidad, tiene algún tipo de problema personal o cuando no le apetece trabajar más. Cada caso requiere de acciones distintas del Scrum Master.
   Hay veces en que los retrasos se deben a que el programador no es consciente de las consecuencias que acarrea un retraso en su código, y por eso se toma las cosas con más calma. Es natural y no suele ser culpa del programador: nadie se lo ha explicado y él no tiene porqué saberlo (típico en empresas con poca o nula comunicación). Con esta reunión se elimina este problema: todo el mundo es muy consciente cuando hay que correr porque se está esperando a que termine, o cuando las cosas se pueden tomar de una forma más relajada.

En este momento el programador actualiza el "sprint backlog" para reflejar el tiempo que queda para terminar la tarea con la que estaba (más adelante explicaremos cómo está organizado y cómo trabajar con el sprint backlog).

¿Que vas a hacer hoy?
En esta pregunta, cada integrante se asigna las tareas que más le gusten, dentro del sprint backlog. Ni el equipo, ni el Scrum Master deben obligar a nadie a hacer una tarea, sino que tiene que ser el propio programador el que elija la que quiere hacer. ¿Por qué? pues sencillamente porque nadie sabrá mejor que el programador las tareas que puede hacer mejor y más rápido. Por lógica, todo el mundo elegirá las tareas que le vayan mejor a sus habilidades y conocimientos, así que poco a poco las tareas se irán asignando de la forma más óptima sin intervención externa (teoría del caos en estado puro :)
Según avanza el sprint, van quedando pendientes las tareas que nadie ha elegido. En ese punto el Scrum Master pude sugerir, pero no obligar.
Hay metodologías que sugieren que las tareas con mayor riesgo deben hacerse antes que las de menor riesgo. Eso tiene su lógica, así que en caso de duda, deberíamos elegir siempre las tareas con mayor riesgo.

¿Que necesitas para avanzar?
Muchas veces, en las empresas tradicionales, las personas que están en puestos de responsabilidad olvidan su principal función: organizar y gestionar el entorno para que sus subordinados pueden trabajar en las mejores condiciones posibles (al fin y al cabo, se trata de maximizar el rendimiento del sueldo que se les paga). Sin embargo, muchos los jefes se quedan con la parte bonita, "organizar y gestionar", olvidándose de para qué se les ha dado ese "poder".

En esta pregunta, el programador lanza un aviso al equipo (y especialmente sobre los que más responsabilidad tienen en el equipo) sobre qué aspectos le tienen bloqueado o deben ser mejorados. El Scrum Master debe hacer lo posible por solucionar esos puntos críticos, aunque si algún otro programador tiene la solución al alcance de la mano, debería decirlo (siempre que haya un buen clima lo hará, pero si hay problemas entre miembros del equipo, no cuentes con que la ayuda surja espontáneamente).

Algunos problemas típicos son:

• temas de programación: "no sé como utilizar la aceleración gráfica en Java". Si estamos en un equipo multidisciplinar (cosa que recomienda SCRUM), es posible que otro programador pueda ayudar o al menos orientar.
• temas de dependencias: "para implementar esta nueva funcionalidad necesito que esté estable el motor de renderización". Normalmente son dependencias que se nos han escapado durante la fase de planificación. Resolverlo es tan sencillo como meter las nuevas tareas en el sprint backlog.
• temas de gestión: "no tengo acceso a la red" o "me estoy retrasando porque cada vez que compilo pierdo 30 minutos". En este caso el Scrum Master debería hacer las gestiones necesarias para solucionar el problema.
  

Algunos problemas puede que se resuelvan facilmente (por ejemplo, añadiendo nuevas tareas al sprint backlog), sin embargo, a veces las cosas se complican.

Si el proyecto está en apuros, lo habitual es que la lista de problemas sea cuando menos generosa. En ese momento, el Scrum Master debe ir recopilando esa lista en un "impediments backlog", o la "pila de problemas". A partir de ese momento, la prioridad del equipo no es avanzar en el "sprint backlog", sino hacer que ese "impediments backlog" desaparezca lo antes posible. Para ello se asignarán los distintos impedimentos a personas del equipo de desarrollo, o incluso a personas fuera del equipo (el administrador de red, el responsable de compras, etc.). Al día siguiente, se revisará tanto el "sprint backlog" como el "impediments backlog", eliminando aquellos impedimentos que se han solucionado, y pudiendose retomar las tareas del sprint que estaban bloqueadas.

Bien, y para terminar, pondremos un ejemplo más o menos gráfico de lo que sería una típica reunión diaria:

- Toñete: Bueno, que sepáis que ya he terminado con la refactorización de los renderizadores.
- Juancito: Perfecto, al final has tardado menos de que esperabas ¿no?
- Toñete: Sí, estaba inspirado y me ha salido de un tirón (:
- Perico (el Scrum Master): Genial, guardaremos esas horas sobrantes para el final del sprint, que nos harán falta.
- Toñete: Hoy voy a empezar a aplicar la aceleración por hardware, aunque la verdad es que no sé ni por donde cogerlo
- Juancito: Yo recuerdo haber leído algo en internet sobre el tema... dame un rato y esta tarde te envío algún código de ejemplo de la clase VolatileImage.
- Toñete: vale tío, muchas gracias. Cuando tenga tu código espero avanzar sin problemas.
- Juancito: Pues yo estoy atascado con el deshacer/rehacer. Está afectando a un montón de módulos y la verdad es que estoy un poco perdido entre tanta clase, herencia y métodos.
- Toñete: quizá te ayudaría usar alguna herramienta de modelado UML, más que nada para que veas las dependencias entre clases y cómo afectará tu cambio.
- Juancito: Sí, quizá sea buena idea... pero no sé cual usar ¿Rational Rose? ¿Together?
- Perico: Creo que en el otro departamento ya están usando alguna. Voy a preguntarles, y si vemos que nos viene bien, gestiono la compra de la licencia para nuestro departamento.
- Juancito: vale... pues entonces mientras consigues eso voy a intentar automatizar las pruebas en los teléfonos móviles.
- Perico: de acuerdo, voy a conseguirte unos cuantos teléfonos para que lo puedas probar en distintas marcas y modelos.
- Juancito: ok, entonces mañana os cuento a ver cómo me ha ido.

El próximo día trataremos el uso de la hoja de cálculo para gestionar el sprint backlog

Etiquetas: agile, SCRUM

Continuemos con nuestra serie sobre SCRUM… tratando el tema de los sprints.

Para ponernos en situación, diremos que el sprint de SCRUM es más o menos lo mismo que la iteración en XP, aunque salvando ciertas distancias.

Podemos definir al sprint como el periodo de tiempo que tiene el equipo de desarrollo para implementar, documentar y probar un conjunto de nuevas funcionalidades (a este conjunto se le suele llamar “incremento”). Al finalizar el sprint, debemos tener una versión lista, empaquetada y con un bonito lazo rojo para entregar a cualquier cliente.

El sprint se divide en tres fases más o menos típicas:

1. - Planificación: una reunión del product owner junto con el equipo de desarrollo para:

• Marcar la duración el sprint: no debería durar nunca más de un mes, con la finalidad de no alargar lo que nunca no se debe ir retrasando: las entregas periódicas. En nuestro caso intentamos hacer sprints de 1-2 semanas, aunque con “trampa”, porque no estamos sacando versiones entregables, sino versiones internas (les falta documentación, pruebas más exhaustivas, etc.). Nuestra asignatura pendiente es hacer sprints “de verdad” de unas 3-4 semanas (quizá con algún cierre intermedio a modo de checkpoint). Tranquilo Juan, estamos en ello (:

• Elegir la funcionalidad a implementar: el product owner irá extrayendo distintas historias de usuario del producto backlog y proponiéndolas al equipo de desarrollo. En ese momento, el equipo puede detectar posibles dependencias entre funcionalidades. En cualquier caso, el equipo de desarrollo estimará en horas de trabajo las funcionalidades a implementar. Por ejemplo:
  
  - Product owner (PO): Bueno, creo que durante este sprint deberíamos tener listo el sistema de deshacer/rehacer para el editor de niveles
  - Equipo de desarrollo (ED): Veamos… la funcionalidad de deshacer/rehacer no es difícil, podemos aplicar una combinación del patrón Command y Memento y lo tendríamos más o menos resuelto. Creo que lo podemos dividir en las tareas: a) Crear clases Command para las distintas acciones del editor de niveles, b) crear la clase Memento para el nivel y c) dar un interfaz gráfico al usuario. Podemos estimarlo en 8, 5 y 6 horas respectivamente.
  - PO: De acuerdo, así que ya tenemos asignadas 19 horas del sprint… por otro lado me gustaría utilizar aceleración gráfica en los renderizadores de niveles... hemos detectado que en cuanto hay muchos objetos en la pantalla va lento.
  - ED: Uy uy... para el carro Manolo… eso ya lo intentamos para los renderizadores isométricos y nos dimos cuenta que antes hay que desacoplar el código … si no, el cambio es tan grande que no hay por donde cogerlo.
  - PO: Ah, vale, no tenía ni idea... o sea, que tenemos que refactorizar el código antes de implementar la aceleración?
  - ED: Sí, hay que crear nuevas clases y probar que los motores funcionen correctamente.
  - PO: Vale, ¿de cuanto estamos hablando?
  - ED: Pues por un lado hay que refactorizar 3 ó 4 clases y hacer las pruebas unitarias, así que un par de días. Y por el otro lado, hay que investigar el tema de la clase VolatileImage y aplicarlo a las clases de renderización, así que ponle otros dos días más.
  - PO: Vale, entonces tenemos 32 horas más, o sea: que tenemos 52 asignadas.
  - ED: OK, ¿algo más?
  - PO: Me temo que la parte de los renderizadores nos va a costar mucho tiempo probarla en todos los teléfonos móviles, así que dejamos 2 días para pruebas y otro más para actualizar la documentación de usuario, así que ya vamos justos de tiempo.
  - ED: Vale, pues se queda así.
  
  Todas las tareas que surjan para hacer durante el sprint se apuntan en una nueva hora de cálculo llamada “sprint backlog”. En esta hoja ya no apuntamos las funcionalidades a cubrir (historias de usuario), sino que las transformamos en tareas concretas (refactorizar X, investigar Y, etc.).
  En el sprint backlog iremos apuntando las horas que faltan para terminar las tareas (en este punto, quedan tantas horas como la estimación que hemos hecho).

2.- Implementación: una vez que tenemos el “sprint backlog” completado, podemos empezar el desarrollo. Se acuerda por ambas partes (product owner y equipo) que hasta que no se termine este sprint no se podrán “colar” nuevas funcionalidades. Si surge una nueva necesidad, se apuntará en el product backlog y en la planificación del próximo sprint se tendrá en cuenta.
Todos los días del sprint se hará una reunión (llamada “daily meeting”) del equipo para ir revisando cómo va el trabajo y actualizar el sprint backlog. El próximo día trataremos este tema.

3.- Revisión: una vez terminado el sprint, se reúnen el product owner, el equipo y cualquier persona interesada (por ejemplo gente de marketing, clientes, etc.) y se hace una demo informal de la nueva funcionalidad (llamada “incremento”). En esta revisión pueden surgir nuevas funcionalidades que serán apuntadas en el product backlog.

Por otro lado, se reúne el equipo de desarrollo consigo mismo, y saca dos conclusiones:

1. ¿Que nos ha ido bien y debemos repetir?
   
2. ¿Qué nos ha ido fatal y debemos mejorar?

Por ejemplo:
- Toñete: me da la sensación que en este sprint la hemos cagao con el tema de las pruebas de los nuevos renderizadores
- Juanín: sí, ha sido un infierno, pensé que no se acababa nunca.
- Toñete: en cuanto podamos deberíamos investigar cómo automatizarlo. Habrá cosas que no se puedan, pero seguro que hay alguna forma de automatizar aunque sólo sea una parte.
- Juanín: sí, lo apunto para colarlo en el próximo sprint.
- Toñete: por cierto, lo que sí que ha ido muy bien es el prototipo para probar lo de deshacer/rehacer
- Juanín: sí, menos mal que lo hicimos, porque yo no tenía ni idea como combinar los patrones Command y Memento. Una vez que tuve el prototipo, no fue más que aplicarlo al resto de casos.
- Toñete: pues para la próxima ya sabemos…

Bien, el próximo día hablaremos sobre cómo es el día a día de la implementación de un sprint y el "daily meeting".

Etiquetas: agile, SCRUM

Ayer hablamos del product backlog, o en castellano: pila de producto. Bien, la persona encargada de llevar a buen puerto este documento es el que SCRUM llama product owner, o para nosotros el propietario del producto. En realidad no se trata de una persona tal cual, sino que estamos hablando de un rol, que en nuestro caso lo adoptamos dos personas a tiempo parcial (Jaime y yo mismo), aunque podría ser una persona a tiempo parcial (lo más habitual) o en proyectos muy grandes, una o varias personas a tiempo completo (ojo, SCRUM no encaja en proyectos grandes, así que si estás en este caso piénsatelo dos veces antes de empezar).

Bueno, pues el(los) propietario(s) del producto deben tener una visión clara del producto a construir (Jaime la tiene, y yo lo intento :), debe(n) saber bien qué se debe implementar, y sobre todo lo que NO se debe implementar.
Por cierto, suele ser más difícil de distinguir lo que NO se debe implementar, ya que parece ser que el 45% de las funcionalidades implementadas nunca llega a usarse. Por otro lado está la teoría del 80/20, donde dice más o menos (traducción libre de las mías):

A muchos desarrolladores les seduce la idea de la teoría del 80/20. Parece que tiene mucho sentido: el 80% de la gente usa el 20% de la funcionalidad. Así que te convences a ti mismo de que sólo necesitas implementar ese 20% de funcionalidad para seguir vendiendo el 80% de las copias. Por desgracia, no siempre es el mismo 20%. Cada usuario usa un conjunto de funcionalidades distinto. [...]

Pero esto es otra historia y debe ser contada en otra ocasión...

Bien, como decíamos, el product owner debe tener una idea clara de la dirección del proyecto, manteniéndo al día y priorizada la pila del producto. No se trata de pasarse meses analizando las necesidades reales y sacar la cojo-pila (también llamdo mega-análisis o super-especificación), sino trabajar unos días para sacar la cantidad de funcionalidad suficiente para cubrir la primera versión (algo que pueda funcionar), y a partir de ahí, añadir cosas.
Lo de siempre: el movimiento se demuestra andando.

Esta figura se parece más o menos al "cliente" que pregonaba eXtreme Programming, donde era la persona que colaboraba con el equipo en redactar las famosas historias de usuario, y que decidía lo que se iba a implementar en cada iteración de desarrollo.

Una vez que la versión está implementada, el propietario de producto la revisará para ver si ha cumplido con las expectativas que él tenía sobre ella... es decir: ver si las funcionalidades que él propuso como útiles y necesarias, realmente lo son (que a veces no lo son).

Cuando el propietario del producto tiene su pila más o menos preparada, colaborará con el equipo de desarrollo para definir la pila del sprint... así que ya tenemos carrete para el próximo día, donde hablaremos de los sprints (:

Etiquetas: agile, SCRUM

Bien, una vez hecha la introducción, vamos a tratar los distintos aspectos de SCRUM, siempre explicando cómo los hemos abordado en Unkasoft y qué problemas hemos tenido (y seguimos teniendo) a la hora de usarlos.

El primer elemento que tratamos de implantar fue el Product Backlog, o pila de producto: se trata de una lista de funcionalidades que debe llegar a tener el producto que estamos desarrollando. En teoría, cuando implementemos todas esas funcionalidades, el producto estará acabado (ya, a ver cuando llega eso, porque yo no lo tengo claro).

Este paso a sido fácil para nosotros, porque hace tiempo que usábamos un documento (que llamábamos "problemas a resolver") donde íbamos apuntando todas las cosas que nos gustaría que tuviera Battlewizard. Este documento lo íbamos ampliando con nuestra propia experiencia, peticiones del departamento de QA, o de empresas que están usando Battlewizard (como nuestros early adopters GPM-e y Karonte).
Adaptarnos a SCRUM a sido tan sencillo como convertir el documento en una hola de cálculo, incluyendo los títulos de las nuevas funcionalidades y con una explicación breve en forma de comentarios. En la propia hoja de cálculo hemos organizando las características en cuatro categorías conforme a la urgencia de implementarlas: muy alta, alta, media y baja.

¿Y para qué nos está sirviendo esto? Pues sencillamente para no olvidarnos de nada y para tener un sitio de consulta cuando queramos saber qué hay que hacer y qué es más urgente. Además, este documento es el punto de partida a la hora de planificar una versión.
Una vez que hemos implementado una característica, la borramos de la pila de producto, y así poco a poco va decreciendo (bueno, en realidad no ha parado de crecer desde que la hemos creado, añadimos más funcionalidades de las que nos da tiempo a implementar, pero con el tiempo y una caña... :)

La persona encargada de mantener este documento es el llamado "propietario del producto" ("product owner") y su función es... bueno, creo que ya está bien por hoy, así que el próximo día hablaremos del propietario del producto...

Etiquetas: agile, SCRUM

Este verano está siendo movidito.
Estamos restructurando el equipo (alguno ya han llegado, y otros están por venir), salida a la calle de dos juegos más (todavía no podemos decir nada sobre ellos pero pronto publicaremos algo aquí sobre ellos) y probar una nueva metodología de gestión de proyectos: SCRUM.

Hace ya tiempo veníamos usando eXtreme Programming como metodología de desarrollo, sobre todo en el equipo de Battlewizard, pero la parte de planificación, gestión y seguimiento de los proyectos la teníamos un poco descuidada. Así que con la ayuda de Juan Palacio nos hemos puesto en marcha y ya vamos por nuestro sexto sprint (:

¿En qué consisten SCRUM? Pues es una metodología de autogestión de equipos, es decir: no hay un jefe que ordene y los demás obedezcan, sino que el propio equipo es el que tiene que auto organizarse.
Bueno, esto de promulgar la autogestión está muy bien, pero tienes sus problemas. No intentes aplicar esta metodología en cualquier sitio, porque yo conozco algunas empresas y algunas personas con las que esto sería un fracaso asegurado.

Justo hace un par de días Joel Spolsky ha publicado unos artículos sobre gestión de equipos, y en ellos cataloga los tipos de gestión típicos las empresas en tres: (como siempre, te recomiendo que lo leas porque no tiene desperdicio):

• Orden y mando: el jefe dice lo que hay que hacer y cómo hay que hacerlo y los subordinados obedecen. SCRUM no cabe aquí, porque promulga justo la filosofía contraria: se intenta que no haya una figura que ordene, sino que sea el propio equipo que se auto-ordene.

• Motivación externa: se intenta motivar a la gente con factores externos, como premios, primas económicas, etc. Tampoco nos vale SCRUM en este caso, porque tendremos gente más preocupada de conseguir los premios que de buscar la mejor forma de organiza su trabajo.

• Identificación: la idea es identificar a las personas con la filosofía de la empresa, ser transparentes con objetivos, logros, etc. y una vez que la gente sabe lo que hay, darles autonomía y esperar a que la autogestión surga espontaneamente. Todo esto está muy relacionado con la teoría del caos (!!) donde un sistema complejo, compuesto por muchos agentes individuales (como la economía mundial, un hormiguero o una empresa), actúa de una forma coherente y óptima si dejas a los agentes individuales que actúen de forma independiente.

Así que el primer consejo: no intentes aplicar SCRUM en cualquier sitio. Primero haz que se respire un clima adecuado y cuando tengas el caldo de cultivo, todo será más fácil.

A continuación tenéis nuestra experiencia sobre algunos elementos de SCRUM que estamos usando en nuestro trabajo diario:

• El product backlog
• El product owner
• El sprint
• El daily meeting
• El sprint backlog
• SCRUM y eXtreme Programming
  

Etiquetas: agile, SCRUM

Durante los años 70 y 80, las compañías definieron sus estrategias con base en ideas de grandes “gurús” como Kaplan y Norton, quienes marcaron objetivos exponenciales de crecimiento basados en economías de escala. Todos estamos de acuerdo que el mercado de los videojuegos es muy goloso, pero ¿quién se llevará al final el pastel?

Me he tomado la osadía de crear un mapa estratégico –inspirado por toda la info de América-, que indique gráficamente los siguientes comentarios. La principal idea es compartirlo, que sea útil a todos los que quieren participar –para los escépticos de estratégica distinta a la pura competición leed el siguiente post sobre 'Strategy of the Dolphin' -

• La base es la perspectiva de crecimiento y aprendizaje, siempre será el motor de nuestra compañía. Nuestro capital más importante, las personas que se han introducido con nosotros en esta aventura, en todo momento deben liberar su creatividad. En el mundo empresarial, abundan las empresas en las que el equipo no conoce la estrategia que se quiere llevar a cabo. O que si la conocen, no se comprueba que este se llegue a ejecutar. Esto último es crítico, así como mantener medidas que nos indiquen si estamos en el buen camino, sin mediciones no hay avance.

• En la perspectiva interna es importante considerar los aspectos operacionales como es el control de gastos, parece ridículo decirlo, pero conozco muchos casos en que lo olvidamos tan pronto comenzamos. Nuestro mercado, curiosamente, la calidad del producto creado es algo valorado a posteriori, el usuario no verá lo que tiene hasta descargarlo –tal vez tengamos que potenciar esta idea-. Hemos vivido muchos casos de juegos con marcas conocidas, que el usuario descarga y la calidad era pésima. Las marcas son necesarias, las personas las asociamos a la calidad, pero incorrectamente desgastará ese mercado. Innovar, la base del siglo XXI, debemos buscar juegos e ideas más originales. Todo esto cruzado con la correcta comunicación, nos pondrá rumbo al éxito.

• La perspectiva de cliente, es sin duda la que muestra los resultados del trabajo realizado. Me lanzo a diferenciar dos “clientes”, el primero es el publicador u operador de telefonía, que publica el juego móvil. Estos se han optimizado bastante, al menos lo observado en España. Saben exactamente el público objetivo, qué es lo que quieren y cuando. Demandan juegos de calidad y con marcas conocidas, todo ello entregado a tiempo, aprovechando lanzamientos de películas o libros. El despliegue y publicación hasta ahora ha sido especialmente tedioso para los publicadores, es un punto que retrasa la llegada al mercado de los productos. Por otro lado, hace falta buscar nuevas ideas que permitan ventas a precios más bajos (juegos con publicidad, contenido extra descargable por el usuario, etc.). El usuario final –perdón, sé que el Cluetrain Manifesto prohíbe decirlo así-, está buscando contenido bueno, a un precio asequible, claro y que no requiera 3 o 5 mensajes para lograrlo.

• En el aspecto financiero debemos controlar los gastos, usar herramientas por ejemplo que nos simplifiquen las tareas de portado a varios teléfonos móviles. Diversificar la entrada de ingresos. Aso como buscar nuevas vías de ingresos distintas a las tradicionales.

Todo esto lleva a una visión, ser un referente en la producción de juegos móviles y diferenciarse no por coste. Aunque suene cliché, lo que importa no es la cantidad sino la calidad. Al final con todo ello lograremos crear valor a los que confiaron e invirtieron en nosotros.

Etiquetas: Juegos móviles

Hablando con varios desarrolladores de videojuegos para móviles siempre terminamos haciéndonos la misma pregunta: ¿Cuál es la diferencia entre el fracaso y el éxito con los videojuegos para móviles? Finalmente, el mercado y las limitaciones técnicas responden a esa pregunta con bastante frialdad.
Hoy en día el éxito pasa por lograr destacar con alguno de los videojuegos desarrollados, donde destacar debe definirse como un éxito de ventas que sobresalga respecto al coste de producción.
Si seguimos al mercado, debemos buscar los éxitos de ventas entre las marcas conocidas y de moda, y lógicamente el ahorro de costes de producción se basa sobre todo, dentro de este mercado, en la deslocalización de los recursos humanos encargados de portar cada juego a cada tipo de teléfono móvil. El éxito consistiría entonces en tener una marca conocida y de moda, desarrollar un videojuego sobre dicha marca y tener un coste de producción bajo. El fracaso entonces debería considerarse como la falta de marca y una imposibilidad de portar los juegos a muchos móviles de manera asequible.
Como mensaje del mercado y de las limitaciones técnicas es una respuesta asumible y lógica, pero no es suficiente para nosotros. Vamos a cambiar el concepto de éxito introduciendo nuevas variables. Ahora creemos que el éxito, pasa por automatizar el proceso de portar los videojuegos entre los teléfonos móviles, un coste casi nulo, y el disponer de juegos divertidos, simples y fáciles de manejar. Buscamos la comodidad del desarrollador, del distribuidor, del agregador, del operador y en definitiva la diversión del jugador. Si somos capaces de hacer y empaquetar un juego divertido en dos semanas con un coste de producción de unos 2.000 €, y luego tenemos ingresos en unos quince países por un valor total de unos 10.000 €, entonces habremos logrado un éxito, porque habremos obtenido una alta rentabilidad.
No hace falta abocarnos a la marca de éxito, sino adaptarnos a la capacidad del mercado para pequeñas empresas como nosotros; debemos automatizar procesos y crear en paralelo los videojuegos. 10 Juegos casuales al mes para un catálogo de empresa, obteniendo unos 10.000 € como objetivo por videojuego y teniendo unos gastos medios de 2.000 € por juego, harán del pequeño desarrollador una empresa de éxito.
Esto no quita disponer de personal creativo que sea capaz de hacer juegos llamativos y divertidos. Si no tenemos presupuesto para publicidad, dejémoslo a los distribuidores y agregadores, por poco que distribuyan y se muevan, algunas descargas obtendremos y podremos rentabilizar el trabajo.
Seguimos apoyando los juegos de calidad, de marcas conocidas haciendo calidad, pero mientras una pequeña empresa es capaz de hacerse con un juego de calidad y con marcas conocidas y de moda, ha de generar catálogo y generar ingresos. Automatizad los procesos o pedid ayuda a los que los estamos automatizando, es parte del camino para avanzar en este mercado.
El éxito total, será sacar videojuegos de marca con un coste asequible de producción.

Etiquetas: Juegos móviles