Pourquoi passer à agile ?
Aujourd'hui, le monde professionnel fonctionne différemment, les logiciels sont à la portée des utilisateurs en quelques clics, les opportunités vont et viennent très vite et les consommateurs sont à la recherche constante d'outils adaptés à leur besoin. De ce fait, le développement logiciel en cascade n'est plus de rigueur et se voit peu à peu remplacer par le développement agile.
Réinventer la méthode de travail
Penser agile c'est bien, mais encore faut-il se plier à sa méthodologie, « nous avons commencé par repenser notre méthode de travail » car « on devait changer fondamentalement de méthodologie » et « travailler d'une manière plus incrémentale, pour livrer plus rapidement et permettre aux utilisateurs de participer activement à l'amélioration du produit ».
Planification du passage à agile
La première étape fut de permettre aux membres exécutifs et aux chefs d'équipe de prendre conscience de la dimension agile, à travers un nouveau projet qui leur était destiné.
Par la suite, l'organisation est passée d'un cycle de développement s'étalant sur plusieurs mois à de courtes itérations de trois semaines. La première itération fut un échec, mais très riche en enseignement, ce qui a permis aux différentes équipes de se réajuster en conséquence pour la seconde itération. Depuis lors, les itérations s’enchaînent sans entrave.
De nouvelles normes
Il faut oublier les différentes phases telles que : planification, développement du code source, intégration et livraison. Avec des cycles courts de trois semaines, le premier jour se résume à la planification de l'itération en cours, par la suite le code est écrit et testé quotidiennement. Ainsi, tout ce fait en même temps sans cloisonnement, ce qui permet de s'assurer du fonctionnement correct du produit.
Un nouvel état d'esprit
« Nous avons adopté un nouvel état d'esprit : échouer rapidement ». Avec le développement en cascade il y avait peu de place à l'erreur, il était donc difficile de faire des ajustements une fois cela arrivé. Agile est différent. On s'attend à faire de petites erreurs, mais nous apprenons vite à les corriger et à nous améliorer pour avoir de meilleurs résultats.
Quelques recommandations :
Aujourd'hui, le monde professionnel fonctionne différemment, les logiciels sont à la portée des utilisateurs en quelques clics, les opportunités vont et viennent très vite et les consommateurs sont à la recherche constante d'outils adaptés à leur besoin. De ce fait, le développement logiciel en cascade n'est plus de rigueur et se voit peu à peu remplacer par le développement agile.
Réinventer la méthode de travail
Penser agile c'est bien, mais encore faut-il se plier à sa méthodologie, « nous avons commencé par repenser notre méthode de travail » car « on devait changer fondamentalement de méthodologie » et « travailler d'une manière plus incrémentale, pour livrer plus rapidement et permettre aux utilisateurs de participer activement à l'amélioration du produit ».
Planification du passage à agile
La première étape fut de permettre aux membres exécutifs et aux chefs d'équipe de prendre conscience de la dimension agile, à travers un nouveau projet qui leur était destiné.
Par la suite, l'organisation est passée d'un cycle de développement s'étalant sur plusieurs mois à de courtes itérations de trois semaines. La première itération fut un échec, mais très riche en enseignement, ce qui a permis aux différentes équipes de se réajuster en conséquence pour la seconde itération. Depuis lors, les itérations s’enchaînent sans entrave.
De nouvelles normes
Il faut oublier les différentes phases telles que : planification, développement du code source, intégration et livraison. Avec des cycles courts de trois semaines, le premier jour se résume à la planification de l'itération en cours, par la suite le code est écrit et testé quotidiennement. Ainsi, tout ce fait en même temps sans cloisonnement, ce qui permet de s'assurer du fonctionnement correct du produit.
Un nouvel état d'esprit
« Nous avons adopté un nouvel état d'esprit : échouer rapidement ». Avec le développement en cascade il y avait peu de place à l'erreur, il était donc difficile de faire des ajustements une fois cela arrivé. Agile est différent. On s'attend à faire de petites erreurs, mais nous apprenons vite à les corriger et à nous améliorer pour avoir de meilleurs résultats.
Quelques recommandations :
- migrer progressivement et doucement : la migration vers un processus de développement agile ne se fait pas en un jour, elle doit être planifiée ;
- analyse des besoins : qu'importe le type de développement logiciel que vous faites, n'essayez pas d'être agile pour être agile, mais pour améliorer le produit. Si le besoin ne se ressent pas, il n'est pas conseillé de passer à une méthode agile ;
- persévérance : il ne faut pas se décourager par l'échec des premières itérations, mais persévérer pour s'améliorer.
- rester à l'écoute : les clients représentent le meilleur indicateur pour mesurer la qualité de son produit, il est donc nécessaire de rester à l'écoute du client si l'on souhaite aboutir à de meilleurs résultats.
Ainsi, le témoignage de Microsoft est riche en enseignement et met en évidence les voies à suivre pour la mise en place d'un processus de développement agile même dans le cadre d'une grande entreprise qui compte des milliers d'employés, ce qui fait resurgir une question récurrente aux méthodes agiles : est-il possible de mettre en place les méthodes agiles en dehors des startups et au sein d'une grande entreprise ? Oui ou non ? Quelles sont les clés du succès ?
La question reste ouverte et sans réponse évidente, alors qu'au même moment certains pointent du doigt l'évolution de l'esprit agile.
Source : Microsoft
Et vous ?
Qu’en pensez-vous ? 
Envoyé par temoanatini
).
