Agile - Primer

Agile est une méthodologie de développement logiciel pour construire un logiciel de manière incrémentielle en utilisant de courtes itérations de 1 à 4 semaines afin que le processus de développement soit aligné avec les besoins changeants de l'entreprise. Au lieu d'un développement en un seul passage de 6 à 18 mois où toutes les exigences et les risques sont prédits à l'avance, Agile adopte un processus de rétroaction fréquente où un produit réalisable est livré après 1 à 4 semaines d'itération.

SDLC Agile vs traditionnel

Rôles dans Agile

Scrum Master

Un Scrum Master est un chef d'équipe et un facilitateur qui aide les membres de l'équipe à suivre des pratiques agiles afin qu'ils puissent respecter leurs engagements. Les responsabilités d'un Scrum Master sont les suivantes -

  • Pour permettre une coopération étroite entre tous les rôles et fonctions.

  • Pour supprimer tous les blocs.

  • Pour protéger l'équipe de toute perturbation.

  • Travailler avec l'organisation pour suivre les progrès et les processus de l'entreprise.

  • Pour garantir que les processus Agile Inspect & Adapt sont exploités correctement, ce qui comprend

    • Stand-up quotidiens,
    • Réunions prévues,
    • Démo,
    • La revue,
    • Réunions rétrospectives, et
    • Faciliter les réunions d'équipe et le processus de prise de décision.

Propriétaire du produit

Un Product Owner est celui qui conduit le produit du point de vue commercial. Les responsabilités ou le propriétaire d'un produit sont les suivants -

  • Définir les exigences et hiérarchiser leurs valeurs.
  • Pour déterminer la date de sortie et le contenu.
  • Pour jouer un rôle actif dans la planification des itérations et des réunions de planification des versions.
  • S'assurer que l'équipe travaille sur l'exigence la plus valorisée.
  • Représenter la voix du client.
  • Accepter les user stories qui répondent à la définition du fait et aux critères d'acceptation définis.

Équipe interfonctionnelle

Chaque équipe agile doit être une équipe autonome avec 5 à 9 membres et une expérience moyenne variant de 6 à 10 ans. En règle générale, une équipe agile comprend de 3 à 4 développeurs, 1 testeur, 1 responsable technique, 1 propriétaire de produit et 1 scrum master.

Équipe interfonctionnelle

Le Product Owner et Scrum master sont considérés comme faisant partie de Team Interface, tandis que les autres membres font partie de Technical Interface.

Comment une équipe agile planifie son travail?

Une équipe Agile travaille par itérations pour fournir des user stories où chaque itération dure de 10 à 15 jours. Chaque user story est planifiée en fonction de la priorité et de la taille de son backlog. L'équipe utilise sa capacité - combien d'heures sont disponibles avec l'équipe pour travailler sur des tâches - pour décider de l'étendue qu'elle doit planifier.

Planification

Point

Un point définit combien une équipe peut s'engager. Un point fait généralement référence à 8 heures. Chaque histoire est estimée en points.

Capacité

La capacité définit combien un individu peut s'engager. La capacité est estimée en heures.

Qu'est-ce qu'une User Story?

Une user story est une exigence qui définit ce qui est requis par l'utilisateur en tant que fonctionnalité. Une user story peut prendre deux formes:

  • En tant que <Rôle utilisateur>, je veux <Fonctionnalité> pour que <Valeur commerciale>
  • Afin de <Valeur commerciale> en tant que <Rôle utilisateur>, je veux <Fonctionnalité>

Lors de la planification des versions, une estimation approximative est donnée à une user story en utilisant l'échelle relative comme points. Lors de la planification des itérations, l'histoire est décomposée en tâches.

Relation entre les histoires d'utilisateurs et les tâches

  • L'histoire de l'utilisateur parle de ce qui doit être fait. Il définit ce dont un utilisateur a besoin.
  • La tâche explique comment cela doit être fait. Il définit comment une fonctionnalité doit être implémentée.
  • Les histoires sont implémentées par tâches. Chaque histoire est une collection de tâches.
  • La user story est divisée en tâches lorsqu'elle est planifiée dans l'itération en cours.
  • Les tâches sont estimées en heures, généralement de 2 à 12 heures.
  • Les histoires sont validées à l'aide de tests d'acceptation.
Relation entre les histoires d'utilisateurs et les tâches

Quand une histoire est finie

L'équipe décide de ce qui est fait . Les critères peuvent être -

  • Toutes les tâches (développement, tests) sont terminées.
  • Tous les tests d'acceptation sont en cours et réussis.
  • Aucun défaut n'est ouvert.
  • Le propriétaire du produit a accepté l'histoire.
  • Livrable à l'utilisateur final.

Qu'est-ce que les critères d'acceptation?

Les critères définissent la fonctionnalité, le comportement et les performances requis par une fonctionnalité afin qu'elle puisse être acceptée par le propriétaire du produit. Il définit ce qui doit être fait pour que le développeur sache quand une user story est terminée.

Comment les exigences sont-elles définies?

Les exigences sont définies comme

  • Une histoire d'utilisateur,
  • Avec des critères d'acceptation, et
  • Tâches pour mettre en œuvre l'histoire.