En SlashMobility no nos cansamos de repetirlo: trabajamos bien y nos lo pasamos mejor. Sin embargo, en la actualidad no basta con ser eficaces, sino que también es necesario ser eficientes. El mundo del desarrollo de apps nos impone tanta competitividad que no basta con terminar el trabajo a tiempo, sino que además, hay que terminarlo usando el menor número de recursos posibles, con el menor número de defectos en el código fuente y haciendo un deploy limpio y sin impacto en el cliente. Entonces, ¿Cómo podemos actuar? ¿Qué herramientas podemos usar para mejorar en nuestros procesos de desarrollo de apps? Hoy veremos una propuesta en base a la experiencia del equipo de SlashMobility y los proyectos en los que estamos involucrados.
1. El código
La propiedad más básica y fundamental de un desarrollador y, por ende, de una empresa dedicada al desarrollo de apps es el código fuente. Actualmente, es muy común encontrar empresas de desarrollo de software con equipos usando metodologías ágiles, que no comparten la misma oficina o que, de hacerlo, no siempre en el mismo horario. ¿Cómo podemos mejorar en los procesos de desarrollo en un equipo multidisciplinar y distribuido? El primer paso es usando un repositorio de código fuente: GIT. El uso de GIT nos va a permitir:- Organizar el código fuente
- Poder integrar el trabajo de diferentes desarrolladores/equipos
- Poder hacer rollbacks
- Organizar los deploys
No obstante, la principal diferencia de GIT con respecto a alguno de sus hermanos como Subversion, es el uso continuado de branches o ramas en repositorios locales y remotos. Nosotros organizamos nuestros proyectos en dos ramas fundamentales: rama master donde se encuentra el código fuente del día a día; y la rama stable, donde se encuentra el código estable, es decir, el que resulta de preparar un entregable o delivery.
Además, usamos ramas locales o remotas para cada uno de los sprints que implementamos. De esta forma, usamos el paradigma «divide y vencerás» para minimizar el impacto de los merge entre ramas. Así, en el peor de los casos, habría que integrar dos ramas de un mismo sprint. En otro caso, si por ejemplo queremos integrar la rama master con una rama temporal de una nueva funcionalidad sin hacer esta división de ramas por sprint, deberemos afrontar la resolución de conflictos en el contexto del proyecto entero ya que en master podremos encontrar cambios realizados en todo el ámbito del proyecto por todos los integrantes del equipo de proyecto.
2. Organizar bien el trabajo con JIRA
Sin duda hay muchas herramientas que hacen algo similar a JIRA pero, por su facilidad de uso, integración y potencia, en SlashMobility es la que recomendamos usar. Esta herramienta tiene un doble propósito:
- Por un lado establecer las tareas según la metodología: en nuestro caso usamos historias de usuario, épicas y sprints.
- Llevar un control de defectos exhaustivo con un test plan incrementa.
Además, JIRA dispone de un plugin nativo que permite gestionar el proyecto usando metodologías ágiles, lo que facilita establecer tareas siguiendo una pizarra de seguimiento Kanban o Scrum (todo, in progress, done). Esto favorece que los integrantes del equipo de desarrollo sepan en todo momento qué tienen que hacer y qué queda por hacer. El uso de esta herramienta varía un poco en base a la metodología elegida.
La gran potencia de esta herramienta es que te permite generar un test plan por cada una de las historias de usuario de cada sprint. De esa forma, y de forma regresiva, se va probando todo el desarrollo de sprint a sprint haciendo que cada sprint review (demo) esté libre de defectos, al menos funcionales.
3. Un poco de documentación: WIKI
Cuando se trabaja en equipos distribuidos y usando tecnologías que cambian cada semana, como es el caso del desarrollo de apps, es importante tener documentado todo con el mayor detalle posible. Además, de la documentación en el propio código fuente que todo desarrollo de app debería tener, en SlashMobility usamos una wiki para gestionar todo el conocimiento de la empresa de forma colaborativa. De esta forma, cuando es necesario recuperar, por ejemplo, cómo implantamos una conexión SSL usando métodos REST o cómo certificamos una app para Apple, toda la empresa puede tener acceso a este conocimiento.
No obstante, nuestra intención con la wiki va más allá. En SlashMobility hacemos partícipes de este conocimiento y colaboración a nuestros propios clientes. Así, los análisis o especificaciones de requisitos, actas, y demás documentación colaborativa con el cliente la gestionamos a través de la wiki. En el 100% de los casos probados con nuestros clientes, éste punto ha sido un éxito.
4. ¡Comunicación!
Como no podía ser de otra forma, por muy cohesionado esté el equipo, siempre hay stakeholders o incluso stoppers de identificación temprana que requieren que el equipo esté en constante comunicación. En SlashMobility usamos SLACK con un doble propósito:
- Chat en grupos y rooms en función de funcionalidades y tecnologías
- Integrado con JIRA
Esta segunda característica permite a todo el equipo recibir una notificación sobre cuando hay algún cambio en alguna historia de usuario y si se ha desbloqueado alguna tarea. Esto agiliza bastante los procesos de control diarios o sprint daily meetings.
5. ¿Cómo mezclo todo para que salga algo decente? SCRUM
De entre la variedad de metodologías ágiles, SCRUM es la metodología que más se adapta a nuestros equipos y proyectos. La hemos adaptado a las herramientas que usamos y a la forma de trabajar de todos nuestros equipos con un gran éxito en nuestros indicadores y procesos internos.
Como conclusión, podemos afirmar que formas de trabajar hay muchas pero lo mejor es seleccionar una metodología y un conjunto de herramientas que se ajusten al equipo y proyectos, el desarrollo de apps en nuestro caso, según su naturaleza y forma de ser. Lo más importante de una metodología es poder aplicarla y adaptarla porque si no, ¿de qué sirven los papeles?
Autor del post: Fco. Javier Fernández (@fjfcarrera), CAO de SlashMobility
