Les problèmes qui présentent l'existant, comment les confronter et les contourner et éventuellement s'en débarrasser Présentation présente à l'Agile Tour Paris 2014

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

4. Un peu d'histoire
Eugène Ionesco

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

8. L'absurde existe
Un peu trop souvent dans
les équipes de dev...

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

12. Le produit existant

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 FILE_NAME?
AWSUM THX
SERVR R FILE
O NOES
INVISIBLE "WFT ERRER?"
SERVR, WTF?
OMG "PROD"
I IZ BUILD_PROD
GTFO
OMG "TEST"
I IZ BUILD_TEST
GTFO
OMGWTF
I IZ BUILD_DEV
OIC
KTHXBYE

16. L'équipe existante

17. L’équipe existante
Pas toujours ouverte au changement

18. Bozo bit
Je ne parle pas aux cons, ça les instruit
http://c2.com/cgi/wiki?SetTheBozoBit

19. Les clients existants

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é

23. L'existant

24. Il suffit de l'implémenter
Un dev à la direction : “On peut commencer
des pratiques agiles ?”

25. Acte 2
Ca n'avance plus

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

29. Organisation

30. Evolution
● Les clients en demandent
● La direction aussi

31. Tests

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

33. Acte 3
Il faut que ça change

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

37. Duplication

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

39. 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 ?

40. Attitude
● L'ambiance est-elle bonne ?
● Est-ce que les problèmes sont la faute des
autres ?

41. 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 )

42. Comment s'en sortir ?
● Tests
● Restructuration
● Organisation
● Réduction de dette
technique
● Maîtrise de l'environnement
● Formation
● Méthodologie

43. Tests

44. 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

45. Organisation
● N'oubliez pas le but final,
● Faire de la thune
● Euh, de créer de la valeur

46. Organisation

47. 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

48. Revue de code

49. 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();
}
}

50. 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;
}
}

51. 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]
}
}
}

52. Le code (côté client)
var selectedElements;
function toggleElm(cls) {
selectedElements = document.getElementsByClassname(cls);
}

53. 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

54. 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

55. Méthodes

56. Focaliser sur l'important
● Un logiciel stable et maintenable
● Des clients contents et collaboratifs
● Un quotidien épanouissant
● De l'excellence technique
● Du bonheur, quoi ?

57. Honnête
● Exposer les fraudes
● Insister sur des
échéances justes
● Ne pas vous laisser
écraser

58. 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

59. 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

60. C’est pas la taille de
l’épée qui compte, c’est
l’agilité du mousquetaire

61. Un peu de lecture

62. Un peu plus...

63. 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

64. License
Cette présentation est sous les licenses
● Beerware
● WTFPL

65. Merci à nos sponsors
Prestige Platinum
Gold