time to market · "quoi" plutôt que sur le "comment". le produit doit être le...

TIME TO MARKET

TIME TO MARKET

TIME TO MARKET

[ MVP ]

Réalisez votre MinimumViable Product pour

éprouver votre concept.

TIME TO MARKET

[ MVP ]

Le périmètre de votre MVP doitêtre réduit tout en permettant demarketer votre produit.

Misez sur les Early Adopters etrécoltez un maximum defeedback.

Votre MVP est déployé etexploitable en production.

TIME TO MARKET

[ FAIL-FAST ]

Échouer vite c’estapprendre vite.

TIME TO MARKET

[ FAIL-FAST ]

Éprouvez rapidement la solution(quelques semaines), récoltez lefeedback de vos utilisateurs etapprenez de vos erreurs.

N'ayez pas peur de tout changer.

Ne l'oubliez pas, vous allezéchouer !

TIME TO MARKET

[ KISS ]

Keep It Simple and Stupid.

Pourquoi faire compliquéquand on peut faire simple

?

TIME TO MARKET

[ KISS ]

Évitez l’over-engineering, si unemaquette "papier" ou un GoogleForm suffit pour éprouver votreconcept, n'allez pas plus loin.

Restez simple ! À la fois sur le plantechnique et sur le planfonctionnel.

TIME TO MARKET

[ PRODUCTIVITÉ ]

Spécifiez moins,développez plus.

TIME TO MARKET

[ PRODUCTIVITÉ ]

Limitez vos spécifications au strictnécessaire, concentrez vous sur le"quoi" plutôt que sur le "comment".

Le produit doit être le plus auto-documenté possible.

La documentation doit êtreversionnée au même titre que lecode.

TIME TO MARKET

[ SAAS ]

Étudiez systématiquementles solutions SaaS.

TIME TO MARKET

[ SAAS ]

Les solutions SaaS sont pérenneset économiques.

Dans certains cas, le SaaS permetd' accélérer la mise en oeuvred'un MVP.

Pensez la vision économique àterme vis à vis des alternatives enterme de coût total (TCO : TotalCost of Ownership) et nonuniquement en terme de coût delicence.

TIME TO MARKET

[ COEUR DE MÉTIER ]

Le coeur de métier ne doitpas être un frein à la

construction de nouveauxservices et applications.

TIME TO MARKET

[ COEUR DE MÉTIER ]

Le rythme d'évolution et delivraison du coeur de métier doitêtre compatible avec l'agilité desservices qui le consomment.

Le coeur de métier doit exposerdes services.

Le coeur de métier doit adopter unprincipe Event-Driven, il rendcompte des actes de gestion sousla forme d'événements.

TIME TO MARKET

[ DÉPLOIEMENTCONTINU ]

Le déploiement enproduction est un non-

événement.

TIME TO MARKET

[ DÉPLOIEMENT CONTINU]

Misez sur le déploiement continuafin d'adapter le déploiement enproduction aux contraintes etbesoins business et non l'inverse.

Les déploiements à travers lesenvironnements, jusqu'enproduction, doivent êtreautomatisés et fréquents.

TIME TO MARKET

[ BÊTA PERPÉTUELLE ]

L’approche bêtaperpétuelle permet

d’impliquer vos utilisateursdans le processus de

développement.

TIME TO MARKET

[ BÊTA PERPÉTUELLE ]

N'hésitez pas à avoir recours auprincipe de bêta perpétuelle danslaquelle les utilisateursparticipent au développement.

Le terme de bêta perpétuelledésigne une applicationdéveloppée en flux tendu, enconstante évolution, et non pasun produit inachevé.

USER EXPERIENCE

USER EXPERIENCE

USER EXPERIENCE

[ PERCEPTION ]

L’expérience perçue parl’utilisateur estfondamentale.

L’ergonomie n’est pasnégociable.

USER EXPERIENCE

[ PERCEPTION ]

