{"id":9584,"date":"2022-01-25T10:25:00","date_gmt":"2022-01-25T10:25:00","guid":{"rendered":"https:\/\/www.cybermedian.com\/fr\/?p=9584"},"modified":"2026-04-20T09:13:56","modified_gmt":"2026-04-20T09:13:56","slug":"pourquoi-scrum-processus-defini-vs-processus-empirique","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/fr\/why-scrum-defined-process-vs-empirical-process\/","title":{"rendered":"Pourquoi Scrum : processus d\u00e9fini vs processus empirique"},"content":{"rendered":"

Il existe des projets assez simples et relativement pr\u00e9visibles, o\u00f9 des outils rationnels de planification et de prise de d\u00e9cision peuvent \u00eatre appliqu\u00e9s.\u00a0D’autres projets plus complexes ou impr\u00e9visibles appellent une approche diff\u00e9rente s’appuyant davantage sur l’auto-organisation et l’innovation.<\/p>\n

La plupart des projets de d\u00e9veloppement de logiciels sont consid\u00e9r\u00e9s comme complexes et de nature impr\u00e9visible en raison de la convergence de trois facteurs\u00a0: les personnes, les exigences et la technologie.\u00a0Les diff\u00e9rentes approches utilis\u00e9es pour la livraison et la gestion des projets pourraient \u00eatre plus facilement comprises dans le contexte des mod\u00e8les de contr\u00f4le des processus et de la complexit\u00e9 des projets.<\/p>\n

Types de contr\u00f4le de processus<\/figcaption><\/figure>\n

Processus d\u00e9fini \u2014 Une approche traditionnelle bas\u00e9e sur un plan<\/strong><\/p>\n

Traditionnellement, une fois qu’un projet d\u00e9marre, un ensemble d’exigences est cr\u00e9\u00e9, puis \u00ab\u00a0approuv\u00e9\u00a0\u00bb.\u00a0Le chef de projet suppose que cette approbation se traduit par un ensemble fixe d’exigences et que la planification peut maintenant commencer.\u00a0Le chef de projet estime combien de temps il faudra pour r\u00e9pondre aux exigences et cr\u00e9e le plan de projet.\u00a0Le plan pr\u00e9voit que le projet sera termin\u00e9 \u00e0 une certaine date, et cette date est communiqu\u00e9e au client.<\/p>\n

Le d\u00e9faut fondamental de cette approche est que le plan, qui pilote tout, est bas\u00e9 sur l’hypoth\u00e8se que les exigences sont fixes et ne changeront pas.\u00a0L’exp\u00e9rience nous a montr\u00e9 que ce n’est jamais le cas ;\u00a0les exigences ne sont jamais fixes \u2014 elles changent toujours.\u00a0Lorsque les exigences changent, le plan est affect\u00e9 ;\u00a0et par cons\u00e9quent, la date d’ach\u00e8vement doit \u00e9galement changer.\u00a0Malheureusement, dans de nombreux cas, cela est impossible et l’\u00e9quipe doit livrer \u00e0 la date \u00e0 laquelle elle s’est engag\u00e9e.\u00a0C’est alors qu’une crise majeure survient et que le projet commence \u00e0 d\u00e9raper.<\/p>\n

Processus empirique \u2014 Approche agile ax\u00e9e sur la valeur<\/strong><\/p>\n

L’approche agile ax\u00e9e sur la valeur est bas\u00e9e sur un\u00a0\u00a0empirisme\u00a0<\/strong>\u00a0qui change tout l’\u00e9tat d’esprit.\u00a0Il suppose d\u00e8s le d\u00e9part que les exigences qui existent au d\u00e9part ne sont pas fixes et qu’elles changeront.<\/p>\n

L’\u00e9tat d’esprit agile suppose \u00e9galement que vous devez livrer \u00e0 une certaine date.\u00a0Cette approche fixe le temps et les ressources et laisse les exigences ind\u00e9termin\u00e9es.\u00a0Pour nous, cette approche ressemble davantage \u00e0 la r\u00e9alit\u00e9 de la cr\u00e9ation de logiciels.\u00a0Maintenant, toute la notion de valeur est parfaitement logique.\u00a0Lorsque vous disposez d’un laps de temps fixe pendant lequel vous n’\u00eates pas s\u00fbr de pouvoir r\u00e9pondre \u00e0 toutes les exigences (car elles changeront et donc le temps n\u00e9cessaire pour les terminer changera), la r\u00e9action naturelle est de hi\u00e9rarchiser les exigences et de terminer en premier. ceux qui ajoutent le plus de valeur au client.<\/p>\n

Vous pensez peut-\u00eatre : \u00ab Qu’en est-il des exigences qui ne sont pas termin\u00e9es \u00e0 la date de livraison ?\u00a0C’est la raison pour laquelle vous utilisez l’approche ax\u00e9e sur la valeur.\u00a0Vous reconnaissez le fait que toutes les exigences ne seront pas satisfaites \u00e0 la date de livraison.\u00a0La question importante \u00e0 se poser est de savoir si vous avez fourni suffisamment de fonctionnalit\u00e9s pour prendre en charge un syst\u00e8me qui apporte de la valeur au client.<\/p>\n

Taux d’\u00e9chec des projets logiciels<\/strong><\/p>\n

Le rapport CHAOS<\/a>\u00a02015\u00a0\u00a0\u00a0a r\u00e9cemment \u00e9t\u00e9 publi\u00e9 par le\u00a0\u00a0groupe Standish<\/a>\u00a0.\u00a0Les rapports CHAOS sont publi\u00e9s chaque ann\u00e9e depuis 1994 et sont un instantan\u00e9 de l’\u00e9tat de l’industrie du d\u00e9veloppement logiciel.\u00a0Cette ann\u00e9e, le rapport a \u00e9tudi\u00e9 50 000 projets dans le monde, allant de petites am\u00e9liorations \u00e0 des impl\u00e9mentations massives de r\u00e9ing\u00e9nierie de syst\u00e8mes.\u00a0Cette ann\u00e9e, le rapport comprend une d\u00e9finition am\u00e9lior\u00e9e du succ\u00e8s en examinant certains facteurs suppl\u00e9mentaires qui \u00e9taient couverts dans les enqu\u00eates pr\u00e9c\u00e9dentes.<\/p>\n

Les r\u00e9sultats indiquent qu’il y a encore du travail \u00e0 faire pour obtenir des r\u00e9sultats positifs des projets de d\u00e9veloppement de logiciels.\u00a0Ce tableau r\u00e9sume les r\u00e9sultats des projets au cours des cinq derni\u00e8res ann\u00e9es en utilisant la nouvelle d\u00e9finition des facteurs de succ\u00e8s (dans les d\u00e9lais, dans le budget avec un r\u00e9sultat satisfaisant).<\/p>\n

Taux d’\u00e9chec des projets logiciels<\/figcaption><\/figure>\n

Avec l’adoption des m\u00e9thodes de d\u00e9veloppement agiles au cours des derni\u00e8res ann\u00e9es, il a \u00e9t\u00e9 possible de comparer les r\u00e9sultats des projets entre les projets agiles et traditionnels en cascade.\u00a0Dans toutes les tailles de projet, les approches agiles ont donn\u00e9 lieu \u00e0 des projets plus r\u00e9ussis et \u00e0 moins d’\u00e9checs purs et simples, comme le montre ce tableau<\/p>\n

<\/figure>\n

Quels sont les probl\u00e8mes de l’approche traditionnelle?<\/strong><\/p>\n

L’approche traditionnelle bas\u00e9e sur un plan n’est pas d\u00e9fectueuse en soi ;\u00a0il n’est tout simplement pas adapt\u00e9 \u00e0 l’industrie du logiciel d’aujourd’hui.\u00a0L’approche bas\u00e9e sur les plans \u00e9tait \u00e0 l’origine bas\u00e9e sur les concepts traditionnels de gestion de projet, issus de l’industrie de la construction.\u00a0Dans l’industrie de la construction, l’approche bas\u00e9e sur les plans convient : les plans, qui sont les exigences, sont fixes et ne changeront probablement pas pendant la construction du b\u00e2timent.\u00a0Vous pouvez estimer combien de temps il faudra pour construire les piliers en acier, couler le b\u00e9ton, etc.<\/p>\n

La raison pour laquelle l’approche traditionnelle bas\u00e9e sur les plans convient \u00e0 l’industrie de la construction mais pas \u00e0 l’industrie du logiciel revient \u00e0 la diff\u00e9rence dans la fa\u00e7on dont nous contr\u00f4lons les syst\u00e8mes empiriques (comme le d\u00e9veloppement de logiciels) et la fa\u00e7on dont nous contr\u00f4lons les syst\u00e8mes d\u00e9finis (comme la construction ou la fabrication). ).\u00a0Le tableau ci-dessous montre les diff\u00e9rences entre les caract\u00e9ristiques d’un processus d\u00e9fini et celles d’un processus empirique.<\/p>\n

Processus d\u00e9fini vs processus empirique<\/figcaption><\/figure>\n

Apr\u00e8s avoir lu le tableau, il est facile de voir que le d\u00e9veloppement de logiciels est d\u00e9finitivement un processus empirique, pas un processus d\u00e9fini.\u00a0Le probl\u00e8me est que nous abordons le d\u00e9veloppement logiciel depuis des ann\u00e9es comme un processus d\u00e9fini \u2014 et cette approche ne fonctionne pas.<\/p>\n

Les r\u00e9f\u00e9rences<\/span><\/h3>\n
    \n
  1. Rapport sur le chaos 2015 du Standish Group<\/a><\/li>\n
  2. Devenir agile dans un mot imparfait \u2014 par Greg Smith & Ahmed Sidky<\/li>\n<\/ol>\n

    Autres lectures Scrum<\/span><\/h3>\n