Avant d'utiliser Signals, la planification des sprints ressemblait souvent à des suppositions, et à mi-parcours, les choses commençaient à s'effondrer. Je ne remarquais pas des problèmes comme trop de pull requests (PRs) ou des membres de l'équipe surchargés jusqu'à ce qu'il soit trop tard pour les résoudre. Avec Signals, je reçois des alertes instantanées lorsque quelque chose ne va pas, comme des PRs qui s'accumulent ou quelqu'un ayant trop de travail. Une fois, ce qui m'a vraiment marqué, c'est lorsque Signals m'a montré qu'un développeur gérait la plupart des fusions de PR. Ce n'était pas quelque chose que j'aurais remarqué par moi-même, et ce n'était pas durable. Nous avons réparti le travail de manière plus équitable, et tout de suite, les choses semblaient plus fluides et moins chaotiques. Un autre grand avantage est le rapport par e-mail à mi-sprint. Il me donne une vue claire de savoir si nous sommes sur la bonne voie ou si nous devons apporter des modifications. Au lieu de gérer les problèmes après qu'ils soient devenus incontrôlables, nous pouvons les résoudre tôt. L'équipe est moins stressée, et nous avons plus de temps pour nous concentrer sur le travail réel.

L'application est très flexible et nous pouvons intégrer de nombreux cas d'utilisation personnalisés très facilement.

En tant que développeur, je suis principalement plongé dans le code ou en train de courir pour fermer des tickets. Suivre chaque PR ? Honnêtement, ce n'est pas toujours dans ma tête. Mais les alertes Slack ? Un vrai changement de jeu. Si un PR reste là, sans rien faire pendant trop longtemps, je reçois une alerte. Simple. Je peux m'en occuper immédiatement. C'est comme avoir un petit assistant qui est toujours au courant des choses, donc je n'ai pas à vérifier toutes les 10 minutes.