Ne négligez pas le travail desdesigners UX, il est fondamentaldans le développement d'uneapplication.

Intégrez le feedback de vosutilisateurs, celui-ci est essentiel.

USER EXPERIENCE

[ PERFORMANCE ]

Misez sur des interfacesperformantes, tant pourles usages internes que

pour les usages externes.

USER EXPERIENCE

[ PERFORMANCE ]

Les interfaces sont tournées versl'efficacité.

La performance d'une interfacepermet de gagner du temps,d’augmenter la satisfaction desutilisateurs et donc de ménagerleur frustration.

USER EXPERIENCE

[ MOBILE FIRST ]

Adoptez une stratégieMobile First.

USER EXPERIENCE

[ MOBILE FIRST ]

Les terminaux mobilesreprésentent la part la plusimportante du marché.

Penser mobile, c'est penser àl'essentiel.

Le Responsive Design est lanorme, c'est une sourced'économies (MVP).

USER EXPERIENCE

[ OMNI-CANAL ]

Adaptez-vous aux usages,l’omni-canal est la norme.

USER EXPERIENCE

[ OMNI-CANAL ]

L'approche omni-canal permetd'offrir à l'utilisateur uneexpérience unifiée (exemple :Netflix).

Les différents canaux sontsynchronisés et cohérents(contrairement aux traitements parbatchs).

Tous les acteurs (clients,conseillers) accèdent aux mêmesinformations.

USER EXPERIENCE

[ SELF-DATA ]

Les utilisateurs sontpropriétaires de leurs

données et de leurparcours.

USER EXPERIENCE

[ SELF-DATA ]

Laissez aux individus, à toutmoment, le contrôle sur leursdonnées personnelles.

Établissez un climat de confianceen permettant aux utilisateurstraçabilité et contrôle en temps-réel.

Les sous-systèmes doiventrépondre aux mêmes exigences.

USER EXPERIENCE

[ CRM/SFA ]

La relation client doit êtreunifiée et contextualiséegrâce à un CRM / SFAsouple, fédérateur etorienté événements.

USER EXPERIENCE

[ CRM/SFA ]

Optez pour un CRM qui gère à lafois la relation client et l'animationde la force de vente (SFA : SalesForce Automation).

Le CRM doit être ouvert auxnouvelles opportunités.

Le CRM produit des événementscorrespondant aux actes degestion pour s'inscrire dans lalogique Event-Driven de laplateforme.

USER EXPERIENCE

[ BIG DATA ]

La plate-forme Big Datapermet de centraliser et

traiter les données del’utilisateur pour servir au

mieux son parcours.

USER EXPERIENCE

[ BIG DATA ]

Centralisez les données duGroupe Maif, des partenaires etdes fournisseurs dans une logiquede parcours.

La "Data Preparation" et lestraitements permettent deconsolider les données.

Les équipes Big Data collaborentavec les Feature Teams pourassurer la gouvernance desdonnées.

USER EXPERIENCE

[ POSTE DE TRAVAIL ]

Le poste de travail estadapté et adaptable aux

usages et canauxmodernes.

USER EXPERIENCE

[ POSTE DE TRAVAIL ]

Adoptez la fédération d'identitépour une expérience unifiée.

Un portail permet d'offrir unevision d'ensemble, il ne remplacepas les applications.

Le poste de travail doit êtremobile, multi-canal et standardafin de permettre l'ouverture dansle cadre de l'entreprise étendue.

USER EXPERIENCE

[ COLLABORATEURS ]

N’oubliez pas que voscollaborateurs utilisent àla maison des applicationsmodernes à l’UX aboutie.

USER EXPERIENCE

[ COLLABORATEURS ]

Traitez tous vos utilisateurscomme des "clients" : internautes,gestionnaires, opérationnels,développeurs, etc.

Ne sous-estimez pas l'effort d'UXà mettre en oeuvre pour lesapplications de gestion à usageinterne.

