Ce qui empêche le mise en place d'une transformation agile

Cela fait plusieurs fois que je trouve ce genre d'article sur les réticences à la mise en place de l'agilité, les coachs agiles, comme un peu frustrés par l'empêchement, y donnent leur leçon d'agilité. 

Je pense plutôt que c'est le fait de la société actuelle de ne pas vouloir être agile les coachs en agilité ne pourront rien y faire.

Car il y a une réelle volonté farouche de freiner l'agilité parfois même inconsciente.

Mise en place de l'Agilité en entreprise

Avant même de lire l'article, je le ressens ainsi car l'agilité prône la liberté des acteurs de l'entreprise. Je peux constater que ce n'est pas le cas sur le terrain, ce n'est pas la volonté de certains que de donner de la liberté dans leurs entreprises, croyez-moi ils ont un management totalement différent.

D'autres cadres de travail en agilité, comme SAFe, prône la dilution de la responsabilité vers les équipes. Là encore pour le "petit chef à l'ancienne du management franco/français", c'est exactement le contraire qu'il recherche. Il veut des outils pour mieux contrôler, mieux cornaquer ses équipes et cela, ce n'est pas tout Agile.

Alors regardons ensemble :

Siècle Digital - 5 caractéristiques empêchant la mise en place d'une transformation agile

Dans cet article, j'ai ressenti une grande maîtrise de l'exercice, de l'agilité vécu sur le terrain et le recul nécessaire à la compréhension.

L'agilité se définit comme une culture et des valeurs permettant d'être performant dans un environnement complexe. La direction doit s'impliquer dans le passage à l'agilité sinon point d'agilité.

Les quatre verbes : livrer, communiquer, réfléchir, s'améliorer.

L'agilité chez les éditeurs de logiciel doit être naturelle, intégrée dans l'ADN de l'entreprise. Le logiciel est une chose complexe à produire qui se modifie constamment et doit franchir des marches technologiques aléatoires pour continuer à exister sans quoi il se fige, se sclérose et meurt. 

Le point 3 : On parlait des indicateurs KPI, voilà un écueil de l'agilité la capacité de production comme indicateur. On connait des entreprises qui sont organisée avec leur service Qualité accouplé à la production et qui ne résonne qu'en indicateur, la vélocité comme indicateur du bon fonctionnement d'une équipe met continuellement l'équipe dans le rouge.

Et bien voilà, moi je ne n'ai pas besoin d'aller plus loin car je sais qu'il n'y a plus de culture d'entreprise, les entreprises ne cultivent plus, stressées par la mondialisation, elles ont totalement abandonné l'idée de la création d'une culture d'entreprise.

Voilà, nous venons de voir rapidement les freins à l'instauration de l'Agilité dans l'entreprise.

CQFD !

Le TDD (Test Driven Developement) par la pratique

Alors le TDD est certainement le sujet qui fait couler le plus d'ancre dans le domaine du développement logiciel c'est dernières années avec cette question de base : Faut-il faire du TDD ?

Test Driven Development

Il s'agit des Tests et de faire des Tests de façon à ce que ces Tests Drivent (dirigent) le Développement. Les pratiques du TDD sont pratiqués autour d'outils comme les Frameworks de Tests Unitaires. 

Au delà de TDD, je trouve "Crafts" avec "Craft Developer, software craftsmanship (l'artisant du logiciel).

Wikipédia - Software craftsmanship

Vous trouverez l'historique de la méthode Software Craftsmanship, vous découvrirez également l'Uncle Bob (Robert Cecil Martin) qui en 2008 proposa une cinquième valeur au Manifeste Agile :

"craftsmanship over execution" En français: "l'artisanat plus que l'exécution".

Cette fois lorsque l'on évoque l'amélioration continue, il s'agit de l'amélioration des humains qui deviennent meilleurs en partageant leurs pratiques, en travaillant conjointement et de manière collaborative. Ainsi chaque développeur devient artisan développeur en améliorant ses compétences et en devenant soucieux de délivrer de la vraie valeur.

On remarque l'imbrication du TDD de l'Agilité et de Crafts pour mener vers une méthode logicielle complète et globale, coder comme art de vivre. Le Software Craftsmanship est complémentaire à l'Agilité.

Ils ont tous les deux un manifeste, une somme de travaux réunie dans un document cours et réalisé par les meilleurs professionnels du domaine.

D'après ChatGpt voici les grands principes Software Craftsmanship :

1. Code propre, facilement compréhensible, bien structuré et maintenable en suivant les principes SOLID.
2. Test Driven Development (TDD), les artisans logiciels écrivent d'abord des tests automatisés avant de coder la fonctionnalité correspondante.
3. Pair programming : Deux programmeurs travaillent ensemble pour favoriser l'apprentissage mutuel, le partage des connaissances, l'amélioration des compétences et la qualité du code.
4. Amélioration continue : Les Softwares Craftsmanship participent à des communautés, assistent à des conférences et partagent leurs connaissances avec d'autres développeurs.
5. Livraison régulière et itérative : Chercher à fournir des fonctionnalités de manière régulière et fréquente, en se basant sur les commentaires des utilisateurs.

Collaboration et communication : avec les clients, les utilisateurs et les membres de l'équipe.

► Pour une présentation de la méthode TDD :

Blog de Jean-Baptiste Vigneron - TDD ou le développement piloté par les tests

Dans un développement classique on ajoute du Code et puis on ajoute de Test permettant de tester ce code. Dans la méthode TDD on écrit d'abord le Test puis le code qui doit vérifier ce Test.

► Pour en terminer avec cette question de ; faut-il faire du TDD, je vous laisse avec le Podcast de Benoit Gantaume :

Artisan Développeur - TDD sous stress avec Khaled Souf

Et voilà, en partant de TDD, on est passé par l'Agilité, on a poursuivit avec Crafts et Software Craftsmanship, nous avons fait un tour des nouveautés sur les méthodologies modernes de développement logiciel.

N'hésitez pas à commenter.

Programmation et principe SOLID

Pour créer un bon code source, il est souhaitable d'utiliser les principes de la méthode SOLID, voici donc les cinq principes à utiliser absolument (au minimum) dans l'écriture de votre code source :

Single responsability : Une classe pour une seule responsabilité

Open/close : Ajouter de nouvelles fonctionnalités sans modifier la classe grâce à l'abstraction et au polymorphisme en créant des classes de base pour factoriser du code commun à tous les objets

Liskov principe de substitution : Les classes génériques (ou dérivées) peuvent être remplacées par leur classe de base

