Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
L’informatique efficience
Informatique par la pratique : Création d’un serveur de jeux de quizz
Créé par Michel Bruchet – ...
L’efficience
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet
Qu’est-ce l’efficience ?
•L'efficience est l'optimisation des outils
mis en œuvre pour parvenir à un
résultat. Elle se mes...
Efficience # Efficacité
• qui est le rapport entre les résultats obtenus et les objectifs fixés
Efficacité C’est efficace ...
Efficience # Rentabilité
• qui est le rapport entre les revenus obtenus et les capitaux investis
Créé par Michel Bruchet –...
Efficience > Efficacité > Rentabilité
Rentabilité Efficacité Efficience
Optimise les ressources employés et
diminuent leur...
L’exploitabilité
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet
Qu’est-ce que l’exploitation informatique
• L'exploitation informatique est l'activité qui consiste à maintenir
opérationn...
VABE : Vérification d’Aptitude à la Bonne
Exploitabilité
1. Vérifier que l’applicatif est conforme aux Normes édictées par...
La scalabilité
Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet
Evolutivité / Scalabilité # Evolué
• Un système capable d’accueillir 200 personnes lorsqu’on est que 50 personnes n’est pa...
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...
Réutilisabilité
La réutilisabilité
• Grand principe de développement qui consiste à réutiliser le code (code source
ou API) produit par d'...
Quelques lois informatiques
Quelques lois en informatique à connaitre
• loi d'Osborn: "les constantes ne le sont pas, les variables ne le seront pas" ...
Méthode Informatique
Il n’existe pas de méthode parfaite
Approche traditionnelle vs Agie
Scrum vs Kanban
Scrum Kanban
Backlog
C’est l’endroit ou l’équipe va planifier les sprints et estimer les stories qui seron...
Quelle méthode est la plus efficiente ?
• IL N’Y EN A PAS : IL FAUT ADAPTER CHAQUE METHODE A L’EQUIPE
Quelle méthode adopt...
La méthode Efficiente
• Elle n’existe pas mais si elle existait elle se rapprocherait plus de
Kanban, car la méthode doit ...
Peut-on appliquer le Kanban au grand projet?
• Telle quelle non !
• Mais un grand projet est une erreur en lui-même
• Un g...
Synopsis d’un projet efficient
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 Roadmap
Product
Backlog
Intervenants : Directio...
Mise en place de l’équipe
Product
Owner /
Stake Holder
QA Validator
Developer
Business
User
System
Administrator
Exploitat...
Plan release
1 Plan release est une subdivision du Product BackLog. On doit définir
• Les major features à livrer
• Jalons...
Constat sur les spécifications
• Les principes et pratiques abordés par cet article ont pour point de départ les constats ...
Spécification générale
• En approche efficiente, il est strictement interdit de réaliser des
spécifications détaillés car ...
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...
Test D’intégration
• Un développeur chargé de l’intégration des différentes fonctions du système doit
appliquer la même qu...
Validation QA
• La Validation se fait à l’intégration de chaque fonctionnalité
et non à la fin du projet de développement
...
Le changement
• Changement chez le client
• L’équipe projet doit accompagner le client dans son changement pour éviter les...
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 St...
Les outils
• Les outils du développeur
• Développement
• Visual studio 2015
• Resharper
• Test – contrôle de qualité
• Ncr...
Merci et Questions
mbruchet@live.fr
https://fr.linkedin.com/in/michelbruchet
Me Contacter
Upcoming SlideShare
Loading in …5
×

L’informatique efficience

483 views

Published on

Qu'est-ce l'efficience en informatique et comment y atteindre

Published in: Leadership & Management
  • Be the first to comment

  • Be the first to like this

L’informatique efficience

  1. 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. 2. L’efficience Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet
  3. 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. 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. 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. 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. 7. L’exploitabilité Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet
  8. 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. 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. 10. La scalabilité Créé par Michel Bruchet – mbruchet@live.fr / https://fr.linkedin.com/in/michelbruchet
  11. 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. 12. Le JITA : Juste in time applicatif
  13. 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. 14. Réutilisabilité
  15. 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. 16. Quelques lois informatiques
  17. 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. 18. Méthode Informatique Il n’existe pas de méthode parfaite
  19. 19. Approche traditionnelle vs Agie
  20. 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. 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. 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. 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. 24. Synopsis d’un projet efficient Direction de Projet / Architect L’équipe Devops L’équipe Devops / client
  25. 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. 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. 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. 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. 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. 30. Processus de réalisation par story
  31. 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. 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. 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. 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. 35. Evolution des besoins de transport
  36. 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. 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. 38. Merci et Questions mbruchet@live.fr https://fr.linkedin.com/in/michelbruchet Me Contacter

×