USER EXPERIENCE

[ TOUT MESURER ]

Tout ce qui peut êtremesuré doit l'être.

Sans mesure, tout n'estqu'opinion.

USER EXPERIENCE

[ TOUT MESURER ]

Pensez les métriques lors dudéveloppement de l'application.Les logs doivent avoir unedimension métier autant quetechnique.

Ne négligez pas les métriques deperformances, elles sontfondamentales.

La Feature Team assurel'exploitation : charge à elle derendre l'application exploitable.

USER EXPERIENCE

[ A/B TESTING ]

L'A/B Testing vouspermet de gagner dutemps en laissant lefeedback trancher.

USER EXPERIENCE

[ A/B TESTING ]

Plutôt que de trancherarbitrairement entre deuxsolutions, n'hésitez pas à mettre enplace l'A/B testing.

Ce pattern consiste à présenterdeux versions différentes d'unemême application et à choisir l'uned'entre elles sur la base demesures objectives de l'activitédes utilisateurs.

USER EXPERIENCE

[ DÉGRADATION ]

Envisagez la dégradationplutôt que l'interruption duservice en cas de panne.

USER EXPERIENCE

[ DÉGRADATION ]

En cas de panne d'un des sous-systèmes, une version dégradéedu service doit être envisagée enpremier lieu plutôt qu'uneinterruption.

Grâce aux Circuit Breakers, isolezune panne afin d'éviter sonimpact et sa propagation surl'ensemble du système.

HUMAIN

HUMAIN

HUMAIN

[ FEATURE TEAM ]

L'équipe est organiséeautour d'un produit ou

d'un service rendu.

HUMAIN

[ FEATURE TEAM ]

Les équipes sont des FeatureTeams, organisées autour d’unensemble fonctionnel cohérent, etcomposées de l’ensemble descompétences nécessaires à cetensemble.

Par exemple : Expert Métier +Développeur Web + DéveloppeurJava + Architecte + DBA +Opérationnel.

La responsabilité est collective, laFeature Team jouit du pouvoirnécessaire à cette responsabilité.

HUMAIN

[ 2-PIZZA TEAM ]

Limitez la taille desFeature Teams (de 5 à 12

personnes).

HUMAIN

[ 2-PIZZA TEAM ]

Limitez la taille d’une FeatureTeam : entre 5 et 12 personnes.

En dessous de 5, elle est tropsensible aux événementsextérieurs et manque de créativité.Au dessus de 12, elle perd enproductivité.

Le terme "2-Pizza Team" indiqueque la taille de la Feature Team nedoit pas dépasser le nombre depersonnes que l’on peut nourriravec deux pizzas.

HUMAIN

[ ARTISAN LOGICIEL ]

Misez sur des personnespolyvalentes qui saventfaire et qui aiment faire.

HUMAIN

[ ARTISAN LOGICIEL ]

Le plus important est la culture dudéveloppement, l' évolutivité et lafaculté d'adaptation.

Recrutez des artisans logiciels(software craftsmen) etdéveloppeurs full-stack , ilsapportent une vraie plus-value parleur savoir faire et leur visiond'ensemble.

Néanmoins, les développeursmobiles - par exemple - sontgénéralement des développeursspécialisés.

HUMAIN

[ RECRUTEMENT ]

Soyez attractifs pourrecruter les meilleurs.

HUMAIN

[ RECRUTEMENT ]

Proposez des modes defonctionnement adaptés auxcollaborateurs : mobilité, homeworking, CYOD (Choose Your OwnDevice).

Laissez du temps pourl’expérimentation et faites en sorteque cela soit organisé dans letemps de travail.

HUMAIN

[ VEILLE ]

L’organisation doit être unmoteur de veille

La veille fait partie dumétier.

HUMAIN

[ VEILLE ]

