IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Arsene Newman

5PARTAGES

7  0 
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.

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 :
  • 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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de
https://www.developpez.com
Le 15/05/2014 à 17:42
Citation Envoyé par temoanatini Voir le message
C'est pas un peu le but justement ? De cloisonner de nouveaux devs (évolutions, nouvelles fonctionnalités...) pour pouvoir les brancher entre eux ?
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.

Citation Envoyé par temoanatini
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)
Je dirais plutôt que le but c'est d'impliquer tout le monde et d'éviter le mode tunnel ( ce truc suffit à planter un projet ).
2  0 
Avatar de Uranne-jimmy
Membre expérimenté https://www.developpez.com
Le 16/05/2014 à 9:48
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 ;
2  0 
Avatar de javan00b
Membre actif https://www.developpez.com
Le 15/05/2014 à 22:12
Citation Envoyé par temoanatini Voir le message
Lorsqu'on créé un system d'exploitation, on ne peut pas sauter une énorme phase d'étude et de planification.

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.

C'est pas un peu le but justement ? De cloisonner de nouveaux devs (évolutions, nouvelles fonctionnalités...) pour pouvoir les brancher entre eux ?

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)
É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 sprint
1  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 16/05/2014 à 10:24
@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.
1  0 
Avatar de temoanatini
Membre averti https://www.developpez.com
Le 15/05/2014 à 17:20
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.
Lorsqu'on créé un system d'exploitation, on ne peut pas sauter une énorme phase d'étude et de planification.

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.
C'est pas un peu le but justement ? De cloisonner de nouveaux devs (évolutions, nouvelles fonctionnalités...) pour pouvoir les brancher entre eux ?

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)
1  1 
Avatar de
https://www.developpez.com
Le 29/08/2014 à 14:33
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.
Si je puis me permettre, pour l’avoir pratiqué pendant 35 ans au sein de l’administration, je peux répondre par l’affirmative, c’est possible. Les clés du succès ? Faire du « Bottom-up » avec du RAD (ça s’appelait comme ça avant l’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 clair, ce ne sont pas les méthodes qui doivent être agiles mais les 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...
Je vais me répéter :
Citation Envoyé par IFA2377 Voir le message
Pour arriver à cela, il faut oublier tous les censeurs qui, pour faciliter la gestion du troupeau, veulent que chacun se comporte de façon similaire. Alors, en se sentant en dehors du système, on invente très vite son propre système pour ne pas être détruit par le système officiel. C’est ce que j’ai fait dès mon intronisation comme programmeur en 1971. Mon système idéaliste a fonctionné durant toute ma carrière et ce n’est que depuis que je suis retraité que je parviens à mettre des mots sur ma démarche d’informatisation ; des mots que j’ai empruntés à d’autres qui ont su mieux que moi expliquer certains comportements, sans rapports avec l’informatique mais étonnamment compatibles avec ma propre histoire. Dans ma démarche de développement, je distingue aujourd’hui l’art et la manière :

L’art est la partie technique, rationnelle qui a ses règles. Ne dit-on pas d’ailleurs que l’on travaille dans les règles de l’art ? C’est le savoir-faire qui s’acquiert par la formation, l’auto-formation, la recherche personnelle, la pratique. Pour un informaticien, c’est la maitrise des langages, des systèmes, des méthodes de développement, etc.

La manière est la partie comportementale. C’est l’attitude qu’enseigne la vie et qui a ses principes. Je parle de « Véloce attitude ».

La véloce attitude est une attitude à trois facettes :

La hoshin attitude : s’investir totalement et librement
Les thèmes de travail ou « Hoshin » ("direction" - "boussole" en japonais) des task forces sont principalement : le juste-à-temps, l'excellence, le changement, l'innovation, la prise de risques, la compétitivité fondée sur le temps de réaction, l'esprit d'entreprise, la participation.

La hoshin attitude s’exprime dans le cadre d’une stratégie des équipes ad’hoc, l'adhocratie qualifiant toute forme d'organisation qui va à l'encontre de la bureaucratie pour aborder le changement. Elle traverse les frontières et les clivages habituels, coupe à travers les organigrammes, les départements, les fonctions, les profils de poste, la hiérarchie et la tradition. C'est en fait la capacité pour une entreprise à intégrer le changement.

La poulpe attitude : utiliser son intuition pour prendre les bonnes décisions
La poulpe attitude consiste :
  • à susciter les évènements
  • à saisir les opportunités
  • à exploiter les coïncidences

Adopter la poulpe attitude, c’est savoir sans savoir, autrement dit c’est l’écoute de soi-même, se fier à son intuition pour agir et réagir plus efficacement au quotidien sans réflexions interminables, raisonnements logiques conscients ou schémas compliqués.

Une personne qui ne sait pas s’écouter est condamnée à obéir aux autres, que ce soient ses parents, ses professeurs ou ses employeurs. C’est pourquoi une personne qui n’écoute pas son intuition est une personne qui n’utilise pas sa liberté. Le problème, c’est qu’on n’apprend pas à l’école à s’écouter soi-même.

L’intuition, c’est se rebrancher sur son moi authentique et sa petite lumière interne. Ce n’est pas une science exacte, c’est une sensibilité artistique qu’on développe, comme le fait d’être mélomane ou cinéphile. Ne pas réfléchir intellectuellement mais instinctivement. Le cerveau aime qu’on le sollicite dans la précipitation, il y a un plaisir beaucoup plus important à écouter son intuition que le plaisir à écouter sa logique analytique.

La positive attitude : vivre en mode chance et savoir lire la vie
Notre spécialité, pour la plupart d’entre nous serait plutôt la concentration, c’est-à-dire la capacité à nous focaliser sur une idée, un travail ou une action, en faisant justement abstraction de tout ce qui nous entoure et pourrait nous distraire de la tâche entreprise. C’est en tout cas comme cela que nous avons été éduqués pendant nos années de formation, que ce soit à l’école ou à l’université. Et c’est encore souvent ce qui est attendu de nous dans notre vie professionnelle.

Vivre en mode chance, c’est regarder différemment sa propre façon d’être dans le monde, prendre les décisions adéquates, décider de faire ou ne pas faire les choses, anticiper la situation à venir, entrer ou non en relation avec les autres, être plus attentif que d’autres face à l’apparition des occasions favorables, fussent-elles issues du seul hasard ; saisir les occasions et rebondir sur les incidents de parcours…

La chance est bien évidemment totalement irrationnelle et choque à bon droit notre sens commun d’héritiers de la modernité et de l’esprit scientifique. Hasards et coïncidences sont en fait des rencontres accidentelles entre des évènements qui ressemblent furieusement à des rencontres intentionnelles.

Cette chance, comprise comme la capacité à tirer parti des circonstances, est aussi et avant tout une ressource. Sans doute moins maitrisable que d’autres, souvent plus impalpable, mais une ressource quand même, bien réelle et dotée d’une puissance extraordinaire pour qui sait en décrypter les promesses, en respecter les principes et les règles.

Bibliographie :

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. »
Les méthodes se labélisent « agiles » parce qu’elles ont introduit dans leurs processus des règles inspirées des principes agiles. La dualité « art-manière » correspond en quelque sorte à la dualité « hard-soft ». Les méthodes dites agiles ont transcrit du soft en hard.

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 :

0  0