Interface : Principe de ségrégation d'interface, on ne doit pas dépendre de fonctions dont on n'a pas besoin. On doit définir des interfaces qui n'obligent pas à implémenter des fonctions dont on n'a pas besoin. Il vaut mieux créer plusieurs interfaces et les objets plus complexes devront implémenter plusieurs de ces interfaces

Dependency injection : Les classes de haut niveau ne doivent pas dépendre des classes de bas niveau, les abstractions ne doivent pas déprendre des détails. En créant des interfaces comme des contrats de fonctionnement.

Il y a plein d'autres choses à voir pour écrire du code réutilisable mais avec SOLID, on a un moyen mnémotechnique qui permet d'aborder cinq sujets profonds pour développer du code source.

Document d'Architecture et de Justification Technique de la Solution Logicielle

Je souhaite vous faire part du le seul document que je souhaiterais trouver systématiquement quand j'aborde la reprise d'un logiciel existant. Un seul document en dehors du code pour comprendre la genèse de la solution logicielle face à laquelle je me trouve.

Et pourtant ce document n'existe que très rarement, il est souvent en morceaux dans d'autres documents de la Qualité Logicielle, je veux vous parler du Document de Justification Technique (DJT).

Wikipédia - Architecture Logicielle

La qualité logicielle, suivant la méthodologie que vous utilisez, préconise un tas de documents suivant le référentiel mais il y a un document que je ne trouve jamais qui me parait pourtant le seul utile à un nouvel arrivant sur un projet logiciel, c'est le Document d'Architecture et de Justification Technique.

On vous parlera du DAT - Document d’Architecture Technique qui est le document réalisé par l'architecte technique au démarrage du projet dans lequel il décrit les briques de base et leurs imbrications dans la réalisation de la solution.

A l'instant donné du démarrage d'un projet, je peux concevoir que l'architecte ne se soit pas posé trop de questions sur la maintenance et les évolutions dans le temps de la solution qu'il met en place mais quelques années après, lorsque j'arrive pour reprendre ou continuer la solution, ce document ne me suffit pas. 

Le DAT est l'image du projet à son démarrage et je souhaiterais absolument savoir pourquoi le choix de ces briques de base ont été faits au début du projet.

Au démarrage du projet l'architecte a fait ses choix de briques car il les connait, les maîtrise, sait comment les mettre en oeuvre, son DAT porte ainsi sa vision de la solution mais avec de l'expérience et du recul, vous savez qu'il en existe d'autres, peut être mieux adaptées, plus facile à maintenir, à mettre en oeuvre. 

C'est là que la partie "justification technique" de ce document est très importante.

Ajout de la Justification Technique au DAT

Par exemple l'architecte de la solution peut très bien écrire, je préconise d'utiliser la brique untel car c'est la seule qui existe pour résoudre cette problématique. Il peut également écrire, nous avions à notre disposition la brique 1 et 2 ou 3 pour telle raison, j'ai choisie la 1.

Quand vous arrivez quelques années après, vous savez alors pourquoi le choix de telle brique a été fait à l'époque. 

Depuis d'autres briques sont apparues sont peut être mieux adaptées mais vous savez alors pourquoi elles n'ont pas été utilisées dans cette solution soit parce qu'elles n'existaient pas soit parce que l'Architecte ne les connaissait pas mais vous connaissez la justification technique du choix qui a été fait.

Donc le Document d'Architecture Technique ne suffit pas, il faut y ajouter les briques envisagées au démarrage du projet, et justifier les choix de telle ou telle brique logicielle, plutôt que telle autre pour que la solution logicielle soit maintenable, reprenable et pérenne.

J'ajoute que même si aujourd'hui dans les plans de DAT on trouve maintenant parfois :

"Vous définissez votre choix et expliquer les raisons qui vont ont poussé à le faire, en citant quelques alternatives possibles."

Vous verrez que dans la pratique sur les différents DAT que vous aurez l'occasion de lire, vous ne trouverez pas cette notion de justification de la solution technique.

Mise d'un logiciel en Tierce Maintenance Applicative ou TMA

La Tierce Maintenance Applicative consiste à transférer à un tiers, une prestataire externe, la maintenance d'un logiciel d'une application. Elle implique trois acteurs l'éditeur du logiciel, son client l'utilisateur et le prestataire qui exécute la TMA.

L'éditeur du logiciel peut alors se concentrer sur ces nouveaux développements sans que ses ressources ne soient occupées, chargées par les corrections la maintenance d'un logiciel déjà livré.

On met le logiciel en Tierce Maintenance Applicative il peut alors être installé sur un environnement différent de l'environnement de développement. La mise en Tierce Maintenance Applicative du logiciel permet à l'éditeur de faire la liste exhaustive de ce qu'il faut pour "faire tourner" le logiciel.

On comprends que cette pratique ait eu du succès entre les entreprises du logiciel. Le principal atout pour l'éditeur, c'est de pouvoir focaliser ses équipes R&D sur des développements des futures releases et non sur la relation avec la client une fois que le logiciel aura été livré.

On peut voir la TMA comme un avantage pour le client utilisateur du logiciel qui est face à une équipe dédiée pour résoudre ses éventuels problèmes avec le logiciel. 

Le prestataire acquière des compétences particulières génération déploiement du logiciel qui n'intéressent pas forcément les ressources R&D de l'éditeur.

La TMA se déroule en trois phases :

Transition

C'est la phase pendant laquelle l'éditeur qui a réalisé la première livraison et le premier déploiement en production, transmet son savoir faire au prestataire de TMA qui devient capable de faire des corrections du logiciel et de déployer une nouvelle version. 

Maintenance

Phase pendant laquelle le prestataire de TMA est face au client, à corriger les bogues éventuellement restants et à maintenir le logiciel en conditions opérationnelles.

Réversibilité

Si la phase de transition s'est bien passée cette phase devrait bien se passer également. L'éditeur peut vouloir changer de prestataire de TMA ou reprendre en interne la phase de maintenance.

Assurer la réussite d'une TMA

Il est indispensable d'utiliser un outil de gestion de projet pour centraliser toutes les demandes faites par le client et un outil de gestion des versions et des codes sources pour centraliser toutes les modifications effectuées sur les codes sources.

Comment réaliser un audit logiciel

Mettons nous en situation de réaliser un audit logiciel au sein d'une société. Pourquoi faut-il élargir cet audit à tout le service développement logiciel et ne pas se cantonner seulement au logiciel proprement dit ?

Un logiciel ce n'est pas seulement le code source, ce sont les documents et les procédures associées, sans lesquels vous ne pourrez pas continuer de faire vivre votre logiciel comme éditeur.

Un logiciel ce sont également les gens qui sont autour et qui détiennent le savoir-faire pour faire évoluer et maintenir votre logiciel en conditions optimales d'utilisation.