L’organisation doit être un moteurde veille en mettant en place desdispositifs tels que la formationcontinue ou les Universitésd’entreprise.

N'hésitez pas à les combiner avecd’autres moyens plus informelstels que : Coding Dojos, BrownBag Lunchs, Conférencesexternes.

HUMAIN

[ CO-CONSTRUCTION ]

Cassez les barrières entreles métiers, misez sur la

convergence desobjectifs.

HUMAIN

[ CO-CONSTRUCTION ]

Pour casser les barrières entre lesmétiers, il ne suffit pas deregrouper les gens autour d'unproduit commun dans un lieucommun.

Les démarches Agiles permettentde supprimer ces barrières afind'assurer la convergence desobjectifs.

Ces pratiques font partieintégrante des clés du succès,l'organisation en est garante.

HUMAIN

[ DEVOPS ]

Les pratiques DevOpspermettent de faire

tomber les murs entreBuild et Run.

HUMAIN

[ DEVOPS ]

Adoptez DevOps pour faireconverger Dev et Ops vers unobjectif commun : servirl'organisation.

Les métiers restent différents !DevOps ne veut pas dire qu'unemême personne effectue lestâches de Dev et d'Ops.Développeurs et Opérationnelssont amenés à collaborer afin debénéficier des compétences dechacun et améliorer l' empathie.

HUMAIN

[ DOULEUR ]

Les tâches pénibles sonteffectuées par la Feature

Team.

L'automatisation endécoule.

HUMAIN

[ DOULEUR ]

Dans une organisationtraditionnelle, le manque decompréhension entre les équipesest généralement lié à la distanceet au manque de communication.

Les membres d'une Feature Teamsont co-responsables etsolidaires faces à toutes lestâches.

La douleur est un facteur clé de l'amélioration continue.

HUMAIN

[ CDS ]

Les centres de servicessont difficiles à concilier

avec l’ engagementcollectif.

HUMAIN

[ CDS ]

Les Feature Teams sontconstruites autour de principes quis'appuient fortement sur lacollaboration et l’ engagementcollectif.

Les centres de services tendentvers la rationalisation et leregroupement de l'informatiquepar métier, ce qui est contraire àcette notion d’engagementcollectif.

HUMAIN

[ VALIDATION ]

L'organisation a un rôle devalidation, sans être

dogmatique.

HUMAIN

[ VALIDATION ]

Veillez à ce que l'organisationconserve son rôle de validationsur les outils et les usages. Enparticulier sur les outils quitouchent le patrimoine (exemple :gestion du code source).

Fournissez aux Feature Teams lesmoyens d'étayer leurs choix.

Ne soyez pas dogmatiques etveillez à encouragerl'expérimentation.

HUMAIN

[ TRANSVERSALITÉ ]

Les Feature Teams sontamenées à communiquer

et à partager leursexpériences etcompétences.

HUMAIN

[ TRANSVERSALITÉ ]

Ne créez pas de barrières entre lesFeature Teams.

Mettez en place une organisationet l’ agilité nécessaire afin que lesFeature Teams communiquententre elles et partagent leurscompétences et expériences.

L'organisation de la transversalitéchez Spotify (Tribus, Chapters etGuildes) est un exemple éloquent.

INTÉROPÉRABILITÉ

INTÉROPÉRABILITÉ

INTÉROPÉRABILITÉ

[ API POUR TOUS ]

Des APIs pour tous lesusages : internes, clients et

partenaires, publics.

INTÉROPÉRABILITÉ

[ API POUR TOUS ]

Ouvrez votre organisation à desnouveaux usages et nouveauxclients grâce aux APIs publiques.

Dans le cadre des partenariatscommerciaux, clients commefournisseurs, les APIs sont leformat d'échange standard.

Les APIs ont également vocation àêtre utilisées pour les usagesinternes à l'organisation.

INTÉROPÉRABILITÉ

[ SELF SERVICE ]

Utiliser une API doit êtresimple et rapide.

