10 Years Challenge

Même équipe, même produits, même code

Bouducon, 10 ans déjà!

... et maintenant?

Dev ⇨ Dev + 10

“Senior”

Même pas mal ^_^

Un parcours... riche en

rebondissements

A la rencontre de l’équipe

T O U L O U S E

Parité!

All around the World

une place à part!

une place à part!

Spécificités

  • Non Medical Device
  • Une famille de produits (Epics)
  • Des applications (MVP + Small Releases)
  • Tous les composants sont partagés
    sans version spécifique à un produit
  • Pas de testeur dédiés, le développeur fait tout
  • Idem “DevOps”

L’orga générale

  • Le PO est dans le bureau à coté ( + daily meeting)
  • Product Support Engineer sur le plateau ( + daily meeting)
  • Le Backlog
  • Les Backlog Items
  • Le dashboard ( Physique -> Numérique)

Agile à notre façon

Agile à notre façon

Definition of Done

Quand peut-on fermer un Backlog Item ?

  • Une définition faite par l’équipe
  • En évolution régulière
  • Tient compte des outils à disposition
  • Liée aux jobs de l’intégration continue

La piqûre de rappel à Gilles

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Déclamation

Individus et

interactions

Au fil du temps

Scrum ? Kanban ? What else ?

Expérience du Daily Open Space

Estimate / No Estimate

Dashboard timing releases

Utilisé par le PO pour communiquer aux clients et au management

Pair / Mob programming

Responding to change ?

Au fil du temps

Un backlog en évolution permanente

  • Une release = 1 groupe de BI
  • Types de BI
    • User Need,
    • Bug Fix,
    • Design Quality,
    • Nouvelle Compatibilité avec système(s) VARIAN

Changing code

How can we evolve our systems towards clean architectures and designs in an incremental Agile way?

https://vimeo.com/68215570 Robert C. Martin: Clean Architecture and Design

Nos changements, pas leur changements

Oui aux changements voulus par (et discutés avec) notre PO

Non aux changements des librairies tierce parties

  • Nous codons les nôtres ⇨ jamais mieux servi ...
  • Nous nous abstrayons les autres
    • Jamais instanciées directement
    • Toujours cachées à travers une API de notre cru
    • Toujours doublées dans les tests (Mocks, Stubs, Spy, Fake et Dumb)

Architecture and Decisions

“the job of an architect is to build a structure that allows decisions to be delayed as long as possible.”

A good architect maximizes the number of decisions not made.

Bob C. Martin

Composants et composabilité

  • Dépendances maîtrisées
  • Injection de Dépendance
  • Architecture hexagonale
    • Alistair Cockburn, 2005

Toujours le même code

  • Fondations solides
  • Socle Commun = Abstractions
  • Découpage intelligent
    • pas de “couches”
  • Peu de Breaking Changes
  • Ré-utilisabilité
  • Richesse de l’expérience accumulée

Contexte et évolutions techniques

  • .Net 2.0 ⇒ .Net 4.5
  • Xaml ⇒ Web
  • Web API : WCF ⇒ asp.net MVC ⇒ Nancy
  • Web User Interface ( HTML + jQuery)
  • Chromium
  • Vue ⇒ Angular
  • Signal R
  • ⇒ .Net Core

Je n’aurai pas été jusque là si...

Branch(es) : an Anti Agile Pattern

Trunk Based Programing

shorturl.at/ekDRY

https://adtmag.com/articles/2017/03/14/agility-code-branching.aspx

Branching by Abstraction

Customer

collaboration ?

Au fil du temps

User Stories

Les plus petites possible

Conversation entre devs et PO

Doit apporter une valeur à l’utilisateur

  • As
  • When
  • Then

🙅 Design Quality (paye ta dette)

Ubiquitous Language

