20140311 - Documentation intrinsèque - Human Talks
-
Upload
clement-bouillier -
Category
Technology
-
view
344 -
download
1
description
Transcript of 20140311 - Documentation intrinsèque - Human Talks
Documentation intrinsèque
Human Talks Lyon – Mars 2014 – Hébergé par l’INSAClément Bouillier - @clem_bouillier
Qui suis-je ?
Architecte/chef de projet/consultant mais avant tout ARTISAN DEVELOPPEUR
> Twitter : @clem_bouillier
Membre actif des groupes suivants> DevLyon : groupe de développeurs partageant une vision de
l’informatique créant de la valeur http://devlyon.fr> MUG Lyon : groupe de passionnés de technologies en
environnement Microsoft sur Lyon> Fier d’être développeur : groupe visant à promouvoir le métier
de développeur en France http://fierdetredeveloppeur.org/
La documentation,
c’est un peu comme la qualité…
(…tout le monde en parle, très peu en font…)
…on vous explique les processus à suivre pour
y arriver (ou pas!)
Exemples typiques :Qualité = spécifications exhaustives, plans de tests, usine de tests manuels…
Documentation = spécifications exhaustives upfront, code commenté, wiki après avoir codé…
Tout ça au bon moment dans le cycle projet évidemment !
…et pourtant le résultat est régulièrement le
même…
Qualité en apparence (pour
le client, à la « recette »)
Aller vers la QUALITE
INTRINSEQUE
Documentation désynchronisée de la
réalité (voire le néant) Aller vers la
DOCUMENTATION INTRINSEQUE
Qualité et documentation
intrinsèque vont de pairNe demande pas d’activités spécialisées ayant un autre but que :
« Produire un logiciel opérationnel PLUS QU’une documentation exhaustive »
1. Documentation fonctionnelle
Développement piloté par l’expérience utilisateur User
Story
…inspirez-vous du Story Mapping…«understanding what your whole system is intended to do » - Jeff Patton
…puis outillez légèrement
Conserver les éléments notés autour des User Story lors de la réalisation (1 User Story = 3C : carte, conversation, confirmation)
+ Regrouper les User Story par Theme/Activité fonctionnel(le)
+ Gérer les User Story obsolètes (suppression/évolutions)
+ Taches…
+ Test Cases…
…et documenter avec une démarche BDD
Piloter vos développements par la description du comportement métier désiré« Conversation » et « confirmation » (cf. 3C) sont intimement liés
Le code est fonctionnellement lié à la User Story
2. Documentation technique
Code explicite PLUS QUE code
commentéEviter les commentaires quand vous pouvez expliciter la même chose dans le codeReprenez les termes métiers dans votre code
/!\ aux abstractions et aux APIs : à documenter (JavaDoc…)
// check to see if employee is eligible for full benefitsif ((employee.flags & HOURLY_FLAG) && employee.age > 65)
if (employee.isEligibleForFullBenefits())
Chapitre 4 de Clean Code – Uncle Bob
TDD = Test Driven Development, mais aussi DESIGN (= conception)
Conception incrémentale PLUS QUE « upfront »+
Documentation des intentions plus que la structure+
BONUS : tests automatisés non-régression
Et en complément…
Commentaires de commit propres (liés au User Story en BONUS)+
Un wiki pour documenter 1. les pratiques de l’équipe2. les exigences transverses
Toutes ces pratiques portent la documentation= Documentation
intrinsèqueUser Story/Story Mapping
BDDTDD
Code explicite
PLUS QUE des processus de documentation complémentaires
Vous ne les connaissez pas ? Etudiez, entrainez-vous au plus vite…
MERCI
QUESTIONS ?
ROTI ?