votre société est-elle prête pour un processus Agile ?

Is Your Company Ready for an Agile Process?

http://www.pmhut.com/is-your-company-ready-for-an-agile-process par Carl M. Manello

« Nous pouvons faire tout, mais nous ne pouvons pas tout faire … du moins pas en même temps. Alors, pensez à vos priorités non pas en termes de celles que vous faites, mais en considérant quand vous les faites. Le timing est essentiel. »- Daniel Millman, auteur et conférencier

Qu’est-ce que Agile ?

agileBeaucoup de groupes de développement regardent pour passer à Agile. Agile offre de nouvelles approches pour beaucoup d’équipe de la vieille école et promet de meilleurs résultats. Cependant, rejoindre cette culture de performance nécessite plus que du désir. Il ne s’agit avec les méthodologies agiles que les choses soient faites plus rapidement ou pour moins cher, il s’agit de faire les bonnes choses au bon moment et de maintenir un haut degré de qualité en ce faisant.

Une fois que chacun s’est engagé sur la nouvelle façon de travailler ensemble, on peut être plus certain que l’organisation est prête pour le changement. Une des plus grandes idées fausses autour d’Agile est qu’il n’y a aucun plan de projet et qu’on a un chèque en blanc. Ces suppositions sont fausses. Même si l’approche de planification est différente, il y a un plan. Et alors qu’il y a une attente de changement, il est important de se souvenir ce changement ne réalise pas sans un coût. Les demandes du travail seront priorisées de 1 à n selon leur valeur pour le business et peuvent par la suite être réordonnancées. Mais puisque l’équipe fera partie de ce travail de priorisation, l’équipe en devient responsable. Pour ce nouveau niveau de responsabilité d’équipe, de nouvelles attentes sont exigées.

Pour réussir avec un processus Agile, il doit y avoir un engagement à tous les niveaux de l’organisation. Agile est une façon différente d’approcher un problème. Il est construit autour des prémices que nous tenons compte l’inconnu et nous nous attendons à ce que de l’inattendu pénètre dans le développement. Donc, il y a un niveau d’acceptation au début de toute initiative Agile qu’il y aura un certain niveau d’incertitude de ce que sera le produit final. La partie de ceci est en raison du principe sous-jacent d’Agile qui est que les utilisateurs obtiendront ce dont ils ont besoin, pas nécessairement ce qu’ils ont initialement demandé.

Changements à tous les niveaux

executiveAu niveau des dirigeants, le niveau d’incertitude dans Agile peut être exceptionnellement difficile à passer. Traditionnellement, les vendeurs sont managés par rapport à des éléments spécifiques à fournir. Les équipes de direction veulent savoir spécifiquement ce qu’elles auront pour leur argent, avant que le contrat ne soit signé et avant que le travail ne commence.

Pour naviguer au travers de ces attentes avant les problèmes surgissent, il y a deux ou trois points clés pour s’assurer que les dirigeants sont vraiment engagés :

  • Les processus agiles permettent aux besoins d’évoluer. Le travail sera priorisé selon sa valeur business, pour que les parties de plus de valeur d’une solution soient créées en premier. En raison de la nature de ce changement dynamique, il doit y avoir un engagement de faire consacrer des ressources business au processus de développement.
  • Il doit y avoir un désir d’accepter que le projet final ne soit pas complètement défini avant que le développement ne commence et les équipes doivent accepter que des changements dans la solution finale planifiée surviennent :
    • Les équipes créent ce qui est nécessaire basé sur un constant retour d’information et
    • les changements doivent être communiqués régulièrement à la direction.

Une fois que l’engagement des dirigeants est sécurisé, l’équipe considérant se déplacer vers Agile devrait regarder les sponsors de projet et leaders business. Parce qu’ils sont une partie intégrante du développement de solution, les personnes dans ces rôles éprouveront le changement le plus important par rapport aux anciennes approches de développement.

Les sponsors de projet et leaders devront s’engager à:

  • relisez ce billet
    relisez ce billet

    Une volonté de passer en revue le travail en cours :

    • Tester et revoir les travaux comme ils sont complétés est crucial au succès.
  • Une volonté de participer activement dans le processus de priorisation des besoins :
    • Les utilisateurs ne peuvent plus s’attendre à ce que tous les besoins soient égaux entre eux et penser qu’ils obtiendront toute la fonctionnalité en même temps.
  • La compréhension que les besoins peuvent être davantage détaillés quand le projet progresse :
    • Les articles de valeur business les plus hautes doivent être détaillés tôt; et
    • les changements de direction sont possibles, mais peuvent exiger un retravail significatif.

