SlideShare une entreprise Scribd logo
1  sur  38
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
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 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
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
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
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
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é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
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
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 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
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 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 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.
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
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 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 : Direction de projets / Product
Manager / Architecte et Chef de projet
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
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
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 modulaire
Je 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
mbruchet@live.fr
https://fr.linkedin.com/in/michelbruchet
Me Contacter

Contenu connexe

Tendances

Introduction à DevOps
Introduction à DevOpsIntroduction à DevOps
Introduction à DevOpsMicrosoft
 
Afterwork Devops : vision et pratiques
Afterwork Devops : vision et pratiquesAfterwork Devops : vision et pratiques
Afterwork Devops : vision et pratiquesOCTO Technology Suisse
 
DevOps - Retour d’expérience - RivieraDev du 20 Octobre 2011
DevOps - Retour d’expérience - RivieraDev du 20 Octobre 2011DevOps - Retour d’expérience - RivieraDev du 20 Octobre 2011
DevOps - Retour d’expérience - RivieraDev du 20 Octobre 2011Henri Gomez
 
DEVOPS - La synthèse
DEVOPS - La synthèseDEVOPS - La synthèse
DEVOPS - La synthèseCOMPETENSIS
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2Sébastien Bourguignon
 
Du cycle en V à DevOps, en passant par agile - Normation
Du cycle en V à DevOps, en passant par agile - NormationDu cycle en V à DevOps, en passant par agile - Normation
Du cycle en V à DevOps, en passant par agile - NormationRUDDER
 
DevOps en pratique - Paris Meetup Bluemix 19/11/2014
DevOps en pratique - Paris Meetup Bluemix 19/11/2014DevOps en pratique - Paris Meetup Bluemix 19/11/2014
DevOps en pratique - Paris Meetup Bluemix 19/11/2014IBM France Lab
 
DODMTL 2019 - Agile et DevOps chez Croesus
DODMTL 2019 - Agile et DevOps chez CroesusDODMTL 2019 - Agile et DevOps chez Croesus
DODMTL 2019 - Agile et DevOps chez CroesusMartin Deslongchamps
 
DevOps vu par les ops
DevOps vu par les opsDevOps vu par les ops
DevOps vu par les opsMichel HUBERT
 
Introduction au DevOps @SfPot 2014
Introduction au DevOps @SfPot 2014Introduction au DevOps @SfPot 2014
Introduction au DevOps @SfPot 2014Jonathan Martin
 
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011Henri Gomez
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSIAprès l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSISébastien Bourguignon
 
Agile lille 2015 devops etapres
Agile lille 2015 devops etapresAgile lille 2015 devops etapres
Agile lille 2015 devops etapresLaurent Tardif
 
DevOps - Qualité, Performance et Télémétrie avec Visual Studio 2015
DevOps - Qualité, Performance et Télémétrie avec Visual Studio 2015DevOps - Qualité, Performance et Télémétrie avec Visual Studio 2015
DevOps - Qualité, Performance et Télémétrie avec Visual Studio 2015Microsoft
 
[devops REX 2016] Comment l’IT peut arrêter de se faire vanner par les devs ?
[devops REX 2016] Comment l’IT peut arrêter de se faire vanner par les devs ?[devops REX 2016] Comment l’IT peut arrêter de se faire vanner par les devs ?
[devops REX 2016] Comment l’IT peut arrêter de se faire vanner par les devs ?devops REX
 
JSS2014 - L'agilité n'est pas une fatalité
JSS2014 - L'agilité n'est pas une fatalitéJSS2014 - L'agilité n'est pas une fatalité
JSS2014 - L'agilité n'est pas une fatalitéNicholas Suter
 

Tendances (20)

The DevOps Wonder @ PHPTour Lyon 2014
The DevOps Wonder @ PHPTour Lyon 2014The DevOps Wonder @ PHPTour Lyon 2014
The DevOps Wonder @ PHPTour Lyon 2014
 
Presentation-DEVOPS-par-GDG
Presentation-DEVOPS-par-GDGPresentation-DEVOPS-par-GDG
Presentation-DEVOPS-par-GDG
 
