1.
L’informatique efficience
Informatique par la pratique : Création d’un serveur de jeux de quizz
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet

2.
L’efficience
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet

3.
Qu’est-ce l’efficience ?
•L'efficience est l'optimisation des outils
mis en œuvre pour parvenir à un
résultat. Elle se mesure sous la forme
d'un rapport entre les résultats obtenus
et les ressources utilisées
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet

4.
Efficience # Efficacité
• qui est le rapport entre les résultats obtenus et les objectifs fixés
Efficacité C’est efficace mais pas efficient
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet

5.
Efficience # Rentabilité
• qui est le rapport entre les revenus obtenus et les capitaux investis
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet

6.
Efficience > Efficacité > Rentabilité
Rentabilité Efficacité Efficience
Optimise les ressources employés et
diminuent leur coût
L’efficacité : Atteindre les objectifs
fixés
Atteindre les objectifs fixés
Utilisés les bonnes ressources
Pas de surcoût
L’atteinte des objectifs fixés n’est pas
obligatoire
Surcoût / Surdimensionnement des
ressources employés
Difficile à mettre en place les
humains mais nécessaire
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet

7.
L’exploitabilité
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet

8.
Qu’est-ce que l’exploitation informatique
• L'exploitation informatique est l'activité qui consiste à maintenir
opérationnel de manière stable, sûre et sécurisée un outil
informatique dans un environnement de développement, de
qualification, de formation, ou de production, dans ses parties
matérielles et logicielles
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet

9.
VABE : Vérification d’Aptitude à la Bonne
Exploitabilité
1. Vérifier que l’applicatif est conforme aux Normes édictées par la Production Informatique
(intégration de l’applicatif dans la supervision, dans l’ordonnanceur, normalisation de
l’applicatif pour en faciliter son exploitation, …)
2. Vérifier la pertinence de la supervision
3. Vérifier la cohérence de l’intégration des traitements dans la plan de production global ainsi
que des procédures de reprise des traitements
4. Vérifier que les niveaux de Qualité de Service (notamment les SLA) sur lesquels la Production
Informatique va s’engager sont atteignables et perdurables.
5. Vérifier la présence, la pertinence de procédure d’exploitation et les dérouler
6. Vérifier le Plan de Reprise d’Activité conformément aux besoin du client (DMIA, etc….)
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet

10.
La scalabilité
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet

11.
Evolutivité / Scalabilité # Evolué
• Un système capable d’accueillir 200 personnes lorsqu’on est que 50 personnes n’est pas scalable
mais évolué. En effet il permet d’atteindre 50 personnes mais que se passera-t-il si on dépasse les
200 personnes ?
#
• Un système capable d’accueillir les 50 personnes et d’être facilement évolutif et rapide sera plus
scalable dans le temps.
En effet
• Que se passera-t-il lorsque les 200 personnes seront dépassés ? Le système de palier par 50 le
permettra tout aussi facilement mais celui prévu initialement pour 200 peut-être pas ?
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet

12.
Le JITA : Juste in time
applicatif

13.
Le JITA : Garantir le retour marché
• Le juste-à-temps concerne tous les aspects de la logistique en amont
et en aval du développement, de la transitique interne à l'usine et les
relations avec la sous-traitance.
• Le principe du juste-à-temps est que la production est "tirée" par la
demande et non par l'offre : il faut produire puis livrer (dans un temps
très court) ce qui est demandé "instantanément" par le client
(production en "flux tendu").
1 Système complexe est un ensemble de sous systèmes imbriqués et
assemblés pour produire une vue unique

14.
Réutilisabilité

15.
La réutilisabilité
• Grand principe de développement qui consiste à réutiliser le code (code source
ou API) produit par d'autres. Cette pratique à beaucoup d'avantages :
• Réduction du temps de développement
• Moindre complexité de l'application (par externalisation dans des API de
certaines fonctions)
• Moindres compétences en interne nécessaires, certaines portions de code
n'étant compréhensible que par quelques gourous)
• Plus grande sûreté de fonctionnement : des API largement répandues et
réutilisées ont moins de chance de contenir des bugs résiduels
• Grande communauté utilisatrice de l'API produisant de la documentation et
isolant rapidement des bugs.
• Pourquoi réinventer la roue ? Autant réutiliser du code produit par d'autre, dans
le respect du droit d'auteur et des licences d'utilisation de ce code.

16.
Quelques lois informatiques

