Quand Microsoft se met à l'agilité
Sa division développeur revient sur sa transition du développement en cascade vers le développement agile
Le 2014-05-14 20:44:26, par Arsene Newman, Expert éminent sénior
Les méthodes agiles font encore parler d'elles et une chose est sure elles sont faciles à mettre en œuvre dans le cas des petites startups, mais qu'en est-il des grandes entreprises de l'IT ? Aujourd'hui Microsoft revient sur le passage de sa division développeur au processus de développement agile, à travers quelques points essentiels.
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 ?
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 ?
-
L'XP prévoit le codage en binôme, Scrum les mêlées et les changements d'équipe http://henrik-kniberg.developpez.com...ti-scrum#L15.6 c'est surement pour éviter le cloisonnement ( pas seulement... ). Non le cloisonnement n'est pas agile.
Envoyé par temoanatini ). le 15/05/2014 à 17:42 -
Uranne-jimmyMembre expérimentéJe sais pas si ça fonctionnera pour microsoft, je sais par contre que pour moi, ce n'est pas une tentative vaine ou voué à l'échec ^^
C'est une méthode de programmation qui a pas mal de qualité, au moins autant qu'une autre. Ce qu'il serait intéressant maintenant c'est de savoir sur quels services de microsoft cela sera utilisé, si ça permettra aux systèmes de windows d'être au final plus aboutit.
Après je pense que dans cet article il ne faut pas oublier un passage, qui fut-il court, est important :
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 ;le 16/05/2014 à 9:48 -
javan00bMembre actifÉvidamment tu ne commence pas avant d'avoir ecris les spécifications de haut niveau et certains vont meme jusqu'a écrire la majorité des scenarios tests. Il y a une enorme phase de planification bien avant tout cela qui peut durer quelque mois.
Il y a beaucoup de rencontre pédagogique organisé pour bien cerner la business logic et tout les autres paramètres.
La méthodologie agile est en accord avec tout ses concepts. Agile ce n'est pas du fur a mesure ou de l'improvisation, les gens pensent souvent cela à cause du développement incrémental, mais par exemple la méthode scrum est très rigide et nécessite beaucoup de planning pour chaque sprintle 15/05/2014 à 22:12 -
SaverokExpert éminent@Uranne-jimmy : je suis en phase avec toi là dessus
Par expérience, l'agile est très bien adapté pour tous les projets, ou phase de projet, avec une grosse partie IHM.
En effet, présenter régulièrement les avancées de la construction d'une IHM permet d'ajuster son ergonomie en fonction des retours utilisateurs (et parfois, certains retours peuvent être très impactant donc plus on les voit tôt, et plus on peut ajuster le tir)
Par contre, pour tout ce qui est très technique, l'agile n'apporte rien ou presque.
En effet, pour les scripts en mode batch ou des flux, en général, il n'y a besoin que de s'entendre sur les interfaces ou moment de la conception.
Si les contrats de services sont bien suivis par toutes les équipes, ça fonctionne très bien lorsque l'on fait sauter les bouchons (à quelques ajustements mineurs près, bien sûr)
Donc oui, l'agile c'est très bien mais ça ne s'applique pas aveuglement partout.
De même, il ne faut pas être extrémiste dans son application non plus. Des ajustements ou "écarts aux concepts" sont permis et même recommandés en fonction de l'équipe, du projet, de la structure d'entreprise, du client, ...
Ce n'est qu'une méthode qui se doit d'être au service du projet et des équipes, et non l'inverse.le 16/05/2014 à 10:24 -
temoanatiniMembre avertiDe 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.
En partant avec quelques idées "assez précises" et un premier cycle de 3 semaines, certes il n'y aura eu que 3 semaines de perdues mais c'est voué à l'échec.Ainsi, tout ce fait en même temps sans cloisonnement, ce qui permet de s'assurer du fonctionnement correct du produit.
Au final, je pense que la méthode agile est plus adapté pour faire soit de petits projets spécifiques, soit plus pour des produits qui ne font plus qu'être maintenus ou avec quelques évolutions (et c'est quelque part le cas pour Microsoft et Windows)le 15/05/2014 à 17:20 -
Les voies à suivre pour la mise en place d'un processus de développement agile dans le cadre d'une grande entreprise qui compte des milliers d'employés font 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.
Aujourd’hui, les méthodes se labellisent « agiles » comme elles se labellisaient « RAD » au siècle dernier.« Agile nécessite l’évolution de la manière d’interagir et de raisonner des développeurs. »
En 2012, un agiliste toulousain s’interrogeait : « Faut-il encore parler de méthodes agiles ? Pourquoi garder ce terme restrictif alors que l'on devrait tout simplement parler de méthodes professionnelles de développement logiciel ? »« Tout d’abord, il faut noter qu’agile relève plus d’un état d’esprit, d’une culture et de principes, plutôt que de méthodes et de pratiques. »
Développer est un art dont les méthodes fixent les règles. Mais il y a la manière d’exercer cet art et la difficulté, c’est de distinguer l’art de la manière. L’agilité n’est pas une méthode qui fixe les règles du développement mais une attitude qui exprime la manière de développer. On parle d’agile attitude. Et ça, ça ne s’enseigne pas, enfin je ne crois pas.
J’ai abordé ce sujet dans la discussion :
« Doit-on soumettre les vétérans à des tests de programmation avant embauche ? ».
Je répondais à puce_84 dont le message a disparu :
Il faut arrêter les méthodes, les process, les structures et mettre un peu de chaos dans ce monde trop bien rangé... Cherche informaticien avec un minimum de connaissances techniques et prêt à toutes les sacrifiées sur l'autel de sa créativité. Ceci n'est que l'avis d'un pauvre philosophe perdu...
L’informaticien ne peut s’empêcher de rationaliser, d’identifier, de classer, de règlementer, d’architecturer, de standardiser, de sécuriser, de chercher des recettes, de se certifier.« La partie la plus difficile avec agile est la transformation de la perception des principes autour d’agile. »
Ainsi, les principes :
- « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles »
- « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte »
… se sont-ils mués en sprints.
Et les principes :
- « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet »
- « La méthode la plus efficace pour transmettre l'information est une conversation en face à face »
… se sont-ils mués en scénarios.
Le développeur extrait de ces scénarios les règles de gestion de la problématique à informatiser qu’il interprète avec sa formation, sa technicité, sa rationalité, sa culture d’informaticien. Et c’est ainsi qu’il réinvente le métier de l’utilisateur.
A ce sujet, il est intéressant de citer certains arguments pertinents auxquels j’adhère sans réserve, de la discussion :
Aparté : Les discussions ont un caractère « consommable » et je trouve dommage de ne pas les exploiter en créant des sortes de synthèses, de cahiers ou d’études dans une rubrique spécifique du site.
« Cycle en V » ou « agiles », ces méthodes sont toutes des méthodes de type « Top-Down ». Je me trompe ? Pour ma part, je n’ai pratiqué professionnellement que du « Bottom-up » avec du RAD, méthode que les développeurs de ma génération pratiquaient sans le savoir.
A propos de RAD, Je propose d’en rappeler les principes. Jean-Pierre Vickoff s’y réfère et les évoque souvent dans son ouvrage mais ne les cite pas explicitement à la façon du Manifeste agile. Une liste de ces principes en annexe aurait été la bienvenue. J’ai extrait de son texte les concepts forts et récurrents qui peuvent faire office de principes.
Évidemment, il est tentant de mettre en parallèle les principes RAD et agiles.
Il est même tentant de mettre en parallèle bien d’autres principes issus de mondes très différents (évoqués plus haut) comme le monde de l’entreprise (La hoshin attitude), le monde de la psychologie (La poulpe attitude et La positive attitude), le monde de la philosophie (citations), le monde de la médecine (sophrologie), le monde du sport (challenges)… et mon propre monde de développeur que j’ai baptisé (méthode APL-AML). D’autres développeurs trouvent des réponses à leurs interrogations dans d’autres mondes comme le théâtre par exemple. Il appartient à chacun de chercher sa vérité. Pour ma part, j’ai répondu à peu près à toutes mes interrogations.
Annexes :le 29/08/2014 à 14:33