Introduction à DevOps
Introduction à DevOpsIntroduction à DevOps
Introduction à DevOps
 
Afterwork Devops : vision et pratiques
Afterwork Devops : vision et pratiquesAfterwork Devops : vision et pratiques
Afterwork Devops : vision et pratiques
 
DevOps - Retour d’expérience - RivieraDev du 20 Octobre 2011
DevOps - Retour d’expérience - RivieraDev du 20 Octobre 2011DevOps - Retour d’expérience - RivieraDev du 20 Octobre 2011
DevOps - Retour d’expérience - RivieraDev du 20 Octobre 2011
 
DEVOPS - La synthèse
DEVOPS - La synthèseDEVOPS - La synthèse
DEVOPS - La synthèse
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2
 
Du cycle en V à DevOps, en passant par agile - Normation
Du cycle en V à DevOps, en passant par agile - NormationDu cycle en V à DevOps, en passant par agile - Normation
Du cycle en V à DevOps, en passant par agile - Normation
 
DevOps en pratique - Paris Meetup Bluemix 19/11/2014
DevOps en pratique - Paris Meetup Bluemix 19/11/2014DevOps en pratique - Paris Meetup Bluemix 19/11/2014
DevOps en pratique - Paris Meetup Bluemix 19/11/2014
 
DODMTL 2019 - Agile et DevOps chez Croesus
DODMTL 2019 - Agile et DevOps chez CroesusDODMTL 2019 - Agile et DevOps chez Croesus
DODMTL 2019 - Agile et DevOps chez Croesus
 
DevOps vu par les ops
DevOps vu par les opsDevOps vu par les ops
DevOps vu par les ops
 
TIAD : DevOps & continuous delivery dans le cloud
TIAD : DevOps & continuous delivery dans le cloudTIAD : DevOps & continuous delivery dans le cloud
TIAD : DevOps & continuous delivery dans le cloud
 
Introduction au DevOps @SfPot 2014
Introduction au DevOps @SfPot 2014Introduction au DevOps @SfPot 2014
Introduction au DevOps @SfPot 2014
 
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSIAprès l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
 
Agile lille 2015 devops etapres
Agile lille 2015 devops etapresAgile lille 2015 devops etapres
Agile lille 2015 devops etapres
 
DevOps - Qualité, Performance et Télémétrie avec Visual Studio 2015
DevOps - Qualité, Performance et Télémétrie avec Visual Studio 2015DevOps - Qualité, Performance et Télémétrie avec Visual Studio 2015
DevOps - Qualité, Performance et Télémétrie avec Visual Studio 2015
 
[devops REX 2016] Comment l’IT peut arrêter de se faire vanner par les devs ?
[devops REX 2016] Comment l’IT peut arrêter de se faire vanner par les devs ?[devops REX 2016] Comment l’IT peut arrêter de se faire vanner par les devs ?
[devops REX 2016] Comment l’IT peut arrêter de se faire vanner par les devs ?
 
Scrum is not enough
Scrum is not enoughScrum is not enough
Scrum is not enough
 
JSS2014 - L'agilité n'est pas une fatalité
JSS2014 - L'agilité n'est pas une fatalitéJSS2014 - L'agilité n'est pas une fatalité
JSS2014 - L'agilité n'est pas une fatalité
 

Similaire à L’informatique efficience

Présentation DEVOPS.pptx
Présentation DEVOPS.pptxPrésentation DEVOPS.pptx
Présentation DEVOPS.pptxboulonvert
 
Présentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxPrésentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxZALIMAZA
 
Présentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptxPrésentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptxZALIMAZA
 
Présentation DEVOPS_.pptx
Présentation DEVOPS_.pptxPrésentation DEVOPS_.pptx
Présentation DEVOPS_.pptxZALIMAZA
 
Présentation DEVOPSS.pptx
Présentation DEVOPSS.pptxPrésentation DEVOPSS.pptx
Présentation DEVOPSS.pptxZALIMAZA
 
Présentation DEVOPS_Mauritanie.pptx
Présentation DEVOPS_Mauritanie.pptxPrésentation DEVOPS_Mauritanie.pptx
Présentation DEVOPS_Mauritanie.pptxZALIMAZA
 
