Blog

Belike es una empresa que desarrolla software y aplica metodologías SCRUM con ese objetivo. Tanto sus propuestas comerciales, como los contratos que firman con sus clientes están redactados siguiendo los principios ágiles. Como bien explican, no tendría mucho sentido escribir un contrato con un alcance súper acotado y posteriormente trabajar bajo el paraguas de la flexibilidad máxima (o viceversa). Ellos piensan que es preferible que sus contratos reflejen lo más fielmente posible el modelo de desarrollo que posteriormente siguen.

A continuación, se resume el proceso ágil que sigue Belike en sus proyectos de desarrollo de software a medida. En concreto, se trata de una foto real del método que utilizan para la construcción de un sistema software de tamaño considerable (+3.000 horas de desarrollo).

Según ellos, consideran imprescindibles los siguientes roles:

• Product owner: 1) es el responsable operativo máximo del proyecto en el cliente. Operativo, no ejecutivo, es decir, un perfil con capacidades tanto técnicas, como de gestión, capaz de aglutinar y transmitir las necesidades funcionales, técnicas y organizativas del cliente, 2) es la cabeza visible del proyecto en el cliente, 3) requiere una alta dedicación al proyecto, 4) participa en el día a día del desarrollo.
• Technical leader: 1) Es el responsable operativo en Belike, 2) coordina los trabajos de desarrollo, y es el interlocutor principal del proyecto en el día a día.
• Executive manager: Existen dos personas con este rol: el responsable ejecutivo del proyecto en el cliente y su homólogo en Belike.

Una vez hemos identificado los roles imprescindibles, estos son los ingredientes principales de la metodología ágil que sigue Belike:

1. Comunicación directa tanto interna, como con los clientes y proveedores: Para esto se apoyan 100% en herramientas colaborativas, principalmente, Trello, Slack, Google Drive, Google Hangouts o Skype. Crean canales en Slack por distintas temáticas y asuntos, de esta manera tanto los chat, como los documentos que intercambian siguen el canal adecuado y llegan a las personas interesadas. En Trello configuran un Kanban Scrum que adaptan totalmente a las condiciones del proyecto.
2. Software funcionando a diario: El cliente debe poder probar los cambios que se están realizando a diario, y casi podría decirse que “en vivo”. De esta manera, obtienen el feedback diario del product owner. Para ello siguen dos estrategias muy conocidas dentro del agilismo: (a) Integración Continua (integraciones automáticas continuas de compilación y ejecución de pruebas, permiten detectar fallos cuanto antes), (b) Entrega Continua (amplía la integración continua, desplegando los cambios en código en un entorno de test y/o producción). Las herramientas que utilizan para llevar a cabo estas dos estrategias son múltiples, pero las dos principales son jenkins y shippable. Ambas estrategias permiten disponer de un entorno de test donde el cliente y el equipo pueden probar los cambios que acaban de confirmarse por los programadores, promocionando dichos cambios al resto de entornos una vez estén aceptados, de una manera ágil, eficiente y segura, además de automática.
3. Maximizar el tiempo de programación: En este punto son bastante estrictos. Cuanto más tiempo están en reuniones, menos tiempo están programando. Por tanto, minimizan las horas de reunión. ¿Y cómo lo hacen? pues básicamente así: (a) Cuando hay que decir o preguntar algo a alguien, se hace y punto. No montan una “reunión” para cualquier asunto que se podría solucionar hablando/chateando, (b) En las reuniones de periodicidad diaria van al grano, además de optimizar quién debe o no estar en esa reunión. Por eso mantienen dos daily meetings, una entre el Product Owner y el Technical Leader, donde el equipo de desarrollo no está (salvo que sea requerido algún programador en concreto) y otra con el equipo de desarrollo. En la primera suele haber más asuntos que debatir, con lo que sacan a los programadores de este debate salvo que sea necesario.

Fuente: BelikeSoftware.com

Una empresa que ha sabido adaptarse perfectamente a las metodologías ágiles es Spotify, haciendo especial hincapié en la figura del Scrum Master. En el blog de iebschool.com, podemos leer los detalles de este ejemplo, del que nos hacemos eco a continuación.

Spotify era consciente del dinamismo de su competencia (Google o Apple por ejemplo), por lo que decidieron acercarse al Scrum de forma muy sistemática. Compitiendo contra semejantes corporaciones, sabían que en cualquier momento podrían ser derrotados a menos que fuesen más rápidos, más baratos y mejores.

Es por eso que han tenido que mejorar sus equipos de trabajo para asegurarse que van más rápido. En Spotify los equipos se organizan por “escuadrones” (squads), pequeños equipos de Scrum con la habilidad de implementar el software desarrollado al final de cada sprint, sin romper ningún otro equipo. Una característica curiosa del funcionamiento de Spotify es que cada uno de estos pequeños grupos tiene una parte del producto que es totalmente suyo. Después crean “tribus” (tribes) agregando distintos escuadrones.

Guillermo Ruiz, de babel.es, entra en detalle sobre cómo funciona esta estructura de “escuadrones + tribus”:

Los Squads son las unidades básicas de desarrollo. En terminología Agile sería un equipo Scrum e igualmente la composición ideal sería entre 6 y 8 personas trabajando de manera conjunta como si fuese una pequeña startup. Los Squads están compuestos por perfiles diversos desde el Product Owner, el Scrum Master y los ingenieros de software. Spotify dota a las personas del Squad de autonomía lo que fortalece la motivación de las mismas. Los Squads, a su vez, se agrupan en organizaciones más grandes de acuerdo a ámbitos relacionados. Estas agrupaciones de Squads se denominan Tribus –tribes-. En el caso de Spotify estos ámbitos funcionales son la app de iOS, de Android, la plataforma de infraestructura, etc. El tamaño de cada tribu puede oscilar desde las 40 hasta las 120 personas. (…) Cada tribu tiene su propio líder. Este rol recibe el nombre de Tribe Lead. El Tribe Lead es el responsable de dotar a todos los Squads del entorno adecuado favoreciendo el soporte mutuo entre Squads y definiendo el objetivo y la visión de la tribu, definiendo sus prioridades y gestionando el tamaño adecuado de la Tribu dentro del presupuesto asignado.

Aun así, Spotify necesita implementar, cambiar y actualizar su código constantemente sin romper nada más. Para ello es necesaria una buena coordinación central de la compañía.

Si quieres ser rápido también es necesario deshacerse de todas aquellas partes del proceso que entorpezcan el avance. En Spotify, por ejemplo, contaban con un equipo de operaciones que se encargaba de las implementaciones, pero el funcionamiento era demasiado lento. Por eso decidieron eliminar esta fase y hacer que los propios desarrolladores implementasen sus trabajos.