Donc faire un audit logiciel ce n'est pas seulement faire un état du logiciel mais c'est également regarder comment est organisé, taillé, le service développement logiciel, sinon vous ne pourrez pas continuer de faire les préconisations nécessaires à la poursuite du développement du logiciel dans de bonnes conditions.

Fixer les objectifs de l'audit logiciel

Il est très important de fixer les objectifs de l'audit logiciel car en fonction des entreprises et de ses équipes l'audit logiciel peut prendre des directions tout à fait opposées et devenir trop vaste pour les ressources mises en place et pour l'audit décidé.

Faire un état des lieux précis et vrai, le vrai est important le ressenti des équipes peut-être tout à fait différent de la réalité et les suppositions peuvent mener à des erreurs importantes.

Lister les écarts par rapport à une situation qui serait plus idéale cela permettra à termes de préconiser les améliorations nécessaires.

Un logiciel est certes drivé par les tests du point de vue de l'équipe de développement mais il est surtout drivé par les clients du point de vue des équipes marketing. Cet antagonisme peut créer un certain de situations de déséquilibre. A l'autre bout de la chaîne vous avez les Opérationnels, ceux qui sont en contact direct avec les clients sur le terrain.

L'audit technique ou audit logiciel, concerne généralement le service R&D de développement logiciel car c'est là que se cachent la plupart des secrets qu'aimerait bien connaitre la direction.

Comment convaincre d'un audit logiciel

Vous vous trouverez le plus souvent dans une situation où l'audit logiciel n'obtient pas forcément l'adhésion de tous, soit le patron vous dira : "non ce n'est pas la peine tout va pour la mieux dans mon service logiciel", soit le DSI vous dira : "je contrôle parfaitement la situation".

L'audit logiciel doit être réalisé avec l'objectif d'améliorer la situation de tous fasse au logiciel. Le patron a surement une question à propos du logiciel qui le taraude proposez lui de trouver la réponse. Le DSI aimerais surement éclaircir ou automatiser tel ou tel procédé proposez lui de trouver la solution.

C'est en trouvant des réponses et des solutions aux problèmes autour du logiciel que arriverez à convaincre que l'audit logiciel est sinon nécessaire du moins utile.

Questions à poser à l'équipe soft

Peut-être qu'il faut dans le cadre de l'audit logiciel assurer à tous que leurs réponses aux questions que les échanges lors de l'entretien resteront confidentiels que leur nom ne sera pas cité, une sorte de clause de confidentialité. Suivant les questions plus au moins délicates.

Es-tu bien dans ton travail ? Facilité pour effectuer les tâches quotidiennes as-tu les moyens ?
Quand tu te pose une question, trouves-tu l'interlocuteur adéquate ?

As-tu à ta disposition les moyens matériels de réaliser la tâche qui t'es confiée ?

Vous pouvez trouver d'autres questions à poser en fonction de l'environnement, de ce que vous savez, du service développement logiciel et de la société.

Sur la documentation

Que penses-tu du niveau de documentation ? Est-elle suffisante ?

Est-ce clair, s'y retrouve t-on facilement ? Toutes les parties du développement sont-elles documentés lesquelles ne le sont pas ?

Que ferais-tu pour améliorer la documentation.

Architecture logicielle

Maintenabilité : à souvent à voir avec les tests, si une application est parfaitement testée, elle sera maintenable et évolutive.

L'architecture logicielle est-elle décrite ? Entièrement ou partiellement, sous quelle forme schéma papier, logiciel.

Vous allez rencontrer des gens qui vont vous dire que cela ne sert à rien de décrire l'architecture qu'il a tout dans la tête.

Est-elle scalable : effets d'échelle dépend des marchés sur lesquels vous souhaitez déployer l'application.

L'équipe forces et faiblesses

forces : motivation; intérêt métier, intérêt technique les bonnes technos sont utilisées.

faiblesses; équipe trop jeune manque de maturité

points noirs : seul un ou deux possède le savoir des différentes procédures.

Evaluer les risques d'évolution

Est-il facile ou difficile de faire évoluer le logiciel ? Que faudra t-il faire pour ajouter ou retirer des fonctionnalités.

Codes spaghetti, non maintenable. Utilisation d'outils maison trop complexes. Utilisation de modules externes anciens, non maintenus.

Mesure de la dette technique

Elle peut se mesurer par rapport à une situation idéale à définir en évaluant l'écart qu'il y a par rapport à cette situation idéale.

Dette technique elle augmente ou elle diminue, la dette technique fait aussi partie de l'analyse des risques. Il y a là des points que doit soulever l'audit s'ils entraînent une trop forte augmentation de la dette technique. 

Couldification

Si je dois tout mettre dans le Cloud que faudra t-il faire, certains processus certaines technologies sont plus facile à migrer vers le Cloud, d'autres sont quasiment impossibles à mettre dans le Cloud sauf à tout reconstruire.

Quid de la Containérisation ?

Stratégie de l'audit logiciel

Vous le comprenez en lisant ces lignes que l’extrême difficulté de l'audit logiciel vient de la confrontation à l'existant, de la confrontation à ceux sont en place, à l'équipe managériale aux dirigeant de l'entreprise.

Vous marchez sur des œufs chaque pas en avant, chaque avancé est un risque, le risque de vous retrouver à découvert sans protection au fond d'un marécage que l'on vous aura concocté. C'est l'image que vous devez avoir en permanence à l'esprit avant de faire progresser votre audit logiciel.

Audit logiciel conclusion

Voilà comment convaincre, comment démarrer votre audit logiciel. C'est une première approximation, vous êtes sur le site commercial de la SoDevLog n'hésitez pas à nous contacter, à nous écrire.

Merci de laisser votre commentaire.

Modéliser une architecture logicielle grâce aux modèle C4 ou C4 model en anglais

C'est quoi la modélisation d'une architecture logicielle à l'aide du modèle C4 ? Je connaissais bien UML et l'outil qui va avec Enterprise Architect alors C4 c'est quoi ? 

C4 c'est l'abréviation de Context, Container, Component and Code. Par rapport à UML qui donne différents moyens pour décrire l'architecture, l'approche C4 c'est d'introduite une notion de zoom avant et arrière suivant le niveau de détails que l'on veut avoir sur une modélisation du projet.

J'ai déjà vu cela quelque part il y a bien longtemps (30 ans environ) il existait un logiciel comme cela sur Macintosh qui permettait de "descendre" et de "remonter" dans la description d'un projet... Aujourd'hui ce serait un logiciel pour créer des Cartes Mentales.

Donc C4 Model c'est un peu comme le DDD une approche descente de la conception pour raffiner son niveau de connaissance du système à modéliser. Je vais très vite car en vérité tout cela ne m'amuse pas beaucoup. 

