On dit qu'à deux, on est mieux, à trois, on est plus nombreux. Mais il s'avère que deux développeurs ne peuvent pas construire un produit à eux seuls (un projet, peut-être, mais pas un produit). Après que Whale Seeker a accueilli avec enthousiasme notre troisième développeur il y a quelques mois, deux choses sont devenues claires pour moi (en tant que deuxième) : le premier changement était que nous pouvions faire beaucoup plus - et pas seulement parce que nous avions une autre paire de mains : les trois d'entre nous pouvaient s'aider mutuellement à se débloquer plus rapidement ("avez-vous essayé..."). Nous avons tiré pleinement parti de cette dynamique en organisant des stand-ups - de courtes ( !) réunions quotidiennes chaque matin qui nous permettent de sortir des ornières dans lesquelles nous nous sommes peut-être enfoncés l'après-midi précédent, et de poursuivre notre chemin.
Mais un autre saut tout aussi notable s'est produit dans la difficulté de se coordonner les uns avec les autres. L'équipe technique est passée d'un seul canal de communication à trois, et l'effort mental nécessaire pour savoir qui effectuait quels changements est monté en flèche. Quelques outils se sont avérés utiles pour atténuer ces difficultés de croissance et nous ont permis de mieux profiter des avantages d'une équipe élargie.
Le premier est le suivi des tâches. En tant que startup relativement petite, où chaque semaine de travail est souvent un terrain inconnu, nous ne pensons pas qu'il soit productif d'imposer des délais trop stricts pour les tâches - mais il est extrêmement utile d'avoir une présentation claire de qui fait quoi à un moment donné, et combien de temps les choses prennent. J'aurais aimé disposer d'un tel outil à l'université. - Ne serait-ce que pour répondre à l'éternelle question : "J'ai résolu ce bug.... maintenant pourquoi est-ce que je le refaisais ? Le suivi des tâches est une excellente extension de la faible mémoire humaine, à long terme comme à court terme : au début de chaque semaine, nous passons en revue les progrès de la semaine précédente et répartissons les nouvelles tâches en fonction de notre capacité. En prime, lorsqu'il s'agit de remplir une demande de subvention ou de se rappeler ce que nous avons fait pour quelque raison que ce soit, c'est facile.
Le deuxième outil, un peu moins facile, qui nous aide à nous développer est l'intégration continue (IC). Avec un plus grand nombre de développeurs, les risques que mon code se mélange à celui de quelqu'un d'autre sont plus élevés. Depuis le premier jour, notre directeur technique, Antoine Gagné, s'est engagé en faveur d'un développement piloté par les tests, mais s'assurer que nos tests sont exécutés et mis à jour régulièrement est un problème qui ne fait que s'étendre au fur et à mesure que l'équipe et la base de code se développent. L'IC consiste à réduire l'intervalle pendant lequel les développeurs ont leur copie de travail du code séparée de la branche principale ("fusionner" plus souvent). Pour y parvenir efficacement, tout en maintenant la branche principale propre et fonctionnelle, nous automatisons le processus de test des modifications entrantes, afin qu'elles ne puissent pas être fusionnées si elles cassent quoi que ce soit d'autre dans l'ensemble de la base de code. Cela s'est avéré plus délicat que nous ne l'avions pensé au départ, en partie à cause des défis uniques posés par l'intégration des méthodes traditionnelles de développement de logiciels avec l'apprentissage automatique, où le succès est une cible mouvante - mais il s'agit d'un autre article en soi ! Quoi qu'il en soit, il est clair que la mise en œuvre de l'IC est la seule façon d'aller de l'avant alors que notre équipe et notre base de code continuent de s'agrandir. Si deux, c'est de la compagnie, et que trois, c'est une foule, nous ne pouvons qu'imaginer le fox-trot de grappes que sera le quatrième ! Mais nous serons prêts.
L'un des derniers défis de la croissance a été de faire en sorte que tout le monde soit sur la même longueur d'onde. À quoi ressemblera notre produit dans six mois ? Dans un an ? Quelles sont les priorités et quelles sont celles qui doivent être mises de côté ? Ce sont des questions sur lesquelles nous avons tous quelque chose à dire. Nous laissons la place à ce type de dialogue en complétant les réunions quotidiennes par deux réunions hebdomadaires de l'ensemble de l'équipe. Pour moi, ces réunions ont pour objectif supplémentaire de me rappeler à quel point le travail que je fais est génial. Lors de ces réunions, l'équipe non technique est informée des défis techniques et l'équipe technique est informée des défis et des opportunités commerciales. C'est une chose de déboguer son code (légère poussée d'endorphine, on passe au prochain bogue), mais c'en est une autre de prendre du recul et de se rappeler à quoi tout cela sert : aider une industrie à réduire la menace qu'elle fait peser sur certaines des espèces sauvages les plus vulnérables de la planète. Je quitte souvent nos réunions du vendredi avec un tel enthousiasme qu'il m'est presque difficile de m'installer pour le week-end !