INTÉROPÉRABILITÉ

[ SELF SERVICE ]

L'utilisation des APIs doit être laplus simple possible. Pensez àl’expérience développeur.

La meilleure solution pour validerl'adéquation avec le besoin est detester l'API rapidement : quelquesminutes doivent suffire !

La plateforme doit proposer uneinterface graphique permettantde tester l'API simplement.

INTÉROPÉRABILITÉ

[ API MANAGEMENT ]

Les utilisations des APIsdoivent être contrôlées et

maîtrisées.

INTÉROPÉRABILITÉ

[ API MANAGEMENT ]

Mettez en place une solution d’APIManagement pour gérer quotas,throttling, authentification etlogging.

Collectez des métriques afin degérer monitoring, filtering etreporting.

INTÉROPÉRABILITÉ

[ EXIGENCES ]

Fixez des exigences auxsystèmes et services

extérieurs intégrés à laplateforme.

INTÉROPÉRABILITÉ

[ EXIGENCES ]

Exigez que les systèmes externesrépondent aux mêmes exigencesque les systèmes internes.

Les systèmes externes doiventpublier des événements etpermettre le monitoringtechnique.

Dans le cas où les données dessystèmes extérieurs doivent êtreintégrées, la synchronisationtotale doit être possible.

INTÉROPÉRABILITÉ

[ MULTI-TENANT ]

L’architecture doit êtrepensée multi-tenant.

INTÉROPÉRABILITÉ

[ MULTI-TENANT ]

Même si la marque blanche n'estpas envisagée à la base, mettez enplace une architecture multi-tenant. Votre application initialeest le premier tenant.

Pensez la multi-instanciationfonctionnelle du système dès ledépart.

INTÉROPÉRABILITÉ

[ PARAMÉTRAGE ]

Les systèmes doivent êtrenativement

paramétrables.

INTÉROPÉRABILITÉ

[ PARAMÉTRAGE ]

Langues, devises, règles métiers,profils de sécurité doivent êtressimple à paramétrer.

Attention à l' hyper-généricité, elleest souvent inutile et source decoût.

Le paramétrage doit être évolutifet rapide en fonction des besoins.

INTÉROPÉRABILITÉ

[ FEATURE FLIPPING ]

Créez des systèmessouples et génériques en

utilisant le feature flipping.

INTÉROPÉRABILITÉ

[ FEATURE FLIPPING ]

Le feature flipping consiste àconcevoir une application commeun ensemble de fonctionnalitésqui peuvent être activées oudésactivées à chaud, enproduction.

Dans une application multi-tenant, le feature flipping permet depersonnaliser les tenants.

Le feature flipping simplifie l'A/Btesting.

RÈGLES DU JEU

RÈGLES DU JEU

RÈGLES DU JEU

[ CHOIX TECHNIQUES ]

Les choix techniques sonteffectués et assumés par

la Feature Team.

RÈGLES DU JEU

[ CHOIX TECHNIQUES ]

La Feature Team doit agir demanière responsable afind'identifier les choix qui l'impactentexclusivement et les choix quiimpactent l'organisation.

Les choix qui dépassent lepérimètre de la Feature Team(exemple : licence, langage deprogrammation peu répandu)doivent être soumis à validationpar l'organisation ou par leprocessus de convergence despairs.

RÈGLES DU JEU

[ BON USAGE ]

Le bon outil pour le bonusage est une source

d'économies.

RÈGLES DU JEU

[ BON USAGE ]

Un mauvais outil imposé à tousest un risque. Le mauvais usaged'un bon outil peut avoir desconséquences très néfastes. Parexemple, les méthodes Agiles malutilisées sont dangereuses.

Les outils doivent être remis enquestion.

Excel est souvent un choixrationnel mais ça n'est pas unoutil à tout faire (CRM, ERP,Datamart, …)

RÈGLES DU JEU

