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. Avis collecté par et hébergé sur G2.com.
Jusqu'à présent, cela semble assez bien. Nous aimons l'utiliser. Avis collecté par et hébergé sur G2.com.
