<style>
.reveal {
font-family: Roboto, Source Sans Pro, Helvetica, sans-serif;
font-size: 32px;
font-weight: 100;
}
.reveal h1,
.reveal h2,
.reveal h3,
.reveal h4,
.reveal h5,
.reveal h6 {
margin: 0 0 20px 0;
font-family: Roboto, Source Sans Pro, Helvetica, sans-serif;
font-weight: 500;
line-height: 1.2;
letter-spacing: normal;
text-shadow: none;
word-wrap: break-word;
}
.reveal section img {
margin: initial !important;
background: initial !important;
border: initial !important;
box-shadow: initial !important;
}
</style>
# SpeedOps
----
<b>Speedrun</b>: aussi vite que possible
+
<b>Ops</b>: opérationnel
Note: le speedops c'est d'être opérationel sur un projet le plus vite posible
----
L’objectif est de pouvoir construire un produit logiciel de manière sereine, malgré la complexité qui s’accumule.
Note:
- La complexité ne s'accumule pas de manière linéaire
- du coup on va avoir des stratégies de gestion de l'évolution de cette complexité dans le temps sur les différents applicatifs.
---
## Opérationnel
> et le rester !
Note:
ça veux dire quoi "être opérationel" ?
----
#### Utilisateurs (99.9%):
- SEULE valeur qui importe c'est ce qui est en <i>Production</i>
- Time To <i>First Deployment</i> : le plus petit possible
- Deployment <i>Frequency</i> : le plus grand possible
- Time To <i>Minimal Viable Product</i> : V1 déployée
Note:
Attention RECETTE N'est PAS La Prod.
Equilibre dans entre la conception du besoin et la première implémentation
Continuer à livrer régulièrement et rapidement
1ere grosse milestone on répond à un parcours utilisateur complet
----
#### Projet:
- Communiquer rapidement sur l'état courant du projet et le faire varier
- Boucle de feedback la plus courte possible
- Problemes => Feature
- Problemes non résolu => Solutions de contournement
Note:
Etre capable de communiquer rapidement sur l'état courant du projet et le faire varier
Boucle de feedback la plus courte possible
Bonne direction
Au problème d'aujourd'hui on essaie d'avoir une solution de contournement
----
#### Code:
- ouvert
- tests automatisés.
- déployé en continu.
- standards (de qualité) des langages et frameworks.
----
#### Velocité
La seule vélocité qui importe pour les utilisateurs c'est celle à moyen / long terme.<!-- .element: class="fragment" data-fragment-index="1" -->
Note:
1ere livraison réponse partielle.
perception de la réduction de distance entre ta réponse partielle et la solution idéale
qui va piloter la satisfaction utilisateur
----
- Coût feature = Première livraison + Bugfix + Dette Technique
- No-code => uniquement sur des fonctionalités support (coût de transcription énorme)
- Quick & Dirty => "Blind Alley" & "Marshes, bog, swamps and other messes"
- Mythe de La Grande Refacto
Note:
Quick Dirty : Blind Alley Marshes, bog, swamps and other messes
(cf clean coder chp. 9)
- Feature : abonnement téléphonique.
- 1er TTFD rapide mauvaise expérience avec une application qui n'évolue pas assez vite
- Grande Refacto : sers à rien si on addresse pas la cause.
---
# Livrer de la valeur jour 1 ?
> Hit the ground running
>
Note:
Aider à être productif
----
#### <i>Core Domain</i>
vs<!-- .element: class="fragment" data-fragment-index="1" -->
#### <i>Generic Subdomain</i><!-- .element: class="fragment" data-fragment-index="2" -->
Note:
CD : Raison d'être du projet (solution n'existe pas)
GS : Facturation une conséquence d'un acte de vente, mais pas pertinent
----
Un projet en ligne c'est un <i>generic subdomain</i> du monde du dev.
- Préparer tout ce qui peut/doit l'être en avance.<!-- .element: class="fragment" data-fragment-index="1" -->
- Penser à l'expérience de dev.<!-- .element: class="fragment" data-fragment-index="2" -->
Note:
DX facile et plaisant de travailler sur le probleme ?
----
#### Git clone...
- Boilerplate(s) applicatif
- architecture
- point d'entrée
- Outils de qualité du code
- Linters
- Prettier
- Readme
- Licence
Note:
Stratégie de découplage de la complexité.
----
#### Continous Integration / Deployment
> Application goes BRR !
Note:
- On balance de l'instance avec des cycles rapide de Build, Release, Run !
----
- Continuous Integration:
- dépendences (cache !)
- build
- validation
- syntaxe code
- tests
----
- Continuous Deployment:
- Cloud / Platform As A Service
- Infrastructure As Code
- Time To Deployment ~ 5 min
Note:
Cattle vs Pet
----
#### Continuous Deployment
<b><i> :warning: Deploiement des branches par feature :warning: </i></b>
----
>L'instance de démo c'est le ppt du dev
----
#### Support de communication
Boucle de feedback quasi-instantanée pour les non techniques.
- Objectif : minimiser friction entre tous partis du projet<!-- .element: class="fragment" data-fragment-index="1"-->
Note:
Réflection exacte de l'état du projet à un instant
----
#### Support exploratoire / acceptance
Faites recetter l'exploratoire qui pose question par PO / Client / User.
Note:
Faites 10 branches si nécessaire (A B testing).
C'est intéressant bien avant la recette
Si il y a une question lors de l'exploratoire tu peux faire valider le comportement en VRAI
Pas de projection
---
# Livrer de la valeur jour 15 (Projet)
>Do the right thing
----
#### Le max de la valeur est non technique:
- On s'intéresse au <i>core domain</i>:
- BDD
- DDD
- Event Storming (Miro etc)
- Driller
- Etat de l'art
- Elaguer les fausses pistes
Note:
Decoupe la complexité métier en portions gérables
----
>We don't know what we don't know
Note:
On ne sais pas ce qu'on ne sait pas
----
>We know what we do not :
>(?)
>(?)
>(?)
Note:
On a identifié les grandes catégories de problèmes à régler
---
# Livrer de la valeur jour 15 (Tech)
>RFC & RTFM
----
#### :smiley: Bonus stage !
- Apprendre les techs / frameworks / libs
- Chemin critique du MVP
- Vision d'ensemble
- Prototype en exploratoire des (?)
---
# Livrer de la valeur jour 30
>Do the thing right
Note:
Une fois qu'on sait ce que l'on doit faire il faut de faire correctement
(process)
----
#### :syringe: Injecter du domaine
- TypeDD : cardinalités.
- <i>Vertical slices minimales</i> en TestDD
Note:
Explorer les cardinalités de notre espace de problème pour ne representer que ce qui est représentable
Parcours les plus critiques : code qui est pas en prod 0 valeur
----
- L'important c'est de mettre le produit dans les mains des autres
- Fake it (until you make it !)
Note:
- Copier / coller des retours pour prévalider le comportement
----
Si tu es satisfait de ce que tu livres c'est trop tard.<!-- .element: class="fragment" data-fragment-index="1" -->
Refacto du projet en continu pour coller au language métier<!-- .element: class="fragment" data-fragment-index="2" -->
Note:
1 maxime
Refacto : Dans les premières semaine très forte variance du language commun du métier
=> barrière à la communication => effacer
faire coller le domaine et sa représentation
---
# Livrer de la valeur jour 60
>Maximum effort
Note:
On a stabilisé un peu notre compréhension et on converge.
----
#### Minimal Viable Product
- Livrer les features incomplètes mais bornées !!!
- Repérer les cas problématiques | Solutions de contournement
- "Et si demain c'est en prod ?"
Note:
Bornées: Feedback => on s'occupe de toi plus tard.
Modale: Solution de contournement
----
- Intégration d'autres dévelopeurs
- Lisibilité métier / coût cognitif
- Simplification du projet
- Le facteur BUS (Covid)
Note:
Le fait de devoir expliquer le projet va pousser l'identification des zones ou la complexité et élevée
---
# Continuer à livrer de la valeur 90+
> Vers l'infini et l'au-dela
----
Scaling horizontal de la solution
Finitions des cas complexes
Conserver l'état au travers du temps
Note:
Satisfaction utilisateur ?
Comment on conserve le rythme ?
Code comme si tu en était responsable à vie
---
# What worked
---
# Production Driven Development
> On déploie à chaque cas métier réussit
----
- Montrer les problèmes/alternatives clef en main plutot que d'en discuter sans fin
- Prendre rapidement des décisions sur des solutions de contournement
- Problème plus complexe que prévu => autre ticket
---
# Clean Architecture
> Obligatory picture
----
<img src="https://blog.cleancoder.com/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg"/>
----
- Application flexible car "au pire" l'impact des changements est localisé
- découplage | isolation | transparence référentielle
- tests <3
---
# Test DD / View DD
- les tests énoncent les cas métiers en language humain pour le prochain dev.
- minimaliste
- pas de mocks
- transparence référentielle
- On teste si il y a de la logique uniquement (0 logique dans les composants)
- L'importance d'un test réside dans la rapidité du feedback
---
## Lisibilité (coût cognitif minimal)
- On type TOUT explicitement (pas d'inférence en PR)<!-- .element: class="fragment" data-fragment-index="1" -->
- Fichiers courts (max-lines: 128 excl. test)<!-- .element: class="fragment" data-fragment-index="2" -->
- Fonctions courtes (max-line-per-function: 16 / max-statements: 8)<!-- .element: class="fragment" data-fragment-index="3" -->
- 1 niveau d'abstraction par fonction<!-- .element: class="fragment" data-fragment-index="4" -->
- seulement l'info nécessaire et suffisante dans le nom<!-- .element: class="fragment" data-fragment-index="5" -->
- remplacer toute condition non explicite par une fonction explicite en terme métier.<!-- .element: class="fragment" data-fragment-index="6" -->
----
#### Storytelling
visibleMapPointsOfInterestThroughViewportAtZoomLevel
<!-- .element: class="fragment" data-fragment-index="1" -->
- cnfsMarkersInViewportAtZoomLevel <!-- .element: class="fragment" data-fragment-index="2" -->
- getMarkerToDisplay<!-- .element: class="fragment" data-fragment-index="3" -->
- mergedMarkersFilteredByTypeToDisplay<!-- .element: class="fragment" data-fragment-index="4" -->
- cnfsByRegionOrEmpty<!-- .element: class="fragment" data-fragment-index="5" -->
- cnfsByDepartmentOrEmpty<!-- .element: class="fragment" data-fragment-index="6" -->
- cnfsPermanencesInViewportOrEmpty<!-- .element: class="fragment" data-fragment-index="7" -->
Note:
- https://cartographie.conseiller-numerique.gouv.fr/
- la problématique est de récupérer les points d'intéret visibles sur la carte au travers de la zone visible (affiche à l'écran) à un certain niveau zoom
- marqueur des conseillé numériques visibles au travers de la zone visible (affiche à l'écran) à un certain niveau zoom
- règle : getMarkerToDisplay : type de marker à afficher en fct du contexte atuelles
- aggrégations des marqueurs
---
# Transmission et intégration de l'équipe
- Code with Me en pair
- Prendre le temps d'expliquer la solution
- Repérer tous les points de coût cognitif important
- On simplifie, on renome, on isole
---
#### Lint & Prettier
- Si ça passe le linter (full configuré) c'est good.
- Regarder le codestyle en PR c'est perdre du temps.
---
# FIN
---
# Quelques références:
- [The importance of a great developer experience](https://medium.com/nick-tune-tech-strategy-blog/the-importance-of-a-great-developer-experience-40567abc0e9a)
- [Core Domain Patterns](https://medium.com/nick-tune-tech-strategy-blog/core-domain-patterns-941f89446af5)
----
Methodologie SaaS 12 factors
- [Twelve-factor app](https://12factor.net/)
Clean Code
- [The Clean Coder](https://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073)
Clean Architecture
- [Clean Architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)
----
Going fast
[The only way to go fast, is to go well](https://sites.google.com/site/unclebobconsultingllc/going-fast)
Delivery
- [The Strategy Is Delivery Again](https://mikebracken.com/blog/the-strategy-is-delivery-again/)
- [Production Driven Development](https://dzone.com/articles/production-driven-development-aka-delivery-driven)
Instances Management
[Cattle vs Pet](https://joachim8675309.medium.com/devops-concepts-pets-vs-cattle-2380b5aab313)
----
Doc beta gouv !
- [General](https://doc.incubateur.net/communaute/)
- [Embarquement Dev](https://doc.incubateur.net/communaute/travailler-a-beta-gouv/bienvenue/embarquement-dev)
- [Standards](https://doc.incubateur.net/communaute/gerer-sa-startup-detat-ou-de-territoires-au-quotidien/je-fais-des-choix-technologique/standards-de-qualite-beta.gouv.fr#standards-de-qualite-logicielle)
----
Artisanat du code:
- [Manifeste Agile](https://agilemanifesto.org/)
- [Manifeste Sowftware Crafters](https://manifesto.softwarecraftsmanship.org/)
----
Readme:
- https://dev.to/scottydocs/how-to-write-a-kickass-readme-5af9
- https://github.com/matiassingers/awesome-readme
----
Conférences:
[Vous livrez encore des bugs en prod en 2019 ? - Jordan Grenat](https://www.youtube.com/watch?v=MocBdTV8qck)
[Et si on redémarrait l'agile - Arnaud Lemaire](https://www.youtube.com/watch?v=sZbmP0JZHBs)
----
Documentations:
CI/CD:
- [Github Actions](https://docs.github.com/en/actions)
- [Gitlab CI](https://docs.gitlab.com/ee/ci/)
{"metaMigratedAt":"2023-06-16T16:27:58.238Z","metaMigratedFrom":"YAML","title":"SpeedOps Comment commencer à livrer de la valeur jour 1 ?","breaks":true,"slideOptions":"{\"transition\":\"slide\",\"controls\":false,\"progress\":true,\"slideNumber\":false,\"showNotes\":false,\"allottedMinutes\":30}","contributors":"[{\"id\":\"5d87520c-c463-4068-a514-5e0d85b2a660\",\"add\":34290,\"del\":20694}]"}