[ BUILD VS. BUY ]

Privilégiez le Build pour lecoeur de métier.

Envisagez le Buy pour lereste, au cas par cas.

RÈGLES DU JEU

[ BUILD VS. BUY ]

Plus un outil porte unefonctionnalité apportant uncaractère différenciant pourl'organisation, plus il a vocation àêtre construit. Le coeur de métierdoit permettre la spécificité ets'adapter souvent et rapidement.Certains progiciels sont parfoisadaptés à ce besoin.

Pour le reste : SaaS, Open Source,Build ou Propriétaire sont à étudierau cas par cas.

RÈGLES DU JEU

[ OPEN SOURCE ]

Privilégiez l’Open Source.

Les choix alternatifsdoivent être étayés.

RÈGLES DU JEU

[ OPEN SOURCE ]

Les solutions propriétaires sontun risque pour l'organisation quidoit être capable de reprendre lamaintenance si besoin.

Rares sont les outils propriétairesqui n'ont pas d'alternatives OpenSource.

L'organisation bénéficie de laCommunauté Open Source etpeut lui reverser sescontributions.

RÈGLES DU JEU

[ MICRO-SERVICES ]

Développez des servicesautonomes et faiblement

couplés.

RÈGLES DU JEU

[ MICRO-SERVICES ]

Le couplage faible doit être lanorme.

Chaque micro-service disposed'une interface clairementdéfinie.

Cette interface détermine lecouplage entre les micro-services.

Le Domain Driven Design permet,notamment avec les BoundedContexts, d'anticiper au mieuxcette problématique.

RÈGLES DU JEU

[ DONNÉES ]

Chaque service possèdeson propre système destockage de données.

RÈGLES DU JEU

[ DONNÉES ]

Un Data Store n'a vocation à êtrecouplé qu'avec un seul micro-service.

L'accès aux données d'un micro-service à un autre est effectuéexclusivement via son interface.

Ce design implique la cohérence àterme à l'échelle de la plateforme.Elle doit être appréhendée à tousles niveaux, y compris UX.

RÈGLES DU JEU

[ PÉRIMÈTRE ]

Chaque micro-service doitavoir un périmètre

fonctionnel raisonnable,qui "loge dans la tête".

RÈGLES DU JEU

[ PÉRIMÈTRE ]

Un micro-service propose unnombre raisonnable defonctionnalités.

N'hésitez pas à découper unmicro-service lorsque celui-cicommence à grossir.

Un service de taille raisonnablepermet d'envisager sereinementla réécriture, si le besoin seprésente.

RÈGLES DU JEU

[ RÉACTIF ]

Le Reactive Manifestoouvre la voie vers la

conception d'architecturesréactives.

RÈGLES DU JEU

[ RÉACTIF ]

La programmation réactive seconcentre sur le flux de donnéeset la propagation du changement.Elle s'appuie sur le pattern"Observer" contrairement àl'approche "Iterator", plusclassique.

Le Reactive Manifesto fixe desaxes fondamentaux : disponibilitéet rapidité, résilience aux pannes,souplesse, élasticité etorientation messages.

RÈGLES DU JEU

[ ASYNC-FIRST ]

Les processusasynchrones favorisent le

découplage et lascalabilité au profit des

performances.

RÈGLES DU JEU

[ ASYNC-FIRST ]

Les échanges entre applicationsdoivent être en premier lieuasynchrones.

Les échanges asynchronespermettent naturellement lecouplage faible, l' isolation et lecontrôle des flux (back-pressure).

La communication synchrone nedoit être envisagée que lorsquel'action l'impose.

RÈGLES DU JEU

[ ÉVÉNEMENTS ]

Le système d'informationsdoit être orienté

événements.

RÈGLES DU JEU

[ ÉVÉNEMENTS ]

Les processus fonctionnelsorientés "événements" sontnaturellement implémentés demanière asynchrone.

