L'approche Agile : comment faire pousser son produit logiciel en pratique ?

Dans mon précédent article je vous exposais comment cela ne faisait pas sens de construire un logiciel et qu’à la place il fallait le faire pousser, pour pouvoir tirer parti de la nature-même du logiciel : versatile, flexible et facile à mettre à jour. Ce second article se penche sur la mise en place en pratique de cette approche.

Faire pousser le logiciel : Comment commencer ?

Première étape : le cas d’utilisation

Il est essentiel de commencer par un unique cas d’utilisation qui fonctionnera de bout en bout.

Ce cas d’utilisation doit être vertical : le but est de traverser toutes les couches du logiciel. Le travail à réaliser contiendra donc une petite tranche de chaque couche. Par exemple, dans le cas d'une application Web, le cas d’utilisation devrait comprendre à la fois le front-end et le back-end, les couches de données et de présentation sur le front-end, et les couches de base de données et de traitement des données sur le back-end.

Il doit également être typique dans le sens où ce cas d’utilisation testera les plus gros risques identifiés. On veut s’assurer que les risques sont sous contrôle. En particulier, les différentes couches du logiciel doivent être intégrées entre elles.

Vous voudrez également que ce cas d’utilisation soit le plus basique possible : tout en étant vertical et typique, vous voudrez qu’il apporte le moins de changement possible… Car le but est de le faire rapidement ! C’est pourquoi votre premier cas d’utilisation sera basique afin d’obtenir rapidement des retours.

À première vue, ce premier cas d’utilisation n’est qu’un embryon de fonctionnalité qui n’apporte que peu de valeur. Et pourtant :

• Ce cas d’utilisation apporte réellement de la valeur, même si ce n’est qu’un petit peu
• Il est démontrable, ce qui veut dire que cette valeur fait sens pour les utilisateurs -- et vous allez pouvoir obtenir des retours dessus !
• Il a aidé à la conception du logiciel en prenant en compte les enjeux majeurs et en s’assurant que les risques sont gérés. Ainsi, la suite du développement se déroulera sans accroc
• Et enfin cette valeur est apportée rapidement, ce qui compense largement le fait que seulement un minimum de valeur soit produite

Deuxième étape : on fait pousser le logiciel

Une fois qu’on a cet embryon qui fonctionne, on peut réellement passer à la phase où on fait pousser le logiciel tel que décrit dans le précédent article :

• N’ajouter que des petits changements qui apportent toujours de la valeur
• S’assurer que les changements et leur valeur sont toujours démontrables
• Toujours intégrer ces changements avec le reste du logiciel
• Ces changements peuvent être effectués sur les différentes parties du logiciel, sans mettre en danger l’ensemble du logiciel

À n’importe quel moment, si on fait fausse route, il est toujours possible de revenir à un précédent état bien connu. C’est facile parce que les étapes sont petites. Et si vous devez jeter votre code, ça ne pose aucun problème. En effet, vous ne jetez qu’une petite quantité de travail.

Quand on fait pousser le logiciel, il est facile de revenir en arrière car les étapes sont petites. Et si vous devez jeter votre code, vous ne jetez qu’une petite quantité de travail.

La gestion de produit : travailler en petits incréments

Des contraintes claires de découpage

En faisant pousser le logiciel, les contraintes de découpage des éléments du backlog sont claires :

• Le logiciel doit être vivant à tout moment : démontrable et pleinement intégré
• Tous les éléments du backlog doivent bien apporter de la valeur
• Il faut découper les éléments du backlog afin d’obtenir du feedback le plus vite possible

Adopter le bon état d’esprit de développement logiciel

Quelles sont les implications de cette manière de penser ?

• La première phase de travail doit permettre d’obtenir un logiciel vivant mais aussi de s’assurer que l’architecture logicielle est adaptée
• Tout en faisant bien attention à ne prévoir que le strict minimum : il faut faire marcher le logiciel en minimisant les efforts nécessaires
• Et tout cela en restant prêt à jeter n’importe quel morceau de code qui empêcherait le logiciel de pousser facilement

Les principes-mêmes de la gestion de produit

En fin de compte, l’approche de faire pousser un logiciel correspond complètement à une bonne gestion de produit :

• Concevoir de petites fonctionnalités, les tester, et ensuite les améliorer -- ce qui correspond à l’approche Lean Startup que je décrivais dans un précédent article

• Pour y arriver, on travaille par petits incréments et on itère le plus rapidement possible
• S’assurer que les risques sont bien pris en compte, pour ne pas mettre en danger la vitesse de développement du produit
• Ne pas perdre son temps à faire ce qui n’apporte pas de valeur

Pour en savoir plus sur comment tester son logiciel de manière agile, consultez notre page sur le testing agile

Quels risques à ne pas adopter ce mindset ?

Voici les risques que vous encourez si dans votre progression vers l’Agilité vous continuez malgré tout de fonctionner en pensant construction plutôt que faire pousser :

• Vous pensez avoir adopté l’Agilité et vous en avez adopté les pratiques, mais votre fonctionnement produit reste inchangé.
• Votre capacité à mettre en production est limitée. Vous prévoyez explicitement les moments de mise en production plutôt que d’avoir en permanence une base de code potentiellement livrable. Résultat immédiat : chaque mise en production s’accompagne de son lot d’imprévus et de mauvaises surprises.
• Le produit n’est pas conçu pour être évolutif : plus la base de code augmente et plus il devient difficile de la modifier. L’équipe devient de moins en moins prédictible, les estimations explosent. Les développeurs se plaignent dès qu’une nouvelle demande arrive…
• Face au manque d’évolutivité du produit, tout le système se rebelle contre le métier ou les utilisateurs afin de limiter au maximum les évolutions. Par exemple, le Definition of Ready devient de plus en plus strict et procédurier. Ou encore, on commence à parler de “scope creep” pour indiquer les demandes qui n’étaient pas prévues au départ alors qu’elles correspondent au besoin réel, inconnu jusqu’ici.
• L’équipe développe un état d’esprit d’exécutant, traitant une liste de tâches, plutôt que de penser au réel sens du produit, au service qu’il doit rendre...

Quand on y pense, passer à l’Agilité et continuer à construire plutôt que de commencer à faire pousser, cela revient à continuer de travailler comme avant !

Prenons exemple sur la nature

Pour conclure, l’analogie avec la nature n’est pas anodine : celle-ci est tellement complexe qu’analyser les éléments fondamentaux qui ont permis à la vie de s’épanouir est certainement le meilleur moyen d’aborder le problème de la complexité dans la gestion des projets logiciels. Nous sommes simplement en train de redécouvrir ce que la nature a découvert par elle-même il y a des milliards d'années…