« Less - Intégration continue » : différence entre les versions

De Wiki Agile
Ligne 245 : Ligne 245 :
<blockquote>Ce n’est pas parce qu’il y a représentation visuelle qu’il s’agit de management visuel. Il est relativement facile de mettre en place de belles zones d’affichage qui seront là pour faire jolies. Le véritable défi est de les rendre “utilisables”. Parmi les gens qui visitent le site de Toyota, un certain nombre d’entre eux évoquent la différence entre leur approche et celle de Toyota. Nous entendons régulièrement des commentaires comme “Maintenant je vois, ce qui est affiché par Toyota permet vraiment d’orienter les actions au quotidien”. C’est là en effet toute la différence, et Toyota suggèrerait que si cela ne sert pas à orienter les actions au quotidien alors autant s’en débarrasser.
<blockquote>Ce n’est pas parce qu’il y a représentation visuelle qu’il s’agit de management visuel. Il est relativement facile de mettre en place de belles zones d’affichage qui seront là pour faire jolies. Le véritable défi est de les rendre “utilisables”. Parmi les gens qui visitent le site de Toyota, un certain nombre d’entre eux évoquent la différence entre leur approche et celle de Toyota. Nous entendons régulièrement des commentaires comme “Maintenant je vois, ce qui est affiché par Toyota permet vraiment d’orienter les actions au quotidien”. C’est là en effet toute la différence, et Toyota suggèrerait que si cela ne sert pas à orienter les actions au quotidien alors autant s’en débarrasser.
</blockquote>
</blockquote>
Sur les produits de taille importante, il s’avère encore plus difficile de fractionner de gros en petits changements. Les développeurs veulent quelques fois restructurer ou ré-architecturer leur système existant et sont convaincus que cela doit être fait en un seul gros changement. Mais nous n’avons pas encore vu de gros refactoring qui ne pourraient être fait graduellement. À chaque fois, après discussion avec les développeurs, nous avons trouvé des moyens de fractionner ce gros refactoring qui-ne-pouvait-pas-l-être. [http://www.amazon.com/Refactoring-Large-Software-Projects-Restructurings-ebook/dp/B0014ELAZA RL06].
Sur les produits de taille importante, il s’avère encore plus difficile de fractionner de gros changements. Les développeurs veulent quelques fois restructurer ou ré-architecturer leur système existant et sont convaincus que cela doit être fait en un seul gros changement. Mais nous n’avons pas encore vu de gros refactoring qui ne pourraient être fait graduellement. À chaque fois, après discussion avec les développeurs, nous avons trouvé des moyens de fractionner ce gros refactoring qui-ne-pouvait-pas-l-être. [http://www.amazon.com/Refactoring-Large-Software-Projects-Restructurings-ebook/dp/B0014ELAZA RL06].


Les changements d’interface sont un problème assez répandus dans les gros systèmes. Beaucoup de composants utilisent des interfaces et doivent être modifiés en conséquence - ce qui rend impossible de le faire graduellement, c’est bien ça ? Pas tant que ça. En fait, un changement d’interface dans une API (interface de programmation applicative - NdT), est assez répandue et pour laquelle il existe une solution bien connue :
Les changements d’interface sont un problème assez répandus dans les gros systèmes. Beaucoup de composants utilisent des interfaces et doivent être modifiés en conséquence - ce qui rend impossible de le faire graduellement, c’est bien ça ? Pas tant que ça. En fait, un changement d’interface dans une API (interface de programmation applicative - NdT), est assez répandue et pour laquelle il existe une solution bien connue :