L' orientation événements permetde favoriser la mise en placed'approches telles que CommandQuery Responsibility Segregation(CQRS) et Event Sourcing.

RÈGLES DU JEU

[ MESSAGE BROKER ]

Privilégiez un message-broker simple , robuste et

performant à un "tuyauintelligent".

RÈGLES DU JEU

[ MESSAGE BROKER ]

Les ESB ont montré leurs limites :la maintenance évolutive estcritique, aussi bien d'un point devue technique qu'organisationnel.

Les messages brokers commeKafka offrent une solution simple,durable et résiliente.

Des endpoints intelligents et destuyaux simples est unearchitecture qui fonctionne àl'échelle : c'est Internet.

RÈGLES DU JEU

[ SYNCHRONISATION ]

La synchronisation totaledu système doit être

pensée dès sa conception.

RÈGLES DU JEU

[ SYNCHRONISATION ]

Si la synchronisation entre deuxsystèmes est assurée par un fluxd'événements, laresynchronisation totale de cessystèmes doit être prévue dès laconception.

Un audit automatique de lasynchronisation (exemple : paréchantillons) permet de mesureret détecter les éventuelleserreurs de synchronisation.

RÈGLES DU JEU

[ CENTRALISATION ]

La configuration desservices est centralisée,

leur découverte estassurée par un annuaire.

RÈGLES DU JEU

[ CENTRALISATION ]

La configuration des micro-services est centralisée pourl'ensemble des environnements.

Un annuaire centralisé permetd'assurer la découvertedynamique des micro-services.

La scalabilité globale du SIdépend de cet annuaire.

RÈGLES DU JEU

[ BAC À SABLE ]

Les Feature Teamsfournissent un

environnement "bac àsable".

RÈGLES DU JEU

[ BAC À SABLE ]

Les Feature Teams maintiennentun environnement "bac à sable"(version actuelle et version à venir)afin de permettre aux autreséquipes de développer àl'échelle.

Dans certains cas non nominaux,des features peuvent êtredésactivées dans l'environnementde développement.

RÈGLES DU JEU

[ DESIGN FOR FAILURE ]

Votre système tomberaen panne !

Concevez-le afin qu’il y soittolérant.

RÈGLES DU JEU

[ DESIGN FOR FAILURE ]

Votre système tombera en panne,c'est inévitable. Il doit être conçupour cela (Design For Failure).

Prévoir la redondance à tous lesniveaux : matériel (réseau, disque,etc.), applicatifs (plusieursinstances des applications), zonesgéographiques, providers(exemple : AWS + OVH).

RÈGLES DU JEU

[ TOOLKITS ]

Fournissez des toolkits,n’imposez pas de cadres

stricts.

RÈGLES DU JEU

[ TOOLKITS ]

Attention aux composantstechniques maisons ettransverses ! Ils sontcontraignants, coûteux et difficilesà maintenir.

Des accélérateurs, toolkits,stacks techniques peuvent êtremis en commun, au libre choixdes Feature Teams, en évitant uneapproche dogmatique.

RÈGLES DU JEU

[ CLOUD ]

Public, privé ou hybride, lecloud (IaaS ou PaaS) est lanorme pour la production.

RÈGLES DU JEU

[ CLOUD ]

Les services de type PaaS sont àprivilégier, ils sont simples etpassent rapidement à l'échelle.

Les services IaaS permettentd'adresser les cas demandant uneplus grande souplesse , mais ilsdemandent plus de travailopérationnel.

Un cloud privé n'est pas unenvironnement de virtualisationtraditionnel, il s'appuie sur ducommodity hardware.

RÈGLES DU JEU

[ INFRASTRUCTURE ]

Les Feature Teams negèrent pas l'infrastructure,

elle est fournie etmaintenue parl'organisation.

RÈGLES DU JEU

[ INFRASTRUCTURE ]

