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