Nous vous proposons une série d’articles pour traiter les problématiques liées au rythme de production d’un logiciel, les frustrations engendrées et les solutions qui peuvent être apportées pour améliorer la vie de l’équipe. Si vous nous avez suivies jusqu’ici, vous avez peut-être retenu qu’au départ du projet, il ne faut pas faire perdurer la durée d’implémentation d’une idée, pour mieux optimiser les coûts et augmenter le retour sur investissement. Votre projet n’est pas le seul dans la course et son endurance est mise à l’épreuve par les pressions qu’il subit en permanence de la concurrence ou de la clientèle (vu au premier épisode). Cependant, dans la précipitation, le manque de bonnes pratiques vous coûte et ralentit votre avancée. Les petits pas sont plus sûrs que les grandes foulées quand il s’agit de maintenir un rythme de production rapide (vu au deuxième épisode). De plus, les décisions prises sans esprit d’équipe ne vous poussent pas dans la bonne direction (vu au troisième épisode) et le manque de vision sur la ligne d’arrivée, vous fait perdre du temps. Enfin, soigner l’arrivée, autrement dit la livraison du produit, est au moins aussi important que de faire un bon départ (vu au quatrième épisode).
Des frustrations vont naitre. Pourtant, pour éviter la souffrance de l’équipe, des solutions existent et n’attendent qu’à être implémentées. Mais elles peuvent être considérées comme un défi pour certaines personnes. Vous nous objecterez que, bien que des solutions existent, il n’est pas aisé de les faire adopter. Il n’est pas non plus évident d’exprimer un point de vue contraire à celui des commanditaires. Il existe en effet des obstacles à la mise en application des bonnes pratiques. Si la volonté ne suffira pas toujours, nous croyons que certaines attitudes sont encourageantes.
Donner le droit à l’erreur et à l’exploration de pistes potentiellement mauvaises est la première étape vers une amélioration. Avec cette idée en tête, les membres de l’équipe sont plus sereins lorsqu’il s’agit d’être transparent sur les risques, les limites ou les obstacles. Le partage de ces informations augmente le champ de vision et rend possible la mise en place de mesures préventives. La recherche d’excellence dans le code et les pratiques, et la formation des équipes est indiscutablement considérée comme un élément indispensable pour produire un bon logiciel. Néanmoins, elle ne devrait pas entretenir un climat de compétition. Comme rappelé dans les 10 principes de l’ egoless programming (programmer sans ego) conceptualisés par Gerald Weinberg dans “The Psychology of Computer Programming”, peu importe le niveau de “karaté” (l’expertise) que l’on a, il y aura toujours quelqu’un d’autre qui en saura davantage (“No matter how much « karate » you know, someone else will always know more “). Au contraire, les connaissances acquises par un membre de l’équipe peuvent bénéficier à tous en étant transmises au travers de formation et d’entraide mutuelles. “Partage ce que tu as appris” (share what you learn) est une des recommandations que font David H. Hoover et Adewale Oshineye dans “Apprenticeship Patterns” pour monter en compétences. Nous savons bien qu’il n’est pas toujours évident de saisir à quel point on est ignorant sur un point sans qu’un plus expérimenté ne nous le révèle. Cependant, selon eux, “lorsqu’une personne enseigne, deux personnes apprennent” : la transmission d’une connaissance est un puissant outil d’apprentissage.
Pour la route
- La qualité ne doit pas être un simple peaufinage. Il faut qu’elle soit une priorité dès le début pour maintenir la stabilité du logiciel. Si l’absence de qualité est délibérée, alors il est primordial de planifier immédiatement sa résolution à une date proche. Ne pas respecter cette règle peut conduire à l’impossibilité de réaliser de nouvelles évolutions voire à la nécessité d’une refonte totale.
- Le chemin vers la réussite du projet n’est pas tout tracé, ce n’est pas qu’une question de temps, il faut explorer pour trouver la solution et connaitre ses priorités. Pour y parvenir, l’identification du MVP (Minimum Viable Product) est primordiale.
- Plus le périmètre est grand plus notre vitesse est réduite, il faut livrer petit à petit ce qui a de la valeur. D’où l’importance de découper le besoin en morceaux livrables apportant de la valeur à chaque incrément. Ainsi, on est focus sur un petit périmètre et le résultat est potentiellement facile à tester et facile à livrer.
- La vitesse de développement n’est pas le seul facteur impactant, il faut livrer fréquemment. Le but est d’éviter les goulots d’étranglement et fluidifier ainsi toutes les étapes pour arriver à apporter rapidement de la valeur aux utilisateurs.
- Pour accélérer, il ne faut pas une grande équipe mais une équipe équilibrée. En effet, il est préférable de rapprocher tous les profils nécessaires dans une même équipe d’une part et avoir la bonne proportion de profils métiers par rapport aux profils techniques.
- Eliminer les échanges et les discussions ne fait pas gagner du temps, il faut partager la vision d’ensemble et les objectifs pour une réussite collective. Il est donc préférable d’appliquer des méthodes telles que le BDD (Behavior Driven Development) ou des outils tels que ”Example Mapping” pour mieux comprendre le besoin et expliciter ses détails avec des exemples concrets qui permettent à la fois de comprendre le besoin mais aussi qui peuvent servir de tests (potentiellement automatisables) pour vérifier l’attendu.
- Être multitâche n’est pas plus efficace, il faut prioriser et rester focus sur une tache à la fois. Ainsi on augmente sa productivité et on libère notre esprit d’une charge mentale inutile.
Nous voilà arrivées au terme de cette série, en espérant vous avoir éclairés sur certains points qui potentiellement vous frustrent et pour lesquels vous n’avez pas de solution. N’hésitez pas à revenir vers nous pour nous faire un retour sur votre expérience.
Nous avons voulu avant tout montrer des directions possibles. A notre avis, le plus grand défi auquel est confrontée toute équipe, est résumé dans la citation d'Henry Ford :
Se réunir est un début, rester ensemble est un progrès, travailler ensemble est la réussite.
