Archive
Le TDD, vous aimez, vous avez essayé … Mais ..!
- Mise en contexte
Les approches TDD (Test Driven Developpement) et ATDD (Acceptente Test Driven Developpement) sont des outils que toutes organisations qui veulent se tourner les méthodologies Agiles devraient utiliser.
C’est une approche qui est bien documentée et il existe beaucoup de formations qu’on peut suivre qui va vous expliquer l’art et la science sur le comment faire des tests automatisés de vos développements logiciels.
Aux files des années, j’ai vu plusieurs organisations ont voulu se lancer en lisant cette bonne documentation et envoyant leurs ressources faire les formations. Elles ont aussi beaucoup de temps à mettre en place les outils tel que NUnit ou Ms-Tests, JUnit .. ou autre framework de tests.. Mais, le “Mais du titre” malgré les efforts, le temps et même l’argent. Vous n’en avez pas fait le succès tant recherché.
Conséquence, vous avez arrêté d’en faire. Car, vous n’y voyez plus votre profit à l’exercice.
- La transformation, elle n’est pas facile à faire
Mais, la vie et aussi en informatique. Il faut parfois faire une bonne préparation. Même si l’approche est bien documentée, je le reconfirme. Il faut mettre en place des choses, voir faire des ajustements dans vos environnements avant d’ajouter cette suite d’outils dans votre arsenal.
Imaginer que vous toujours utiliser le langage Cobol dans un environnement central. Mais, du jour au lendemain, vous décider de passer à un environnement Web genre ASP.NET en C#. Il ne suffira pas de former, au langage C#, vos ressources. Ils devront apprendre une toute nouvelle manière de programmer. Mais, vos architectes devront aussi penser différemment leurs désignes d’applications.
C’est la même chose, lorsqu’on veut de se lancer dans les approches de type TDD. Il y a des devoirs à faire. Il faut aussi apprendre à nos programmeurs à faire des tests. Toutes les formes de tests et pas seulement ceux automatisés. Car, avant de faire des tests automatisés, il faut savoir bien tester et surtout savoir qu’est-ce que c’est un test.
Ils devront aussi apprendre à programmeur leurs classes, leurs fonctions. Autrement dit, revenir à la base des techniques de programmation. Car, un vrai test, ça doit tester une seule chose. Et dans nos livres d’initiation à l’université, une fonction devait aussi faire une seule chose.
C’est la même chose au niveau du design Les classes doivent avoir cette d’être dite testable. J’attends par testable, qu’elle soit simple à construire le code qui fera le test de la fonction et des fonctions.. Le temps normal d’un test unitaire automatisé devrait être quelque secondes (2-5 secondes. Voir généralement, moins d’une seconde.
Donc, il faut aussi penser un design pour facile à tester. J’ai déjà vu des classes que pouvoir faire un des tests automatisés avec elle. Il fallait mettre plusieurs heures de travail, pour automatiser la création du test et je ne parle du grand nombre des lignes de code qu’on doit écrire. On vient presque être obligé de faire un test fonctionnel pour ce qui devait être à l’origine un test unitaire.
- On fait comment ?
Bravo, vous avez décidé de poursuivre ! Mais, vous voulez savoir comment on fait ?
La première étape, je crois que vous l’avez fait, c’est-à-dire donner une formation sur l’art du test automatisé. Ils sont heureux , (je vous le souhait et je l’espère) d’avoir fait cette formation. Mais, malgré qu’ils aient un bel outil entre les mains.
Il faut passer à la prochaine étape, mettre le cadre d’utilisation de ce nouvel outil. Ce n’est pas parce que vous avez choisi d’utiliser cette approche qu’il faut l’utiliser partout d’un premier temps. Je recommande d’abord le faire sur un petit projet. Comme dit si bien, l’expression, l’expérience s’acquièrent avec le temps.
Voir peut-être, permettre d’abord seulement à certaines ressources de l’utiliser dans un petit projet ou partie d’un projet. Trop souvent, les organisations veulent faire ce virage en grande vitesse, et ce, n’est pas toujours une bonne idée.
Profitez-en pour définir sur quoi , ils seront utilisés. Car, les tests automatisés ne convient pas à tout et pour tout. Vous n’aurez peut-être pas tous les gains d’une intégration complète. Mais, la partie où ils seront utilisés vous apportera d’un premier temps la rentabilité tant recherchée.
- Plus qu’un framework générique
L’autre chose importante qu’il faut réfléchir. C’est que parfois nous avons besoin plus les outils d’un framework générique. Un framework générique comme son nom l’indiquent, sont conçus pour faire un travail générique.
Donc, parfois, lorsqu’on veut lui faire un travail plus particulier ça demande une connaissance particulière. Mais, pourquoi faire évoluer cette solution générique vers une solution plus particulière qui répondra à vos besoins.
Exemple, vous testez souvent des dates de transactions qui doivent être validé dans des conditions que vous pouvez généraliser. Pourquoi ne pas vous en faire un kit de tests prédéfinis.
En établissant cette suite de tests, vous pourrez facile vous assurez de leurs qualités. Mais aussi, facilité le travail de vos programmeurs.
- En conclusion
Choisir de faire un passage aux tests unitaires automatisés n’est pas une chose simple. Elle doit se faire en plusieurs étapes tout comme toutes les transitions vers une méthodologie Agile.
Elle aura des impacts partout dans votre développement logiciel. Mais, si vous persister que vous faites les bons choix et que vous avez un bon accompagnement. Je crois qu’avec le temps, vous en ferez un succès.
Être architecte ou concepteur en contexte Agile, est-ce possible ?
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
L’automne arrive à grands pas !
L’autonome arrive à grands pas.. Bien sûr pas les journées froides et pluvieuses. Mais, le démarrage de vos nouveaux projets que vous voulez lancer cet automne.
Pourquoi pas les planifier en utilisant les méthodologies Agiles. C’est donc le temps de mettre en place les structures et les outils qui vous permettront de mener à bien votre projet en utilisant aux mieux tant vos ressources humaines que celle budgétaire.
Ce ne sera pas quand le projet partira qu’il faudra choisir et mettre en place une ou plusieurs méthodologies Agiles. Prenez ce temps, plus ralenti pour vos équipes pour tout mettre en place.
Nos équipes sont prêtes pour vous accompagner, vous orienter vers les meilleurs choix de mise en place d’un buffet de services agiles au sein de votre organisation. Nous prendrons le temps de vous écouter afin de trouver avec vous les meilleures solutions.
Vous ne croyez pas que cela peut faire la différence dans votre organisation, laissez nous passer quelques heures au sein de vos équipes. Quelques heures qui nous permettront de jeter un regard extérieur, mais un regard d’expert !
Nous croyons que nous pouvons faire une différence dans vos projets, vous accompagnez dans votre quête de la meilleure solution, mais surtout aux meilleurs coûts.
On commence quand, vous voulez manger quoi ? Notre chef a déjà ses ustensiles et les livres de recettes en main !
Les comités d’architectures, pour ou contre.
Les comités d’architectures, pour ou contre.
On dit en méthodologies Agiles qu’on doit prioriser le travail d’équipes. Mais, à quel prix ? Surtout quand et comment, on parle d’architecture logicielle.
Un architecte logiciel au sien d’une équipe traditionnelle est le maitre après Dieu. Il est surtout le maitre désign logiciel. C’est lui, éminence grise, sur ce domaine. Les autres membres de l’équipe n’ont qu’à appliquer ce que ce « Dieu » a décidé.
En plus, de son travail s’effectue en début de projets. Où il met les grandes lignes de l’architecture (L’ARCHITECTURE LGOCIEL) et puis s’en va du projet. Et dans de très rares cas, lorsqu’on est vraiment chanceux et que le projet est long (conséquemment très gros). Et parfois, il reviendra en cours de projet, pour faire une revue d’architecture.
Mais, disons que cette stratégie n’est pas vraiment « Agile ». Mais, certaines organisations pour aider (ou favoriser) le travail d’équipe. Mais aussi la compréhension des membres des équipes de développement. Elle forme de ce qu’on appelle des comités d’architecture.
Un comité où les membres, indépendamment de leurs niveaux de compétences, s’assoient ensemble pour construire l’architecture du logiciel et bien sûr la mettre en œuvre. Arriver à un consensus sur les différents choix d’architectures nécessaire aux projets.
J’avoue que dans certains contextes et lorsque l’équipe est restreinte, cela peut fonctionner. Par contre, si l’équipe est trop grande, que la disparité des compétences (surtout en architecture logiciel) ne s’égale pas. On peut tomber dans le piège de la réunitivite. La maladie des réunions qui s’étire pour n’arriver à aucun consensus.
Donc, c’est quoi le compromis qu’il faut faire. Je sais, vous voulez une solution toute faite. Mais, si vous êtes lecteurs réguliers de mon blogue, vous savez que je ne donne jamais de solutions toutes faites. Je propose généralement une approche plutôt qu’une solution.
Mais, c’est quoi le rôle de l’architecte logiciel au sein d’une équipe Agile. D’abord concevoir cette architecture logiciel, je sais c’est évident. Mais, c’est bien de se le rappeler. Mais, contrairement aux environnements traditionnels. Il n’est pas le « DIEU » de l’architecture. Mais, l’expert aux SERVICES, oui aux SERVICES des autres membres de l’équipe.
De plus, son intervention aux projets de ne doit pas se limiter à une p’tite vite en début de projet. Mais, tout au long du projet. Il est au service de l’équipe et de ses membres
Donc, l’approche que j’utilise (oui je suis aussi Architecte logiciel « Agile ») et qui fonctionne avec les équipes dans lesquelles je l’ai appliqué. C’est que je conçois seul une première version de l’Architecture. Une fois conçu, je la présente oui, à un comité d’architecte « RESTREINT ». Il est généralement composé de 2 à 3 autres personnes (membre de l’équipe bien sur), ceux qui sont les plus expérimentés ou qui peuvent apporter quelque chose aux discussions.
Je présente toujours le concept d’architecture, en disant que je leur présente ma vision pour leur faire valider. Je suis à leur service et non l’inverse. Le but de cette première rencontre, c’est d’établir les bases de « NOTRE » vision de l’architecture logicielle. Lorsqu’il est nécessaire, nous pouvons ensemble la raffiner.
Une fois que cette petite équipe est arrivée à un consensus. Je dis bien un consensus, peut-être pas à la véritable architecture. Mais, les premières bases qui doivent être mises en début de projet. Elles seront et devront être raffinées en cours de projet. J’utilise cette approche à chaque phase importante d’architecture.
Tout faire en équipe, c’est philosophiquement bien. Mais, impossible à appliquer correctement dans le monde réel. Si nous sommes trop nombreux à discuter ensemble pour des choses simples. Il risque fort qu’on consomme du temps inutilement. Prendre de faire la sélection d’un groupe de composantes ou des grandes lignes d’architectures. Nous n’avons pas besoin d’avoir l’opinion de chacun des membres. Au besoin, leur poser individuellement la question, pourra très bien suffire
Il faut prendre le temps d’évaluer la rentabilité des efforts et le temps consommé aux projets. N’oublions pas, notre « ULTIME » but c’est de produire un logiciel. Ne pas faire, des réunions justes pour faire réunion.
En résumé, faire des comités d’architectures logiciels, oui, seulement lorsque c’est nécessaire. Rappelez-vous de vous poser les questions suivantes.
Pourquoi je fais quelque chose ?
Pour qui je le fais ce quelque chose?
Et surtout comment on doit fait la chose ?
Quelle est le meilleur outil pour construire le Web ?
Quelle est le meilleur outil pour construire le Web ?
Lors du dernier #WEBCAMP #QC, cette question a été lancée. Il y a eu un débat intéressant !
Mais, j’aimerais si vous me permettez, d’y réponde en plus de 140 caractères.
Toujours lorsque me pose ce genre de question, je réponds à peu près la même réponse. « un petit calepin, un crayon, mes deux (2) oreilles et mon équipe ».
Car, avant toute de choses, l’origine de l’application web que nous voulons construire est un « CLIENT ». Sans lui, il n’y aurait pas de projet !
Mes 2 oreilles me permettent l’écouter, mon calepin et mon crayon prendre des notes sur son besoin. C’est seulement après pris conscience de son besoin que je puisse enfin choisir qu’elle sera le meilleur outil pour répondre à son besoin.
Peut-être parfois, je prendrai des plates-formes #OpenSource ! D’autres du .Net ou même du Java (J2EE). Mais, peu importe vers quoi se tournera mon choix, il devra absolument répondre à ces critères.
1-Techniquement et efficacement rentable pour mon Client ! Si pour arriver à construire l’application qui rempli son besoin ! Que parce que j’ai choisi le langage « X » dans l’environnement « Y », le projet me prend 6 mois de plus avec des « Gourous » qui seront seules à comprendre ce qu’ils font. À mes yeux, je me tire dans le pied.
2-Une fois le projet terminé ! Est-ce que le client ou encore une équipe réduire, sera capable de supporter et d’entretenir l’application et son environnement ! J’ai trop vu souvent ! De belles applications, qui faisait pour quelque chose de simple (informatiquement parlant) et qui demandait une armée pour la supporter. Et là, je ne parle pas d’une plate forme de gestion de grandes entreprises. !
3-Mes choix technologiques sont-ils compatibles avec l’environnement de mon Client. Exemple, si mon client est ORACLE-JAVA-LINUX-Progress mur à mur, et que je lui arrive avec une application construire en ASP.NET sur une base de données SQL SERVER. Comme on dit l’application a besoin d’être belle ..!
4-L’expertise, l’expertise (les ressources humaines) nécessaire pour la mettre en œuvre existe-t-elle sur le marché local ou régional de MON CLIENT. Si mon client est perdu dans le Grand Nord et les seuls programmeurs qui peuvent l’aider et qui habite sa région, ne connaît que le PHP. Je n’irais pas l’écrire en JSF parce que tout simplement moi j’aime ça. On attache nos clients par la qualité des services qu’on lui rend et non par notre expertise technique qu’on possède.
5-Le web existe depuis longtemps, il a vu passé plus d’un langage ! C Pour faire les CGI-BIN, de l’ASP standard, Java pour faire des applets et tout le reste. La question n’est pas de répondre qui est le meilleur ! Mais, qui est le meilleur aujourd’hui ! Si refaisons le projet dans un an, dans 2 ans nos choix seront peut-être différents.
Je fais du Web depuis presque ses débuts ..! Et malgré toutes ces années, je n’ai pas trouvé le LANGAGE DE PROGRAMMATION meilleur que tous les autres. J’en ai juste trouve certain mieux adapter pour répondre à un besoin ou à contexte donné.
Rappelez-vous, le langage de programmation est un outil et non un moyen. L’outil est remplaçable par un autre. Quant au moyen, c’est la seule manière de faire la chose.
En résumé, ayez un bon coffre à outils !
L’intégralité organique, fonctionnelle, une petite définition.
Agile et la modélisation, une première réflexion !
Durant cet exercice classique, l’architecte ou le modalisateur effectuait la conception du logiciel et de sa base de données. Un travail qui pouvait prendre beaucoup de temps. Un beau travail qui n’apporte rien au client, et ce, tant que le travail de programmation n’était pas commencé.
Mais en Agile, comme nous livrons des petits morceaux d’applications fonctionnelles par cycles. Il est difficile de penser qu’on peut faire toute la modélisation en début de projet. D’autant plus que de cycle en cycle, le besoin peut changer. Donc, ce qu’on aura modélisé au début (selon les approches classiques) risque de plus correspondent au besoin ou tout simplement être invalidé en cours de route.
Cette réflexion, pourrait faire conclure plusieurs personnes qu’il n’est pas nécessaire d’effectuer la modélisation ou de créer une architecture logicielle. Pourtant, même si nous sommes en Agile, elle demeure aussi importante.
Maintenant que nous sommes d’accord avec ce principe. Vous me direz comment, il faut le faire ? Je n’ai pas de techniques infaillibles. Mais, quelques principes que j’utilise selon le besoin.
Il y a plusieurs façons de faire cette modélisation, cette architecture logicielle. Mais, ce qui est généralement reconnu est de le faire selon le principe du juste à temps. C’est donc de faire ce qui est nécessaire pour le cycle.
Pour ma part, je conseille la règle du 110-120% nécessaire pour le cycle. L’excédentaire est une prévision pour le cycle suivant. 100% du besoin de ce que nous devons construire et 10-20% de mise en place des pièces qui seront nécessaires pour l’interconnexion des cycles suivants.
Par exemple, si nous travaillons sur la facette de la fiche Client. Il serait intéressant de prévoir les orientations des facettes commandes et facturations. Sans pour autant compléter le travail de ces dernières facettes.
Il arrive parfois pour le besoin du projet, nous avons besoin de mettre en place les bases ou les orientations d’architecture. Dans ce cas, n’ayez pas peur de faire un premier cycle consacré qui couvrira ces orientations. Mais, surtout faire une modélisation qui pourra évoluer selon les besoins durant le déroulement du projet. Il sera toujours le temps de le faire dans le cycle qui touchera la facette concernée.
Construiriez-vous une application, s’en savoir où en aller ? S’en avoir une vision de l’architecture sur quoi baser votre développement. Bien sûr que non. Donc, faire de la modélisation va de soit. Pour ce faire, voici quelques techniques quipeuvent vous aidez à faire cette modélisation. J’aime bien utiliser la modélisation par domaine pour la partie plus organique et les « User Story » pour la partie plus fonctionnelle.
Une bonne référence qui vous permettra de mieux faire la lumière sur le comment de la modélisation en contexte Agile, je vous suggère cette référence en Anglais : Agile Modeling. Elle couvre beaucoup de techniques relatifs à cette approche.
Mais, surtout voyez cette référence, commune une autre boite d’outils, et non le moyen comment faire la modélisation. Être Agile, faire un projet en Agile, ce n’est pas d’abandonner vos bonnes pratiques. C’est simplement, parfois, de les utiliser différemment !
En autres mots, il ne faut pas chercher à tout réinventer toute la modélisation. Il suffit de restreinte sa pensée au besoin du cycle. Rappeler-le souvent à vos architectes classiques.
Rappelez-vous la règle du rhinocéros. Il est difficile de le manger d’une seule bouchée, mais en toutes petites bouchées, c’est plus facile.
Bonne lecture à tous. L’équipe de Génération Agile !
Génération Agile
