Features et Capabilities

Il y a une innovation sous Linux. Je suis fier de certaines caractéristiques techniques très utiles. Il existe des fonctionnalités sous Linux qui ne sont pas disponibles dans d’autres systèmes

—Linus Torvalds, créateur de Linux

Features et Capabilities

Une Feature est un service qui répond à un besoin des parties prenantes. Chaque fonctionnalitré inclut une hypothèse d’avantage et des critères d’acceptation. Elle est dimensionnée ou fractionnée selon les besoins pour être livrée par un seul Agile Release Train (ART) dans un incrément de programme (PI).

Une Capability est un comportement de solution de niveau supérieur qui couvre généralement plusieurs ART. Les capacités sont dimensionnées et divisées en plusieurs fonctionnalités afin de faciliter leur mise en œuvre dans un seul PI.

Les fonctionnalités se prêtent également au modèle de processus Lean UX, qui inclut une définition de la fonctionnalité minimale commercialisable (MMF), une hypothèse d’avantage et des critères d’acceptation. Le MMF aide à limiter la portée et l’investissement, améliore l’agilité et fournit un retour rapide. Les fonctionnalités se comportent de la même manière que les fonctionnalités. Cependant, ils sont à un niveau d’abstraction plus élevé et soutiennent la définition et le développement de grandes solutions.

Détails

Les Features et les capabalities sont au cœur du modèle de spécifications SAFe. Ils sont essentiels à la définition, à la planification et à la mise en œuvre de la valeur de Solution. La figure 1 illustre le contexte plus large de ces éléments de travail:

Figure 1. Fonctionnalités dans le contexte SAFe

La figure 1 montre que les solutions sont développées à l’aide de fonctionnalités. Chacun reflète un service fourni par le système qui répond à un besoin important des parties prenantes. Ils sont conservés dans le backlog du programme et sont dimensionnés pour tenir dans un PI afin que chacun apporte une nouvelle valeur. Les fonctionnalités peuvent provenir soit du contexte local de l’ART, soit de la division d’Epics ou de capacités.

Les Program et Solution Kanban prennent en charge le flux de fonctionnalités et de capacités, en passant par l’état de cheminement, l’analyse, backlog, la mise en œuvre, la validation, le déploiement et les états de version. Ce processus fournit une analyse économique raisonnée, un impact technique et une stratégie pour une mise en œuvre progressive.

Le Product Management et System Architect/Engineering système possèdent les fonctionnalités et les outils, respectivement. Les exigences non fonctionnelles (NFR) définissent des attributs système tels que la sécurité, la fiabilité, les performances, la maintenabilité, l’évolutivité et la convivialité. Les NFR servent de contraintes ou de restrictions à la conception du système pour les différents backlogs. Les Features sont classées par ordre de priorité en utilisant le travail le plus court pondéré en premier (WSJF) et sont planifiées et revues aux limites des PI. Ils sont divisés en récits et sont implémentés, intégrés, testés et démontrés à mesure que la fonctionnalité devient disponible.

Description des fonctionnalités

Les Features sont définies à l’aide d’une matrice de fonctionnalités et avantages (FAB):

• Feature – Une courte phrase donnant un nom et un contexte
• Hypothèse de bénéfice – Le bénéfice mesurable proposé pour l’utilisateur final ou l’entreprise

Évitez de définir des fonctionnalités avec le format «voix de la user story» conçu pour prendre en charge un rôle d’utilisateur; les fonctionnalités fournissent généralement des fonctionnalités pour plusieurs rôles d’utilisateur. En outre, l’utilisation de la même méthode pour décrire des user stories et des fonctionnalités peut être source de confusion pour l’entreprise, d’autant plus qu’elle ne connaît généralement pas les stories.

La figure 2 illustre un exemple de FAB avec quatre caractéristiques différentes:

Figure 2. Matrice des caractéristiques et avantages

Création et gestion de fonctionnalités

Les Products Managers, en collaboration avec les Products Owners et d’autres parties prenantes clés, définissent les caractéristiques dans le contexte local d’un ART. Certains résultent de la division des épopées.

Les System Architects créent généralement des enabler feature. Le backlog du programme est utilisé pour maintenir les enablers parallèlement aux features métiers. Les enablers ouvrent la piste architecturale et soutiennent l’exploration, ou peuvent fournir l’infrastructure nécessaire pour développer, tester et intégrer l’initiative.

