Ressources
Les organisation se sont emparait de Agile comme la solution à leur problème mais n’ont jamais réellement changé “Agile” ideas are applied poorly
Organizations that try to improve usually do improve, and so even if “Agile” ideas are applied poorly, trying will almost always provide some benefits to the organization.
I’ve tried to help those people understand that their organization is doing “Agile” wrong
Et lorsque les idées sont mal appliquées, elles créent souvent la confusion et entraînent plus de travail à faire en peu de temps tout en augmentant la pression au sein de l’équipe.
When “Agile” ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to “go faster”. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing “Agile” poorly will result, more often than not, in far more defects and much slower progress than could be attained.
Ron Jeffries rejoins les mots de Ken Beck qui souhaitait créer (avec Agile) un monde meilleur pour les développeurs
Kent Beck said over a decade ago. I would like the world to be safe for developers.
Cet article s’adresse donc aux développeurs pour qu’ils prennent conscience de cette mauvaise utilisation du terme Agile dans les organisation (“le fake Agile”). Ron Jeffries incite chaqu’un à chaque développeur à se former sur “comment faire un logiciel”
I believe that developers should detach their thinking from any particular named “Agile” method. Instead, they should turn their attention and learning to ways of doing software development that will work within any of those “Agile” methods.
Lorsqu’il parle d’apprentissage, il souhaite que les développeurs se forme à créer un logiciel opérationnel, suivre les bonnes pratiques de développement et apporter de valeur de manière régulière
No matter what framework or method your management thinks they are applying, learn to work this way:
- Produce running, tested, working, integrated software every two weeks, every week. Build your skills until you can create a new fully operational version every day, twice a day, multiple times a day.
- Keep the design of that software clean. As it grows, the design will tend to become complex and crufty. Resist and reverse this tendency consciously, refactoring in tiny continuous steps, all the time, so that your rate of progress is as steady and consistent as possible.
- Use the current increment of software as the foundation for all your conversations with your product leadership and management. Speak in terms of what’s ready to go, and in terms of what they’d like you to do next.
Il souhaite ainsi avoir une équipe auto-organisé qui est capable de choisir son processus de fonctionnement car elle a compris comment créer un logiciel
The Manifesto calls for “self-organizing” teams, and in the best case, that comes down to the team choosing its own process. If I were starting a company, I’d let the teams choose any process they wish.
Grâce à sa connaissance, elle peut très bien choisir un processus déjà existant ou en créer un nouveau, prendre des pratiques en rejeter d’autres. Cette conscience lui permet d’avoir le choix de choisir comment travailler
If you do get a chance to choose, I’d recommend that you start with something like Extreme Programming. It contains all the planning and feedback loops you need, and it includes the basic technical practices you need to do what we’ve been talking about here, and to do what I’d be asking for.
Conserver le coeur Agile
Néanmoins, Ron Jeffries est fier du coeur de la philosophie Agile qu’il estime comme la meilleure manière de créer un logiciel
However, the values and principles of the Manifesto for Agile Software Development still offer the best way I know to build software, and based on my long and varied experience, I’d follow those values and principles no matter what method the larger organization used.
Mais il reproche aux entreprises d’utiliser uniquement le terme Agile sans y appliquer les valeurs et les principes. A mon sens Agile n’est pas une utopie, mais dans de nombreuses organisation il n’y a jamais eu la volonté de changement, le top management pensé qu’Agile allait résoudre des problèmes sans opérer de chanqement dans le fonctionnement organisationnel de l’entreprise. Agile doit commencer par un changement initier par le haut (la direction) et non être appliqué par le bas (le développement)