Un changement majeur pour des décideurs est que les décisions doivent être fermes et que toute correction d’une décision aura des impacts significatifs.

Changement pour les techniciens aussi

Ce n’est pas juste « le côté business » de l’équation qui devrait s’attendre au changement. Le côté livraison de l’équipe doit être prêt aussi. La structure de l’équipe de développement diffère légèrement d’une équipe « waterfall » traditionnelle. Un des changements principaux est celui d’un Propriétaire de Solution. Le propriétaire de solution travaille avec les utilisateurs métier et les développeurs pour assurer que la solution répondra aux besoins.

Le Propriétaire de Solution a besoin de ces compétences:

  • La capacité de faciliter la capture de besoins du métier et de comprendre de quelles informations les développeurs ont besoin.
  • La capacité de faciliter la priorisation du travail selon la valeur business :
    • Cette priorisation est nouvelle pour beaucoup d’utilisateurs côté métier. Le développement traditionnel considère tout avec une valeur égale. Cet ordonnancement des besoins peut demander un effort considérable.

Le rôle de l’analyste business n’est pas significativement différent; cependant, les outils et les processus changeront. Les besoins dans Agile sont décrits comme des Histoires d’Utilisateur au lieu du cahier des charges des besoins traditionnel. Il y a un focus nouveau sur l’expérience utilisateur et les résultats, pas sur la solution en elle-même. La solution technique reste la préoccupation de l’architecte technique et des développeurs. Un Analyste à besoins des items suivants:

  • La capacité à se concentrer sur l’expérience utilisateur et pas le système
  • La capacité de communiquer avec le business en termes business
  • La capacité d’identifier le problème principal que le système est sensé résoudre et qui va bénéficier de sa mise en œuvre

developer womanL’équipe de développement prend un rôle plus actif dans la définition de la solution dans un Processus Agile. Il y a un certain nombre de changements pour l’équipe aussi :

  • L’architecte technique doit:
    • Être réactif au changement;
    • Posséder des compétences technologiques fortes pour pouvoir pour concevoir des solutions qui sont extensibles; et
    • Être capable de travailler avec l’incertitude en créant des designs flexibles.
  • L’équipe de développement a tendance à être plus expérimentée et avoir besoin des choses suivantes :
    • Une capacité de fournir des évaluations réalistes;
    • Un focus nouveau pour penser en termes du problème business à résoudre;
    • Un désir d’engager les utilisateurs métier et les analystes dans le processus pour assurer que la solution répond aux besoins; et
    • Une capacité à penser aux impacts sur l’Expérience utilisateur partout dans le processus.

Le personnel des opérations doit s’engager à :

  • Déployer fréquemment dans des environnements de test.
  • Accepter que les structures de données et des besoins de stockage évolueront (parfois radicalement) pendant le projet.
  • Répondre aux besoins de l’équipe de développement pour supporter les priorités business.

customer satisfactionDans Agile, les équipes doivent toujours manager les attentes de leurs clients et s’assurer qu’il y a une compréhension que le changement fait partie du processus. L’idée est que cette coordination avec les utilisateurs et placer la valeur business au centre assure que seulement les articles qui ont d’une assez forte valeur business sont développés.

Les processus dans Agile diffèrent des méthodes habituelles. Les attentes sur les équipes sont différentes. Les interactions entre des personnes de l’équipe peuvent être différentes. Cependant, Agile n’est pas seulement centré sur les différences liées à la rapidité. Bien que la vitesse soit souvent un résultat, Agile est un recentrage sur livrer d’abord ce qui est le plus important et de plus de valeur. Donc, avant que vous ne regardiez à transformer votre organisation par Agile, assurez-vous que vous comprenez bien tous les changements que vous soutenez. Comprenez que passer à Agile est un changement qui déplace l’organisation vers des livraisons incrémentales. Un processus Agile fournira significativement plus de visibilité au processus de développement et permettra aux utilisateurs de prendre des décisions business plus informées.

Campana & Schott
Partenaire de DantotsuPM

3 réflexions sur “votre société est-elle prête pour un processus Agile ?

  1. Ping : Votre société est-elle prêt...

  2. Ping : votre société est-elle prêt...

  3. Ping : les articles les plus consultés en mai 2013 | DantotsuPM.com

n'hésitez pas à commenter les billets et à partager vos idées.

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.