Qu'est-ce que Scrum ?

Scrum fait partie de la méthodologie agile. C'est le cadre le plus populaire pour le développement agile, et c'est un cadre de processus simple.

Un "cadre de processus" est un ensemble de règles qu'un processus doit suivre pour être conforme au cadre. (Par exemple, le cadre de processus Scrum prévoit des cycles de développement appelés Sprints, tandis que le cadre XP prévoit la programmation en binôme, etc.)

"Léger" signifie que le processus comporte aussi peu d'étapes supplémentaires que possible, de sorte que l'on puisse consacrer le plus de temps possible à l'accomplissement d'un travail utile. Un processus Scrum est différent des autres processus agiles parce qu'il utilise certaines idées et méthodes, que l'on peut classer en trois groupes : Les rôles, les artefacts et les boîtes de temps.

Scrum est le plus souvent utilisé pour gérer le développement de logiciels et de produits complexes en utilisant des méthodes itératives et incrémentales. Par rapport aux processus traditionnels "en cascade", Scrum fait une grande différence en ce qui concerne la quantité de travail effectuée et le temps nécessaire pour obtenir des résultats. Les processus Scrum permettent aux organisations de s'adapter facilement à des exigences qui changent rapidement et de fabriquer des produits qui répondent à des objectifs commerciaux changeants. Un processus agile Scrum aide l'entreprise parce qu'il lui permet :

• Améliorer la qualité des produits ;
• Mieux gérer le changement (et s'attendre à des changements) ;
• Les estimations sont plus précises et prennent moins de temps ;
• Être plus responsable du calendrier et de l'état du projet.

Quelles sont les exigences de Scrum ?

Scrum ne dit pas exactement à quoi doivent ressembler les exigences. Il indique simplement qu'elles doivent être intégrées au carnet de commandes du produit et sont appelées "éléments du carnet de commandes du produit", ou "PBI" en abrégé. Étant donné qu'un sprint a une durée déterminée, nous pouvons également supposer que la mise en œuvre de chaque ensemble devrait prendre beaucoup moins de temps que le sprint lui-même. La plupart des projets Scrum adoptent la méthode "Extreme Programming" (XP) qui consiste à appeler une demande de fonctionnalité une "User Story", mais un petit nombre de projets utilisent encore le terme plus ancien de "Use Case" (cas d'utilisation). Dans cet article de blog, nous irons dans le sens de ce que la plupart des gens pensent et nous parlerons de trois artefacts d'exigences assez standard que l'on peut trouver dans les backlogs de produits.

• Témoignage de l'utilisateur

  Sous la forme d'une histoire, une "histoire d'utilisateur" décrit la caractéristique souhaitée (exigence fonctionnelle). Les user stories sont généralement rédigées par le Product Owner, qui en est également responsable. Le format n'est pas standard, mais il comporte généralement un nom, un texte descriptif, des liens vers des documents externes (comme des captures d'écran) et des informations sur la manière dont la mise en œuvre sera testée.

• Histoire

  Toutes les exigences relatives à un nouveau développement ne sont pas tournées vers l'utilisateur, mais elles signifient toutes qu'il y a beaucoup de travail à faire. La plupart du temps, mais pas toujours, ces exigences sont des travaux qui doivent être effectués pour soutenir les fonctionnalités que les utilisateurs finaux voient. Nous appelons ces exigences qui n'ont rien à voir avec la fonction "Histoires techniques". Les histoires techniques ont les mêmes parties que les histoires d'utilisateurs, mais elles n'ont pas besoin d'être écrites comme des histoires si cela n'est pas utile. La plupart du temps, les membres de l'équipe écrivent les histoires techniques qui sont ensuite ajoutées au Backlog de produit. Le Product Owner doit connaître ces histoires et leur relation avec les User Stories afin de les classer (les ordonner) pour qu'elles soient construites.

• Insecte

  Un défaut, également appelé rapport de bogue, est une description de la manière dont le produit ne fonctionne pas comme il le devrait. Les défauts sont conservés dans un système de suivi des bogues, qui peut être ou non le même système que celui qui stocke le carnet de commandes. Si ce n'est pas le cas, le responsable de l'assurance qualité (généralement le propriétaire du produit) doit ajouter chaque défaut au carnet de commandes du produit afin qu'ils puissent être planifiés et classés dans le bon ordre.

Conclusion

Dans l'environnement mondial hautement compétitif d'aujourd'hui, le temps nécessaire à la mise sur le marché de nouveaux produits logiciels a été divisé par dix. Commençant par une étude de marché sur un concept ou les besoins d'un client, le cycle de vie du produit ou le processus de développement du système se poursuit jusqu'au déploiement et à l'exploitation du système. Le manifeste scrum est nécessaire pour développer rapidement un système et pour répondre aux changements d'exigences initiés par le client, même à un stade avancé du développement. Cela s'explique par la concurrence mondiale et l'évolution des besoins des clients, qui ont donné naissance au Manifeste Scrum. Scrum devient de plus en plus populaire et cette tendance devrait se poursuivre pendant de nombreuses années.