« Less - Intégration continue » : différence entre les versions
De Wiki Agile
| Ligne 100 : | Ligne 100 : | ||
* la vitesse du cycle des retours d’informations | * la vitesse du cycle des retours d’informations | ||
'''Capacité à fractionner des gros changements''' - fractionner des gros changements en petits changements, tout en conservant dans un état opérationnel les anciennes fonctionnalités, est une compétence qui doit être apprise. Les meilleurs développeurs sont ceux qui, dans cette perspective du fractionnement, intègrent le plus fréquemment. Le développement piloté par les tests, en cycles courts de 10 minutes, est une très bonne technique arriver à cela. | '''Capacité à fractionner des gros changements''' - fractionner des gros changements en petits changements, tout en conservant dans un état opérationnel les anciennes fonctionnalités, est une compétence qui doit être apprise. Les meilleurs développeurs sont ceux qui, dans cette perspective du fractionnement, intègrent le plus fréquemment. Le développement piloté par les tests, en cycles courts de 10 minutes, est une très bonne technique pour arriver à cela. | ||
'''Vitesse d’intégration''' - plus l’intégration des changements prend du temps dans le dépôt de code, moins les développeurs le feront fréquemment. Les changements sont lotis dans un soucis d’efficacité. L’effort d’intégration est impacté par le surcoût du processus (le coût de transaction), tel que les approbations et les revues nécessaires avant que les développeurs soient autorisés à intégrer. Il faut réduire ce surcoût ou trouver des manières créatives de faire les choses différemment. Par exemple, nous avons travaillé avec un groupe produit de 40 personnes dans lequel le message d’enregistrement (check-in en anglais dans le texte pour les lecteurs plus habitués avec ce terme - NdT) devait mentionner la personne qui avait revu le code. Le résultat ? Les développeurs ont loti beaucoup de changements pour rendre les revues de code plus “efficaces” et cela a eu comme conséquence de retarder l’intégration - une optimisation locale. La solution ? Les revues de code peuvent être faites à la place sur du code intégré - ce qui a pour effet de ne pas retarder l’intégration. | '''Vitesse d’intégration''' - plus l’intégration des changements prend du temps dans le dépôt de code, moins les développeurs le feront fréquemment. Les changements sont lotis dans un soucis d’efficacité. L’effort d’intégration est impacté par le surcoût du processus (le coût de transaction), tel que les approbations et les revues nécessaires avant que les développeurs soient autorisés à intégrer. Il faut réduire ce surcoût ou trouver des manières créatives de faire les choses différemment. Par exemple, nous avons travaillé avec un groupe produit de 40 personnes dans lequel le message d’enregistrement (check-in en anglais dans le texte pour les lecteurs plus habitués avec ce terme - NdT) devait mentionner la personne qui avait revu le code. Le résultat ? Les développeurs ont loti beaucoup de changements pour rendre les revues de code plus “efficaces” et cela a eu comme conséquence de retarder l’intégration - une optimisation locale. La solution ? Les revues de code peuvent être faites à la place sur du code intégré - ce qui a pour effet de ne pas retarder l’intégration. | ||