Simplement j'ai trouvé une description de poste à pourvoir avec "connaissance de la modélisation C4 impérative". Et je souris intérieurement d'imaginer tous ces gens faire de beaux petits dessins sans savoir où cela les mène. Comme c'est le cas avec de nombreuses "modélisations".

L'outil : Structurizr

L'outil Structurizr pour modéliser votre architecture logiciel en modèle C4

Oui, c'est assez confus, sur le site également, certainement un outil dans lequel il faut investir en découverte et en connaissance. Disons que c'est le seul à parler de décomposition d'architecture en modèle C4.

Contexte

Description du contexte de l'utilisateur en situation, on dirait la description des cas d'utilisation en UML.

Conteneur

On raffine les grandes boîtes que l'on a dessinées au niveau du contexte. Tout est là, c'est la grande idée du modèle C4 comme de beaucoup de méthodologies de spécification. Vous pouvez ainsi faire une décomposition de votre architecture que vous ferez évoluer avec vos connaissances.

Composant

On raffine chacun des Conteneurs que l'on décompose en composants.

Code

Ils parlent de diagramme de classes UML. Moi j'opterai pour une description en pseudo code.

Conclusion

C'est du déjà vu, c'est même une façon de faire de la conception et pas tellement de la spécification, le raffinage des différents blocs de fonctionnalités c'est clairement de la conception. Peut-on spécifier avec ce modèle ? Vous verrez que dans les bonnes pages que le mot spécification n'est pas utilisé.

Les bonnes pages :

C4 model : LA solution pour les diagrammes d'archi ?
Vous n'en apprendrez pas plus.

Pour approfondir l'architecture en microservices et le DDD :

Architecture modulaire, microservices : on en est où ?
Le métier d'abord le découpage en microservices et un travail métier et non technique. Permet de revoir le DDD. Après le CCCC le DDD ;-)

Et pour aller plus loin rien de mieux que la source :

Microsoft - Concevoir une application orienté microservices
Là c'est du lourd, complet extrêmement détaillé, voyez le dessin :

Architecture en Microservices

Ce n'est pas du modèle C4, mais ça les vaut largement en matière de description de modélisation d'architecture ! En un regard on a une vision complète et synthétique du logiciel comme sur une véritable carte.

C'est incroyable, il y a Simon Brown qui prétend détenir la licence du modèle C4 licence CC BY 4.0 ça me rappelle mais cours de méthodologie logicielle, il y a trente ans lorsque l'on avait subit au sein de la SAGEM une formation obligatoire où l'on apprenait à dessiner des boite et des flèches, cette formation avait du durer 3 jours ! Et à la fin pareil une licence d'utilisation du modèle MEF ?!

Avec mes collègues, on se regardait et on se faisait la même réflexion, cette formation nous apprend à dessiner des boites et des flèches ! Pendant trois jours !

A l'époque cela pouvait peut-être se justifier, le logiciel était quelque chose de nouveau et d'un peu magique que nos managers souhaitaient qu'on leur explique, d'une façon ou d'une autre. Donc on a appris nombre de modèle de spécification conception etc... merise et autres.

Aujourd'hui il y a une absolue nécessité de spécifier un logiciel, un SI. Il faut écrire pour combien d'utilisateurs à qui, pourquoi, comment et puis faire une conception pour répondre aux spécifications. Les moyens de description sont innombrables alors il faut simplement choisir le plus adapté.

C'est quoi la rétrospective d'équipe dans le cadre de la méthodologie Agile ?

La réunion de rétrospective d'équipe qui a lieu à la fin de chaque Sprint permet de garantir le respect du processus d'amélioration continue. C'est cette réunion qui permet à chacun de faire le point sur son expérience du sprint qui vient de s'écouler et ceci afin d'améliorer l'efficacité de toute l'équipe.

L'amélioration continue est un processus qui n'est pas seulement dans l'Agile mais qui doit être une préoccupation de toutes les équipes de développement. À ce titre il faut "mesurer" savoir où l'on en est, pour être certain que l'on s'améliore et que l'on est capable de mesurer cette amélioration.

Et je trouve le très bon site de l'Agiliste sur ce sujet :

L'Agiliste - L'art de la Rétrospective
Comment dérouler une réunion de rétrospective, ce que j'aime c'est que l'on ne cherche pas à juger, on ne cherche pas à trouver de coupable, on cherche juste à établir un état des lieux, une prise de conscience de soi pour que chacun puisse s'améliorer. 

SOAT Blog - La rétrospective : qui ? quoi ? comment ?
C'est un moment de partage avec un jeu le "Safety check" :

Un jeu permet à chacun de s'exprimer de façon non verbale, d’extérioriser quelque chose même pour les plus timides.

Je pense qu'il est important que tout le monde s'exprime donne son ressentiment. Pour être certain d'assurer une amélioration continue de l'ensemble de l'équipe en globalité.

Voilà, je me devais de faire ce focus sur la "réunion de rétrospective" dans le cadre méthodologie agile, dans le cadre de l'amélioration continue, sans dérouler la totalité de la métho agile.

Quels outils pour gérer l'agilité dans un projet logiciel

Il y a un outil dont on parle tout le temps en méthodologie agile pour gérer les projets de façon agile, c'est SAFe. Il y a un certain rejet de SAFe de la part de la communauté des agilistes et c'est normal puisque SAFe est un outil souvent trop contraignants pour conserver de l'agilité.

C'est quoi SAFe ? C'est un Framework Agile (Scaled Agile Framework® - SAFe®) permettant de gérer de très grands projets de plusieurs équipes. SAFe se veut être un outil global dans l'entreprise veillant à ce que toutes les "équipes" de l'entreprise travaillent sur ce qui compte à tous les niveaux.

Avec une petite comparaison Google Trend entre SAFe et Jira avec le terme Agile pour essayer de voir qui s'intéresse à quoi :


Trend SAFe Agile vs Jira agile

On vois l'engouement pour SAFe. Les gens qui se revendiquent de SAFe : Scaled Agile. Trop compliqué, peu clair, finalement il faut prendre un cours suivre une formation. Finalement ce n'est pas très Open Source.

Et puis un post bien fait sur les différents outils qui peuvent vous permettre de gérer vos projet en agilité :

Agilemouse - Quel outil pour gérer notre projet agile ?

Voilà mais faut-il un outil pour gérer vos projets en Agilité, l'agilité c'est une culture, une façon de penser. L'outil c'est un carcan !

Mise à jour de septembre 2020 : Dans mon milieu professionnel, on parle beaucoup de Jira-Confluence. Je refais une petite recherche sur google trend pour voir. Voici ce que je trouve aujourd'hui :