Les problèmes d'infrastructure nesont pas du ressort des FeatureTeams. L'infrastructure doit leurêtre fournie et maintenue par unservice transverse.

RÈGLES DU JEU

[ CONTENEURS ]

Les conteneurs offrent lasouplesse nécessaire à un

outillage hétérogène.

RÈGLES DU JEU

[ CONTENEURS ]

Les conteneurs offrent lasouplesse nécessaire aux FeatureTeams pour leur permettre unoutillage hétérogène dans uncontexte homogène.

RÈGLES DU JEU

[ ENVIRONNEMENTS ]

L'utilisation de conteneurspermet de s'affranchir des

problèmesd'environnements

techniques.

RÈGLES DU JEU

[ ENVIRONNEMENTS ]

Les conteneurs (exemple : Docker)permettent de s'affranchir desdifférences d'environnement.

Le processus de déploiement doitêtre agnostique à l'environnement.

Certains composants comme lesbases de données ne doivent pasêtre déployés dans desconteneurs. Leur déploiement estmalgré tout automatisé.

RÈGLES DU JEU

[ MÉTRIQUES ]

Les mesures doivent êtrecentralisées et

accessibles à tous.

RÈGLES DU JEU

[ MÉTRIQUES ]

Les métriques sont accessibles àtous avec différents niveaux degranularité : vue détaillée pour laFeature Team concernée,agrégations pour les autresmembres de l'organisation.

L'accès aux métriques n'impliquepas l'accès aux données unitaires,celui-ci doit être contrôlé pourpréserver la confidentialité.

Tous les environnements sontconcernés.

RÈGLES DU JEU

[ QUALITÉ ]

La qualité logicielle estun facteur clé.

RÈGLES DU JEU

[ QUALITÉ ]

Les revues de code sontsystématiques. Elles sonteffectuées par des membres de laFeature Team ou d'autresmembres de l'organisation, dans lecadre de l'amélioration continue.

Ça n'est pas vous qu'on auditemais votre code : "You are not yourcode !".

La qualimétrie peut être en partieautomatisée, mais rien ne vautl'"oeil neuf".

RÈGLES DU JEU

[ TEST AUTOMATISÉS ]

Le testing automatisé estun prérequis non

négociable audéploiement continu.

RÈGLES DU JEU

[ TEST AUTOMATISÉS ]

Le testing automatisé permetd'assurer la qualité du produitdans le temps.

Il est un prérequis au déploiementcontinu, il permet changements etdéploiements fréquents.

Le déploiement en productiondevient un événementanecdotique !

RÈGLES DU JEU

[ NIVEAUX DE TESTS ]

Des tests à tous lesniveaux : unitaires,

intégration, fonctionnels,résilience, performance.

RÈGLES DU JEU

[ NIVEAUX DE TESTS ]

Les tests d'intégration etfonctionnels sont les plusimportants, ce sont eux quigarantissent le bonfonctionnement du produit.

Les tests unitaires sont adaptés audéveloppement.

Les tests de performancepermettent de mesurer laperformance dans le temps.

Les tests de résilience permettentd'anticiper les pannes.

RÈGLES DU JEU

[ COUVERTURE ]

La couverture est leprincipal indicateur objectif

de qualité des tests.

RÈGLES DU JEU

[ COUVERTURE ]

La couverture de code par lestests est une bonne métrique dela qualité du code.

C'est une condition nécessairemais pas suffisante, la couvertured'une mauvaise stratégie de testspeut être élevée sans être garantede la bonne qualité du code.

RÈGLES DU JEU

[ SÉCURITÉ ]

La sécurité est unprocessus, elle ne doit pasêtre traitée en réaction aux

problèmes.

RÈGLES DU JEU

[ SÉCURITÉ ]

Des experts sécurité peuvent êtreintégrés directement aux FeatureTeams si nécessaire.

Des experts sécurité sontdisponibles dans l'organisationpour auditer, sensibiliser ettransmettre.