17.
Quelques lois en informatique à connaitre
• loi d'Osborn: "les constantes ne le sont pas, les variables ne le seront pas" :
• Ceci traduit des défauts récurrents de conception dans les programmes dans lesquels les programmeurs définissent
en constantes des données qu'ils tentent de modifier, provoquant ainsi des bugs ; et des variables que les fonctions
ne modifient jamais faute de rencontrer la condition favorable qui provoquerait ce changement de valeur.
• Loi de Parkinson : Loi selon laquelle, "tout comme les gaz parfaits, les données tendent à remplir tout
l'espace dont elles disposent".
• Ainsi, concevoir des ordinateurs avec toujours plus de capacité mémoire encourage les développeurs d'applications à
en consommer plu
• Loi de Murphy : Tout ce qui est susceptible de mal tourner, tournera nécessairement mal
• Loi de Gates : la vitesse d'exécution des logiciels est divisée par 2 tous les 18 mois à technologie
constante
• Loi des scouts : « Personne ne connait tout car il ne connait que ce qu’il a besoin ». Plusieurs personnes
ensemble connaissent plus qu’une personne seule
• Deuxième loi des scouts : Laisse le lieu que tu quittes plus propre que tu ne l’as trouvé si tu veux le
retrouver propre

18.
Méthode Informatique
Il n’existe pas de méthode parfaite

19.
Approche traditionnelle vs Agie

20.
Scrum vs Kanban
Scrum Kanban
Backlog
C’est l’endroit ou l’équipe va planifier les sprints et estimer les stories qui seront
affectées aux sprints.
Workflow
Vous pouvez mapper vos colonnes aux états de vos workflows JIRA. Ces
colonnes pourront changer si votre workflow change, en ajoutant ou retirant
simplement des colonnes.
Planification des Sprints
En général lorsque l’on planifie les sprints, le product owner et le project manager
se réunissent avec les développeurs et leur demandent des etimations. Ces
informations peuvent être entrées directement dans JIRA Agile.
Swimlanes
Les swimlanes sont très pratiques pour séparer et organiser les demandes. Un
exemple peut être de grouper les demandes par attribution. On peut ainsi voir
facilement combien de demandes sont affectées à chaque développeur.
Agile Board
Il s’agit du mode Travail, où l’on peut voir le tableau Agile en tant que tel, avec une
colonne par statut. Il permet de voir l’avancement d’un sprint.
Contraintes
Il est possible de positionner des contraintes minimum et maximum sur le nombre
de demandes se trouvant dans chaque colonne. La couleur de fond de la colonne
changera en fonction du respect ou non des contraintes. Cela offre un visuel
simple pour la prise de décision.
Rapports
Avec les Scrum boards, vous disposez de plusieurs rapports d’avancement des
sprints.
Burndown Chart – vérifie l’avancement des équipes par rapport à ce qui était
prévu. Si le scope initial du sprint a été modifié, cela sera également visible dans
ce rapport. Les autres rapports disponibles sont : Sprint Report, Epic Report,
Velocity Chart, Version Report, etc.
Rapports
Kanban dispose également de rapports.
Un rapport qui est très utile en Kanban est le Control Chart. Il permet de mesurer
le temps de cycle pour les demandes. C’est-à-dire qu’il calcule le temps moyen
effectif pour traiter les demandes.
Scrum+Kanban
Ce board permet d’appliquer les fonctionnalités basiques de Kanban pour améliorer le traitement des stories.

21.
Quelle méthode est la plus efficiente ?
• IL N’Y EN A PAS : IL FAUT ADAPTER CHAQUE METHODE A L’EQUIPE
Quelle méthode adopter, si l’équipe est nombreuse et/ou que les fonctions
sont très complexe ?
Adopter la méthode itérative
Quelle méthode adopter, si l’équipe est petite et qu’on souhaite démarrer
rapidement ?
Adopter la méthode KANBAN
Quelle méthode adopter si on a besoin d’un état des lieux détaillé d’avancé
du projet ?
Adopter la méthode SCRUM

22.
La méthode Efficiente
• Elle n’existe pas mais si elle existait elle se rapprocherait plus de
Kanban, car la méthode doit être
• La plus simple
• Permettre le plus de participation entre les équipes
• Permettre une communication continu entre les différents membres
• Permettre une autodocumentation du développement pour simplifier
l’intégration de nouveaux membres

23.
Peut-on appliquer le Kanban au grand projet?
• Telle quelle non !
• Mais un grand projet est une erreur en lui-même
• Un grand projet doit être divisible
• Un grand projet regroupe plusieurs domaines ou phases
• Chaque domaine ou phase doit être un projet à part entière
• Avec un début, une ou plusieurs mêlées et un fin

24.
Synopsis d’un projet efficient
Direction de Projet / Architect L’équipe Devops
L’équipe Devops /
client

25.
De l’idée au projet
Boite à idées /
Atelier de visions
Story mapping Agile Roadmap
Product
Backlog
Intervenants : Direction de projets / Product
Manager / Architecte et Chef de projet

26.
Mise en place de l’équipe
Product
Owner /
Stake Holder
QA Validator
Developer
Business
User
System
Administrator
Exploitation, Durabilité,
Performance, Déploiement,
Supervision, Monitoring,
Configuration
Service
Pourquoi ne pourrait-on pas ?
Comment pourrait-on ?
Quelle-est la première étape
pour aller d'ici à là ?
Que peut-on arrêter de faire ?
Planning, coût, risque,
opportunités, validation
Planning, coût, risque,
opportunités, validation

