Être architecte ou concepteur en contexte Agile, est-ce possible ?

Like This!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

Le constat

Avec l’arrivée en grand pas et d’un pas sur des méthodologies Agiles change du travail de bien des intervenants. L’un de ces rôles qui subissent un changement, une évolution de sa pratique. C’est bien celui de l’architecte et concepteur.

Dans une approche plus traditionnelle, l’architecte, son exercice consistait à mettre en place des structures qui seraient à exploiter plus tard. Mais, trop souvent malheureusement, après leur passage au sein du projet. L’architecte devait apporter les grandes visions de l’architecture. Cependant, elles étaient souvent immuables et difficiles à faire évoluer rapidement.

L’architecture qu’on dépose doit couvrir tout le besoin du projet, tenté de prévoir tout, voir même l’impossible, ce qui serait nécessaire à mettre en œuvre durant la vie de projet. Autrement dit, de réponse aux grandes questions et données les pistes de réponses aux détails qui seront éclaircies par la suite.

La transition vers l’agilité

Dans un monde idéal Agile ou lorsqu’on découpe le projet en petite phase, il est plus difficile de prévoir tout ce qui peut arriver en début de projet. Encore plus, lorsqu’on adresse le changement dès qu’il arrive. Si vous, ne l’avez pas compris, le rôle de concepteur tel que nous l’avons connu, en Agile. Ça n’existe plus !

Mais, le besoin de mettre en place une architecture existe toujours. Certains vous diront qu’on ne peut pas faire dans l’architecture en mode Agile. Et que conséquemment, l’architecture du projet doit être projet qui ne sera pas incluant dans la gestion Agile du projet.

L’évolution du rôle d’architectes

Pour ma part, je ne partage pas ce point de vue. D’ailleurs, j’ai mis la base de réflexion dans ce billet titré : Agile et la modélisation, une première réflexion !

Le rôle de l’architecte tant par son expertise que par l’apport qu’il peut apporter au projet est important. Mais, avant de bien jouer son rôle, il devra apprendre à penser différemment. Trop souvent dans les approches traditionnelles, ils avaient une sorte de statut de Dieu. Je ne veux pas faire ici le procès d’aucuns. Je ferais le mien aussi ! Le temps et parfois, la multiplicité des projets nous imposent d’avoir cette mauvaise attitude.

Il m’est arrive aussi, de déposer en une heure, le travail de plusieurs jours à une équipe. J’avoue, dans ce contexte, je ne suis pas très collaboratif envers l’équipe de programmeurs. Encore plus, si cette intervention se fait en coup de vent, sans une vraie implication dans l’équipe de développement.

Mais, en contexte agile, la collaboration à toute son importance. Encore plus pour ce qui est de la mise en place de l’architecture. Afin de respecter et de pousser au maximum cette collaboration. Beaucoup d’équipes, choisir de former les fameux comités d’architectures.

La non plus, je ne pense pas que c’est une bonne stratégie. Je crois qu’il faut repenser le modèle d’interversion de l’architecte tant dans l’attitude que dans l’acte lui-même.

Il ne faut plus être des gurus qui apportent un savoir que nous sommes seules à détenir. Que seulement nous avons la solution aux problèmes. Je crois que nous devons oui apporter une connaissance, notre connaissance et notre expérience aux services de l’équipe de développement et bien sur celui du client.

Une stratégie s’impose.

La stratégie que je recommande toujours, ce n’est pas de faire l’architecture itérative. Mais, une architecture qui est évolutive. Il ne faut chercher à répondre à toutes les questions, c’est impossible. C’est certain le besoin va changer en cours de route du projet.

Il faut aussi répondre à des grandes questions avant de lancer le projet, quoi soit en Agile ou autrement, les bonnes pratiques en architecture. Qu’on parle d’analyse préliminaire, de cycles zéro, nous devons définir ces orientations.

À la différence près que ces orientations ne doivent pas être coulées dans le béton. Même chose pour la présentation, je choisis toujours de le faire avec ouverture. Je trouve aussi intéressant d’avoir l’opinion de l’équipe. J’ai eu parfois de belles surprises. On besoin de leurs expériences, car, c’est eux qui vont la mettre œuvre.

L’évolution de l’architecture au fil du temps

