Version DevSecOps – Product Owner

Le Product Owner joue un rôle particulièrement important dans DevSecOps et la coordination des versions. Dans ce dernier article de blog sur DevSecOps et la coordination des versions, nous explorerons le personnage du Product Owner.

Jusqu'à présent, nous avons rencontré le coordinateur des versions, architecte de sécurité et le Coordonnateur des opérations . Avec ces trois autres membres clés de l'équipe de publication, le Product Owner est responsable de s'assurer que le produit a été construit selon les exigences. Cela comprend généralement ce que j'appelle «test à spectre complet» – test unitaire, fonctionnel, de régression, de sécurité, d'intégration, d'acceptation par l'utilisateur et de performance.

Dans mon post précédent sur DevSecOps and Release Coordination, j'ai défini le concept de «libération présumée». L'idée est que toutes les versions candidates sont ciblées pour un déploiement éventuel en production. Cela est logique étant donné que la valeur commerciale est dérivée d'un effort de développement une fois qu'il est livré aux mains des utilisateurs finaux. À cette fin, le Product Owner travaille en étroite collaboration avec les autres membres de l'équipe de publication afin de minimiser la quantité de frais généraux et d'approbations nécessaires pour fournir de la valeur. C'est le principal objectif de l'équipe de mise en production: garantir que les produits sont déployés en production de manière sûre, efficace et sécurisée.

Et donc, enfin et surtout, veuillez rencontrer Katie, notre responsable produit!

Introduction: responsable produit [19659006] En tant que Product Owner, j'ai la responsabilité et l'autorité sur mon produit, et mon rôle principal est de comprendre et de communiquer le comportement fonctionnel des applications en fonction des besoins commerciaux définis.

Je suis responsable de l'examen et de la hiérarchisation des demandes commerciales en ce qui concerne mon produit. Je coordonne régulièrement avec les parties prenantes de l'entreprise pour mettre à jour la stratégie produit et le positionnement en support aux objectifs commerciaux globaux. Pendant le développement, je travaille en étroite collaboration avec le responsable du développement pour dimensionner et attribuer le travail à des sprints spécifiques en fonction des ressources disponibles, des dates de sortie cibles et de la capacité de livraison de l'équipe. Pour le processus de libération, je suis responsable de m'assurer que la préparation du produit est complète pour la mise en production.

Figure 1. Propriétaire de produit DevSecOps Katie

Comme indiqué précédemment, il y a quatre clés requises états de préparation à la libération du système. Ces quatre statuts de produit garantissent à l'équipe de publication que le candidat logiciel a satisfait à toutes les normes définies pour la version de production. L'équipe de publication est composée du propriétaire du produit, du coordinateur des opérations, de l'architecte de la sécurité et du coordinateur des versions. Cette équipe représente le seul décideur de ce qui est et n'est pas mis en production. Comme illustré ci-dessous, le propriétaire du produit est ultimement responsable de s'assurer qu'un produit a été correctement évalué, testé et est prêt pour la production. Il convient de noter, cependant, que la plupart de l'évaluation sera menée par d'autres équipes, telles que l'équipe de développement effectuant le test de code et d'unité et le propriétaire de l'entreprise effectuant l'acceptation des utilisateurs. Le Product Owner est censé être impliqué dans toutes les activités d'assurance de la préparation du produit.

Figure 2. Exemple d'états de préparation à la publication

Lors de la réunion de coordination de la publication, le Product Owner passe en revue tous les tests et la vérification. résultats avec l'équipe de publication, discute de tout problème système en suspens et affirme que le produit est prêt pour la livraison.

Responsabilités relatives à l'utilisation des outils et au flux de travail

La propriétaire du produit peut utiliser un certain nombre d'outils dans l'exécution de ses fonctions. Certains des outils possibles sont présentés ci-dessous (par exemple Jira / Confluence pour les exigences et la collaboration). Les responsabilités du flux de travail sont également indiquées et comprennent la gestion du backlog, le nettoyage des priorités, la planification de sprint agile et le support de développement.

Figure 4. Planification et exécution du sprint du propriétaire du produit DevSecOps

Artefacts clés

Il existe plusieurs artefacts clés que le propriétaire du produit utilise, suit ou gère d'une autre manière:

• User Stories – Une description complète d'un comportement fonctionnel d'une application particulière. Définir (nom et description de base) et les détails (éléments de données, comportement commun, gestion des exceptions, conception d'interface) à un degré suffisant pour l'estimation, le développement et les tests.
• Demandes commerciales – Ces demandes sont collectées séparément de l'utilisateur histoires et évaluées par le propriétaire du produit par rapport à la vision, au budget et au calendrier de livraison du produit.
• Stratégie / vision du produit – Il s'agit d'une description générale d'un produit logiciel particulier, tel qu'un site Web ou une collection d'API. . La stratégie de produit décrit l'objectif du produit / de l'application, le public cible, la valeur apportée à l'organisation, la vision à court et à moyen terme de l'amélioration du produit et une description détaillée du comportement fonctionnel.
• Journal des tâches prioritaire – Il s'agit d'une collection d'éléments de travail (c'est-à-dire des tâches ou des user stories) qui sont hiérarchisés dans un seul carnet de travail. Le responsable du développement et le propriétaire du produit travaillent ensemble pour intégrer les éléments du carnet de commandes dans la planification du sprint.
• Planification du sprint – La planification du sprint est l'élément central du développement agile. Un contenu de sprint est généralement développé au moins un sprint avant le travail en cours. Le but est de garantir que l'équipe se voit attribuer un travail prioritaire en fonction du niveau d'effort attendu, de la capacité de l'équipe, du nombre de ressources et de la durée du sprint (par exemple 2 semaines).

Conclusion

Il devrait être clair à ce stade que la coordination des versions est un aspect essentiel du développement logiciel. Sans un moyen de régir le processus de publication, il est inévitable que l'augmentation de l'intégration du système entraîne des problèmes. Cependant, il est également nécessaire de garantir des pratiques de publication agiles pour permettre un développement et une livraison rapides de la valeur commerciale. Dans ces articles de blog, j'ai présenté une telle approche pour équilibrer ces deux forces opposées – la gouvernance et l'agilité. L'utilisation de divers personnages DevSecOps illustre non seulement le rôle / la responsabilité des membres de l'équipe, mais aussi comment et quand ils interagissent. J'espère que ces articles vous aideront dans votre parcours DevSecOps!