Características de Branch Agile

Las principales características de nuestro marco de trabajo

El Manifiesto Ágil de metodologías comprende cuatro valores centrales y 12 principios para el desarrollo de software. Existía entre ellos un enfoque llamado Crystal, de la que nosotros adaptamos porque en el peor de los casos genera pocas perdidas ya que contempla los riesgos y complejidad

Al adaptar la metodología de desarrollo a Diseño, agregamos caracteristicas y las llamamos Branch.

Los orígenes de Crystal
A principios de la década de 1990, Alistair Cockburn trabajó en IBM y se le encomendó la tarea de desarrollar una metodología. Entrevistó a equipos exitosos y aunque no seguían una metodología formal, compartían algunas formas comunes de trabajar, a partir de esta investigación, construyó una familia de metodologías, y las llamó Crystal.

Llamó a los enfoques tomando cristales geológicos, mientras mas duras (oscuras) reflejan un enfoque más rígidos y estructurados dependiendo el tamaño del equipo, criticidad y prioridad del proyecto.

Por el contrario, el enfoque más orgánico se llamó Crystal Clear, orientado a equipos de 1 a 6 personas, donde en el caso que fallé el proyecto le costará a la empresa solo un poco de dinero no esencial.

Crystal Clear
Tiene como roles mínimos al Patrocinador, Diseñador Senior y Programador, donde todos trabajan juntos con el canal de comunicación de su libre elección, y diseñador juega el rol principal de tomar decisiones técnicas.

Los roles del gerente de proyecto, analista de negocios, tester, etc. son compartidos entre todos los miembros del equipo, y los proyectos deben tener una iteración máxima de 60 a 90 días, obviamente pueden ir tan rápido como gusten.

Las 7 propiedades de Crystal
Encontré interesante los 7 principios de Crystal, donde solo las primeras 3 son obligatorias:

1. Entrega Frecuente:
   La propiedad más importante, entregar con frecuencia código probado y funcional a usuarios reales. Si no hace esto, corre el riesgo de descubrir demasiado tarde que ha producido un producto que nadie necesita.
2. Mejoramiento reflexivo:
   Por muy bueno que sea el equipo, siempre puede mejorar. trabajar juntos para descubrir cómo mejorar sus prácticas laborales futuras.
3. Comunicación osmótica:
   La ósmosis es una forma de aprendizaje pasiva y sutil por absorción. al estar muy integrados los proyectos pueden operar con muy poca estructura.
4. Seguridad personal:
   Todos los miembros del equipo deberían poder hablar sin miedo al ridículo o las represalias, ya sea una idea nueva, preocupación o problema que encuentren, donde mostrar desacuerdo es saludable. Este tipo de entorno permite a los equipos resolver sus problemas y mejorar el rendimiento.
5. Enfoque:
   Saber en qué trabajar y hacerlo. Esto sugiere comunicación clara, priorización de requisitos, establecimiento de objetivos, etc. También significa preferir el “super tasking” sobre “multi tasking”
6. Fácil acceso a usuarios expertos:
   Cultura, lenguaje y procesos análoga a usuarios reales y consultores.
7. Pruebas automatizadas, configuración e integración frecuente:
   integración continua para que los errores pudieran detectarse en cuestión de minutos.

Los aportes de Branch
Las adaptaciones y características que usamos para el contexto de diseño:

1. Efectividad:
   Es la matriz de energía sobre tiempo, intentando buscar rutas que por el tamaño del equipo economicen energía y amplíen resultados, lo que permite que el equipo gane, pueda comunicar que rutas trajeron aprendizaje y genera utilidad y competitividad.
2. Destreza:
   Los roles se definen orgánicamente por proyecto, mientras que en determinado proyecto puedes ser diseñador senior, en otro puedes ser el gerente de proyecto, dependiendo la destreza que se necesite.
3. Propósito:
   Es lo que determina tu lugar en la organización, por sobre las habilidades que posea cada uno, se necesita estabilidad en el equipo, y eso solo lo da insertar a personas que corren hacia la misma dirección, la salida de un colaborador representa un riesgo incluso económico.
4. Ramas:
   No contemplamos iteraciones completas como unidad de entregable, sino cada hilo, rama o proceso, y la facturación es por horas, no por el desarrollo final
5. Git vocabulary:
   usamos la terminologia de Fork, request and merge para poder comunicarnos tanto en diseño como en desarrollo.

En general este artículo, esta orientado a los colaboradores de nuestra red de trabajo para tener una comunicacion clara sobre los procesos y cómo cada unidad ejecuta o deriva una tarea, como siempre consideramos nuestra organización una beta constante y sientase libre a refactorizar las cosas.

Jose Aljovin — KGDM Vision carrier.