Comment réaliser un audit logiciel

Disons que l'on réalise un audit du service logiciel au sein d'une société. Pourquoi faut-il élargir au service développement logiciel ?

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.

Réaliser un audit logiciel

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 facile ou difficile de faire évoluer le logiciel

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 à mettre dans le Cloud. 

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

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

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

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
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 :

Comparaison des outils de méthodologie logicielle
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.

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
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 :

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

Avec une page particulièrement qui nous concerne :


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 !

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, y donnent leur leçon d'agilité. Je pense que c'est le fait de la société actuelle de ne pas vouloir être agile. Oui 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, ils ont un management totalement différent.

D'autre cadre de travail en agilité comme SAFe prône la dilution de la responsabilité vers les équipes. Là encore un "petit chef à l'ancienne", ce exactement le contraire de ce qu'il veut. 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
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 

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 !

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 vais réaliser une série d'articles 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
Méthodologie Scrum en un seul Diagramme
Je vais citer un collègue Blogger le "Chef d'équipe"

Chef d'équipe - Origine de la méthodologie Scrum

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."
 
Le Guide Scrum
À la fin de chaque sprint, l’équipe doit fournir un livrable fonctionnel.

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

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 ;-)

By Eric Evans - Domain Driven Design Pattern Summaries Word document dddcommunity.org, CC BY 2.5, https://commons.wikimedia.org/w/index.php?curid=9389541
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

Implémentation du DDD en C#
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 :

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 :

https://www.agiliste.fr/exemple-dorganisation-projet-agile/

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à on arrive à la substance ...

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
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.

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.

Comment devenir un ingénieur DevOps

C'est quoi une Matrice de traçabilité des exigences ?

Voilà mon sujet sur l'amélioration de la qualité ce matin, trouver à quoi peut bien servir une matrice de gtraçabilité des exgigences. Je vais recadrer légèrement en abordant ce sujet du point de vu de la norme : 

EN 62304 Medical device software.

Defines the life cycle requirements for medical device software. Dit comme cela c'est un peu court mais c'est surtout payant :

https://www.en-standard.eu/csn-en-62304-medical-device-software-software-life-cycle-processes/
European Standards - CSN EN 62304 - Medical device software - Software life-cycle processes

Wikipédia nous parle de la La gestion des exigences avec une définition de la traçabilité des exigences.

Définition de la traçabilité des exigences :

S'il on veut être conforme à cette norme, il doit être possible de retracer jusqu'à leur origine chacune des exigences et chacun des changements les affectant ; les exigences doivent donc être documentées pour achever la traçabilité.

Définition de l'exigence :

Les exigences sont l'expression d'un besoin documenté. Facile à dire mais vous verrez combien de clients formuler leurs exigences par orale sans prendre de note et sans documenter. Donc écrire documenter est un point essentiel de la traçabilité.

Matrice de traçabilité :

Il s'agit donc de regarder pour chacune des exigences exprimées s'il on a bien la possibilité de la tracer jusqu'à l'origine.


Pour le reste il faut payer ... c'est un sujet à creuser.

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.


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

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 :

http://www.eqlhenix.fr/le-metier-damoa
une distinction est faite entre AMOA et AMOE
AMOE : choisie une solution technique et à fabrique/développe les logiciels correspondant au besoin des utilisateurs.
AMOA : 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.

C'est quoi ITIL ?

Vous vous demandez ce que c'est ITIL par rapport à d'autres méthodologies ? Je vais essayer de trouver les éléments de réponse à cette question.

ITIL c'est un ensemble de bonnes pratiques (best practices) pour la gestion d’un système d’information, édictées par l’Office public britannique du Commerce.
On observe une augmentation continuelle de la demande de services informatiques. Fin 1980 début 1990, le gouvernement britannique (OGC) demande une étude sur les bonnes pratiques de la gestion des services.

ITIL : Informations Technologie Infrastructure Library, ensemble de livres sur les bonnes pratiques de la gestion des services informatiques.

L'activité de mise en oeuvre d'ITIL concerne principalement l'amélioration des processus existants.

Pour se faire :
  • évaluer la maturité des processus existants,
  • s'assurer de l'implication du management pour engager la démarche,
  • s'assurer que les conditions du changement culturel sont satisfaites pour modifier ou améliorer la fourniture des services.
La prise en compte des demandes clients est primordiale.
Il faut assurer la fiabilité des projets dès la conception.

Cycle de vie des projets

Principaux points visés par la méthodologie :
  • Comment organiser une production informatique ?
  • Comment améliorer l’efficacité du système d’information ?
  • Comment réduire les risques ?
  • Comment augmenter la qualité des services informatiques ?
Processus : tâche pendant laquelle des participants produisent des livrables.

ITIL V2 entre 1990 et 2004 produit deux livres :

Service Delivery :
Concerne la planification et l'amélioration à long terme de la fourniture des services liés aux technologies de l'information.

Service Support :
Se concentre sur les opérations au jour le jour et le support aux services.

Fourniture des services (Service Delivery)

Gestion des niveaux de service (SLM Service Level Management)
du financement des services
de la capacité
de la disponibilité
de la continuité
de la sécurité

Pour chacune de ces discipline on observe les points suivants :
les objectifs
le périmètre
les concepts
les bénéfices et les difficultés
la mise en place
les activité
les indicateurs
certains autres points dépendants de la discipline traitée

Service Support

Fonction Service Desk

détection des incidents 
prise des appels 
coordination des actions

Gestion des incidents 

enregistrement des incidents
processus de gestion des incidents
classification escalade et remonté

Gestion des problèmes

traitement des erreurs connues
interrelation entre les processus

Gestion de la configuration

modélisation de l'infrastructure IT
maitrise des éléments de configuration
base de données de gestion de la configuration

Gestion des changements

préparer et valider un changement
traitement des demandes de changement

Gestion de mise en production

cycle de vie et processus de distribution

Ce qui fait le succès d'ITIL

C'est non propriétaire
Non dogmatique

ITIL représente l'expérience et les pratiques cumulées des meilleurs sociétés fournisseurs de services.
Toutes les pratiques citées dans ITIL ne sont a prendre systématiquement comme étant les meilleurs pratiques.

Liens vers ITIL

https://itil.fr/
Le portail des meilleurs pratique ITIL
Il faut s'abonner : https://itil.fr/sabonner

mise à jour 2017
ITIL France

mise à jour en 2020 : www.itil.fr le nom de domaine est réservé mais pas de site correspondant on dirait bien que tout ceci ... est à l'abandon.