Trend SAFe vs Jira vs Genius

Et bien SAFEs n'est plus du tout la même place, je découvre GENIUS j'avais entendu parler de TRELLO et le méthode Kanban.

Capterra - Logiciels de gestion de projets
Un comparatif mais je trouve que le souci de ce genre de page c'est que tous les logiciels sont au même niveau quelques soit leur importance. Les critères de comparaison ne sont pas ceux qui vous intéressent.

ATLASSIAN - Agile Coach - Qu'est ce que SAFe ?
Pour décrire ce qu'est SAFe mais on y découvrira les freins, le carcan. Evidemment on a besoin de l'adhésion de la Direction, c'est toujours le souci numéro un, l'adhésion des dirigeants.

Scaled Agile - SAFe Lean-Agile Principles
Une somme sur le Lean/Agile tout ce qu'il faut savoir sur SAFe et donc peut être trop contraignant.

Tient cela me rappelle mes premiers cours de qualité logicielle car j'ai participé au sein de la SAGEM à l'élaboration de la Qualité dans les années 90. On a donc écrit des pages et des pages de référentiels de pratiques à adopter. Et je me disais qu'à chaque fois au début d'un projet, il faut définir, ce que l'on va, et ce que l'on ne pas, utiliser dans de la méthodologie logicielle. 

La première tâche sur un projet logiciel, c'est donc de contextualiser par rapport à la méthodologie qui peut être trop contraignante et dire, écrire ce que l'on ne va pas utiliser et pourquoi on ne va pas le faire. L'inconvénient majeur de toutes ces méthodologies, c'est qu'elles sont trop contraignantes. Un petit projet ne se gère pas de la même manière qu'un grand projet, une erreur c'est de vouloir appliquer l'ensemble des préconisations de SAFe à un petit projet.

Méfiez vous des ayatollahs de telle ou telle méthodologie qui voudront appliquer à la lettre tous les préceptes d'une façon dogmatique. Tous les projets sont différents et se gèrent différemment aucune  méthodologie ne peut gérer tous les types de projets.

Mon outil idéal pour gérer un projet avec agilité ... je cherche encore.

En savoir plus sur Jira

Indicateur KPI pour mesurer la performance d'une société en qualité logicielle

On se pose souvent la question de mesurer la qualité d'une entreprise qui développe du logiciel. Et je connais la difficulté qu'il peut y avoir à se lancer dans une telle évaluation. Alors comment savoir si le logiciel développé par une entreprise est de qualité ?

J'ai rencontrer des sociétés qui était obligées d'utiliser du code source sans savoir à quoi il pouvait bien servir mais quand le Responsable logiciel les enlève, le logiciel ne fonctionne plus !

Je me demande si mon indicateur est un bon indicateur. Evidemment plus cet indice KPI est élevé plus la société est mauvaise, l'objectif serait de faire tendre cet indicateur vers zéro.

Cet indicateur ne permet pas à priori de suivre l'évolution de la qualité dans une entreprise. Il ne me permet pas de mettre en place en processus d'amélioration continu. Je le mesure à un instant donné je peux le réduire mais il ne représente pas l'évolution de la Qualité ...

Il faut savoir que ces indicateurs KPI sont classés en trois catégories permettant :

KPI - indicateur de mesure de la qualité en Entreprise

• Équilibration
• Anticipation
• Alerte

Notre KPI doit tendre vers zéro et le rester tout au long de la vie de l'entreprise. Ce KPI trop élevé peut entraîner la mort de l'entreprise. Les décisions à prendre sont alors trop lourdes de conséquences.

Je trouve que ce site est le meilleur et le plus complet pour présenter les KPI :

PILOTER.ORG - Qu'est-ce qu'un indicateur de performance ?

Site informatif et complet sur les indicateurs de performance et pas seulement pour les sites web.

Avec une page particulièrement qui nous concerne :

PILOTER.ORG - Le tableau de bord de la Direction du Système d'Information

Le métier de la Qualité logiciel est primordial au sein d'une entreprise qui développe et commercialise du logiciel (software).

Trouver un indicateur KPI pour un tel type d'entreprise n'est pas une chose aisée. Si vous avez pris soin de parcourir le site de PILOTER.org vous savez que ce n'est pas simple.

Je vous propose comme indicateur de performance KPI : 

Le nombre de lignes de code que la société est encore obligée d'utiliser alors que le développeur qui les a écrites est parti sans les documenter et sans montrer ce qu'il a fait au responsable du développement qui se demande à quoi elle servent ?

CQFD !

Agilité, principes de base par Pablo Pernot

Un fois n'est pas coutume, je vous fais part d'une vidéo sur l'agilité. Ce sont vraiment les bases fondamentales de d'agilité celles qu'il faut absolument connaitre :

Agile Grenoble 2017 - Keynote Pablo Pernot

Comment engager les gens derrière l'agilité ?
Les fondamentaux de l'agilité, agile on ne sait plus ce que cela veut dire réellement

Agile ça veut dire que l'on est dans un monde complexe. Etre agile veut dire évoluer dans ce monde complexe. Comment être performant dans un monde complexe ? On responsabilise.

Suis-je engagé, impliqué ? On responsabilise les gens mais il on le droit à l'erreur. Mais le droit à l'erreur doit être sécurisé donc il faut limiter le champ d'action (sprint). Faire de petites choses priorisées par valeur.

Pour savoir si on se plante ou pas, il faut un vrai regard, un vrai retour sur ce que l'on fait sur des choses finies. Pour ça il faut développer des éléments verticaux, depuis les données jusqu'à l'interface afin de pouvoir juger de l'utilité.

La bascule pour le management c'est le lâché prise. Pour l'équipe produit c'est de ne pas avoir tout, tout de suite.

Comprendre pourquoi il y a une forte implication des joueur dans les jeux vidéo :
Pourquoi mon ex-belle mère me demande une vie à Candy Cruch Saga alors que d'habitude elle ne me demande rien.

Les 4 points clefs de l'implication