Notre architecte sera amené à évoluer aux fils du temps, aux files des besoins. Il faut aussi gérer cette évolution. Il faut être juste réactif. Ce n’est pas le temps que nous arrivons à implémenter un besoin qu’il faille faire pour l’architecture. Encore moins, lorsque le programmeur est prêt à la mise en œuvre.

Il faut essayer de prévoir, un ou plusieurs cycles à l’avance. Un architecte n’est pas un pompier qui éteint les feux lorsqu’ils se présentent. Mais, une personne qui cherche à les éviter autant que possible.

Donc, je suggère souvent d’utiliser la règle du cycle -1. On essaie de mettre en œuvre l’architecture ou la modélisation qui sera nécessaire un cycle à l’avance. Exemple, en exécutant le cycle 2, si nous savons que nous devrons normale répondre à un problème donné dans le cycle 3. Il est temps de mettre en place maintenant. Il pourra arriver que nos décisions du cycle 2 changent ou évoluent lors de l’exécution du cycle 3. C’est normal, il faut travailler en conséquence et en conscience de ce phénomène.

Fausses idées

Beaucoup de fausses idées persistent sur l’impossibilité de cette transformation tant du rôle d’architecte que de l’architecture elle-même en contexte Agile. J’espère, suite à cette réflexion, que vous n’hésiterez plus à faire parvenir au sein de vaux équipes Agiles.

Les méthodologies Agiles, ce ne sont pas juste un monde pour les programmeurs, mais pour tous les intervenants d’un projet informatique.

Quelques références sur l’architecture logiciel Agile (ou en anglais : « Agile Modelling »)

  • D’abord la section de mon blogue qui traite d’Architectures logicielles
  • La référence en Agile Modelling. Mais, ce n’est pas pour les débutants : http://www.agilemodeling.com/
  • Une définition en anglais de l’agile modelling :http://en.wikipedia.org/wiki/Agile_Modeling. Elle est courte. Mais, une série de bonnes références en fin de texte.
  • La dernière, moi Bruno Larouche, je suis un architecte de solution et j’exerce en contexte agile . Je peux « Coacher » vos équipes, dont vos équipes d’architectures.

En conclusion