Présentation DEVOPS_Black.pptx
Présentation DEVOPS_Black.pptxPrésentation DEVOPS_Black.pptx
Présentation DEVOPS_Black.pptxZALIMAZA
 
Présentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptxPrésentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptxssuserf298861
 
Présentation DEVOPS_hyper.pptx
Présentation DEVOPS_hyper.pptxPrésentation DEVOPS_hyper.pptx
Présentation DEVOPS_hyper.pptxZALIMAZA
 
Présentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptxPrésentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptxZALIMAZA
 
Présentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptxPrésentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptxZALIMAZA
 
Méthodes agiles, frameworks javascript: optimisez votre time to market
Méthodes agiles, frameworks javascript: optimisez votre time to marketMéthodes agiles, frameworks javascript: optimisez votre time to market
Méthodes agiles, frameworks javascript: optimisez votre time to marketmichael_bailly
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...Sid Ahmed Benkraoua
 
Méthodologie projet, historique et innovation
Méthodologie projet, historique et innovationMéthodologie projet, historique et innovation
Méthodologie projet, historique et innovation2le
 
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
qualimétrie logiciel -  Entreprise Software Analytic - nov 2015qualimétrie logiciel -  Entreprise Software Analytic - nov 2015
qualimétrie logiciel - Entreprise Software Analytic - nov 2015Julien Vq
 
Methodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPMethodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPNicolas Perriault
 
Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)David VALLAT
 

Similaire à L’informatique efficience (20)

Présentation DEVOPS.pptx
Présentation DEVOPS.pptxPrésentation DEVOPS.pptx
Présentation DEVOPS.pptx
 
Présentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxPrésentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptx
 
Présentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptxPrésentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptx
 
Présentation DEVOPS_.pptx
Présentation DEVOPS_.pptxPrésentation DEVOPS_.pptx
Présentation DEVOPS_.pptx
 
Présentation DEVOPSS.pptx
Présentation DEVOPSS.pptxPrésentation DEVOPSS.pptx
Présentation DEVOPSS.pptx
 
Présentation DEVOPS_Mauritanie.pptx
Présentation DEVOPS_Mauritanie.pptxPrésentation DEVOPS_Mauritanie.pptx
Présentation DEVOPS_Mauritanie.pptx
 
Présentation DEVOPS_Black.pptx
Présentation DEVOPS_Black.pptxPrésentation DEVOPS_Black.pptx
Présentation DEVOPS_Black.pptx
 
Présentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptxPrésentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptx
 
Présentation DEVOPS_hyper.pptx
Présentation DEVOPS_hyper.pptxPrésentation DEVOPS_hyper.pptx
Présentation DEVOPS_hyper.pptx
 
Présentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptxPrésentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptx
 
Présentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptxPrésentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptx
 
Méthodes agiles, frameworks javascript: optimisez votre time to market
Méthodes agiles, frameworks javascript: optimisez votre time to marketMéthodes agiles, frameworks javascript: optimisez votre time to market
Méthodes agiles, frameworks javascript: optimisez votre time to market
 
Dev opsday case study
Dev opsday   case studyDev opsday   case study
Dev opsday case study
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
 
Méthodologie projet, historique et innovation
Méthodologie projet, historique et innovationMéthodologie projet, historique et innovation
Méthodologie projet, historique et innovation
 
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
qualimétrie logiciel -  Entreprise Software Analytic - nov 2015qualimétrie logiciel -  Entreprise Software Analytic - nov 2015
qualimétrie logiciel - Entreprise Software Analytic - nov 2015
 
Methodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPMethodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XP
 
Méthodes agile
Méthodes agileMéthodes agile
Méthodes agile
 
Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)
 
12 agile
12 agile12 agile
12 agile
 

Plus de Michel Bruchet

Rechercherunproduit pitch-en
Rechercherunproduit pitch-enRechercherunproduit pitch-en
Rechercherunproduit pitch-enMichel Bruchet
 
Rechercherunproduit pitch
Rechercherunproduit pitchRechercherunproduit pitch
Rechercherunproduit pitchMichel Bruchet
 
