Les Vertus de l'emergence
•
0 j'aime•843 vues
La pensée émergente est un des aspects de l'agilité qu'il est parfois difficile d'appréhender. Souvent cantonnée à des problématiques d'architecture, cette manière de penser est même réfutée par les approches classiques ou les pseudo-agilistes ! Cette session montre que l'émergence, au-delà de la pensée, est un des mécanismes fondamentaux des projets agiles, bien au-delà des problèmes d'architecture: dans la compréhension du besoin, le fonctionnement des équipes et même la stratégie d'entreprise.
Recommandé
Contenu connexe
En vedette
En vedette (16)
Plus de Christophe Addinquy
Plus de Christophe Addinquy (20)
Les Vertus de l'emergence
- 1. Les vertus de l’émergence Texte Christophe Addinquy caddinquy@frenchsug.org @addinquy http:// addinquy.tumblr.com/
- 2. «Comment la refactorisation répétée, un processus exclusivement de bas en haut, produit-il une conception élégante ? Ceci est une affirmation très controversée, supportée par bien peu de preuves...» «... rien dans TDD ne traite directement des aspects de performances. Une possibilité serait que ce soit pris en compte lors de la refactorisation...» Paul C. Jorgensen, Ph.D., Professor School of Computing and Information Systems, Grand Valley State University, Allendale, MI
- 14. Rétrospective Evolution des pratiques Démonstration Ajustement du backlog Implémentation storie Ajustement fonctionnalité Daily meeting Priorisation des tâches Interaction de pairs Design émergent Integration continue Construction émergente TDD Ajustement du code Compilation incrémentale Ajustement syntaxique
- 17. «Les espèces qui survivent ne sont pas les espèces les plus fortes, ni les plus intelligentes, mais celles qui s'adaptent le mieux aux changements » Charles Darwin «L'évolution procède comme un bricoleur qui pendant des millions et des millions d'années, remanierait lentement son oeuvre, la retouchant sans cesse, coupant ici, allongeant là, saisissant toutes les occasions d'ajuster, de transformer, de créer » François Jacob
- 21. « Si j’ai vu si loin, c’est que j’étais monté sur des épaules de géants » Isaac Newton
Notes de l'éditeur
- \n
- Mr Jorgensen ne croit pas aux architectures émergentes : elles ne disposent pas de plan d’ensemble préalable, il n’y a pas de gourou qui en trace préalablement les grandes lignes en définissant comment cette architecture peut « scaler ».\nLes arguments de mr Jorgensen sont bien entendu édifiants : ils figurent en bas de la citation. Vous n’imaginez pas à quel point cela m’impressionne !\n\nEn fait, ce dont nous parlons là, c’est d’architectures émergentes.\nPeuvent-elles scaler ?\nEst-il possible de commencer petit sans avoir d’idées arrêtées (ou peu) sur la façon dont on va faire grandir le système en performance ?\nSi on considère comme important un facteur d’échelle de 100, trouve-t-on des exemples d’architectures émergentes avec un facteur d’échelle plus important encore ? Beaucoup, beaucoup plus important…\n
- Je pense que vous aurez reconnu au moins l’un d’entre eux ! Pour les autres, c’est certainement plus difficile, voir beaucoup plus difficile ! Nous allons commencer par celui qui vous est familier.\n
- Tout le monde a entendu parler des chiffres faramineux avancés sur facebook lors de l’IPO. Nous pourrions passer les 5 prochaines minutes à les aligner. Je n’en citerais que 2 :\nLe trafic sur facebook aujourd’hui est équivalent à celui de la totalité de l’Internet en 2004\n60000 serveurs estimés.\nCe que tout le monde sait aussi, c’est que la première version de facebook a été développée par une seule personne en quelques semaines, le plus classiquement du monde en PHP !\n\nAujourd’hui, l’architecture, c’est … toujours du PHP pour le front end, mais compilé en C++ avec HipHop, associé à une technologie BigPipe pour en accélérer le rendu et Varnish qui est le proxy HHTP\nCôté base de données online, c’est toujours du MySQL mais aggrégé en cluster de plusieurs dizaines de milliers d’instances.\nOn compte nombre de technologies dans la stack logicielle, comme Thrift qui sert à la fois de couche service et de server d’application, Memcache (plusieurs To de cache), Haystack qui est la système de stockage de photo (on parle de plusieurs centaines de milliards de photos !) et un système de stockage analytique offline qui doit avoisiner aujourd’hui les 1000 pétaoctets, construit sur HBase.\nEn fait facebook a même développé sa propre architecture matérielle de servers : Open Computer Servers, désormais une initiative open-source !\nCela fait beaucoup de choses. Ce qui est intéressant c’est que tous ces éléments ont été introduits les uns après les autres, permettant à l’architecture de grandir progressivement.\n\n
- Je n’ai pas retrouvé la photographie de l’original, mais il est intéressant de savoir que la première version de ce service fonctionnait en fait sur cette machine, appartenant à cette personne !\nCe qui est intéressant ici, c’est que la plateforme s’est définie comme un « micro blogging » donc avec une architecture orientée « gestion de contenue » pour se métamorphoser en une plateforme de messaging. On est passé d’une architecture full RoR à une architecture « en mémoire » où on a gardé le front en Ruby (mais qui sert assez peu) avec un back-end en Java / Scala avec encore une fois du Memcached / varnish (cache de pages) et surtout un MOM Scala propriétaire (Kestrel). La persistence différée est assurée par un gros cluster MySQL.\nIci ce n’est pas seulement une évolution de l’architecture pour assurer la scalabilité mais une mutation de paradigme de la gestion de contenue au messaging, une chose que les créateurs du service ignoraient au départ.\nNous ne sommes pas ici pour faire des concours de chiffres. Les 340 millions de messages par jours paraissent modestes par rapport aux chiffres que l’on peut voir concernant Facebook. N’oubliez quand même pas que c’est un service de messagerie « broadcast ». Cela ne porte pas tellement à conséquences quand on s’appelle Christophe Addinquy, mais quand pn s’appelle Lady Gaga…\n\n
- Je n’ai pas retrouvé la photographie de l’original, mais il est intéressant de savoir que la première version de ce service fonctionnait en fait sur cette machine, appartenant à cette personne !\nCe qui est intéressant ici, c’est que la plateforme s’est définie comme un « micro blogging » donc avec une architecture orientée « gestion de contenue » pour se métamorphoser en une plateforme de messaging. On est passé d’une architecture full RoR à une architecture « en mémoire » où on a gardé le front en Ruby (mais qui sert assez peu) avec un back-end en Java / Scala avec encore une fois du Memcached / varnish (cache de pages) et surtout un MOM Scala propriétaire (Kestrel). La persistence différée est assurée par un gros cluster MySQL.\nIci ce n’est pas seulement une évolution de l’architecture pour assurer la scalabilité mais une mutation de paradigme de la gestion de contenue au messaging, une chose que les créateurs du service ignoraient au départ.\nNous ne sommes pas ici pour faire des concours de chiffres. Les 340 millions de messages par jours paraissent modestes par rapport aux chiffres que l’on peut voir concernant Facebook. N’oubliez quand même pas que c’est un service de messagerie « broadcast ». Cela ne porte pas tellement à conséquences quand on s’appelle Christophe Addinquy, mais quand pn s’appelle Lady Gaga…\n\n
- Je n’ai pas retrouvé la photographie de l’original, mais il est intéressant de savoir que la première version de ce service fonctionnait en fait sur cette machine, appartenant à cette personne !\nCe qui est intéressant ici, c’est que la plateforme s’est définie comme un « micro blogging » donc avec une architecture orientée « gestion de contenue » pour se métamorphoser en une plateforme de messaging. On est passé d’une architecture full RoR à une architecture « en mémoire » où on a gardé le front en Ruby (mais qui sert assez peu) avec un back-end en Java / Scala avec encore une fois du Memcached / varnish (cache de pages) et surtout un MOM Scala propriétaire (Kestrel). La persistence différée est assurée par un gros cluster MySQL.\nIci ce n’est pas seulement une évolution de l’architecture pour assurer la scalabilité mais une mutation de paradigme de la gestion de contenue au messaging, une chose que les créateurs du service ignoraient au départ.\nNous ne sommes pas ici pour faire des concours de chiffres. Les 340 millions de messages par jours paraissent modestes par rapport aux chiffres que l’on peut voir concernant Facebook. N’oubliez quand même pas que c’est un service de messagerie « broadcast ». Cela ne porte pas tellement à conséquences quand on s’appelle Christophe Addinquy, mais quand pn s’appelle Lady Gaga…\n\n
- Voici une bien belle infrastructure bien scalable, n’est-ce pas ?\nJe ne vais pas m’étendre sur cet exemple qui présente une évidente évolution en terme d’architecture.\nGoogle, c’est aujourd’hui 150000 servers estimés, probablement plus, en fait.\n\n
- Vous connaissez peut-être cette machine, c’est un NeXT. En fait, ce n’est pas la machine qui est intéressante, mais la personne à laquelle elle appartient, il s’agit d’un physicien Anglais qui a développé un système, ou une architecture devrais-je dire documentaire distribuée. Elle est toujours en service et a en fait fêté ses 20 ans le 6 Août dernier. On dit qu’il a délibérément choisi imprononçable en Français, car il l’a appelé le World Wide Web. Il a bel et bien commencé à fonctionné sur cette seule machine et ne servait à l’origine que des sites statiques.\nBien sûr je ne vais pas discourir sur ce qu’est devenu le Web en terme d’ampleur et d’évolutions technologiques. Nous savons tous que Tim Berners Lee est sans aucn doute brillant, mais son système initial était très simple et ne servait que des pages statiques.\nParallèlement (ou précédemment devrais-je dire) Donald Knuth, un des esprit informatiques les plus brillants a travaillé pendant plusieurs décennies sur un système appelé Xanadu, bien plus complexe, ambitieux et tentant de résoudre beaucoup de problèmes dès le départs (liens, publication, micro-paiemnets, ownership, liens mutiples, historique et archivage, etc…\nLe système conçu par TBL était bien plus simple, bien plus fragile et n’avait probablement pas 5% des fonctionnalité de Xanadu. Mais l’approche descendante de Knuth a échouée, enlisée dans sa complexité et l’incapacité de mettre en œuvre une telle architecture à grande échelle.\nA l’inverse, TBL a commencé petit, mis en open-source sa technologie et s’est appuyé sur la communauté mondiale pour imaginer et implémenter ce que l’on pourrait développer à partir de là. En 20 ans, le Web a surpassé tous les objectifs projetés ou imaginés pour Xanadu. Avec une évolution architecturale complètement émergente !\n\n
- Les exemples que nous avons vu ont tous ceci en commun : ils ont commencé petit, ils se sont exposés tôt, sans attendre de « murir », d’avoir « bien analysé toutes les facettes du problème ». Ils ont fait avec ce qu’ils connaissaient sur le moment et se sont focalisés sur le problème présent, mais en surveillant et en réagissant sur la façon dont les choses ont évolué, comme ce fut le cas pour Twitter.\nCes idées sont celles mises en avant par le Lean Startup : débuter et montrer tôt, afin que le feedback oriente l’évolution du produit.\nOn voit que les évolutions, aussi bien sur une architecture qu’au niveau du business sont le fruit des contraintes de l’environnement sur le système. Le système nous « parle », nous l’adaptions à l’environnement.\n\n
- La dynamique agile repose entièrement sur ce principe de feedback-adaptation-émergence, sous forme de cycles allant de la seconde jusqu’à l’itération pour s’étendre au projet. Le fonctionnement d’un projet agile peut être ramené à une somme de boucles de feedback de différents ordre et de différentes natures\n\n
- On vient de voir le principe de l’émergence au sein de projets, voir d’entreprise, mais existe-il au sein d’ensembles plus grands dans la société humaine ?\nDans le business des religions one ne se dit pas : tiens c’est cool, je vais créer une religion, alors il y aura des paroisses, des diocèses avec des évêques, des cardinaux et un conseil pontifical et moi je serais tout en haut. Enfin généralement ce dernier point fait partie du plan initial.\nSeulement le seul moyen de procéder, c’est d’avancer progressivement car on ne peut pas anticiper de la progression…\n\n
- … et surtout pas des étapes intermédiaires !\nEn fait, on doit commencer par faire ce que l’on peut avec les 12 gars que l’on a sous la main.\nOn a donc un modèle évolutif :\nD’abord par enseignement direct\nEnsuite un modèle de diffusion (enseignement de proche en proche, petites cellules)\nEnsuite une structure régulée et hiérarchisée\nChaque évolution du modèle correspond à une adaptation à l’écosystème.\n\nEn parlant d’écosystème, peut-on transposer cette vision de l’émergence au-delà des sociétés humaines ?\n\n
- La citation de Charles Darwin est incontournable et traduit bien l’aspect évolutif des espèces.\nJ’aime bien aussi cette seconde citation qui met plus l’accent sur le côté émergent … et refactoring !\nOui, le refactoring n’a pas été inventé par XP, mais par le mécanisme fondamental d’évolution des espèces vivantes !\n\n
- C’est ce mécanisme qui nous conduit des bactéries du précambrien … jusqu’à Justin Bieber.\nL’émergence de la vie, c’est bien, mais peut-on inscrire l’émergence dans un cadre plus large ?\n\n
- L’univers : 500 milliards de galaxies formées de 300 milliards d’étoiles chacune. Mais au départ :\nUn soupe de gluons-quarks (20 à 30 ms)\nPuis la constitution d’atomes : mais uniquement de l’hydrogène et de l’Hélium.\nIl faudra attendre la formation d’étoiles pour voir se former des éléments plus lourds.\nIl n’y a pas de plan d’ensemble à la formation de l’univers : il émerge des lois de la physique, à partir d ‘éléments précédemment formés.\n\n
- Je ne dénie pas ici le fait qu’on ne sache pas faire de grandes réalisations « top-down ». Après tout la grande muraille de Chine a été ainsi construite, sur près de mille ans ! De nombreux projets sont aussi réalisés ainsi avec succès.\nPourtant les réalisations exceptionnelles à l’image des fruits de la recherche scientifique sont émergents, construites sur le savoir et l’expérience acquise pour chaque fois aller un pas plus loin.\nLa conception descendante a démontré des réalisations depuis plusieurs milliers d’années, mais la réalisation émergente la surpasse en ampleur depuis 14 milliards d’années.\n\n