Une enquête réalisée par le Standish Group Study (2002) a montré que 2/3 des fonctions d’un système d’information sont rarement ou jamais utilisées, et qu’uniquement 1/5 des fonctions sont toujours ou souvent utilisées par le métier. Donc, 2/3 des fonctions ayant exigé du temps et de l’argent ne créent aucune valeur pour les affaires des entreprises. Pire encore, elles continuent leur chemin de gaspillage lors des opérations de maintenance et d’évolution des systèmes.
Comment peut-on arriver à ce type de paradoxe : accepter de consacrer du temps et de l’argent à des fonctions que personne n’utilise ?
Absence de priorisation basée sur le ROI entre les fonctions d’un système est une des sources de cette aberration. Il faut dire aussi que les démarches traditionnelles adoptées pour construire les systèmes d’information ne sont pas d’une grande aide, bien au contraire, elles accentuent ce phénomène.
Pour mettre fin à la spirale dépensière, des méthodologies alternatives ont vu le jour, comme la méthodologie Agile Scrum. Celle-ci a séduit un large public et des entreprises de renommée internationale, parmi lesquelles : Yahoo, Microsoft, Google, Motorola, SAP, Cisco, Lockheed Martin, GE Medical, Capilal One, FED (Réserve Fédérale Américaine), etc. Avec un numéro spécial consacré entièrement à Agile Scrum, nous avons voulu vous faire découvrir une autre voie pour ne construire que les fonctions dont vous avez réellement besoin
Les méthodologies traditionnelles : des limites et une résistance au changement
Cette méthodologie trouve son avantage dans sa suprême logique, son sens rationnel : il faut tout penser avant de construire, écrire tout, suivre un plan détaillé de réalisation. Mais elle accorde très peu d’importance à l’aspect gouvernance des projets, au facteur humain et à la priorisation des fonctions. Toutes les fonctions sont traitées avec le même niveau de priorité, quelques soient leurs ROI. De plus, elle exige un ensemble de facteurs clés de succès difficiles à faire réunir avant le démarrage d’un projet, exemple :
La méthodologie Agile SCRUM, une réponse aux limites des approches traditionnelles de type cycle en V
L’esprit fondateur de la démarche est la construction progressive du produit cible en commençant par les fonctionnalités à fort retour sur investissement (ROI), pour s’assurer au fil de l’eau de sa qualité, de sa cohérence avec les besoins de l’entreprise, tout en prenant les imprévus techniques, les évolutions du périmètre et les mutations du marché.
Comment peut-on arriver à ce type de paradoxe : accepter de consacrer du temps et de l’argent à des fonctions que personne n’utilise ?
Absence de priorisation basée sur le ROI entre les fonctions d’un système est une des sources de cette aberration. Il faut dire aussi que les démarches traditionnelles adoptées pour construire les systèmes d’information ne sont pas d’une grande aide, bien au contraire, elles accentuent ce phénomène.
Pour mettre fin à la spirale dépensière, des méthodologies alternatives ont vu le jour, comme la méthodologie Agile Scrum. Celle-ci a séduit un large public et des entreprises de renommée internationale, parmi lesquelles : Yahoo, Microsoft, Google, Motorola, SAP, Cisco, Lockheed Martin, GE Medical, Capilal One, FED (Réserve Fédérale Américaine), etc. Avec un numéro spécial consacré entièrement à Agile Scrum, nous avons voulu vous faire découvrir une autre voie pour ne construire que les fonctions dont vous avez réellement besoin
Les méthodologies traditionnelles : des limites et une résistance au changement
La méthodologie traditionnelle adoptée sur un grand nombre de projets de système d’information représente une cascade d’étapes, dont la plus connue est la méthode cycle en V. Celle-ci commence par une phase de planification, de conception et de documentation très détaillée. Ensuite, arrive le développement, les tests, la validation et le cycle se clôture avec la mise en exploitation du système final.
Cette méthodologie trouve son avantage dans sa suprême logique, son sens rationnel : il faut tout penser avant de construire, écrire tout, suivre un plan détaillé de réalisation. Mais elle accorde très peu d’importance à l’aspect gouvernance des projets, au facteur humain et à la priorisation des fonctions. Toutes les fonctions sont traitées avec le même niveau de priorité, quelques soient leurs ROI. De plus, elle exige un ensemble de facteurs clés de succès difficiles à faire réunir avant le démarrage d’un projet, exemple :
- les bonnes idées doivent être identifiées préalablement au démarrage de tout projet ;
- l’entreprise doit être capable de prévoir le futur avec précision, y compris les changements économiques et les imprévus métiers comme technologiques ;
- les responsables de projet doivent planifier les tâches incertaines avec exactitude...
Cependant, la réalité des entreprises est différente : l’environnement économique est soumis à des changements réguliers, les bonnes idées peuvent arriver après un certain temps, les projets sont souvent confrontés aux imprévus techniques ou métiers et la planification de l’incertain reste une tâche difficile à mener…
Autant de facteurs sources de changement que les méthodes traditionnelles ignorent. Des limites qui pénalisent fortement les projets des entreprises.
La méthodologie Agile SCRUM, une réponse aux limites des approches traditionnelles de type cycle en V
L’esprit fondateur de la démarche est la construction progressive du produit cible en commençant par les fonctionnalités à fort retour sur investissement (ROI), pour s’assurer au fil de l’eau de sa qualité, de sa cohérence avec les besoins de l’entreprise, tout en prenant les imprévus techniques, les évolutions du périmètre et les mutations du marché.
Un cadre de gouvernance articulé autour de 3 piliers, qui sont agencés et ordonnés dans un processus itératif