• objectif clair (avec du sens)
• règles claires
• feed back (des mesures)
• invitation (pas d'obligation)

Sentiment de contrôle de son outil de travail.
Sentiment de Progresser
Sentir que l'on appartient à une communauté
Les tailleurs de pierre avoir l'impression de construire une cathédrale, ensemble

Se préoccuper en premier du temps et de l'argent, ce sont toujours de faux départs.

Voilà, il est cool Pablo, parfois son discours est un peu trop rodé à mon goût. Il lance des mots pour nous éblouir de sa science sur l'agilité et c'est normal mais cet éblouissement peut nous faire croire qu'il cache quelque chose. En tous cas, on le sens proche de nous avec les mêmes préoccupations du coup on se sent vraiment bien avec lui à côté.

Et à la fin, on a tout compris sur l'Agilité ;-)

C'est quoi le Story Mapping dans le cadre de la méthodoloogie Agile ?

En effet, je vois bien la méthodologie agile, les "users stories" mais précisément le Story Mapping c'est quoi ? Le "backlog de produit" est un ensemble de récits utilisateurs (users stories) que l'on classe par valeur d'affaire (apport de la valeur ajoutée pour le projet).

Le risque de cette organisation en users stories, c'est de perdre les Devs dans des "petites user storie" afin d'éviter cela Jeff Patton - USer Story Mapping a écrit un livre. Il faut retourner au Telling c'est à dire au récit. Il faut faire réciter à l'utilisateur ce qu'il fera lorsque qu'il utilisera le produit afin que chaque dev comprenne bien l'enchainement des "users stories".

ATOMIC OBJECT - Design Thinking Toolkit, Activity 2 – Story Mapping
Ici c'est en anglais mais on sent bien que la maitrise du Story Mapping est là :
But premier du Story Mapping : obtenir les détails qui vont permettre de comprendre "l'expérience utilisateur".

Au passage, on nous donne un outil de création de Backlog : Pivotal Tracker

Référence : Encore User Story Mapping by Jeff Patton and Peter Economy (2015)
Là c'est vraiment un de ces sites qui vous perdent totalement. L'objectif est de vous faire acheter le livre et sinon il y a un tas de vidéo.

MyAgile PARTNER - Story Mapping, bien comprendre sa création
Un bel exemple : un site e-commerce
Il faut bien sûr commencer par rassembler des post-it et un grand espace mural ou tableau de 3 ou 4 mètres de long minimum.

Le Story Mapping c'est

Le Story Mapping c'est donc agencer les "users stories" pour un faire un product backlog c'est à dire une feature réalisable par l'équipe de Développement dans le temps imparti du Sprint.

CQFD !

Qu'est ce que c'est la méthodologie Scrum ?

Je souhaite écrire un article pour faire le tour de la méthodologie Scrum car jusque là, j'y suis allé par de petites touches décrivant ici et là les principes les outils mais il me faut une vision complète de ce qu'est la méthodologie Scrum.

Je ne peux plus faire d'approximation, il me faut faire le tour complet du Sujet.

Méthodologie Scrum en un seul Diagramme

Je trouve la publication du manifeste Agile :

Agile Manifesto

Manifeste pour le développement Agile de logiciels

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Agile Manifesto ou Manifest Agile

Principes sous-jacents au manifeste agile

Nous suivons ces principes

1- Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

2 - Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.

3- Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

4 - Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

5 - Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.

6 - La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

7 - Un logiciel opérationnel est la principale mesure d’avancement.

8 - Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

9 - Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.

10 - La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

11 - Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.

12 - À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Il s'agit là des douze principes de la méthode Agile.

1 - Travailler en cycles courts ne suffit pas, l'implication exige que le Product Owner pour valider les livraisons soit le client ou l’utilisateur final, sinon cela ne fonctionnera pas.

2 - C'est le principe même de l'agilité, il faut alléger les phases de spécifications et de conceptions en amont car elle évolueront au cours du projet. L'acceptation du changement nécessite une organisation spécifique.

L'organisation en Scrum

Définition :

"Cadre de travail permettant de répondre à des problèmes complexes et changeants, tout en livrant de manière productive et créative des produits de la plus grande valeur possible."

Donc Scrum n'est pas une méthodologie ... Scrum c'est un cadre avec une description des rôles.

Scrum Master : coordinateur des équipes (le guide de l'avancement du projet, gourou ...)

Product Owner : collabore avec le client (le fondateur ou le boss ...)

Delivery Team : les développeurs

Etape 1 : Product Backlog : Analyse des besoins, identification de toutes les fonctionnalités afin de composer les "user stories".

Etape 2 : Le Sprint : répartition des tâches, tier les fonctionnalités sur une durée de deux semaines.

Pour la répartition des tâches on peut utiliser le jeu de cartes avec les points de difficultés, chacun estime la difficulté qu'il aurait à développer la user storie (la tâches ou le use case) c'est le Planning Poker.

Avant chaque sprint : une réunion de sprint planning meeting, c'est une négociation entre le PO et l'équipe pour sélectionner les exigences prioritaires pour le client.

En suite, chaque jour la mêlée (ou stand-up meeting), on fait évoluer le tableau en trois colonnes en racontant :

• ce que l'on a fait hier 
• les problèmes rencontrés la veille
• ce que l'on va faire aujourd'hui

Etape 3 : Sprint Review : chaque semaine ou fin de sprint, avec le Product Owner pour faire une démonstration de ce qui a été créé. Puis le client confirme si la fonctionnalité se comporte comme il le souhaite.

Le Guide Scrum de l'agiliste

Le Product Owner, ou le chef de produit porte la vision du produit c'est un expert du domaine métier

Le Scrum Master doit renoncer au style de management commander contrôler et doit adopter un management participatif.

L'Equipe de développement est pluridisciplinaire et globe tous les rôles

À la fin de chaque sprint, l’équipe doit fournir un livrable fonctionnel.

La mêlée doit faire naitre un esprit d'équipe il ne faut pas qu'elle soit simplement un reporting vers le Scrum master, il doit donc être déjà au courtant de l'avancement car c'est son rôle.

Graph d'avancement ou Burndown Chart : ce que l'on a déjà grillé, bruler comme travail/effort permet de tracer le graphique d'avancement du projet.

La Rétrospective de Sprint : consiste à dire/trouver ce qui aurait pu être amélioré lors du sprint précédent cette réunion participe à l'effort pour l'amélioration continue.

Le Kit Gratuit de l'Agiliste

Conclusion sur le cadre Scrum et l'Agilité

Le cadre de travail Scrum permet/incite à une interaction permanente entre les acteurs du projets, entre le Product Owner et le Client pour valider les nouvelles fonctionnalités, entre le Scrum Master et l'équipe dans un dialogue permanent et journalier et même entre les éléments de l'équipe qui s'expriment les uns devant les autres pour faire part de leur avancement, de leurs difficulté, on est donc dans l'agilité avec une adaptation possible et rapide aux changements éventuels.

Je n'ai pas encore fait le tour, je reviendrai...

Vous souhaitez poursuivre vos lectures :

Claude Aubry - Scrum, Agilité & Rock'N Roll

Vous avez un commentaire, merci de votre participation.

C'est quoi la conception DDD (Domain Driven Design) ?

Vous vous demandez ce que peut bien être la conception Domain Driven Design DDD ou la conception pilotée par le Domain en français ? Et bien je vais essayer de répondre à cette question.

Petit préambule intéressant : Vous vous souvenez de la bonne vieille méthode du cycle en V qui met en face à face dans un V les Spécifications d'une part et le Test et la Validation d'autre part,  la conception et les Tests d'intégration etc ... Et bien j'ai lu récemment des articles ayant pour sujet la réhabilitation de ces méthodologies face aux méthodologies agiles.

Comme quoi, il suffit d'attendre assez longtemps et tout fini par arriver.

Alors le DDD c'est quoi ? Encore un truc à la c(bip) pour dégager les vieux codeurs et leur faire croire qu'ils n'ont rien compris ;-)


Patterns in strategic domain-driven design and the relationships between them

D'après le Xebia blog la conception DDD lie le fonctionnel et le code se serait dommage autrement je ne dis pas que seul le code fait foi car il y a aussi la documentation mais la description fonctionnelle ou la conception et le code source doivent être liés par une relation simple et évidente.

Conception DDD

Pour une fois, on ne parle pas de méthodologie, il s'agit bien d'une façon de concevoir le code.

Exemple de DDD : xblanc33/DDDvsJavaBean
Un tour rapide sur la mise en œuvre de la conception DDD c'est brillant d'une très grande clarté.
Je ne peux m'empêcher de citer ici les 3 concepts Utilisé par Xavier Blanc :

Trois concepts à manipuler

Le postulat est le suivant, certes tout est objet, mais tous les objets ne sont pas les mêmes. Il est important de distinguer certains types d'objet : Value Object, Service et Entity.

Un Value Object est un objet qui représente une valeur et même une constante. L’exemple le plus utilisé est celui du point GPS avec la latitude et la longitude. Chaque point GPS est défini par sa latitude et sa longitude. Du coup, aucun intérêt à changer les valeurs (pas de setter).
Un Service est un objet qui offre une ou plusieurs fonctions (stateless si possible). De fait on peut construire un Service, l’utiliser et le supprimer. Un service n’a pas réellement d’état, c’est juste un ensemble de fonctions.
Un Entity est un objet qui est identifiable et qui a un état propre qui va changer. L’Entity est l’objet « noble » de la programmation orienté objet. Par contre, plutôt que des setter, il offre des méthodes métiers qui vont permettre d’exécuter l’application (on choisira des noms explicites pour ces méthodes).

Une fois ces trois concepts connus, le DDD préconise l’utilisation de Value Object et de Service plutôt que d’Entity. En d’autres mots, il faut essayer de manipuler le plus possible de Value Object et de Service.

Encore une fois ces pages pourraient disparaître, je garde donc une trace minimum pour être capable d'aborder ce sujet de la conception DDD s'il venait à se présenter.

Méthodes Agiles

Pour vous montrer à quel point, côté Agilité c'est foisonnant, voici une page qui présente toutes les méthodes agiles et leurs concepts :

nut&cache - Les méthodes Agiles – La liste complète des méthodologies Agiles

C'est plutôt un ensemble lexicale, on y trouve le FDD : Feature Driven Development (FDD) Le Développement Dirigé par les Fonctionnalités, en français. On parle de modélisation du produit ...

Tout ça est bien joli mais il faut s'accaparer les termes et faire "à sa sauce" en fonction de son expérience (XP).

Qu'avons nous appris ? Pas grand chose que nous ne sachions déjà.

Le DDD et les microservices

Voilà donc deux sujets, fort intéressant du moment, évoqués dans cet article :

donetechno - Les microservices : une architecture Agile — Deuxième partie
Pour connaitre les questions principales sur les microservices, un vrai délire architectural. Plein de questions sur les microservices, l'agilité par rapport aux microservices et finalement pas grand chose sur le DDD (Domain Driven Development).

Un exemple de code sources en C#

Oui, il y en a qui sont allé jusqu'à l'implémentation en C# voici un article en anglais simple et efficace. Voici donc du code en C# réalisé avec une méthode de conception DDD (Domain Driven Development) :

C’était un exemple de code mais il a disparu du net ! Le projet s'appelais QuoteEngine : DoboTEK - Domain-driven design DDD practical implementation in C# .NET


Visual Studio 2017 - Implémentation du DDD en C#

Peut être que l'on peut retrouver ce projet sur Gihub  à voir j'ai trouvé ça :

antonellanicito/QuoteEngine

Il faudrait retrouver le DDD (Domaine Driven Development) dans ce projet.

Voilà, le DDD ... disons que c'est une méthode de conception centrée sur le domaine métier qui conçoit un modèle commun qui permet aux développeurs d'avoir une meilleure connaissance du fonctionnel et du vocabulaire utilisé par le métier. 

Le DDD permet aux gens du métier de mieux visualiser ce que les devs ont en tête pour la conception du logiciel. Le DDD (Domain Drivne Design) permet de meilleurs échanges entre les gens du métier et les devs.

Have fun!

Méthode Agile - Résumé

Quel est le meilleur résumé, le plus efficace sur la Méthode Agile, il y a tellement de littérature sur le sujet, on s'y perd très facilement.


Méthode Agile - Résumé

Alors pour simplifier, voici une page de présentation de la Méthode Agile :

L'Agiliste - Exemple d’organisation projet Agileagile/

Avec en résumé les deux rôles principaux, le Product Owner qui détient les connaissances produit et le Scrum Master qui fait partie de l'équipe exécutante, il relate de l'avancement de l'équipe de développement.

Product Owner : est assuré par un membre de l’équipe métier (MOA)

• Alimente et maintient le Product Backlog, et pré priorise les éléments de ce dernier.
• Ajuste les fonctionnalités prioritaires du Product Backlog (candidates au périmètre du prochain sprint) et s’assure que les pré-requis aux développements associés seront disponibles en temps voulu (exemples : décisions métier, jeux de données du SI amont,…).
• Rédige les User Stories associées aux fonctionnalités prioritaires et dessine au besoin des maquettes d’écran.
• Répond aux questions soulevées par l’équipe de développement en cours de Sprint et complète au besoin les User Stories associées.
• Vérifie en cours de Sprint la bonne couverture du besoin des fonctionnalités terminées en collaboration avec l’équipe de développement.
• Rédige les plans de tests.
• Participe à la réunion de revue de sprint au cours de laquelle, elle aide le Product Owner à accepter ou rejeter les fonctionnalités présentées.
• Teste avant mise en production la conformité du produit dans son ensemble.

Scrum Master : appartient à l’équipe de développement (MOE)

• S’assure que l’équipe est pleinement opérationnelle et productive.
• Établit une collaboration étroite entre l’ensemble des rôles et fonctions.
• Supprime les obstacles rencontrés par l’équipe de développement.
• Protège l’équipe des interférences extérieures.
• Assure le suivi du processus.

Voilà, nous avons maintenant une vision succincte mais complète de la Méthode Agile.

AMOA : Assistance à Maîtrise d’Ouvrage (côté client)

AMOE : Assistance à Maîtrise d’Œuvre (côté réalisation)

Le DevOps c'est quoi ?

DevOps est LE terme à la mode en ce moment, il faut absolument faire du DevOps alors le DevOps c'est quoi ? 

Et bien c'est un terme un peu comme ITIL, un ensemble de bonnes pratiques quand on a dit ça on ne peut pas s'arrêter là. Il faut entrer dans les détails, dans tous les détails. Car le DevOps intervient à toutes les étapes du développement logiciel.

Microsoft - Parts Unlimited MRP

Voici le site de Microsoft qui présente chacune des étapes du développement logiciel "à la façon DevOps" dans une simulation complète d'une entreprise de développement logiciel, c'est vraiment top ! C'est vraiment une partie à étudier en profondeur, ce sont les équipes de Microsoft qui ont fait un effort particulièrement important pour nous présenter cet aspect de leur métier, de notre métier, le DevOps.

La simulation est vraiment complète avec un Github. Malheureusement des liens sont cassés ! Avec des cours sur par exemple "Infrastructure as Code" ; Il faut pouvoir coder scripter votre infrastructure pour en conserver une description complète et une trace reproductible et pouvoir la faire évoluer dans le temps plus facilement. Dans ce cas la définition de l'infrastructure devient le script qui devient donc comme une empreinte complète et fidèle de l'infrastructure nécessaire à l'exécution de votre application.

Inutile de vous dire que tout est codé dans le Cloud.

Lors d'un meetup sur le DevOps, j'ai noté également d'autres termes :

Terraform
Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently.

Meteor

Prometheus
Power your metrics and alerting with a leading open-source monitoring solution.

Value Stream Mapping

Il y a une multitude d'outils à chaque étape du développement qui vous permettent d'assurer le Test & l'Automatisation de chacune de ces étapes quelque soit la chaîne de développement avec laquelle vous travaillez. Il y des passerelles.

Le terme DevOps vient de la volonté de rassembler deux types de ressources de l'entreprise. Les Développeurs et les Opérationnels car les problèmes de l'entreprise qui développe du logiciel ont été identifiés à la frontière des ceux deux services. 

Les Développeurs font des trucs que les Opérationnels ne peuvent pas se permettre devant le client et de l'autre côté des Opérationnels trouvent des astuces pour palier aux problèmes du système qu'ils ne rétrofitent pas aux développeurs.

Bien des problèmes viennent d'une mauvaise communication entre les opérationnels et les développeurs de ces deux services.

Le DevOps c'est une culture, une culture qui doit se répandre dans toute l'entreprise.

Donc si vous êtes un DevOps vous devez pouvoir tout reconstruire à partir de scripts faciles à mettre en oeuvre.

Il y a trop de trucs installé sur la machine du Développeur lors du déploiement de l'application cela va poser des problèmes aux Opérationnels dont l'installation du produit ne va pas fonctionner. Ils devront chercher ce qui manque !

Voilà le DevOps c'est tout cela. Si vous débutez retenez surtout que DevOps c'est un état d'esprit qui vous permet de vous sortir des pièges dans lesquels tombent toutes les équipes de développement qui ne possèdent pas cette culture cet état d'esprit.

Le Blog - Outils de Développement Logiciel
Comment devenir un ingénieur DevOps

Approche Agile plutôt que méthode Agile

Malgré l'utilisation et l'application stricte de méthodes traditionnelles, on découvre que bien des projets informatiques sont des échecs voir de véritables fiascos. L'apport de l'approche Agile est considérable dans la réussite d'un projet et elle garantie la satisfaction du client.



Méthode Agile

Les causes de l'échec des projets informatique avec l'utilisation des méthodes classiques :

• Cahier des charges de la taille d'une encyclopédie
• Pas de place pour l’improvisation, réfractaire au changement
• Effet tunnel de la méthodologie du cycle en V

A la fin du projet, le client s'étonne de la non conformité aux attentes.

http://www.agiliste.fr/introduction-methodes-agiles/

La méthode Agile se concentre sur la satisfaction du client et de l'utilisateur final. Elle favorise le travail collaboratif de l'ensemble de l'équipe de développement.

Cadre méthodologique Scrum

Scrum c'est un package avec le product owner et le scrum master.

Product Backlog : liste des fonctionnalités du produit triées par importance de Valeur Ajoutée ROI

Planning Poker : estimation collaborative des sprints et de leurs difficultés

Sprint Backlog : le comment ?

Stand-up meeting : réunion journalière de 15 minutes, debout pour éviter de s'éterniser

Burndown Chart : courbe d'avancement

Revue de sprint : à la fin de chaque sprint

Rétrospective de Sprint

http://www.agiliste.fr/guide-de-demarrage-scrum/

Méthodologie du forum ouvert 

WikipédiA - Méthodologie Forum Ouvert

Comédie - Présentation du Forum Ouvert - Un dialogue auto-organisé

 

Assistance à la Maîtrise d'Ouvrage (AMOA)

C'est quoi l'Assistance à la Maîtrise d'Ouvrage ou AMOA ? Pour y répondre, je me promène sur le site d'une SSII et je trouve les définitions suivantes :

Description de l'AMOA - Assistance à la Maîtrise d'Ouvrage 

Cette description de l'AMOA est un peu en forme de cycle en V. Avec une descente jusqu'à la phase 3, spécifications, conception, développement et une remonté jusqu'à la phase 6 : Validation puis Support technique et fonctionnel ...

Bref, bien peu d'agilité. Alors peut-on allier cycle en V et agilité ? C'est bien la question.

Littérature sur l'AMOA

La MOA, c'est le client la Maîtrise d'Ouvrage, celui qui va utiliser le résultat du projet, l'AMOA c'est son assistance l'AMOA est donc là pour assister le client pour l'aider à définir ses besoins, pour l'aider à décider des changements souhaités dans le futur système d'information.

Le métier d'AMOA est un métier de consultant, d'écoute et de formalisation pour comprendre, décrire et faire en sorte que le futur logiciel aide l’utilisateur à être plus performant dans son métier.

Une distinction est à faire entre AMOA et AMOE :

AMOA (côté client) : décide du lancement d'un projet et qui confie la réalisation à la MOE. Elle est responsable du résultat du projet, assume l'usage du produit et finance sa réalisation.

AMOE (côté réalisation) : choisie une solution technique et à fabrique/développe les logiciels correspondant au besoin des utilisateurs.