🤹 [23/02/2023] Venez, on lit les 12 principes du manifestes AGILE !

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

L'entrée des pratiques dev-ops commence enfin à entrer dans les boites, mêmes les grosses. L'arrivée d'accelerate, redit la meme chose avec des chiffres. L'inssistance sur le fait que ce sont des fonctionnalités et non des taches technique montre l'intéret pour la vision produit de l'agile. Il y a encore beacoup trop de projet qui ne sont pas en production, mais on sent que les choses avancent sur ce point.

Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.

Oui, c'est mis en place dans beaucoup de projet AGILE aujourd'hui.

1er problème : Il y a encore une tendance a remettre les cahiers des charge et dossier d'architecture dans les critères d'acceptance dans les tiquet jira…

2e problème : On trouve beaucoup de boite, qui sous prétexte d'agile, changent du jour au lendemain de grosse priorité dans le sprint. Dans SCRUM, le respect de l'inviolabilité du sprint me semble une pierre angluaire.

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

Cf. Le point numéro 1

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

Un des points que je vois les moins dans la réalité. Les developpeurs ne voient que très très rarements les utilisateurs finaux. Les PO sont très souvent externes aux projets et ne sont pas de vrais owner de leurs produits.

L'arrivée des UX ces dernieres années est une très bonne chose. Mais l'idéale, que je n'ai jamais vu, reste quand meme de faire travailler developpeurs avec de vrais utilisateurs finaux avant et après les démos.

Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.

VPN en carraf, connexion internet lente, sites internet censuré pour des raisons de sécurité, machine de travail hyper lente, choix du système d'exploitation imposé, interdiction d'installer ses logiciels sur son poste de travail…

Faut-il encore parler des languages de programmation et technos imposé par d'obscure achitect déconnecté du terrain a des developpeurs qui les déteste et ne les maitrise pas ? Je ne compte plus les fois où j'ai vu ce genre de conditions de travail détestable pour les dev…

On me rétorquera que les dev font leurs divas, que l'acces a youtube n'est pas nécessaire pour coder et qu'il est légitime, pour des raisons de sécurité, on leur interdit d'installer tel ou tel logiciel…

Certe, mais dans un marché hyper tendu où les salaires des bons developpeurs sont hypers haut, brider de tel manière les techs me semble dangereux voir stupide d'un point de vue managériale.

La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

Après un émerveillement du télétravail dû à la crise covid, la réalité est revenue rapidement. Les projets avancent mieux lorsque l'équipe travail dans un meme bureau. Bien sur le full-télétrail semble une utopie, mais la formule 3 jours de présentiel / semaine s'ancre peu à peu. Une victoire a été obtenue, les équipes mixtes en offshore (Nottament en Inde) semble avoir montré leur nullité. Ouf !

Un logiciel opérationnel est la principale mesure d’avancement.

Le point 7 est clairement un point éludé de nombreux projet AGILE actuellement : On y trouve davantage de discution autour des Story Points ou pire, des jours/hommes, que de démonstration de logiciel qui fonctionnent. Les manageurs et les comptables revent d'avoir un voyant vert qui leur dit "tout va bien" et un "voyant rouge" qui leur dirait "tout va mal". L'agile rappel ce point essentiel, il faut aller sur le terrain, voir les projets "en vrais" pour savoir ce qui se passe. Les rapports excels de jours hommes traversses mal le mur de la réalité.

Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

Je crois qu'il n'y a moins de problème sur ces questions-là tellement le marché des dev est tendu. Forcer sur les heures de travail d'une équipe tech c'est clairement prendre le risque d'en voir se barrer en cours de réalisation du projet. En revanchem je trouve des rythmes plus poussés chez les PO.

Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.

Rien de particulié à dire. A vue de nez, j'ai l'impression que 20% des projets autour de moi font des tests automatiques et du TDD. La qualité s'observe et commence à se mesurer avec le taux de couverture de code et les analyse type sonar cube. Certe, c'est loin d'être parfait, mais j'ai l'impression que les choses bougent sur le sujet de la qualité. C'est encouragant.

La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

Si je devais parler de ce qui complexifie les projets tech, je dirais qu'elles sont principalement issues des pratiques de sécurité et d'OPS imposé par les grosses boites.

Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.

Je suis tellement fan de ce point-là ! Mais vraiment. C'est ce qui fait toute la substance de l'agilité. La présence d'archis, de responsable sécurité et co sont pour moi des entraves a l'automie. On commence a savoir que les components teams ne fonctionnent pas. Pourtant ca ne bouge pas et la bureaucratie technique reste une réalité très douloureuse.

A vouloir materner les équipes, on les empeches d'etre créatif et responsable. L'auto-organisation est une vraie réponse aux questions de motivation. (Cf. point 5)

À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

C'est tout le sens de la rétro. Ca commence à entrer, et quand c'est fait régulièrement, on voit des miracles. Au-delà de l'aspect amélioration continue, il y a quelque chose de psychanalique de groupe dans la rétro que j'aime beaucoup.

Voilà pour les 12 principes relus rapidement. En espérant que cela vous a interessé !