Swanseacon 2016
En septembre, j’ai assisté à la deuxième édition de la swanseacon, une conférence sur le thème du développement agile et le software craftsmanship.
La conférence était assez dense et variée. Vous trouverez dans cet article un petit résumé de mon top 3. Tout en bas, vous trouverez la liste de tous les talks auxquels j’ai assisté. S’il y en a une qui vous intéresse, n'hésitez pas à me laisser un commentaire.
Voici mon top 3 :
Opening Keynote - Agile and architecture, finally friends after 15 years
By Simon Brown (slides disponibles ici)
Dans la keynote d’ouverture, Simon Brown revient sur son expérience dans le développement logiciel et sur l’évolution de la perception de la notion d’architecture.
Ce mot est devenu tabou car souvent associé à des architectes enfermés dans leur tour d’ivoire. Il renvoie à des méthodes de travail « waterfall », où les architectes se limitaient à produire une documentation destinée aux développeurs.
Aujourd’hui, 15 ans après l’apparition du manifeste agile, Simon Brown fait le constat qu’un certain nombre d’équipes ne se préoccupent plus de l’architecture ni du design de leur logiciel sous prétexte d’agilité.
Cette position est souvent assumée en évoquant des arguments de ce type :
- Le software livré ne ressemble jamais au produit décrit dans le document d’architecture
- L’architecture émergera naturellement à coup de réfactoring
- A quoi bon penser design quand on pratique le TDD
Néanmoins, Brown rappelle 2 des 12 principes sous-jacents au manifeste:
- Principe 9 : Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.
- Principe 11 : Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
Discuter donc d’archi et de design ne contredit pas l’agilité et peut même la renforcer. Brown va plus loin en affirmant que si « big design is dumb », « no design is dumber ».
Alors comment éviter les pièges du passé ?
Trouver le point d’équilibre en ayant juste assez de up front design pour créer des bases solides et imaginer les frontières du logiciel. La dose d’architecture dont on aura besoin dans un projet agile serait donc celle qui donnerait un cap aux développements (un starting point).
La principale difficulté reste, cependant, un langage commun pour représenter l’architecture logicielle.
Introducing Eager Design
By Marcello Duarte (slides disponibles ici)
Dans sa présentation, Marcello Duarte introduit une approche assez inattendue dans une conférence sur le développement agile. Car, si l’agilité pousse à reporter toutes les décisions structurantes jusqu’au dernier moment, l’« Eager Design » prévoit d’anticiper un certain nombre de décisions concernant la conception logicielle.
Au lieu de se concentrer sur nos méthodes de delivery, Marcello Duarte met l’accent sur les problèmes à résoudre.
Marcello utilise le framework Cynefin pour cibler le domaine d’application de cette approche. Si l’outside-in convient parfaitement aux problématiques futiles ou compliquées (partie droite du modèle), l’« Eager Design » est plus adapté à la résolution des problématiques complexes et nouvelles (haut gauche). 
L’approche est inspirée de la programmation fonctionnelle et du DDD et suit 4 principes:
#1 Jump to the problem worth solving #2 Eagerly replace primitives with types #3 Compose [the domain algebra] inside-out #4 Avoid mutable state
J’avoue que cette présentation m’a bien plu et je suis curieux d’en apprendre plus.
Closing keynote - Beyond breaking bad. The current state of agile in ten easy lessons
By Sander Hoogendoorn (slides disponibles ici)
Dans cette édition de SwanseaCon, il y a eu plusieurs talks qui dénonçaient ce qu’est devenu le « marché de l’agile » (https://youtu.be/a-BOSpxYJ9M) ; le scrum-bashing revenait souvent dans les discussions.
Sur ce sujet, la présentation qui m’a le plus plu a été la keynote de fermeture, et cela pour deux raisons : 1 - J’ai trouvé qu’elle était la plus complète sur le sujet 2 - Sander Hoogendoorn est un orateur d’exception
Voici la liste des dix leçons de Mr Hoogendoorn :
Lesson 1 : The waterfall model and why it should have never existed Lesson 2 : Agile is no silver bullet either Lesson 3 : A scrum master is not always a true master Lesson 4 : We are not manufacturing Lesson 5 : Self-organization is pretty tough Lesson 6 : Allow the team to learn continuously Lesson 7 : You are not Usain Bolt Lesson 8 : Get rid of your stereotypical Scrum board Lesson 9 : There is no such thing as one-size-fits-all agile Lesson 10 : Do we really need projects?
Je ne vais pas détailler les 10 leçons. Je vous laisse voir les slides pour cela. Je vais me concentrer plutôt sur les idées qui m’ont le plus frappé dans cette keynote.
Idée #1 : Recentrer le discours sur le développement. Au delà des méthodes et des rituels, adopter l’Agile c’est écrire de meilleurs logiciels plus rapidement.
Idée #2 : On aime bien utiliser des métaphores et comparer le développement logiciel à la construction de bâtiments. On le fait pour simplifier mais également parce que cela donne l’impression qu’il s’agit d’un processus dont toutes les contraintes sont connues d’avance, donc maîtrisables et « planifiables ». Mais ce n’est pas le cas. On crée des logiciels, on ne les construit pas. Le processus de création n’est jamais le même et c’est bien pour cela que les développeurs sont souvent des gens passionnés.
Idée #3 : Apprendre en continu
Ce graphique représente les scores obtenus au pinball par le même joueur. On remarque une nette amélioration par palier. Chacun de ces paliers coïncide avec l’apprentissage d’une nouvelle technique. On remarque également que chaque bond est précédé par une légère chute de performance, qui correspond au coût du nouvel apprentissage.
Idée #4 : Arrêter les scrum kanban ==> Visualiser les flux à la place
Idée #5 : Arrêter de faire des projets ==> Livrer de la valeur en continu
Un récapitulatif bonus en image par Stephen Mounsey
La liste de tous les talks auxquels j’ai assisté:
- Opening Keynote - Agile and architecture, finally friends after 15 years (slides ici)
- Understanding abstractions. Or, how do regular expressions work?
- Introducing Eager Design (slides ici)
- KISS me quick; The battle against complexity
- Refactoring and code smells (slides ici)
- Common pitfalls of TDD and suggestions how to make TDD work better for you
- How and Why to Love Cucumber
- Object-Orientated Views (Confluence REX)
- It doesn't always have to be Scrum
- A Toolset for Creating a Potentially Releasable Product Increment (REX) (slides ici)
- User-Story Point estimation: a new approach
- The Heroes of programming - 10x developer myth
- An Insider’s View Of Agile In The Public Sector (REX) (slides ici)
- Migration - from 'Jurassic Park' to MicroServices (REX)
- Teal Organisations: A Living Example (REX by Sandro Mancuso)
- Get your head in the Clouds!
- Education for Engineers
- Closing Keynote - Beyond breaking bad. The current state of agile in ten easy lessons (slides ici)