Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à Bref
Similaire à Bref (20)
Plus de Emilien Pecoul
Plus de Emilien Pecoul (11)
Bref
- 1. Bref. L’agile est en péril. 1
- 4. Valeurs Les individus et leurs interactions plus que les processus et les outils. Du logiciel qui fonctionne plus qu’une documentation exhaustive. La collaboration avec les clients plus que la négociation contractuelle. L’adaptation au changement plus que le suivi d’un plan. 4
- 5. Scrum / Kanban / XP… Stand up quotidien Définition du terminé TDD Itération … 5
- 6. ? ? 6
- 7. A cause de toi (nous) 7
- 8. A cause de toi (nous)Le principe oublié? Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité Une attention continue à l'excellence technique et à une bonne conception sont indispensable à l’agilité 8
- 9. Code bien conçu Code évolutif Satisfait besoin client 9
- 10. ? ? Une attention continue à l'excellence technique et à une bonne conception sont indispensable à l’agilité 10
- 12. Hexagonal + Event Driven Couches + ORM 12
- 13. Est-ce que mon code est simple à faire évoluer? Est-ce que j’ai une belle architecture?
- 15. Bref 15
- 16. L’agile est en péril 16 Scrum et Kanban VS XP
- 17. Bref 17
- 18. Jenkins est ton a! 18 Sauvez l’agilité !
- 20. Bref. L’agile est en péril. 20
Notes de l'éditeur
- Je me suis dit que j’allais vraiment joué le jeu en ayant 20 slides de 20 secondes qui défilent seules. Du coup vous ne m’en voudrez pas si je lis un peu mon texte… Bref, L’agile est en péril.
- J’ai commencé par me demandé si la slide présentation, dont tout le monde se fou, devait compter dans les 20 slides de 20 secondes. En même temps, ca fait toujours 20 secondes de gagné, donc je me suis dit que ce serais quand même mieux de la compter. Et comme il ne me reste déjà plus que quelques secondes je me présente: Je m’appelle Emilien, je suis un développeur passionné en freelance, et vous pouvez me trouver sur Twitter
- Une des meilleures explication de l'agilité que j'ai pu lire jusqu'à présent c’est: Des principes, traduits par des concepts qu'on met en pratique à travers des compétences. J’aime bien pque on voit bien que pour être agile, on doit avoir des pratiques bien défini, pour mettre en œuvre ces principes que nous revendiquons.
- Alors en terme de valeurs et de principes, on tombe tous facilement d’accord. D’ailleurs, on a même écrit un manifeste pour ça.
- En termes de pratiques, forcément c’est plus compliqué. On a globalement différentes méthodes avec des pratiques plus ou moins contraignantes qui se rejoignent ou pas. La méthode la plus à la mode semble être SCRUM (d’ailleurs je commence a entendre des gens qui me parle de devenir « SCRUM master » au lieu de devenir « Chef de projet », j’imagine qu’on peut voir ça comme une amélioration).
- Du coup, je me demande pourquoi, alors que l’agilité semble devenir « la norme », on voit tellement de projet agiles en principe mais qui ne le sont pas du tout en pratique? Pourtant tout est bien fait comme le formateur certifié SCRUM a dit! Des itérations, des user stories, des rôles dans des équipes de 5 à 9 personnes… Alors pourquoi ça échoue?
- A mon avis c’est a cause de nous, Parce-que nous avons beaucoup insisté sur des techniques de management agiles. Mais a force de vouloir convaincre des décideurs, on en a oublié d’expliquer aux développeurs comment être agile. On a laissé croire que le changement se trouvé juste au niveau managériale.
- Et pourtant l’un des principes agile met en avant ce point en particulier! Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité. Bon, d’ailleurs si on me demandait mon avis, je dirais plutôt : Une attention continue à l'excellence technique et à une bonne conception sont indispensable à l’agilité.
- Ca semble évident, mais puisque c’est si souvent oublié je me permet d’en remettre une couche: Du code bien conçu permet de faire facilement évoluer ce code dans le temps. Du code évolutif permet de mieux répondre aux besoins du clients qui évoluent aussi.
- Alors comment avons-nous pu oublié ce principe fondamental de l’agilité aussi facilement? Bon ok j’exagère un peu, en vérité tout développeur qui lance un nouveau projet VEUT bien le concevoir. Donc ce principe n’est pas réellement oublié, il est simplement interprété par «Soyez balèzes, et faites une belle architecture ». Vue que tlm pense être balèze, l’interprétation qui reste est « faites une belle architecture »
- Mais c’est quoi une belle architecture? Dire de faire une belle architecture c’est comme expliqué a quelqu’un qui veut investir de l’argent en bourse, qu’acheter des actions quand elle sont pas chère et les revendre quand elles sont cher c’est la meilleur chose à faire pour devenir riche. Ou encore comme expliqué comment les gnomes voleurs de slip gagne de l’argent: 1> Ils volent des slips 2> ? 3> Ils font du profit
- Bref, dire qu’il faut du code de qualité pour être agile, c’est bien (même si je pense qu’on ne le dis pas assez), mais encore faut il savoir comment. Et pour savoir comment on place souvent le débat au niveau de l’architecture. Par exemple est-ce qu’il vaut mieux partir sur une architecture en couche ou sur une architecture hexagonale? Même si j’ai mon avis sur la question, je ne prendrais pas parti car ce n’est tout simplement pas la bonne question.
- La seule question à se poser c’est: est ce que mon code est simple à faire évoluer. Et ça c’est très simple à évaluer: Comment se passe vos livraisons? Est-ce que vous râler à chaque demande d’évolution ou est ce que vous le prenez comme une opportunité d’améliorer votre code? Est-ce que vous avez peur quand vous changez une ligne de code?
- Et pour que ce code puisse être simple à faire évolué sans tout cassé, on a besoin d’outils automatique comme les TUA. Ceux qui ont un peu pratiqué ont vite découvert qu’en écrivant son TU avant son code, on arrive à faire émerger une architecture robuste. C’est le TDD.
- Bref, revenons en à nos moutons. On sait que l’agilité c’est à la mode. On sait que SCRUM est particulièrement à la mode parmi les agiliste. Et on voit beaucoup de projets qui se disent agile mais qui ne pratique ni le TDD, ni le pair programming, ni l’intégraton continue. Du coup, on voit beaucoup de projets agiles qui échouent, ce qui fait que des personnes pensent que « l’agilité ça marche pas pour eux».
- C’est pour cela que je pense que l’agile est en péril. Si on continu à laisser de coté les pratiques techniques comme le TDD quand on parle d’agilité, alors on prend le risque que seul des pratiques plus simples comme le daily stand up et les user stories soient associé à l’agilité. On ne peut pas être agile si on est pas agile en terme de gestion de projet ET de technique
- Bref, je ne dis pas que tout le monde doit être agile. Je dis juste qu’il est de la responsabilité de ce qui croit en l’agilité, de faire prendre conscience à ceux qui veulent pratiquer que l’adaptation doit se trouver à tous les niveaux, managériale et technique. L’agilité sans tester, c’est se tirer une balle dans le pied!
- Alors svp sauvez l’agilité. Si vous croisez une équipe qui pense être agile en construisant un SI sans une ligne de TU, montrez leur que c’est pas agile! Faites leur prendre conscience de la différences entre leur valeur agile et leur livraisons qui se passent dans la douleur.
- A ceux qui pensent que tester c’est doutez, Montrez à quel point il faut être prétentieux pour penser pouvoir garder le contrôle d’un SI complexe, batî par plusieurs dizaine de personnes sur plusieurs années, sans l’assistance d’outils automatique permettant de garantir le comportement du système?
- Bref, l’agile est en péril, parce que trop de personnes pensent être agiles en collant des post it. Et c’est de la responsabilité de tout ce qui croit en l’agilité de montrer des techniques de développement concrète qui permette à une équipe de produire du code de qualité qui s’adapte aux changements.