Tout comme les fonctionnalités professionnelles, les fonctionnalités enabler peuvent provenir d’épopées ou émerger localement au niveau de l’ART. Les enablers qui traversent le système Kanban seront soumis à une allocation de capacité dans le backlog de programmes afin de garantir que l’accent soit suffisamment mis sur le développement de la solution et l’extension de la piste architecturale. À chaque limite d’IP, le pourcentage de ressources à affecter aux nouvelles fonctionnalités (ou capacités) par rapport aux facilitateurs est estimé pour guider le train.

Prioriser les fonctionnalités

Le modèle de hiérarchisation WSJF est utilisé pour séquencer les travaux (par exemple, features, capabalities) en fonction de l’économie du flux de développement du produit. Étant donné que la mise en œuvre des bons emplois dans le bon ordre produit le maximum d’avantages économiques, il est difficile de surestimer l’importance de ce processus critique.

Product et Solution Management a le pouvoir de hiérarchiser les fonctionnalités, tandis que les architectes de systèmes et de solutions et les ingénieurs ont le pouvoir de hiérarchiser les fonctionnalités enabler.

Caractéristiques d’estimation

L’estimation des fonctionnalités permet de prévoir la livraison de valeur, d’appliquer la hiérarchisation WSJF et de dimensionner les épopées en les divisant en entités et en additionnant leurs estimations individuelles. L’estimation des fonctionnalités se produit généralement dans l’état d’analyse du programme Kanban et repose sur des techniques d’estimation normalisées, similaires à celles utilisées par les équipes Agiles (voir l’article sur la planification des itérations pour plus de détails). Au cours de l’analyse, des experts en la matière de l’ART participent à des activités d’exploration et de dimensionnement préliminaire. Lors de l’état d’analyse, les fonctionnalités de dimensionnement ne nécessitent pas de les scinder en récits ou l’inclusion de toutes les équipes susceptibles de les développer.

Accepter les fonctionnalités

Les critères d’acceptation permettent de déterminer si la mise en œuvre est correcte et offre les avantages pour l’entreprise. La figure 3 en donne un exemple:

Les critères d’acceptation atténuent le risque de mise en œuvre et permettent une validation rapide de l’hypothèse de bénéfice. De plus, les critères d’acceptation sont généralement à l’origine de plusieurs récits, ainsi que de tests fonctionnels, développés et automatisés pour prendre en charge les tests de refactorisation et de régression. Bien que généralement appliqué aux articles, le développement piloté par le comportement (BDD) crée un meilleur alignement et des tests d’acceptation détaillés des fonctionnalités.

Product Management est responsable de l’acceptation des fonctionnalités. Ils utilisent des critères d’acceptation pour déterminer si la fonctionnalité est correctement implémentée et si les exigences non fonctionnelles sont remplies.

Les capacités

La majeure partie de cet article est consacrée à la définition et à la mise en oeuvre des fonctionnalités, car elles constituent la description la plus courante du comportement du système. Les fonctionnalités présentent les mêmes caractéristiques et pratiques que les fonctionnalités. Par exemple, ils:

• Sont décrits en utilisant une hypothèse de phrase et de bénéfice
• Sont dimensionnés pour s’intégrer à un PI, cependant, ils ont souvent besoin de plusieurs ART
• Sont raisonnés et approuvés à l’aide de la solution Kanban. Le backlog de solutions contient des fonctionnalités approuvées
• Avoir des enablers associés pour décrire et apporter de la visibilité à tous les travaux techniques nécessaires pour soutenir un développement et une mise à disposition efficaces des capacités de l’entreprise
• Sont acceptés par les Solution Managers, qui utilisent les critères d’acceptation pour déterminer si la fonctionnalité est adaptée à l’utilisation

Les capacités peuvent provenir du contexte local de la solution ou résulter de la séparation d’épopées de portefeuille pouvant couvrir plusieurs flux de valeur. Le contexte de la solution est une autre source potentielle de fonctionnalités, dans laquelle certains aspects de l’environnement peuvent nécessiter de nouvelles fonctionnalités.

Division des fonctionnalités et des capacités

Les Capabalities doivent être décomposées en fonctionnalités à implémenter. Ils sont à leur tour divisés en histoires consommables par les équipes au sein d’une itération. SAFe fournit dix modèles pour le travail de fractionnement, comme décrit dans Leffingwell [1], chapitre 6.

1. Étapes de workflow
2. Variations de règles commerciales
3. Effort majeur
4. Simple / complexe
5. Variations de données
6. Méthodes de données
7. Différer les qualités du système
8. Des opérations
9. Scénarios d’utilisation
10. Sortir un pic

La figure 4 illustre la division d’une capacité en fonctionnalités.

Apprendre encore plus

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

© Scaled Agile, Inc.