{"id":78,"date":"2022-12-20T14:28:59","date_gmt":"2022-12-20T13:28:59","guid":{"rendered":"https:\/\/blog.twentyeight.be\/fr\/?p=78"},"modified":"2023-11-07T15:06:07","modified_gmt":"2023-11-07T14:06:07","slug":"les-criteres-dacceptation","status":"publish","type":"post","link":"https:\/\/blog.twentyeight.be\/fr\/2022\/12\/20\/les-criteres-dacceptation\/","title":{"rendered":"Les crit\u00e8res d’acceptation"},"content":{"rendered":"\n

A quoi servent-ils?<\/h2>\n\n\n\n

Ils sont moteurs de communication et de r\u00e9flexion<\/strong><\/h3>\n\n\n\n

Ils d\u00e9clenchent le processus de r\u00e9flexion de l’\u00e9quipe et am\u00e8nent \u00e0 penser, \u00e0 comment une fonctionnalit\u00e9 va se comporter du point de vue de l’utilisateur final (persona)<\/p>\n\n\n\n

Souviens toi, une story c’est surtout une amorce \u00e0 la discussion \/ r\u00e9flexion.<\/p>\n\n\n\n

Servent de base aux cas de test<\/strong><\/h3>\n\n\n\n

Aide l’\u00e9quipe \u00e0 \u00e9crire des cas de tests pr\u00e9cis et sur base des crit\u00e8res accept\u00e9 par tout le monde et donc coh\u00e9rent sur l’ensemble de la vie du ticket.<\/p>\n\n\n\n

Ils d\u00e9crivent \u00e9galement des sc\u00e9narii n\u00e9gatifs , et des unhappy flow<\/p>\n\n\n\n

Ils affinent le scope<\/strong><\/h3>\n\n\n\n

D\u00e9finissent la port\u00e9e, les limites du ticket et r\u00e9duisent les ambigu\u00eft\u00e9s. Ils clarifient.<\/p>\n\n\n\n

Garantie<\/strong><\/h3>\n\n\n\n

Ils garantissent que tous les parties prenantes et utilisateurs ont une compr\u00e9hension commune et sont satisfaits de ce qu’ils obtiennent.<\/p>\n\n\n\n

Ils aident \u00e0 l’estimation<\/strong><\/h3>\n\n\n\n

Ils pr\u00e9sentent ce qui doit \u00eatre exactement d\u00e9velopp\u00e9 par l’\u00e9quipe. Gr\u00e2ce \u00e0 ces exigences pr\u00e9cises, l’\u00e9quipe peut \u00e9ventuellement diviser en t\u00e2ches qui aideront \u00e0 une estimation globale.
(Du coup, \u00e7a aide aussi \u00e0 diviser une story en \u00ab\u00a0sous-story\u00a0\u00bb)<\/p>\n\n\n\n

\n

Les crit\u00e8res d’acceptation sont indispensables, car ils \u00e9vitent les r\u00e9sultats inattendus et mettent tout le monde d’accord sur la mani\u00e8re dont va \u00eatre impl\u00e9ment\u00e9 un ticket.<\/strong><\/p>\nLe Jardinier<\/cite><\/blockquote>\n\n\n\n

Qui r\u00e9dige les crit\u00e8res d’acceptation?<\/strong><\/h2>\n\n\n\n

Le PO bien entendu …<\/p>\n\n\n\n

Tout le monde le sait, le PO, il fait beaucoup beaucoup de chose, donc, il d\u00e9l\u00e8gue. Il d\u00e9l\u00e8gue a qui veut \/ peut le faire dans l’\u00e9quipe.<\/p>\n\n\n\n

    \n
  1. Les analystes qui connaissent bien le sujet du ticket<\/li>\n\n\n\n
  2. Le m\u00e9tier qui en faisant cela s’assurera que le besoin exprim\u00e9 sera bien rempli<\/li>\n\n\n\n
  3. Le d\u00e9veloppeur qui confirmera sa compr\u00e9hension du ticket<\/li>\n\n\n\n
  4. Le QA qui va chercher la petite b\u00eate, l’incoh\u00e9rence dans le r\u00e9cit<\/li>\n<\/ol>\n\n\n\n
    \n

    La mani\u00e8re la plus efficace de cr\u00e9er les crit\u00e8res d’acceptation est tr\u00e8s certainement un savant m\u00e9lange des diff\u00e9rents r\u00f4les et comp\u00e9tences.<\/strong><\/p>\nLe Jardinier<\/cite><\/blockquote>\n\n\n\n

    Quand r\u00e9diger les crit\u00e8res d’acceptation?<\/strong><\/h2>\n\n\n\n
      \n
    1. Avant le d\u00e9veloppement du ticket. (Merci capitaine Obvius)<\/li>\n\n\n\n
    2. Durant les exercices d’affinage du backlog<\/li>\n\n\n\n
    3. Durant l’analyse d’une demande m\u00e9tier<\/li>\n\n\n\n
    4. A la r\u00e9daction de la demande m\u00e9tier<\/li>\n\n\n\n
    5. Durant une phase de discovery<\/li>\n<\/ol>\n\n\n\n

      Le format<\/h2>\n\n\n\n
      \n
      \n

      La check liste<\/h2>\n\n\n\n