Archive
L’architecture Agile et la documentation.. Est-ce possible ?
1. Introduction
Souvent lorsque nous parlons des Méthodologies Agiles,
l’un des premiers éléments qui sont souvent cités. C’est qu’on ne fait pas de
documentation. Pourtant on doit en faire, c’est nécessaire. Je vous ai donné
les premières bases de la documentation ici dans cet article On documente quoi et comment.
Mais, lorsqu’on réussit à convaincre les gens, que la
documentation est nécessaire. Il y a encore trop souvent, une de ces grandes
parties délaissées de la documentation. C’est bien la documentation de
l’architecture. Pourtant, c’est la base de notre logiciel.
Soyez prévenu, choisir de documenter son architecture. Ce
n’est pas un choix facile. Car, il y a plusieurs approches. Mais, la seule et
unique règle que nous vous recommandons, c’est la simplicité et l’efficacité
doit primer sur tout le reste.
De plus, peu importe votre choix d’outils pour documenter
votre architecture, c’est très important. Il doit produire une documentation
vivante et partageable facilement. Et pourquoi pas, être écologique en
priorisant une solution électronique de vos documents.
2. Pourquoi documenter l’architecture, c’est bien qu’une question de choix
La phase de l’architecture de notre logiciel est l’une des
plus importantes, tout au long de notre processus de développement logiciel.
Elle a pour but d’apporter la vision tant sur le travail à accomplir que sûre
qu’ont les orientations possibles de notre logiciel.
Mais la meilleure manière de partager et de présenter cette
vision, surtout au-delà de la période de développement. C’est faire de la
documentation de l’architecture, et peu importe le format, elle sert essentiellement
à communiquer durant le développement aux membres de votre équipe qui mettront
en œuvre cette vision.
L’autre point important pour lequel nous faisons de la
documentation, c’est pour la partie d’entretiens du cycle de vie de notre
logiciel. Un logiciel en moyen passera entre 75%-80% du temps en mode
entretien. Souvent, l’équipe qui fera cet entretien sera différente de celle
qui l’aura développé. Donc, il risque fort qu’il n’ait plus personne pour
raconter l’histoire des décisions qu’on a prises dans les différents travaux
d’architecture et d’analyse.
C’est facile de voir un beau modèle objet ou de données,
qu’en on la personne qui l’a conçu pour l’expliquer. Mais, imaginer que la
personne n’est plus dans l’organisation pour expliquer ces choix. Il peut
arriver que certains morceaux soient plus difficiles à comprendre.
En fin compte, faire ou non, la documentation c’est bien
une question de choix, de choix sur le comment on va la faire. Mais aussi,
jusqu’à où on va la documenter.
2.1. Juste assez, juste nécessaire
La règle qui régit ma pratique est juste assez pour la
compréhension des équipes qui vont nous suivre. Mais aussi nécessaire à garder
l’historique ou l’histoire de décisions qui ont été prises dans les différentes
étapes de la conception. La responsabilité de l’architecture, c’est de trouver
des solutions, avant qu’ils ne surviennent !
Autrement dit, ce qui est nécessaire pour comprendre le
processus décisionnel et le résultat obtenu. Donnez aux équipes l’information
qui leur sera utile pour continuer à maintenir ce que vous et votre équipe a
mis en œuvre. Il faut répondre au pourquoi et comment on prit cette décision.
3. La documentation de la modélisation, UML pourquoi ou pourquoi pas!
L’un des outils qui sont souvent utilisés en modélisation,
c’est bien UML. C’est un excellent outil pour présenter la modélisation tant
objet que donnée.
Mais parfois, cette forme de modélisation n’est pas
toujours accessible à tout le monde. Elle est plus destinée aux personnes plus
techniques. Pour ma part, je l’utilise pour discuter avec les programmeurs ou
autres gens techniques.
Apprendre UML, malgré qu’une la connaissance peut
s’apprendre dans les livres ou assit dans une classe de formation. Il reste
toujours que le reste de la connaissance s’apprend uniquement par l’expérience.
Donc, malgré les nombreuses qualités d’UML, et je suis
loin d’en faire le procès ici, il ne correspond pas à tous les besoins et n’est
pas destiné à tout le monde.
A titre d’exemple, un diagramme de classe pour expliquer
le contenue d’un logiciel à client qui ne connait pas la modélisation objet, je
ne suis pas sur qu’il va comprendre quelque chose.
Il faut donc trouver un outil, un langage que toutes les
personnes impliquer dans la discussion vont comprendre. Et au besoin, pourquoi
pas d’inventer votre en cas de besoin. Dessiner vos propres diagrammes, un
formalisme que tous les gens vont comprendre.
Et bien sûr, server aussi d’UML avec les gens qui le
comprennent ou encore si c’est plus facile pour vous. Mais, n’oubliez pas
l’objectif c’est de communiquer et de partager
4. Une documentation plus écrite ou en mode texte
Le premier réflexe que plusieurs personnes quand on parle
de documentation. C’est d’ouvrir un traitement de texte (Genre Microsoft
Word). Mais, parfois, écrire un texte pour tout détailler. Ça ne correspond
pas au besoin que vous devez combler.
Certaines choses se décrivent bien dans un texte. Mais
d’autres pas. Il faut savoir quand et comment, il faut le faire dans un texte
ou avec un autre moyen.
De plus, il ne faut pas oublier que la plupart du temps,
un texte est un complément aux autres composantes qui documentent l’application.
Donc, il ne faut pas chercher à tout écrire ce qui est déjà dit d’une autre
manière dans un autre outil.
J’ai trop souvent vu que les gens écrivaient en mode texte
un cas d’utilisation ou autre chose qui se décrivait par lui-même. Plus tôt, se
limiter que simplement décrire les cas limites ou l’interaction avec d’autres
cas.
Fixer la limite du texte ou de sa portée n’est pas une
chose facile, certaines règles s’appliquent. Mais c’est aussi un peu un art et
une science.
4.1 L’art et la science de la documentation.
Savoir limiter la portée d’un texte est tant un art
qu’une science. Mais, de manière simple, je dis souvent d’écrire en mode texte
ce qui n’est pas évident au premier regarde des autres composantes de
documentations. Surtout si vous n’êtes pas là pour donner les explications
manquantes. Dans le cas contraire, ajouté du texte qui permettra à votre
lecteur de bien comprendre.
Un petit truc de métier, lorsque je ne suis pas sur de la
facilité de la compréhension. Je présente le diagramme ou le texte à une
personne qui n’a pas ma connaissance et je lui demande de m’expliquer ce qu’il
comprend. Généralement, je limite ce petit exercice à 3-5 minutes pas plus.
S’il n’est pas capable de m’expliquer, c’est qu’il manque de l’information ou
encore que mon diagramme est trop complexe.
5. Conclusion
En conclusion, faire la documentation de l’architecture
d’un logiciel ce n’est pas une chose facile à bien faire. Mais, ce n’est pas
pour autant qu’il ne faut pas la faire.
C’est un défi qu’il faut relever. Car, un logiciel et son
architecture aura une vie beaucoup plus longue qu’on peut l’imaginer lors de sa
conception. C’est donc la documentation qui l’un de ces maillons qui, je crois,
vous permettra de rendre agréable toute la vie de votre logiciel. Tant durant
son développement que durant son entretien.
Il ne vous reste plus qu’à trouver votre besoin en
documentation et comment le combler!.
Mes quatre murs de mon bac à sable : Développement logiciel
- Introduction
Combien de fois, j’ai attendu dire par des clients ou d’autres personnes, même des professionnels de l’informatique. Qu’il suffisait de mettre beaucoup de programmeurs ensemble pour produire un bon logiciel et parfois, en sous-entendant qu’on pourrait aussi le fouetter de temps en temps, s’ils accumulaient un peu de retard.
Mais aux jours d’aujourd’hui, il ne suffit plus de mettre une gang de programmeurs ensemble. Construire un logiciel aujourd’hui c’est un autant un art qu’une science. Un groupe de programmeurs peuvent faire un excellent travail. Mais, il leur faut un terrain de jeux, un environnement de travail qui leur permettra de mettre efficacement leurs compétences en action.
Qu’est-ce que ça demande de plus ? C’est une question qu’on me pose souvent. Lorsque, je réponds à cette question. J’utilise souvent l’apologie du bac à sable. Un bon bac à sable bien construit, les enfants peuvent y jouer tout en sécurité. C’est un peu à cette image qu’il faut construire l’environnement des programmeurs. En leur donnant tant les outils que l’environnement (le mur et le sables), ils pourront exercer leur travail de programmation au mieux.
- Le premier mur celui l’analyse fonctionnelle
Le premier mûr, j’avoue aujourd’hui, c’est lui le moins oublié. D’autant que la formation de nos programmeurs d’aujourd’hui fait partie de la formation de base dont ils reçoivent tant nos Cégeps que nos universités.
- L’analyse fonctionnelle, c’est quoi ?
Mais, avant de vous parler de l’importance de l’analyse fonctionnelle, je vais d’abord définir ce que c’est. Pour moi, l’analyse fonctionnelle c’est d’abord le processus qui permet de répondre à la question: « c’est quoi ce va faire le système à construire ? » ou plus simplement, décrire le comportement attendu par l’application à la fin du processus de développement.
C’est aussi de définir le processus qui permettra de comprendre les différents scénarios d’utilisations possibles (positif). Ceux que l’utilisateur pourra faire. Ainsi que les limites ou le cadre de ces scénarios.
Il est aussi important de définir les scénarios impossibles. Un marteau ne coupe pas une planche de bois. C’est la même chose pour un logiciel. Il ne fait pas tout. Ça serait trop le fun ! 
- L’importance de l’analyse fonctionnelle
Une règle bien simple pour se rappeler l’importance de faire ou non un dossier fonctionnel. La règle, c’est simple si c’est plus compliqué qu’un « hello word » et qu’on ne peut résumé le « Détail » du traitement et des scénarios en 2 phases que tout le monde va comprendre, on fait un dossier fonctionnel.
Il ne faut pas oublier que le dossier fonctionnel, ne sert pas seulement au développement du logiciel ou de la fonction du logiciel. Il est aussi utile pour la maintenant, les essaies et comme documentation initiale.
Mais d’abord et avant tout, c’est un contrat qui lit l’équipe de développement avec le demandeur de ce logiciel, le client. Qu’il soit externe ou externe à l’organisation ou à l’équipe, il le lit. C’est lui qui permettra de définir si ce qui a été demandé a été bien livré. !
Donc, sans ce mur, nous ne serons pas par où entrer !
- Le deuxième mur, l’autre pendant de l’analyse, celle organique ou logicielle
L’autre mu qui a aussi toute son importance, c’est bien l’analyse organique. Mais avant de définir l’importance, je vais définir c’est quoi.
- La définition, ça manche quoi en hivers
Ça mange quoi en hivers cette analyse organique. Mais, c’est justement c’est qui nous empêche d’avoir en hiver. L’analyse fonctionnelle nous a dit quel genre de maison et comment elle serait divisée. Mais c’est l’analyse organique qui nous dira comment les murs seront faits et surtout comment commander les matériaux nécessaires pour construire cette maison.
J’allais oublié, en informatique nous ne construisons pas de maison. Mais des logiciels, et parfois des logiciels pour aider à la construire c’est tout… hi hi !
Vous trouvez mon apologie drôle, mais pourtant elle dit vrai. Il faut aussi définir comment sera fait l’ensemble des morceaux de notre logiciel. C’est le plan détaillé de toutes les cloisons, le filage et la tuyauterie de notre maison.
C’est aussi à cette étape qu’on va prendre les décisions sur l’art et le comment on va faire les choses. Qu’ont déterminé si on va se construire des gabarits ou des modèles pour pouvoir récupérer le travail ou encore le simplifier.
Construire un logiciel, c’est bien plus qu’écrit du code dans un langage de programmation.
- Est-ce qu’on ne peut pas en faire !
On me dit souvent, mais programmeur sont bons et ont beaucoup d’expérience. Donc, pas besoin de faire cette étape. Mais parfois, il faut savoir où sera la cuisine ou la salle de bain, pour savoir comment passer les files ou les tuyaux.
Vos ouvriers, les programmeurs, sont peut-être très compétents. Mais parfois, il faut avoir plus que la vision de la pièce qu’on construit.
Les programmeurs d’aujourd’hui sont des bons intégrateurs ou de bons assembleurs. Mais il faut parfois, voir souvent leur donner un bon plan. Imaginez vouloir assembler un meuble IKEA sans le manuelle d’instructions. C’est presque impossible, vous risquer d’avoir un résultat incertain ou encore avoir des pièces en trop. C’est la même chose avec logiciels.
Donc, faire une maison ou une meuble IKEA sans plan, pas pour moi. A la limite, j’accepterais un plan partiel plutôt que de ne pas en avoir du tout.
- C’est qui le fait
Donneriez-vous à votre meilleur ouvrier le travail de construire le plan du pont qui servira à faire passer des camions. C’est la même chose pour ce travail. Ça demande un professionnel de l’analyse organique. Je vous reviendrais prochaine avec ce profil dans un autre billet.
- le troisième mur, les tests unitaires automatisés.
Allez, je vous propose un petit jeu. Je vous donne procédure de 10 étapes et à chacune d’elle vous devrez valider le résultat. Jusque-là c’est facile.
Complexifions ce petit jeu, je vous demande de refaire 100 (cent) fois, voir 1000 (mille) cette même procédure. Et à chaque fois, le résultat des étapes peut changer aléatoirement. Je suis sûr que vous me direz que c’est compliqué et que le risque d’erreurs de tout genre est grand, et vous aurez raison.
C’est pourtant ce qu’on demande à un programmeur de faire pour valider son travail.
- L’ordinateur c’est bien faire !
Un ordinateur c’est bien essentiellement quatre grandes taches, addition, soustraire, multiplier et comparer un résultat.
Le plus drôle de l’histoire, c’est aussi ce qu’on demande généralement dans un test unitaire. Donc, pourquoi ne pas demandé à l’ordinateur de le faire pour nous. C’est la réflexion que plusieurs informaticiens on fait lorsqu’ils ont développé les outils de tests unitaires automatisés.
- La qualité d’un bon logiciel
La qualité d’un bon logiciel passe par la qualité de ces tests unitaires, mais aussi par leur exécution. Nous savons qu’il est difficile de bien répéter un très grand notre de fois la même procédure sans risque d’erreurs.
Nous savons aussi que l’ordinateur c’est bien faire cette tache. Donc, pourquoi ne pas lui faire faire. D’autant, ce n’est pas parce que les tests exécutés la semaine passée se sont terminés avec succès. Que le résultat ne sera pas différent aujourd’hui avec toutes les modifications qu’il y a eu dans le code.
Avec les tests unitaires automatisés, on peut relancer plusieurs tests, même ceux qu’on pense que le nouveau code. Vous serez peut-être surpris.
Un test unitaire automatisé, c’est un peu comme testé le pilier du pont, tout au long de la construction, et ce, avant que les gros camions passent dessus.
- le dernier pour compléter le carré, le gestionnaire de sources.
Faites-vous des backups d’un document important sur lesquelles vous travaillez ? Normalement, oui ! (Sinon vous devriez !).. Imaginez donc, travaillez sur plusieurs documents (fichier de codes sources) en simultanés et surtout par plusieurs personnes.
C’est impossible, pourtant c’est se qu’on fait à tous les jours avec nos fichiers de code. Il y a plusieurs stratégies et plusieurs outils, du simple partage réseaux jusqu’à l’outil qui fait la gestion des sources.
- La gestion des sources
La gestion des sources, c’est l’art de prendre une copie des fichiers, mais aussi de conserver les différentes versions. Jusque-là, on peut le faire avec plusieurs répertoires, voir plusieurs disquettes.
En plus, il est intéressant de savoir ce qui a été modifier et surtout par qui, pour le cas, qu’on ne comprendrait pas la démarche de la modification. Ce cas, il ne suffit pas avoir seulement 2 versions du fichier.
Imaginez, une application moyenne d’aujourd’hui, c’est grosso modo 500 voir 1000 et plus fichiers. Donc, savoir à quelle version on est rendu .. Disons simplement que c’est trop compliqué sans outils.
Vous comprendrez aussi, que conserver des dizaines de copies, le volume de données stockées devient rapidement important. C’est pourquoi que nous avons besoin d’un outil qui le fera pour nous. D’autant que les outils de gestion de sources modernes gèrent l’historique des versions en conservant seulement le différentiel. La partie qui a été modifiée, le fichier sont construits en appliquant les modifications sur le fichier de référence
- Pour vivre sans !
Vivre sans, c’est possible .. Mais à, mais yeux, on n’a pas justification valable. Car, il y a de bons produits open source et même des sites web qui offre ce service.
Ce n’est pas la qualité de votre personnel ou de vos processus qui peuvent justifier l’absence d’un outil dans votre environnement de développement logiciel.
A titre d’exemple, même les projets que je suis le seul développeur, j’utilise un outil de gestion de sources. Donc, pourquoi pas vous ?
- La conclusion
En conclusion, développer un logiciel, c’est bien plus que d’écrire du code qui va répondre aux quelques notes qu’on avait prises pour dire ce que ça ferait.
Si ça était si facile, tout le monde le ferait et nos grandes écoles (collèges et universités) ne forceraient pas pour l’enseigner. Il n’aurait pas non plus des gars comme moi qui prônent l’idée et pour certain en écrive des livres sur le sujet.
Tenez-le pour dit, sans c’est 4 murs indispensables à la construction d’un bon logiciel. Vous allez m’entende argumenter longuement et avec beaucoup d’acharnement.
Vos ressources sont compétences, donnez leur un bon environnement de travail et surtout de bons outils. Ils ne pourront qu’en être meilleurs et davantage concentrer sur le vrai travail de développement logiciel.
Comment choisir ou quelle tâche choisir dans un Scrum Board ?
Comment choisir ou quelle tâche choisir dans un Scrum Board ?
Ces deux petites questions, ils me sont souvent posés. Parce que beaucoup de gens ne savent pas comment choisir les différentes tâches. Par réflexe, beaucoup de gens cherchent à choisir les tâches qui aiment en premier, en espérant que les activités qu’il n’aime pas seront faites par d’autres.
J’ai vu à quelques reprises ce phénomène arrivé. Vers la fin du cycle, on se retrouve avec seulement les unités de traitement que personne ne veut faire.
Mais, parfois, ces infâmes, elles sont parfois prérequises ou postérieures à une autre tâche plus « fun ». Donc, si personne ne l’a fait rapidement. En fin de sprint, on risque de prendre du retard voir être incapable de respecter sont engagement tout ce qui a sur ce Scrum Board.
Donc, comment faire pour bien choisir les différentes tâches. Généralement, je leur explique une petite règle fort simple. Elle se compose de trois éléments.
Un exemple, tu prévois faire dans ta semaine cinq unités de travail. Prends 2 que tu as beaucoup de fun à faire, celle que tu payerais presque pour les faire. 2 autres que tu as moins d’intérêts et une malgré tes compétences tu ne prends pas de plaisir voir que tu détestes faire.
Mais, parfois il ne faut se limiter à bien choisir ces tâches. Il faut aussi savoir les ordonner. En plus, de la répartition que j’ai expliquée plus haut. Il faut garder à l’esprit que nous voulons tous avoir du fun et idéalement toute la semaine. Donc, il ne faut jamais garder à l’esprit que si nous faisons à la fin la tache que nous n’aimons pas. Il y a un risque que nous soyons moins efficaces à la faire.
Pour ma part, je commence toujours ma semaine avec des taches que j’ai du plaisir. Après tout qui aime les lundis. La deuxième que je choisis dans les trois que j’ai moins d’intérêts, voire celle que je déteste. Durant l’exécution de celles que j’aime moins, je pourrais me motiver en me disant qu’il m’en reste une le fun pour la fin.
Avec cette petite règle simple, normalement tout le travail sera fait efficacement. N’oublions pas, nous sommes engagés individuellement et en groupe à livrer toutes les taches. Je crois que cette petite règle nous aidera à les livrer dans le bonheur.
Mais, ce n’est seulement un conseil, pas une loi à suivre les yeux fermés, c’est une solution parmi tant d’autres. Trouver votre méthode ! Celle-ci en sera peut-être l’une de votre.
Le super programmeur !
Un rôle si important, mais qui, dans beaucoup d’organisations, est en voie de disparition. Pour ne pas dire inexistant.
Mais, qu’est-ce qu’un super programmeur? Pourtant, je suis sur que vous en avez connu. Vous savez ce genre de programmeur qui programme plus vite que son ombre. Celui qui est capable de programmer n’importe quoi, mais surtout à la vitesse super Grand « V ». Le Programmeur qui est capable de construire un bout de code de grande qualité, en temps ridicule. Ces machines à produire du code.
J’ai connu et j’en suis sûr, vous aussi, des programmeurs qui étaient capables de coder 3-4 fois plus vite que les autres. Quand tout le monde se sauvait et disait que c’était impossible à résoudre, eux apportaient la solution aux problèmes. Eux, leur cerveau est conçu comme à machine à programmer.
Mais, malheureusement aujourd’hui avec les « Échelles salariales », ces super programmeurs finissent par avoir atteint la limite de l’échelle et de l’avancement possible. De plus, il faut reconnaître leur « Excellent » travail. Et dans les échelles classiques, c’est un peu impossible.
Pourtant, on a souvent besoin de ces superhéros du code dans les projets. Surtout ceux qui, en plus de leurs qualités de codeurs, sont d’excellent travailleur d’équipes. Combien de fois, en tant qu’architecte, j’aurais souhaité avoir une de ces « bêtes rares » pour valider certains concepts que seuls, ces supers programmeurs, pourraient faire.
Mais, comme ce rôle de « Super Programmeur » a disparu ou n’existe tout simple plus dans la grande vision de nos gestionnaires, on doit souvent faire des tours de passes passes. Car, j’avoue que c’est difficile, voir complexe de différencier un programmeur normal d’un super programmeur. Ce travail demande une grande expertise pour les identifier. Il y a beaucoup d’appelés, mais peu d’élus. Surtout ceux qui seront heureux encore longtemps, d’être de super programmeurs.
Donc, beaucoup de gestionnaires ont choisi la voie facile, en leur donnant une promotion au titre d’architecte. Souvent à celui d’architecte organique.
Mais, le problème, le rôle d’architecte organique et celui de super programmeur, demandent des compétences totalement différentes. Le super programmeur doit avoir une connaissance très approfondie de code et du langage de programmation. Il doit pouvoir répondre au comment on va programmer ou coder cette procédure ou cette fonction. Il doit être une encyclopédie vivante du code ou de l’environnement en question.
Quant à l’architecte, il doit répondre à la question du design. Comment l’ensemble va fonctionner. Et non, le détail d’une procédure ou d’une fonction. Il doit apporter la vision sur l’ensemble du projet. Je m’amuse souvent à résumer que mon travail d’architecte, c’est justement de trouver comment on va éviter de coder telle ou telle partie. Et ce que veut le super programmeur, c’est justement codé !
Avoir un bon architecte et un super programmeur, c’est un pair qui augmente la possibilité de succès du projet. L’architecte apporte la vision de la solution et le programmeur confirme la faisabilité de la solution.
Les super programmeurs ont le droit aussi à l’avancement et de faire reconnaître leurs compétences si exceptionnelles. Je crois qu’il faut transformer nos organisations pour leur faire une place. La place qu’ils méritent vraiment.
Lorsqu’on donne une promotion à une personne, ce ne doit pas être une punition. Mais, une récompense. Un vrai programmeur, encore plus un super programmeur, déteste profondément faire de la documentation et du design. Donc, lui donner un rôle où il fera de moins en moins de code et où il aura à produire de la documentation. C’est vraiment lui donner la meilleure punition.
Je ne dis pas qu’un super programmeur ne peut pas devenir un architecte ou un analyste. Mais pour le devenir, il doit aussi avoir les compétences qu’implique telle ou telle fonction. J’ai vu souvent de super programmeurs qui sont devenus architecte (sans avoir les compétences nécessaires), malheureusement tant pour eux que nous. Le travail, surtout la documentation, était très teinté par le code qu’il imaginait derrière. Je crois qu’un bon architecte ne doit pas être influencé par le code. Mais par le travail qu’il doit accomplir et son environnement.
J’ai vu certains qui devenaient aigris, qui n’avaient plus la possibilité de faire ce qu’ils aiment vraiment. Permettons-leur d’exploiter leur si grand talent pour la programmation, permettons-leur de continuer leur excellent travail. Ce sont des gens d’exception, ne les détruisons pas à leur faire faire autres choses que ce à quoi ils sont les meilleurs.
L’informatique n’est hiérarchique. Mais une structure à cmpétences diverses. Donc, reconnaissons le travail de chacun et j’en suis sûr que nos projets n’en seront que de meilleure qualité et surtout livrés plus rapidement. En terminant, j’espère que vous ferez la réflexion de savoir si vous devez ou non ajouter ce rôle à vos équipes.
Contrôler le chaos : comparaison entre les approches traditionnelles et les méthodologies Agiles
1 Introduction
La plupart des méthodologies modernes visent à contrôle du chaos qui peut survenir dans un projet informatique. Chacun a sa stratégie et si on demande aux experts de la méthode, chacun dira que la sienne est meilleure.
Le chaos c’est quelque chose qui ne devait pas arriver. Mais qui peut arrive. Donc, gérer le chaos, c’est de gérer l’incertitude des évènements possibles.
2 La comparaison
Chacun propose un modèle qui permettra soit géré ou encore faire face au chaos. Mais, généralement on trouve 2 grands modèles. Le premier est modèle prédictif, qu’utilise généralement la méthode Mérise ou la méthode Macroscope.
Quant aux secondes modèles, celui qui est utilisé par les méthodologies Agiles est plus réactif que prédictif.
2.1 Le modèle prédictif
Par le modèle prédictif, comme son nom l’indique, on essaie d’établir un plan de travail qui va défini l’ensemble des étapes nécessaires pour livrer le projet. D’abord en définissant, les grandes étapes qui seront bien sûr en sous étape.
Le plan résultant final permet de livrer le logiciel selon un calendrier défini. Et si en cours, de route le client arrive avec un changement. Le modèle prévoit une mécanique de gestion des demandes changements et généralement, les demandes de changements sont exécutées en fin de projets.
2.1.1 Le problème du modèle prédictif
Malheureusement, même si vous c’est vos meilleurs planificateurs qui construisent les plans de travail. Il arrivera des problèmes, des changements qu’ils étaient impossibles à prévoir.
La mécanique des demandes de changement fonction généralement bien. Il ne permet pas de changer rapidement de directions ou d’orientation du projet.
Mêmes choses, lorsque problème survient en cours de routes, il devient difficile de suivre le beau plan et redemande un replanification. Donc, le chargé de projet, aussi un bon comptable pour pouvoir bien gérer les budgets.
N’oublions qu’avec le plan, vient un budget qui va couvrir tous les frais d’exécution. Donc, tout changement va demander un rajustement de budget, et j’ai vu rarement à la baisse.
2.1.2 L’avantage
Ce modèle est plus simple à expliquer et à justifier aux dirigeants d’entreprises. Car, ils peuvent voir comment va « normalement » se dérouler le projet et surtout comment sera dépensé l’argent qui sera alloué pour lui.
Le gestionnaire pourra suivre aussi facile. Il aura aussi par conséquent, avoir des points de contrôles réguliers.
2.1.3 Type de projets
Cette approche fonction pour des types de projets, dont le risque, ou la gestion du risque est limitée. Un projet dont nous avons une plage de fonctionnalités définie. Il est facile d’établir un plan de projet.
Il vous suffira de mettre un bon gestionnaire de projets qui géré, les différents imprévues qui pourra arriver.
2.2 Le modèle réactif
Le modèle réactif est le modèle qu’utilisent les méthodologies pour gérer et accepter le changement qui peut arriver encore de route.
Je précise, ce n’est pas parce qu’on est dans un modèle plus réactif qu’on ne fait de la planification. Sans écrire de long plan, je prends des notes pour planifier mes journées ou mes semaines de travail.
2.2.1 Le délai ou la durée
Les approches traditionnelles essaient de planifier aux mieux l’ensemble du projet. Tous les travaux qui seront à faire. Mais, les approches agiles, un prédicat qu’il va avoir du changement qu’on nous devrons l’adresser.
Au lieu de faire une planification pour la durée complète, on fait pour un court cycle. On découpe aussi le projet en phases. Et pour chacune, des phases l’objectif est de livrer une partie de logiciels fonctionnels et utilisables.
2.2.2 Le cadre budgétaire
Comme nous ne défissions pas un plan global pour le projet. Il est donc impossible de définir un budget global pour le projet. Nous travaillons avec un cadre ou une enveloppe budgétaire définis.
Ce budget ne couvera pas l’ensemble du projet. Mais, un parti que les différents cycles pourront puiser.
L’avantage de modèle budgétaire, c’est que nous savons ce que va couter cette phase du projet.
2.2.3 La liste d’épicerie
Imaginer partir à l’épicerie, avec liste et un billet de 100$, sans savoir les différents prix des articles à acheter.
Il est facile de mettre tous les articles dans le panier, sans compter. Mais, lorsqu’il sera temps de payer à la caisse. Il pourrait arriver qu’on manque d’argent. C’est pourtant ce que fait le modèle prédictif.
Dans un modèle, réactif, au lieu de tout mettre dans le panier sans compter le prix final. Nous priorisons d’abord, avant de partir à l’épicerie, l’importance des différents articles.
Une fois rendus à l’épicerie, nous pourrons choisir les articles selon la priorité, l’importance. Mais surtout en respect à notre budget. Donc, arrivés à la caisse, nous n’aurons pas de difficulté à payer.
2.2.4 La réaction aux changements
Au lieu de mettre en place une mécanique, qui est parfois complexe, qui permet d’adresser en fin de projets, les demandes de changements. On dit aux clients que le changement est bienvenu. Mais, qu’il pourrait avoir des conséquences le contenu de son panier d’épiceries.
Exemple si, notre conjointe nous appelle pendant l’épicerie, nous pourrons devoir choisir d’échanger ou non, un article. Le tout en contexte de notre budget : temps et argent.
De plus, comme le cycle de livraison est court, généralement 2 à 4 semaines, il sera facile de le planifier pour le cycle suivant s’il n’y a pas de possibilité de l’inclure dans le courant.
2.2.5 Les types de projets
Le modèle prédictif convient généralement pour de projets qui contiennent beaucoup d’incertitude. Exemple des projets qu’il y a beaucoup, de recherches et développements.
Souvent, il est utilisé dans application de technologies de pointe, dont l’organisation n’a pas encore la parfaite maitrise.
Le développement d’applications qui sont destinées dans un marché en plein mouvement Il fonctionnement bien dans ce genre de modèle.
2.2.6 Les inconvénients
Cette approche permet de réduire l’incertitude en réduisant le délai de livraison. Mais, c’est bien beau de le dire dans une phrase. Mais, il aura aussi des impacts sur l’organisation tant du travail.
Dans les approches traditionnelles, la livraison s’effectuait en fin de projet. Mais, avec l’approche le plus part des approches Agiles, l’équipe de projets livrent une partie du logiciel dans un délai court, 2-4 semaines et surtout à rythme soutenu.
Donc, il faut aussi en prendre conscience.
3 Conclusion
Les deux approches cherchent à leur manière à gérer le chaos. Mais, chacun utilise une stratégie différente de l’un de l’autre. Ni l’une ni l’autre n’est meilleure que l’autre. Elle convient à différents types de projets et d’organisation. N’ayez pas peur de prendre le temps d’évaluer vos besoins et surtout des impacts sur votre organisation.
Si vous voulez posez une réflexion sur l’impact des méthodologies agiles, je vous invite à lire ce billet : Agile, de Haut jusqu’en bas, et Droite à Gauche.
Une vingtaine d’idées ou attitudes gagnantes pour promouvoir votre carrière dans le monde des méthodologies Agiles!
Aujourd’hui, je suis tombé sur ce petit billet en anglais 20 Simple Things You Can Do to Boost Your Agile Career et j’ai l’idée de vous traduire. Mais, surtout compléter par mes réflexions personnelles.
| # | Idées | Réflexions |
| 1 | Prenez vous responsabilités | Il faut être responsable tant dans ses actions que des ses paroles. Il ne faut pas, il ne faut plus passer au suivant la responsabilité de no actes insouciants. |
| 2 | Vous dit que vous allez faire quelque chose. Faites-le ! | C’est une belle parole à dire. Mais, il ne faut pas juste l’affirmer haut et fort. Mais, il faut le vivre.
J’ai vu trop souvent entendre des gens, qu’ils allaient faire ceci ou cela. Mais, que dans les faits, ils ne faisaient rien en bout de course. |
| 3 | Aidez les autres. | La meilleure ressource, ce n’est pas celle qui trouve toujours la solution. Mais, cette qui aide tous les membres à la trouver.
Le travail d’équipe en agile a toute son importance. |
| 4 | Le respect | Travaillez dans une équipe que les échanges et les communications ne font pas sous la base du respect. Je ne suis pas intéressé.
Je rappelle toujours à mes équipes. Vous ne savez pas quand, vous aurez besoin de votre besoin. Donc, arranger-vous qu’il soit ouvert à vous aider lorsque ce jour arrivera. |
| 5 | Soyez positif, ayez une attitude positive | C’est normal de ne avoir pas le moral de temps en temps. Mais, avoir une attitude négative tout le temps ça affecter le moral de toute l’équipe. Donc, la performance négative de celle-ci
À l’inverse, l’attitude positive d’un membre, influence aussi positivement la performance de l’équipe. Dites bonjour avec un sourire le matin et vous verrez l’effet que cela aura. |
| 6 | Accepter le changement « Embrace change » | Le changement fait partie de tout projet informatique. Donc, il faut en prendre conscience et surtout l’accepter. |
| 7 | Suggérez des améliorations | Si vous voyez de choses améliorer, partagez les. Ne les gardez jamais pour vous. Mais, soyez aussi conscient que ça pourrait arriver que votre position ne soit pas mise en œuvre. |
| 8 | Portez attention aux petits détails. | C’est la somme des petits détails, surtout la somme des petites erreurs qui feront en bout de course que l’application soit fonctionnelle ou pas. |
| 9 | Soyez fier de votre travail | Lorsqu’on est fier de notre travail, nous en prenons généralement plus grand soin. De la petite choses jusqu’à la grande, soyez en fier ou verrez, elle sera plus facile à faire. Et la qualité suivra ! |
| 10 | Travaillez dur | Travaillez dur, travaillez efficacement. Travaillez sur quoi ça rapporte au projet. |
| 11 | Soyez formé, soyez informé | Je crois que nous sommes jamais assez bien informés ou formés sur notre travail ou le travail qu’il y a faire. Poser des questions est signe d’intelligence. Ne pas en poser, c’est…! |
| 12 | Partagez vos connaissances | Vos connaissances, c’est une de vos grandes richesses. Si vous voulez la faire grandir. Le seul moyen que je connais, c’est de la partager. |
| 13 | Ayez une attitude de professionnels | Vous n’êtes pas perdue dans le bois toute seule. Vous vivez dans environnement avec d’autres. Imaginez que si c’est à vous, que vous feriez vivre cette mauvaise attitude. Comment réagiriez-vous ? |
| 14 | Rester flexible | Parfois la meilleure solution, ce n’est pas celle qui convint. |
| 15 | Faites tout ce qu’il faut faire | On ne devrait jamais faire les choses à moiré. Pourtant, il est si facile de faire autrement. |
| 16 | Soyez honnête ! | En parole et en acte.. ! Je préfère que me disent 100 fois par une personne qu’elle n’est pas compétente.
Qu’elle le fasse tout de travers de peur d’avouer son incompétence. Et en fin de compte, que je sois oublié de reprendre entièrement le travail. |
| 17 | Soyez modeste | Pour ma part, quelqu’un qui a la grosse tête sur un projet. C’est un des pires éléments qu’il peut avoir.
Reste simple et les honneurs arrivent bien assez vite. |
| 18 | Laissez les autres vous faire des éloges. | La suite d’idée que la précédente ..! Dire qu’on est bon. C’est facile. Le démontrer, c’est un autre pair de manche. |
| 19 | Soyez heureux et aimé votre travail. | Être heureux, c’est ce que voulons tous. Donc, adopter une attitude en conséquence. |
| 20 | Soyez vous-même ! | Ce que les gens achètent c’est que vous prétendez être.. Si vous faites de fausses représentations. Elles seront dures à soutenir ! |
Cette traduction était très libre. Je voulais avec poursuivre la réflexion amorcé par le premier billet.
Ê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
Quand et comment, on devient un « Coach Agile »
Lorsque je regarde mon parcours qui a fini, par me faire devenir un coach Agile. La seule réponse que je peux dire sur le « quand » je le suis devenu.. C’est que je le ne suis jamais devenue, je l’ai toujours été, c’est la formation et l’expérience qui fait que j’en suis devenu un bon, c’est tout.
Le comment n’est pas plus simple à répondre. Car, il n’y a pas de parcours parfait, un parcours qui mène à un succès garanti. Je connais plusieurs « Coachs Agile » et on a tous des parcours différents.
C’est souvent une question de qualités personnelles qui font qu’on devient un jour un « Coach Agile ».
Je pense qu’il faut avoir beaucoup d’entre gens et de l’ouverture d’esprit avec une bonne dose de patience. N’oubliez pas, on accompagne et on forme des personnes, donc on doit communiquer et échanger avec elles.
Des formations en animation de groupe ne peuvent pas nuire lorsque vous aurez à animer des groupes. Mais, avant de vouloir former les autres, il faut aussi se former soi-même. Il faut bien apprendre sur les sujets qu’on veut accompagner. Il ne suffit pas de lire le livre « Agile pour les nuls » pour être capable de former les gens en Agiles.
Il faut avoir mis cent fois, peut-être milles fois sur le métier les choses qu’on veut enseigner. Car, je peux vous le confirmer, qu’il y a toujours un étudiant qui vous posera la question qui tue !La question que vous n’aurez pas immédiatement la réponse. Donc, il faut s’y préparer ! Il est intéressant d’avoir beaucoup de « backgrounds » pour ne pas vous planter à première question.
Ainsi, il faut lire beaucoup, écouter encore plus le besoin des autres. Mais, surtout d’être assez humble pour répondre, le jour on se fait poser une question que n’ont pas la réponse, qu’on ne l’a pas maintenant. Mais, qu’on va revenir plus tard avec elle, une fois qu’on l’aura trouvé.
En résumé, les questions quand et comment ne se posent pas. C’est un cumul de différentes choses; des expériences diverses, de la formation et de l’auto formation, d’intérêt biens sûrs et surtout de ne pas avoir peur de se tromper et de recommencer qui fera peut-être un jour vous deviendrez un coach Agile.
Chaque Coach Agile que j’ai connu aux files de ma carrière, avait tous un parcours différent. De ce fait, si vous voulez devenir un « Coach Agile »! Faites votre propre chemin, toutefois soyez prévenue que la route sera longue et remplie d’embuches. Mais, pour moi, lorsque je regarde en arrière, je ne ferais jamais d’autre choix qui m’on conduit à devenir un coach Agile aujourd’hui. J’aime ce que je fais, j’aime aider les gens à mieux travailler et j’espère toujours lorsque j’accompagne quelqu’un qu’il devienne rapidement meilleur que moi. Là mon travaille de coach sera un succès.
Un proverbe japonnais dit : « On reconnaît l’excellent d’un maitre d’arts martiaux, lorsque son meilleur élève le surpasse ». J’essaie toujours d’avoir cette attitude !
Je n’ai pas de solutions, juste une approche pour en trouver.
Souvent, je commence mes interventions chez mes clients par cette phrase. Je ne vous le cacherai pas, plusieurs restent surpris ! Un consultant qui n’a pas de solution !
C’est pour cela que je prends toujours le temps de leur expliquer qu’il m’est impossible d’avoir une solution à un problème que je ne connais pas ! Et que même que lorsque j’aurais une connaissance suffisante du problème à résoudre, la choix de la solution de m’appartiendra pas.
La meilleure des solutions ne conviendra peut-être pas à son contexte d’entreprises ou de personnes. Pour expliquer, je prends souvent de l’exemple: Il peut vouloir aller chercher un litre de lait au dépanneur !
Pour aller chercher son litre de lait, je peux lui proposé plus moyens de transports (plusieurs solutions). Mais, si je ne regarde pas ses capacités ou ses intérêts. Le choix de la solution, dans ce cas si le moyen de transport, il sera mauvais par définition. Donc, il n’est pas ma responsabilité de faire ce choix. Mais, bien de conseiller au mieux notre client en lui proposant plusieurs solutions dans son contexte.
Ce principe d’idées s’applique aussi à l’informatique et au développement logiciel. Trop souvent nous voulons livrer NOTRE meilleure solution sans regarder au contexte.
Donc affirmant que je n’ai pas de solutions. Je ne veux pas dire que je suis dans l’incapacité d’en trouver. Mais, que peu importe la solution ou les solutions que je pourrais trouver. Je dernier choix ou encore la décision sur la solution choisis, ne repose pas sur mes épaules, mais sur celle du client.
En conséquence, nous devons être là pour conseiller, pour apporter des lumières les choix possibles, poser des questions qui permettront en bout de courses aux clients de prendre sa meilleure décision.
Il ne faut pas oublier que notre premier devoir en appliquant cette approche que nous ne devons pas à trouver une seule solution, mais un éventail de solution possible !
Les devoirs d’apprentissage de la problématique restent tout aussi présents. En amenant le client à prendre et comprendre tant son besoin que les solutions possibles. Là je pense qu’est la seule solution qu’on peut avoir tout long du projet bien plus qu’une simple réponse ou qu’une simple solution.
En terminant, la prochaine fois qu’un client vous demandera si vous avez une solution à son problème. Essayer de lui dire que vous n’en avez pas, que vous avez seulement une approche pour en trouver. Bien sûr, j’espère que ce sera une approche Agile. Si vous le faite avec confiance, je suis sur que le client travaillera longtemps avec vous.
Priorité à l’efficacité!
Un jour, un vieux sage en affaire m’a donné un conseil pour les affaires. Celui-ci s’applique très bien aux développements logiciels.
Je le partage aujourd’hui avec vous:
"Toujours donner la priorité aux choses qu’on peu faire efficacement soi-même , pour les autres, on demande à quelqu’un de plus habile dans ces domaines de les faire de façon efficace."
Pour démontrer son point, il me disait de comptabiliser le temps consacré à chacune des taches que je fais aux mêmes tarifs que je charge sur un contrat. Une fois comptabilisé, on compare les couts. Si le cout qu’on charge à notre compagnie est équivalent à plus de 75 % du coût d’un spécialiste ou tout simplement d’une personne plus compétente que nous, cette tâche doit être déléguée.
Notre temps doit être consacré à mieux servir notre client. Servir un client, ce n’est pas juste lui livrer quelque chose. Mais lui livré de la qualité.
Appliquons maintenant cette belle réflexion à l’informatique et plus précisément aux développements logiciels.
Même si nous sommes tous des informaticiens compétents. Nous avons tous nos forces et nos faiblesses. Je me prends pour exemple, concevoir un modèle de donnée ou même des requêtes SQL pour l’exploiter. Non, seulement je vais le faire avec efficacité. Mais aussi avec grand plaisir. Par contre, faites-moi faire du JavaScript ou encore CSS. Je vais y arriver sans pour autant y être efficace.
Ce n’est pas vrai que parce que nous sommes de bons informaticiens, nous sommes efficaces dans toutes les sphères. Tout faire pour notre client, ne veux pas dire perdre du temps précieux, mais bien travailler intelligemment. N’oublions pas que c’est dans son intérêt à lui que nous travaillons.
Donner priorité à l’efficacité, c’est aussi de choisir les tâches pour lesquelles l’exécution est rentable autant pour le client que pour l’entreprise.
Je sais, c’est parfois impossible pour différentes contraintes de donner ou de laisser les tâches, pour laquelle nous sommes moins compétents, à quelqu’un d’autres. Mais, il faut chercher à mettre l’accent sur les bonnes priorités. Tant dans notre gestion d’entreprise que sur les mandats que nous octroient nos clients.
Si vous étiez le client, est-ce que vous vous payeriez pour faire ce travail, sachant que vous n’êtes pas le plus efficaces?
Génération Agile
