10 ans de Code (Agile Bordeaux 2019)

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é!

https://girlknowstech.com/women-in-coding/

All around the World

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

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

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

https://stefanoalletti.wordpress.com/2017/10/27/hexagonal-architecture/

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

https://adtmag.com/articles/2017/04/21/agile-branch-by-abstraction.aspx

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 ?

https://compassionatecoding.com/

April Wensel

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