Microservices architecture v2
Microservices architecture v2Microservices architecture v2
Microservices architecture v2Michel Bruchet
 
Configure an environnement for ASP.NET Core 2
Configure an environnement for ASP.NET Core 2Configure an environnement for ASP.NET Core 2
Configure an environnement for ASP.NET Core 2Michel Bruchet
 
Microservices architecture
Microservices architectureMicroservices architecture
Microservices architectureMichel Bruchet
 
Architecture multi tiers et système de notification
Architecture multi tiers et système de notificationArchitecture multi tiers et système de notification
Architecture multi tiers et système de notificationMichel Bruchet
 
Video3 mise enplacedaikibo
Video3 mise enplacedaikiboVideo3 mise enplacedaikibo
Video3 mise enplacedaikiboMichel Bruchet
 
Video2 agilite etscalabiliteentreprise
Video2 agilite etscalabiliteentrepriseVideo2 agilite etscalabiliteentreprise
Video2 agilite etscalabiliteentrepriseMichel Bruchet
 
Aspnetcore introduction
Aspnetcore introductionAspnetcore introduction
Aspnetcore introductionMichel Bruchet
 
Startpoint - Sprint 2 - Objectifs
Startpoint - Sprint 2 - ObjectifsStartpoint - Sprint 2 - Objectifs
Startpoint - Sprint 2 - ObjectifsMichel Bruchet
 
Devops - VSTS - Source
Devops - VSTS - SourceDevops - VSTS - Source
Devops - VSTS - SourceMichel Bruchet
 

Plus de Michel Bruchet (20)

Meetup daikibo 1
Meetup daikibo 1Meetup daikibo 1
Meetup daikibo 1
 
Rechercherunproduit pitch-en
Rechercherunproduit pitch-enRechercherunproduit pitch-en
Rechercherunproduit pitch-en
 
Rechercherunproduit pitch
Rechercherunproduit pitchRechercherunproduit pitch
Rechercherunproduit pitch
 
Proxy pattern
Proxy patternProxy pattern
Proxy pattern
 
Proxy pattern
Proxy patternProxy pattern
Proxy pattern
 
Microservices architecture v2
Microservices architecture v2Microservices architecture v2
Microservices architecture v2
 
Configure an environnement for ASP.NET Core 2
Configure an environnement for ASP.NET Core 2Configure an environnement for ASP.NET Core 2
Configure an environnement for ASP.NET Core 2
 
Microservices architecture
Microservices architectureMicroservices architecture
Microservices architecture
 
About netcore2
About netcore2About netcore2
About netcore2
 
ECommerce Logging
ECommerce LoggingECommerce Logging
ECommerce Logging
 
Architecture multi tiers et système de notification
Architecture multi tiers et système de notificationArchitecture multi tiers et système de notification
Architecture multi tiers et système de notification
 
Revue sprint2
Revue sprint2Revue sprint2
Revue sprint2
 
Revue sprint 1
Revue sprint 1Revue sprint 1
Revue sprint 1
 
Video3 mise enplacedaikibo
Video3 mise enplacedaikiboVideo3 mise enplacedaikibo
Video3 mise enplacedaikibo
 
Video2 agilite etscalabiliteentreprise
Video2 agilite etscalabiliteentrepriseVideo2 agilite etscalabiliteentreprise
Video2 agilite etscalabiliteentreprise
 
Ingenius Web Services
Ingenius Web ServicesIngenius Web Services
Ingenius Web Services
 
Aspnetcore introduction
Aspnetcore introductionAspnetcore introduction
Aspnetcore introduction
 
Startpoint - Sprint 2 - Objectifs
Startpoint - Sprint 2 - ObjectifsStartpoint - Sprint 2 - Objectifs
Startpoint - Sprint 2 - Objectifs
 
StartPoint - Sprint 1
StartPoint - Sprint 1StartPoint - Sprint 1
StartPoint - Sprint 1
 
Devops - VSTS - Source
Devops - VSTS - SourceDevops - VSTS - Source
Devops - VSTS - Source
 

L’informatique efficience

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