En 1944, dans Poésie 44, (Sur une philosophie de l'expression), Albert Camus écrivait: " Mal nommer un objet, c'est ajouter au malheur de ce monde ".

DDD : the King of the Domain is the Model

du BI au BDD

  • On essaye d’écrire des spécifications exécutables qui reprennent toutes les exigences du Bi
  • BI ⇒ Besoin Utilisateurs
  • BDD ⇒ exigences métiers et techniques qui font partie de la résolution du Besoin Utilisateur

Executable Specifications aka BDD

Gherkin / Cucumber ⇒ Specflow/ C# ⇒ NUnit

On écrit nos premiers steps naïvement

On se pose des questions sur la manière de formuler

On se pose la question de le ré-utilisabilité

De l’expression des concepts à l’écriture d’une forme abstraite dans le code

Au début on apprenait de 0

Seul au monde ?

Who should read BDD executable specifications?

Everyone ?

Developers !!!

Product Owner =>

  • Code is fluent enough,
  • DDD is in place,
  • Event Storming performed,
  • so tests are “human aware readable”

I Write tests ....

  • How can my tests be a form of collaboration with customers?
  • Ils donnent de la documentation pour l’ API publique du composant (Behavior)

Je n’aurai pas été jusque là si...

Prendre du temps pour en gagner

Working

software ?!

Au fil du temps

TDD

Design and Write Test first

Think how your code can be tested in isolation

How you can write a test only by re using existing steps

Writing tests

Tests should:

  • Respond to behavior changes.
  • Not respond to structure changes.
  • Be cheap to write.
  • Be cheap to read.
  • Be cheap to change.

https://medium.com/@kentbeck_7670/programmer-test-principles-d01c064d7934

TDD efficace

Tests should:

  • Minimize programmer waiting (so... run fast!).
  • Run reliably.
  • Predict deployability (not only work on my machine).

https://medium.com/@kentbeck_7670/programmer-test-principles-d01c064d7934

Continuous Integration

  • Mise en place par l’équipe
  • Essais successifs
  • ... loin d’être parfait

Fait Maison = fait avec amour

Résistant à la mode

C’est à nous!

YAGNI (adapté à ce dont on a uniquement besoin)

Je n’aurai pas été jusque là si...

...WITH comprehensive documentation

Au fil du temps

Processus Qualité Mondial et Dérivations

Scriptable Generation of Documentation

Contexte: Minor Release Documentation (incremental)

Sources de données:

  • Backlog produit (TFS / JIRa / ...)
  • Source repositories ( TFS: changesets, labels, reviewers, approvers, ...)
  • Code artefacts (MS Build, proj files, target files)
  • Specs Sources (only BDD can do it!)
  • Tests artefacts (Execution Results, Specflow files, Attributes )
  • Tests environnements (MVs...)
  • Text templates

XML -> XSL -> XHTML -> PDF -> signed PDF

Je n’aurai pas été jusque là si...

Living Documentation

No comments!!!!

Fluent Code

Documented Abstractions & Design

Readable Tests

Executable Specifications with BDD

Résister au temps

Au fil du temps

Le temps est rarement un ami

  • Limites de la mémoire
  • Quel support pour se souvenir?
    • Commentaires?
    • Documentation?
    • Source code (repository)
    • Tests
  • Se relire
  • Se comprendre
  • Être compris
  • Être stable

Pourquoi / pour qui j’écris du code

  • Pour les clients?
  • Minimiser la souffrance
  • Pour l’équipe ?
  • Pour moi ?

Global Ownership of Code

Conception émergente

... pas toujours!

Kill the routine

  • Nouveaux Produits / Nouvelles technos
  • Ateliers
  • Kata
  • Changements de méthode
  • Aller à des conférences
  • Déménager
  • Ca reste un “problème”...
  • ... ou est-ce un problème?

Y’a pas que le boulot dans la vie!!!

Having

Fun

Au fil du temps

Role-Game your Code!

Une idée du PO

On joue l'exécution du programme

Jeu de rôle

On dévoile l’architecture technique en s’amusant

Faire du code

Responsable

Au fil du temps

Compassionate coding

  • Optimiser
    • Valeur
    • Plaisir
    • Impact Social
    • Impact Environnemental
  • Ralentir

Le code et son impact

  • Bug Free by Design
  • Yagni
  • Dead Code
  • Open/Close
  • Easy to change
  • Fast ( code + tests)
  • Sobriété
    • mémoire
    • cycles CPU
    • taille déploiement

Agile

Crafter

Au fil du temps

Step by step

Not only working software,

but also well-crafted software

Not only responding to change,

but also steadily adding value

Not only individuals and interactions,

but also a community of professionals

Not only customer collaboration,

but also productive partnerships

10 ans de Code (Agile Bordeaux 2019) - Google Slides