Donc, la réponse à la question : « Être architecte ou concepteur en contexte Agile, est-ce possible ? », à mon un humble avis, c’est oui ! N’hésitez pas à laisser un commentaire pour compléter ou pour vous opposer à cette réflexion

  1. novembre 25, 2010 à 10:04

    Bonjour Bruno et merci de partager ton point de vue sur cette question sensible que j’ai entendue très (trop ?) souvent !

    Je crois que tu le résumes bien ici la fonction : « [un architecte] est une personne qui cherche à les [éviter les feux] autant que possible ».

    Être architecte ou concepteur n’est donc pas tant une affaire de titre que de compétence et de « focus ». Si on nomme une personne responsable de la qualité du logiciel livrée, elle va s’intéresser plus particulièrement aux bugs possibles et que personne d’autre n’a vu. Le fait qu’elle y arrive plus ou moins bien va dépendre de beaucoup de choses, mais surtout de sa compétence et son expérience dans des systèmes ou projets similaires. Pour l’architecture et la conception, je crois qu’il en va de même.

    La question devient alors : avez-vous des personnes qui ont cette expérience sur le projet et pensez-vous que ce soit important pour la réussite de celui-ci ? La réponse est beaucoup moins évidente et dépend du contexte. Beaucoup (et j’en fais partie) pensent qu’un architecte doit savoir bien programmer également, et l’avoir fait sur de gros projets ; pour la simple raison que c’est le gage qu’elle a accumulé l’expérience nécessaire à sa fonction. Il existe peut-être d’autres moyens de l’acquérir, mais c’est assez douteux dans les organisations et projets traditionnels, ou l’on minimise le coût en retirant les architectes du projet dès que leur intervention ne se justifie apparemment plus ; leur enlevant ainsi le retour d’expérience (feedback) sur leur architecture … ce qui fait qu’ils n’acquièrent effectivement pas ou plus l’expérience nécessaire à remplir leur fonction !

  2. novembre 25, 2010 à 10:33

    Merci M. Olivier Gourment,

    Vous avez bien compris et complété mon idée..Il faut mettre les bonnes personnes dans les bonnes fonctions pour qu’ils nous aident à apporter le focus sur la tâche.

    On parle souvent de l’intégralité de l’équipe de développement, on oublie trop souvent qu’elle s’applique à tous les membres de l’équipe, y compris aux architectes, aux QA, Etc.

    C’est vrai aussi, les organisations cherchent parfois de fausses économies en voulant sortir trop rapidement certains membres des équipes. Juste pour faire des économies ..

    En terminant, j’aime votre question: « avez-vous des personnes qui ont cette expérience sur le projet et pensez-vous que ce soit important pour la réussite de celui-ci ? » Je pense que je vais devoir y répondre prochainement dans un billet et je vous invite en faire autant de votre coté ..!

  3. novembre 25, 2010 à 10:41

    Et pour compléter la réflexion sur l’intégralité de l’équipe de développement, j’aimerais vous inviter à lire ce billet : http://generationagile.com/2010/03/16/l%E2%80%99integralite-de-l%E2%80%99equipe-de-developpements/

  4. Karl Metivier
    novembre 28, 2010 à 11:07

    Oui, c’est bien possible. Un architecte logiciel en mode agile, fait partie de l’équipe et doit aussi faire sa part et coder. De toute façon, un architecte logiciel qui ne fait plus de programmation devient avec le temps de plus en plus obsolète. Il doit en plus avoir la vision globale du système et la partager à l’équipe. Et aussi avoir en tête les requis fonctionnels et non fonctionnels. Bref, ce n’est pas un rôle facile, mais combien essentiel !

    • novembre 29, 2010 à 4:38

      Merci Karl pour ton excellent commentaire.

      Cependant, j’aimerais revenir ou compléter le point dont un architecte doit faire sa part de code. Oui, je suis d’accord. Il doit faire sa part de code. Mais, ce n’est pas une priorité à tous les sprints. Il est en premier lieu, le concepteur de l’application.

      Si sa charge de concepteur lui permet, il doit faire de la programmation, tant pour garder la main comme tu dis. Mais, pour s’assurer ce qu’il a pensé, s’implémente correctement et facilement. Ce n’est pas une règle juste une recommandation de bonnes pratiques.

      À tout cela, j’ajouterais aussi une responsabilité. Il doit aussi participer à toutes les revues de codes, incluant ceux durant les sprints pour laquelle, il n’aurait pas fait de code.

      J’ai aussi l’habitude, dans tous les sprints de me garder des unités de temps pour faire du « Pair Programming » avec les autres ressources. Tant pour travailler sur des composantes plus critiques que pour augmenter ou valider l’expertise de chacun.

      J’aime et je partage ton expression  » Il doit en plus avoir la vision globale du système et la partager à l’équipe. Et aussi avoir en tête les requis fonctionnels et non fonctionnels. « . Car, le rôle d’architecte qui simple et complexe à la fois. Ce n’est pas pour tout le monde.

      Tout ça pour dire que ce rôle est beau défi humainement et techniquement. En conséquence, c’est pour cela qu’il y a plusieurs appelés, mais peu d’élus.

  5. janvier 31, 2011 à 9:09

    Je définis le rôle d’architecte comme l’acteur responsable de la conception de haut niveau et de la décomposition d’une solution complexe en travail qui sera exécuté par plusieurs équipes. Dans un contexte agile, ce que j’ai vu est que le rôle de l’architecte unique peut être réparti dans les différentes équipes. Chaque équipe a un membre qui est un représentant d’une équipe architecture qui se réunit régulièrement (chaque itération). Cette équipe peut fonctionner une itération avant le développement pour aider à prototyper/valider des solutions s’il y a besoin.

  6. mai 5, 2014 à 4:25

    Je suis moi même architecte en milieu agile et pratique l’architecture selon des principes très proches : en phase d’avant projet il s’agit de définir une vision technique du projet puis de prendre un rôle de coach pendant la phase de développement.

    Ces pratiques sont appelées Just Enough Up Front Design pour la partie avant projet et Emergent Design pour la phase de développement. Très utilisées, ces deux méthodologies se complètent pour former un tout cohérent. J’ai développé le rôle de l’architecte selon ces pratiques dans une série d’articles dédiés : http://lilobase.wordpress.com/2014/04/30/concepts-de-larchitecture-logicielle-just-enough-up-front-design/

    • mai 10, 2014 à 1:23

      Merci de votre commentaire, Je ne connaissais pas « Just Enough Up Front Design », c’est vrai c’est très intéressant !

  1. novembre 25, 2010 à 12:00
  2. avril 5, 2012 à 2:49

Répondre

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

%d blogueurs aiment cette page :