27.
Plan release
1 Plan release est une subdivision du Product BackLog. On doit définir
• Les major features à livrer
• Jalons de date
• On peut estimer la capacité nécessaire et les réactions à entreprendre

28.
Constat sur les spécifications
• Les principes et pratiques abordés par cet article ont pour point de départ les constats suivants :
• Les utilisateurs ne savent ce qu’ils veulent qu’après avoir vu une première version du logiciel (Principe d’incertitude
du besoin de Humphrey).
• Les besoins changent souvent durant le processus de développement du logiciel (Principe d’incertitude de Hadar Ziv
– 1996).
• Spécifier intégralement un système interactif est impossible (Lemme de Peter Wegner – 1995).

29.
Spécification générale
• En approche efficiente, il est strictement interdit de réaliser des
spécifications détaillés car le temps passés à réaliser ces spéc
allongent le JITA ce qui augmente le risque de rejet de l’application
• Exclure toute connotation technique et détails d’IHM de la
spécification écrite. La documentation technique de type
architecture (logicielle ou matérielle) trouvera sa place dans un
dossier d’architecture si le projet le nécessite ainsi que dans le code
source
• Privilégier le vocabulaire de l’utilisateur, le langage naturel (plutôt
que télégraphique), au présent (plutôt qu’au futur) et décrire
l’expérience utilisateur.

30.
Processus de réalisation par story

31.
Développement
• Le développement est le fait de passer les tests unitaires au vert et
rien d’autre
• Aucun surplus ne doit être réalisé
• Le développement doit être évolutif mais non évolué
• Chaque classe doit mettre de ce quelle a à faire
Celui qui sait, fait ! Une classe par fonction ! Une application modulaire
Je me limite au minimum
pour être au vert !

32.
Test D’intégration
• Un développeur chargé de l’intégration des différentes fonctions du système doit
appliquer la même que le développeur d’une fonction
• Les tests d’intégration doivent couvrir les aspects suivants
• Fonction, Déploiement, Configuration, Journalisation, Debugging, Monitoring, Compatibilité et
conformité
• Un environnement d’intégration doit être prévu et similaire à la production (en
nombre de composants mais d’unité)
• Les tests d’intégration doivent être automatisés
• Les tests d’intégration doivent être restitué dans un cahier d’acceptation
• Les développeurs d’intégration sont responsable de la branche intégration dans le
contrôleur de source.
• Les tests d’intégration doivent être définis entre les développeurs et les
administrateurs

33.
Validation QA
• La Validation se fait à l’intégration de chaque fonctionnalité
et non à la fin du projet de développement
• La QA s’assure la conformité du développement et des
spécifications
• La QA s’assure que les tests d’acceptance sont en vert
• La QA s’assure que les documents et spécifications intégrent
bien les derniers cas d’usage spécifiés et développés
• La QA s’assure que les tests fonctionnels humains sont
conformes aux spécifications
• La QA est garant du temps de traitement de l’application
conformément aux prérequis

34.
Le changement
• Changement chez le client
• L’équipe projet doit accompagner le client dans son changement pour éviter les
effets boomerang
• Des ateliers changement doivent être prévu dès le départ pour former les utilisateurs
à la future version et non pas attendre la fin du projet
• Les animateurs doivent remonter à l’équipe projet toute remarque des utilisateurs
via un jeu de questionnaire
• Un atelier de relecture des retours clients doit être prévu pour éviter le rejet futur
• Changement chez le développeur
• Les spécifications doivent être flexible pour permettre le changement à tout moment
• Les Développements doit être suffisant mais trop

35.
Evolution des besoins de transport

36.
Formaliser les spécifications
• La matrice Given-When-Then est un format recommandé pour le test fonctionnel
d'une User Story:
• (Given) (Etant donné) un contexte,
• (When) (Lorsque) l'utilisateur effectue certaines actions,
• (Then) (Alors) on doit pouvoir constater telles conséquences
• Par exemple:
• Etant donné un solde positif de mon compte, et aucun retrait cette semaine,
• Lorsque je retire un montant inférieur à la limite de retrait,
• Alors mon retrait doit se dérouler sans erreur ou avertissement
• Des outils tels que JBehave, RSpec ou Cucumber encouragent l'utilisation de cette
formule

37.
Les outils
• Les outils du développeur
• Développement
• Visual studio 2015
• Resharper
• Test – contrôle de qualité
• Ncrunch
• Nunit
• Spécification
• Specflow
• Contrôle de source
• Team Service Git
• Planing / Tâche
• Team Service Work Item
• Les outils du Build
• Build
• Team Service Build
• Test – automatique
• Nunit runer
• Team Service Test
• Spécification
• Specflow generator for doc
• Contrôle de source
• Team Service Git
• Planing / Tâche
• Team Service Work Item
• Release
• Hosting
• Azure
• Partage de packages
• Team Service Package

38.
Merci et Questions
mbruchet@live.fr
https://fr.linkedin.com/in/michelbruchet
Me Contacter