L’informatique efficience

L’informatique efficience

Informatique par la pratique : Création d’un serveur de jeux de quizz

Créé par Michel Bruchet – [email protected] / https://fr.linkedin.com/in/michelbruchet

L’efficience


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


Efficience # Efficacité• qui est le rapport entre les résultats obtenus et les objectifs fixés

Efficacité C’est efficace mais pas efficient


Efficience # Rentabilité• qui est le rapport entre les revenus obtenus et les capitaux investis


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ésUtilisé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


L’exploitabilité


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


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 supervision3. 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 traitements4. 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érouler6. Vérifier le Plan de Reprise d’Activité conformément aux besoin du client (DMIA, etc….)


La scalabilité


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 ?


Le JITA : Juste in time applicatif

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

Réutilisabilité

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.

Quelques lois informatiques

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

Méthode InformatiqueIl n’existe pas de méthode parfaite

Approche traditionnelle vs Agie

Scrum vs KanbanScrum Kanban

BacklogC’est l’endroit ou l’équipe va planifier les sprints et estimer les stories qui seront affectées aux sprints.

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

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

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

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

RapportsKanban 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+KanbanCe board permet d’appliquer les fonctionnalités basiques de Kanban pour améliorer le traitement des stories.

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érativeQuelle méthode adopter, si l’équipe est petite et qu’on souhaite démarrer rapidement ?Adopter la méthode KANBANQuelle méthode adopter si on a besoin d’un état des lieux détaillé d’avancé du projet ?Adopter la méthode SCRUM

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

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

Synopsis d’un projet efficientId

ées

Atel

ier d

e vis

ion

Stor

y map

ping

Swot

/ Ro

adm

ap

Back

log

Défin

ition

de

l’équ

ipe

Défin

ition

d’u

n

plan

de

rele

ase

Spéc

ifica

tion

géné

rale

Déve

lopp

emen

t

Spéc

ifica

tion

par l

’exem

ple

Réal

isatio

n du

déve

lopp

emen

tTe

st u

nita

ire Test

d’a

ccep

tanc

eIn

tégr

ation

co

nten

u Test

d’

inté

grati

on

Clie

nt/U

tilisa

teur

Direction de Projet / Architect L’équipe Devops L’équipe Devops / client

De l’idée au projet

Boite à idées / Atelier de visions

Story mapping Agile RoadmapProduct Backlog

Intervenants : Direction de projets / Product Manager / Architecte et Chef de projet

Mise en place de l’équipe

Product Owner /Stake HolderQA ValidatorDeveloperBusiness UserSystem 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

Plan release1 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

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

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.

Processus de réalisation par story

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 modulaireJe me limite au minimum pour être au vert !

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

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

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

Evolution des besoins de transport

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

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

Merci et Questions

[email protected]://fr.linkedin.com/in/michelbruchet

Me Contacter

mailto:[email protected]

https://fr.linkedin.com/in/michelbruchet

L’informatique efficience

Leadership & Management

Transcript of L’informatique efficience