Agile Tour Paris 2014 : Travailler Avec L'Existant, Sam Cranford
1. Agile Tour Paris 2014
Travailler avec l'existant :
ou comment s'en débarrasser
www.agileparis.org
www.twitter.com/AgileTourParis
www.facebook.com/AgileParis
team@agileparis.org
Meetup.com/AgileParis
2. Travailler avec l'existant : ou
comment s'en débarrasser
Les problèmes qui présentent l'existant,
comment les confronter et les contourner et
éventuellement s'en débarrasser
Sam Cranford – Upwiser
@nostradamnit
me@nostradamnit.com
delicious.com/nostradamnit
3. Qui suis-je ?
● Développeur entreprise depuis 15 ans
● Agiliste depuis plus de 10 ans
● Très (trop) expérimenté en travaillant avec
l'existant
● noter: presentation en fr_US
5. Bon, c'est qui?
● Dramaturge Français
● Créateur accidentel du Théâtre de l'absurde
6. Amédée ou comment s'en
débarrasser
● Pièce absurde en 3 actes
● Quelque chose encombre l'avancement
● La crise causé par l'encombrant
● La libération de l'encombrant
7. Ok, c'est quoi le rapport ?
● L'absurde – un décalage entre l'attente de
l'homme et l'expérience qu'il fait du monde
● L'existant – un projet en cours, en
production qui gagne de l'argent
un décalage entre le but d'un projet et son
déroulement actuel
9. Présentation en 3 actes
Le cycle de vie d'un projet informatique
● On commence avec des bonnes idées et
les bonne intentions
● On prend des décisions douteux et s'y
accroche
● On décide finalement de corriger ses
erreurs
10. Acte 1
Pourquoi on n'avance plus / pas assez vite?
● L'existant dans ces diverses incarnations
● Le code
● L’équipe
● L’état d'esprit
● Les connaissances
11. On existe
● Un produit existant
● Une équipe existante
● Des clients existants
● Des problèmes
existants
● L'existant, quoi ?!?
13. Le code (coté serveur)
public class BlahFormatter : ICanHaz
{
public string BlahFromUrl()
{
var context = Config.GetGlobalConfig("blahContext");
String url = HttpContext.Current.Request.Url;
var mehConverter = new MehConvertor(context);
var blah = BlahFactory.getFreshBlah(url);
var meh = mehConvertor.convert(blah);
return meh.toString();
}
}
14. Le code (cote client)
e = ""
function toggleElm(cls) {
for (i = 0; i < document.all.length; i++) {
if (document.all[i].className == cls) {
e = document.all[i]
}
}
}
15. Le code (build)
HAI 1.2
CAN HAZ STDIO?
I HAZ A FILE_NAME
ITZ
'build.environment
'
I HAZ A SERVR ITS
noob
PLZ OPEN FILE
22. Les problèmes existants
● Le produit n'est pas stable
● Il manque des fonctionnalités
● Le temps d’évolution est trop long
● L’équipe n'est pas stable / formée / motivée
● La direction met la pression, sans direction
● Le code n'est pas très structuré
26. Comment est-on arrivé là ?
Cercle vicieux des manques :
● De temps
● De connaissances
● D'organisation
● D’évolution
● De tests
● De passion
27. Temps
● Comme on n'est pas
nombreux, on a
beaucoup à faire et
beaucoup de retard
● Et donc on travaille à
l'arrache !
28. Connaissances
● Comme on est en retard, on n'a pas le temps
de faire de la veille technologique
● Comme le travail actuel nous frustre, on n'a
pas envie de continuer
32. Passion
● Travailler dans des
conditions pareilles est très
fatigant, ça sape le moral
● Une équipe démotivée
crée des produits sans
passion
● Ce manque de passion se
voit dans le résultat
34. Comment évaluer l'existant ?
● La structure
● La technique
● L'humain
● L'attitude
● La possibilité de changer
35. Structure
● Postulat : vous n’êtes pas là
pour changer l’équipe
● Donc il faut trouver les
moyens d'injecter des
bonnes pratiques sans trop
déranger
36. Technique
● Vous êtes là pour faire
avancer le projet
● Vous êtes expert dans votre
domaine
● Exigez du professionnalisme,
soyez l’ingénieur que vous
êtes
38. SOLID
● Principe de Separation de
responsabiltés
● Principe d'Ouvert / Fermé
● Principe de substitution de
Liskov
● Principe de ségrégation
d'Interface
● L'inversion de
Dépendance
40. Humain
● Est-ce que les collègues
veulent changer ?
● Est-ce que les devs sont
traités avec respect ?
● Les collègues sont-ils
honnêtes dans leurs
interactions ?
● Les chefs s'imposent-ils des
échéances irréalisables ?
41. Attitude
● L'ambiance est-elle bonne ?
● Est-ce que les problèmes sont la faute des
autres ?
42. Le test de Joël
1.Utilisez-vous un système de
gestion de version ?
2.Pouvez-vous effectuer une
compilation en une seule
étape ?
3.Faites-vous des compilations
journalières?
4.Avez-vous un logiciel de suivi
de problèmes ?
… ( il y a 12 questions )
43. Comment s'en sortir ?
● Tests
● Restructuration
● Organisation
● Réduction de dette
technique
● Maîtrise de
l'environnement
● Formation
● Méthodologie
45. Restructuration du code
● Ajouter et/ou réorganiser le projet pour qu'il
soit compréhensible et cohérent
● Enlever le code mort, les fonctionnalités
non-nécessaires, tout ce qui encombre le
code
Credits - http://www.qwan.eu/en
48. Dette technique
● Ne pas la cacher, partager la douleur
● L'isoler
● Préparer pour l'injection de dépendances
● Rendre le code testable → découplage
50. Le code (côté serveur)
public class BlahFormatter : ICanHaz
{
public string BlahFromUrl()
{
var context = Config.GetGlobalConfig("blahContext");
String url = HttpContext.Current.Request.Url;
var mehConverter = new MehConvertor(context);
var blah = BlahFactory.getFreshBlah(url);
var meh = mehConvertor.convert(blah);
return meh.toString();
}
}
51. Le code (côté serveur)
public class BlahFormatter : ICanHaz
{
public string BlahFromUrl(string Url, IConvertor convertor)
{
var blah = BlahFactory.getFreshBlah(url);
var meh = mehConvertor.convert(blah);
return meh;
}
}
52. Le code (côté client)
e = ""
function toggleElm(cls) {
for (i = 0; i < document.all.length; i++) {
if (document.all[i].className == cls) {
e = document.all[i]
}
}
}
53. Le code (côté client)
var selectedElements;
function toggleElm(cls) {
selectedElements = document.getElementsByClassname(cls);
}
54. Environnement
● Insister sur les outils
suffisants, au minimum
● Machines performantes
● Environnement de
développement isolé
● Automatisation des
builds et des tests
● Éviter les espaces
ouverts généralisés
55. Formation
● Créer / inculquer une culture
d’apprentissage
● Proposer des ateliers aux pauses déjeuner
(dojos, découvertes techniques,
discussions)
● Discuter avec l’équipe de la technique
● Jeux sérieux –> tastycupcakes.org
57. Focaliser sur l'important
● Un logiciel stable et maintenable
● Des clients contents et collaboratifs
● Un quotidien épanouissant
● De l'excellence technique
● Du bonheur, quoi ?
58. Honnête
● Exposer les fraudes
● Insister sur des
échéances justes
● Ne pas vous laisser
écraser
59. Maturité
● C'est le resultat de la vecu
● Si on sait apprendre de ses experiences
60. Humilité
● Savoir reconnaître ses fautes, ses erreurs
“L'humilité n'est pas de penser moins à soi-même,
mais penser moins de soi-même” C. S.
Lewis
61. Résumé
● Cliquez ici pour ajouter un résumé
Les 16 C s
● Courage
● Compassion
● Collaboration
● Capacité
● Communauté
● Cohérence
● Compréhension
● Conclusif
● Coordination
● Correct
● Confort
● Composé
● Créatif
● Convaincant
● Convivial
● Clair
62. C’est pas la taille de
l’épée qui compte, c’est
l’agilité du mousquetaire
65. Merci !
● Aux organisateurs de l'Agile Tour Paris
● Aux participants !
● A Upwiser et tous mes anciens et futurs
collaborateurs
● A tous les agilistes
● A Okiwi.org et les agilistes de Bordeaux
