Le document présente des meilleures pratiques en ingénierie logicielle, mettant l'accent sur l'importance du développement agile, de l'automatisation et de la mesure des performances. Il aborde des concepts comme le 'minimum viable product', les tests A/B, et la culture DevOps pour favoriser l'innovation et l'efficacité. Enfin, il suggère la formation d'équipes de taille optimale pour maximiser la créativité et l'efficacité dans le développement de produits logiciels.

1. geantsduweb.com
Les Géants du Web
10 pratiques
Ludovic Cinquin, DG France
Guillaume Plouin, Practice Leader Prospective
Stephen Perin, Consultant Senior
Petit déjeuner – mardi 20 novembre 2012
1
© OCTO 2012

2. 2
© OCTO 2012

4. Plus Gros
4
© OCTO 2012

5. 5
© OCTO 2012

6. Build vs Buy
! Pas de progiciels
! Beaucoup d’Open Source
Bref, le contraire de beaucoup de DSI
6
© OCTO 2012

7. Une certaine logique
7
© OCTO 2012

8. Mais aussi…
! … des progiciels souvent peu adaptés au très gros
! coût de licence rédhibitoire
! Généricité
! Architecture
8
© OCTO 2012

9. 9
© OCTO 2012

10. Commodity Hardware
! Small is beautiful…
! … mais ça change des choses
10
© OCTO 2012

11. NoSQL
! Pas SQL ou plutôt pas seulement SQL
(Not Only SQL)
! Pour aller là où les SGBDR montrent
leurs limites
11
© OCTO 2012

12. NoSQL
Le théorème de CAP
« Availability »
Les clients peuvent
toujours accéder au
système (lecture écriture)
La stratégie des sites
L’univers des SGBRD
à gros trafic.
Avec cohérence in fine
« Partition tolerance »
« Consistency » Le système continue a
Tous les clients ont fonctionner en cas de
la même vue de la « partition » - plusieurs
donnée sous-ensembles n’arrivent
plus à communiquer
12
© OCTO 2012

13. Open API
13
© OCTO 2012

14. Open API
! Ensemble, on va plus loin !
14
© OCTO 2012

15. Plus Vite
« One of the things we most value
at Facebook engineering is moving fast. »
15
© OCTO 2012

17. Minimum Viable Product
« le MVP est la version d’un nouveau produit qui permet à
une équipe de collecter sur les clients early adopters le
maximum d’enseignements validés, et ce avec un minimum
d’effort »
Eric Ries, Lean Startup
! Réaliser rapidement un prototype de produit minimal, pour
! Vérifier l’existence d’un besoin
! Identifier le marché associé
! Valider les hypothèses business
17
© OCTO 2012

18. Comment ?
! Des itérations courtes
! Avec la question « est-ce que la suppression de cette fonctionnalité
rend le produit sans aucune valeur pour mon client ? »
! Le minimum qui est réalisé doit l’être à la perfection
18
© OCTO 2012

20. Test A/B
! Comparer la perception par 2 populations d’utilisateurs
! 2 pages d’accueil, 2 visuels, 2 formulaires, etc.
! Segmentation de la population ?
! date d’inscription, ordre alphabétique, etc.
! Condition d’arrêt ?
! Échantillon significatif
20
© OCTO 2012

21. Google Website Optimizer
21
© OCTO 2012

23. DevOps ?
1. Infrastructure
as
Code
provisionner
des
environnements
de
manière
fiable,
industrielle
et
dynamique
Dev
2.
Con/nuous
Delivery
Le
déploiement
en
con/nu
Ops
3.
Culture
de
la
collabora/on
Des
rituels
communs
pour
favoriser
les
échanges
23
© OCTO 2012

24. Continuous Delivery
« Plus il est difficile de déployer,
plus il faut le faire souvent »
! Mises en production incrémentales avec un niveau de risque
minimal
! Fiabiliser les processus de déploiement par l’automatisation
! « Feature Flipping » : décorrélation entre déploiement du code
et des fonctionnalités
24
© OCTO 2012

25. Efficacité opérationnelle extrême
1 Ops 2,3 millions d’utilisateurs
2 MEP / J
25
© OCTO 2012

26. Plus efficace
26
© OCTO 2012

28. L’obsession de la mesure
« In God we trust – everything else we test. »
Principes
! Sans mesure, tout n’est qu’opinion
! Ce qui ne se mesure pas, ne se pilote pas
28
© OCTO 2012

29. Concrètement
! Des métriques partout
! Test automatisé
! Baser les décisions sur les métriques
! Cycles courts d’expérimentation / apprentissage
29
© OCTO 2012

30. L’obsession de la mesure
« Tout le monde doit être capable d’expérimenter,
apprendre et itérer.
La position hiérarchique, l’obédience et la tradition
ne doivent pas avoir de pouvoir.
Pour que l’innovation fleurisse, la mesure doit
régner. »
Werner Vogels , CTO, Amazon
30
© OCTO 2012

31. Quelle est la bonne taille d’équipe pour
fabriquer un produit logiciel remarquable ?
31
© OCTO 2012

32. Pizza teams
! 5 à 15 personnes
! En deçà, manque de créativité
! Au delà, perte d’efficacité
32
© OCTO 2012

34. Comment organiser le travail des équipes
lorsque la taille de l’entreprise augmente ?
34
© OCTO 2012

35. Component team

36. Feature Team
Marketing – Responsable produit – Ergonome – Graphistes – Développeurs – Testeurs – Exploitants

37. Features teams
! Autonomie / pas de dépendances inter-équipes
! Toutes les compétences
! Comment assurer la cohérence d’ensemble ?
à « Communautés de pratiques »
37
© OCTO 2012

38. Design for failure
« Everything fails all the time »
Werner Vogels, CTO d’Amazon
38
© OCTO 2012

39. Design for failure
! Plusieurs patterns
! Eventual consistency
! Graceful degradation
! Feature Flipping
! Simian Army
39
© OCTO 2012

40. Design for failure
« The best way to avoid failure is to fail
constantly »
40
© OCTO 2012

41. Design for failure
Source : http://www.stelligent.com/tag/simian-army/

42. Table ronde
42
© OCTO 2012