Il existe des projets assez simples et relativement prévisibles, où des outils rationnels de planification et de prise de décision peuvent être appliqués. D’autres projets plus complexes ou imprévisibles appellent une approche différente s’appuyant davantage sur l’auto-organisation et l’innovation.
La plupart des projets de développement de logiciels sont considérés comme complexes et de nature imprévisible en raison de la convergence de trois facteurs : les personnes, les exigences et la technologie. Les différentes approches utilisées pour la livraison et la gestion des projets pourraient être plus facilement comprises dans le contexte des modèles de contrôle des processus et de la complexité des projets.
Processus défini — Une approche traditionnelle basée sur un plan
Traditionnellement, une fois qu’un projet démarre, un ensemble d’exigences est créé, puis « approuvé ». Le chef de projet suppose que cette approbation se traduit par un ensemble fixe d’exigences et que la planification peut maintenant commencer. Le chef de projet estime combien de temps il faudra pour répondre aux exigences et crée le plan de projet. Le plan prévoit que le projet sera terminé à une certaine date, et cette date est communiquée au client.
Le défaut fondamental de cette approche est que le plan, qui pilote tout, est basé sur l’hypothèse que les exigences sont fixes et ne changeront pas. L’expérience nous a montré que ce n’est jamais le cas ; les exigences ne sont jamais fixes — elles changent toujours. Lorsque les exigences changent, le plan est affecté ; et par conséquent, la date d’achèvement doit également changer. Malheureusement, dans de nombreux cas, cela est impossible et l’équipe doit livrer à la date à laquelle elle s’est engagée. C’est alors qu’une crise majeure survient et que le projet commence à déraper.
Processus empirique — Approche agile axée sur la valeur
L’approche agile axée sur la valeur est basée sur un empirisme qui change tout l’état d’esprit. Il suppose dès le départ que les exigences qui existent au départ ne sont pas fixes et qu’elles changeront.
L’état d’esprit agile suppose également que vous devez livrer à une certaine date. Cette approche fixe le temps et les ressources et laisse les exigences indéterminées. Pour nous, cette approche ressemble davantage à la réalité de la création de logiciels. Maintenant, toute la notion de valeur est parfaitement logique. Lorsque vous disposez d’un laps de temps fixe pendant lequel vous n’êtes pas sûr de pouvoir répondre à toutes les exigences (car elles changeront et donc le temps nécessaire pour les terminer changera), la réaction naturelle est de hiérarchiser les exigences et de terminer en premier. ceux qui ajoutent le plus de valeur au client.
Vous pensez peut-être : « Qu’en est-il des exigences qui ne sont pas terminées à la date de livraison ? C’est la raison pour laquelle vous utilisez l’approche axée sur la valeur. Vous reconnaissez le fait que toutes les exigences ne seront pas satisfaites à la date de livraison. La question importante à se poser est de savoir si vous avez fourni suffisamment de fonctionnalités pour prendre en charge un système qui apporte de la valeur au client.
Taux d’échec des projets logiciels
Le rapport CHAOS 2015 a récemment été publié par le groupe Standish . Les rapports CHAOS sont publiés chaque année depuis 1994 et sont un instantané de l’état de l’industrie du développement logiciel. Cette année, le rapport a étudié 50 000 projets dans le monde, allant de petites améliorations à des implémentations massives de réingénierie de systèmes. Cette année, le rapport comprend une définition améliorée du succès en examinant certains facteurs supplémentaires qui étaient couverts dans les enquêtes précédentes.
Les résultats indiquent qu’il y a encore du travail à faire pour obtenir des résultats positifs des projets de développement de logiciels. Ce tableau résume les résultats des projets au cours des cinq dernières années en utilisant la nouvelle définition des facteurs de succès (dans les délais, dans le budget avec un résultat satisfaisant).
Avec l’adoption des méthodes de développement agiles au cours des dernières années, il a été possible de comparer les résultats des projets entre les projets agiles et traditionnels en cascade. Dans toutes les tailles de projet, les approches agiles ont donné lieu à des projets plus réussis et à moins d’échecs purs et simples, comme le montre ce tableau
Quels sont les problèmes de l’approche traditionnelle?
L’approche traditionnelle basée sur un plan n’est pas défectueuse en soi ; il n’est tout simplement pas adapté à l’industrie du logiciel d’aujourd’hui. L’approche basée sur les plans était à l’origine basée sur les concepts traditionnels de gestion de projet, issus de l’industrie de la construction. Dans l’industrie de la construction, l’approche basée sur les plans convient : les plans, qui sont les exigences, sont fixes et ne changeront probablement pas pendant la construction du bâtiment. Vous pouvez estimer combien de temps il faudra pour construire les piliers en acier, couler le béton, etc.
La raison pour laquelle l’approche traditionnelle basée sur les plans convient à l’industrie de la construction mais pas à l’industrie du logiciel revient à la différence dans la façon dont nous contrôlons les systèmes empiriques (comme le développement de logiciels) et la façon dont nous contrôlons les systèmes définis (comme la construction ou la fabrication). ). Le tableau ci-dessous montre les différences entre les caractéristiques d’un processus défini et celles d’un processus empirique.
Après avoir lu le tableau, il est facile de voir que le développement de logiciels est définitivement un processus empirique, pas un processus défini. Le problème est que nous abordons le développement logiciel depuis des années comme un processus défini — et cette approche ne fonctionne pas.
Les références
- Rapport sur le chaos 2015 du Standish Group
- Devenir agile dans un mot imparfait — par Greg Smith & Ahmed Sidky
Français
English
简体中文
繁體中文
Deutsch
Español
العربية
Italiano
Português
日本語
Nederlands
Русский