L'art du développement agile, 2e édition

Analyse des incidents

AUDIENCE

Toute l'équipe

Nous apprenons de nos échecs.

Malgré tous tes efforts, il arrive que ton logiciel ne fonctionne pas comme il le devrait. Certaines défaillances seront mineures, comme une faute de frappe sur une page web. D'autres seront plus importantes, comme un code qui corrompt les données des clients, ou une panne qui empêche l'accès des clients.

Certaines défaillances sont appelées bogues ou défauts, d' autres sont appelées incidents. La distinction n'est pas particulièrement importante. Quoi qu'il en soit, une fois que la poussière est retombée et que les choses fonctionnent à nouveau correctement, tu dois comprendre ce qui s'est passé et comment tu peux t'améliorer. C'est ce qu'on appelle l'analyse des incidents.

NOTE

Les détails sur la façon de réagir lors d' un incident sortent du cadre de ce livre. Pour un excellent guide pratique sur la réponse aux incidents, voir Site Reliability Engineering : How Google Runs Production Systems [Beyer2016], en particulier les chapitres 12 à 14.

ACCEPTE L'ÉCHEC

Les équipes Agiles comprennent que les échecs sont inévitables. Les gens font des erreurs ; des erreurs de communication se produisent ; les idées ne fonctionnent pas.

Plutôt que de s'engager dans une quête donquichottesque pour éviter l'échec, les équipes Agile l'adoptent. Si l'échec est inévitable, l'important est de le détecter le plus tôt possible, de l'éviter tôt, pendant qu'il est encore temps de s'en remettre, de le contenir, afin que les ...