Former l'équipe agile - Série d'entraînement agile Partie 2

1. Forming de l'introduction de l'équipe agile: Bonjour, je suis Teresa Bennett, et voici la deuxième partie de la série de formation Agile pour les analystes d'affaires. Et cette partie de la série, nous allons envisager de former l'équipe Agile. Il y a quatre sujets que nous aborderons dans cette formation. Le premier est les unités de l'équipe. Nous allons parler de l'unité opérationnelle et de l'unité de développement, et de quels secteurs de l'organisation appartiennent à chacune de ces unités. Quand nous parlons de notre équipe et de rassembler les gens qui feront partie de cette équipe Agile. Ensuite, nous allons examiner les rôles des membres de l'équipe et déterminer quels rôles sont assumés par les personnes de ces deux unités. Ensuite, nous passerons aux meilleures pratiques pour l'équipe. Qu' est-ce que nous devons faire de façon constante pour assurer le succès de notre équipe ? Pour chaque sprint et chaque projet que nous réalisons. Ensuite, nous parlerons de votre équipe, votre rôle au sein de votre équipe Agile et des changements d'état d'esprit dont vous pourriez avoir besoin pour passer une commande pour réussir dans une équipe Agile. Et ce que la flexibilité signifie pour vous lorsque vous travaillez dans un environnement agile. Alors rejoignez-moi dans la prochaine vidéo et commençons. 2. Unités de l'équipe Agile: Deux unités forment l'équipe Agile. abord, nous avons l'unité face au client, que vous pouvez également considérer comme l'unité commerciale. Les personnes qui forment cette équipe sont, tout d' abord, le client, qui est le sponsor du projet. Vous avez également l'équipe marketing, qui est l'équipe marketing de votre entreprise ou l'entreprise pour laquelle le produit est destiné. Si votre entreprise est une société d'experts-conseils et qu'elle a été amenéeà participer à un projetdans à participer à un projet autre organisation que l'équipe de marketing de cette organisation. Le responsable de produit est la personne qui gère les opérations du produit. Et ils font également partie de l'unité orientée client. Et puis, bien sûr, nous avons les cadres que je considérerais comme n'importe qui de niveau directeur ou supérieur. Nous avons également le CMMI, qui sont des experts en la matière. Ce sont les personnes qui travaillent avec AND OU soutiennent le produit. Donc ce sont eux qui travaillent vraiment avec elle jour après jour et qui connaissent vraiment tous les écrous et boulons du produit. Ils sont donc en mesure de répondre à vos questions sur comment faites-vous ça ? Que se passe-t-il si un client le demande ? Comment traversez-vous ce processus ? Ils devraient pouvoir répondre à ce genre de questions. Nous avons également des intervenants dans le cadre de l'unité axée sur les clients. Ce sont des personnes ou des groupes qui ont quelque chose à gagner ou à perdre du résultat de votre projet. La raison pour laquelle je mentionne quelque chose à perdre ici est de penser cela en termes de quand vous faites une mise à jour d'un processus, il y a parfois des choses qui sont supprimées du processus car nous rendons les choses plus efficaces. Et cela peut prendre des mesures qu'un groupe particulier de personnes faisait ou prendre un processus tout à fait que le groupe faisait. Donc, un détenteur de pieu qui perd quelque chose pourrait être un groupe qui n'aura plus à remplir une fonction parce que les changements apportés rendent les choses plus efficaces et que cette fonction n'est plus nécessaire. Et puis, bien sûr, il pourrait y avoir d'autres personnes impliquées selon ce qu'est le projet. Vous pourriez donc avoir besoin de considérer les représentants du service à la clientèle, personnel des ventes, peut-être les réceptionnistes. Si, par exemple, le logiciel est peut-être un système de réservation d'hôtel. Donc, vous auriez des employés de réception, n'importe lequel de ces gens que vous pourriez avoir à penser qui pourraient être inclus soit lisse ou un autre groupe de personnes qui pourraient avoir besoin d'être impliqués dans le projet et puis d'autres gestionnaires de produits et parties prenantes. Alors, qui d'autre pourrait être impliqué en dehors des parties prenantes que vous avez déjà pensé ? Y a-t-il d'autres personnes qui pourraient être touchées ? Voyons maintenant qui est inclus dans l'unité de développement. Nous avons, bien sûr, les développeurs, non ? Ce sont les gens qui codent. Ils développent l'application. Ils apportent des modifications au logiciel, l'analyste d'affaires. C' est donc la personne qui détaille les histoires pendant les séances de toilettage avec l'unité d'affaires. Donc, si vous êtes l'analyste d'affaires, alors. C' est là que la majeure partie de votre travail se fera au sein de l'équipe Agile. Qa est également impliqué dans l'unité de développement. Donc, l'équipe d'assurance qualité est les personnes qui font des tests de logiciels, tests de procédures, des tests de flux de processus, tout autre chose que les tests unitaires, ce qui est généralement fait par les développeurs parce qu'ils testent leurs propres avant qu'ils ne le retournent. Donc, les tests unitaires ne sont pas inclus dans l'assurance qualité, cela fait partie de la fonction développeur. Mais tout autre test qui se passe est généralement inclus dans le menton alimentaire de l'assurance qualité, puis dans le gestionnaire de projet. Le gestionnaire de projet peut être séparé du Scrum Master. Ou le chef de projet peut aussi être discriminatoire. Ou j'ai vu cela dans les deux sens dans différentes organisations dans lesquelles j'ai travaillé. Cela dépend donc uniquement de la façon dont votre organisation est mise en place et de la manière dont elle définit les rôles et les responsabilités au sein de son organisation. Ainsi, vous pouvez avoir un rôle combiné où le gestionnaire de projet et le maître de mêlée ou la même personne, ou étaient-ils des rôles distincts assumés par deux personnes différentes. Ensuite, nous avons les rédacteurs techniques et ou les rédacteurs de manuels de formation. Ils sont responsables de la création de la documentation technique et de la documentation de formation. La documentation de formation peut être effectuée par l'unité cliente. Il se peut donc que quelqu'un de l'unité opérationnelle soit chargé de rédiger le manuel de formation. Encore une fois, cela dépend uniquement de la façon dont l'organisation est mise en place au sein de l'entreprise dans laquelle vous travaillez. J' ai donc travaillé dans des organisations où ils n'ont pas eu un rédacteur de manuel de formation dédié. Ainsi, l'équipe technique qui a fait la rédaction technique a également créé le matériel de formation. Et j'ai aussi travaillé dans des organisations où l'unité opérationnelle, c'est vrai, l'unité en contact avec le client avait une équipe de formation et est quelqu'un pour rédiger le matériel de formation. Ça dépend donc de la façon dont ils sont mis en place. S' ils ont une personne pour créer le matériel de formation dans le cadre de l'unité axée sur les clients, ils seraient inclus dans ce domaine plutôt que dans l'unité de développement. Ensuite, nous avons notre UX et concevons des gens créatifs. Ce sont donc les personnes qui définissent l'aspect et la sensation de l'application et de l'expérience utilisateur. Ensuite, nous avons les spécialistes de l'architecture qui sont également inclus dans l'unité de développement parce que nous parlons d'architecture système, architecture de base de données. Il s'agit plus de l'architecture technique que de tout ce qui serait lié à l'entreprise. Et puis on a un autre genre d'autre catégorie, non ? Donc, tout autre personnel informatique ou I S qui est nécessaire à la réussite du projet. Encore une fois, cela dépend de la façon dont votre organisation est mise en place et de la destination de ce projet particulier, ainsi que autres unités qui pourraient être impliquées dans ce projet particulier. 3. Rôles d'équipe: Ensuite, jetons un coup d'oeil aux rôles de l'équipe. Nous allons donc parler de qui est responsable de quoi pour les deux unités dont nous venons de parler, l'unité axée sur les clients et l'unité de développement. Chacune de ces personnes a certaines responsabilités au sein de l'équipe. Donc, pour l'unité face au client, ils sont responsables de la vision du produit et de la feuille de route. Ils sont également responsables de la gestion de l'arriéré de produits, qui est la portée, mais considèrent cela comme la portée du projet. Que faisons-nous pour ce projet ? On s'attend à ce qu'elles soient préparées avec des détails au moment opportun. Donc, à tout moment que l'équipe de projet a besoin de détails spécifiques liés à n'importe quoi pour les fonctions d'affaires du projet. Ils doivent être prêts à répondre à ces questions. Ils doivent établir des attentes claires en matière d'acceptation, signifie qu'ils doivent s'assurer que toute l'équipe comprend ce à quoi ils attendent lorsqu'ils diront que ce qui a été développé et construit répond à leurs attentes. Ils doivent donc nous dire dès le départ quelles sont ces attentes pour que nous construisions pour répondre à ces attentes. Que l'espoir est avant que nous arrivions au point où nous rétrogradons un produit à eux. Ils disent oui, c'est comme ça que je m'attendais à ce que ça soit. Et bien sûr, ils sont très impliqués dans la communication au sein de l'équipe non seulement en définissant et en aidant l'équipe à comprendre ce qu'elle veut, mais aussi en communiquant tous les changements et leurs commentaires à ce qui est créé et construit pour eux. L' unité de développement est responsable de l'estimation, ce qui signifie qu'elle doit avoir une bonne maîtrise pour estimer le temps qu' il leur faudra pour terminer tout ce qui est dans le cadre du projet. Ils sont responsables de la planification et de l'engagement pour l'itération. Ainsi, une itération est également connue sous le nom de sprint dans le monde Agile. Et un Sprints dure généralement deux semaines, peut-être trois semaines. J' ai vu certaines organisations faire des sprints de quatre semaines. Cependant, je mets en garde contre eux parce que vous commencez à passer à un état d'esprit plus en cascade lorsque vous entrez dans un sprint qui dure quatre semaines ou même plus longtemps que cela. Donc le meilleur délai pour un sprint est de deux semaines ou trois semaines, mec. Et pendant ce sprint, ou ce que l'on pourrait appeler une itération, l'espoir est que l'unité de développement soit capable de planifier ce qu'elle va faire pendant cette itération et de s'engager à cela, puis sortir de la autre extrémité de cela avec ces choses terminées. Évidemment, ils vont devoir exécuter l'itération, non ? Donc, après avoir planifié et engagé ce qu'ils vont faire, ils doivent être en mesure d'exécuter cela et d'accomplir les tâches qui doivent être effectuées. Et après ça, c'est là que vient la démo que j'ai mentionnée avant quand je parlais de l'unité commerciale. Donc, l'équipe de développement va faire une démo à la fin que pour sprint pour montrer ce qui a été accompli pendant cette période. Et si la communication s'est bien déroulée, et que tout le monde a eu la même compréhension que ce qu'ils voient dans la démo devrait être ce qu'ils attendaient de voir. Et donc, ils devraient dire : oui, j'accepte cela parce qu'il a été construit comme nous l'avions prévu. Et bien sûr, ils sont censés fournir une communication claire pendant chacun des sprints jusqu'à la fin du projet. 4. Meilleures pratiques et votre équipe: Parlons maintenant des meilleures pratiques de l'équipe. Nous voulons commencer en équipe et finir en équipe. Ce que nous entendons par là, c'est quand vous commencez sur un projet pour tout le monde est très excité à ce sujet. Poudre à canon comme oui, nous allons faire ce truc où à bord avec ça, nous ne voulons pas entrer dans un cycle où nous sommes excités par les choses. Et puis nous entrons dans une itération et nous commençons à travailler à travers elle et des problèmes surgissent. Et au moment où nous avons terminé cette itération dans cette période de deux ou trois semaines. Et on arrive à la fin, tout le monde pointe du doigt et dit, eh bien, on n'a pas fait ça parce que ce n'était pas clair. Et on n'a pas fait ça parce que cette personne n'a pas fait ça. Nous voulons commencer en équipe et finir en équipe. Et ce que cela signifie, c'est que pendant toute cette période de deux à trois semaines, nous travaillons ensemble et collaborons ensemble. Nous soulevons des problèmes qui surgissent et nous les résolvons ensemble pour terminer ce sprint. Toujours ensemble en équipe et on ne se sépare pas. Et avoir ces choses arriver qui peuvent briser cela et causer la mauvaise volonté pendant une équipe. La communication est donc essentielle tout au long du processus afin que l'équipe reste cohésive et travaille ensemble. Et une partie de cela est le numéro deux, qui est une communication ouverte et honnête. Si vous manquez quelque chose, si vous avez un barrage qui vous empêche de faire quelque chose. Nous devons être capables de parler de ces choses et de trouver des solutions à ces choses. Le numéro trois est inspecter et adapter. Donc, ce que cette meilleure pratique signifie, c'est que nous examinons toujours ce que nous faisons, réfléchissons à la façon dont nous pouvons le faire mieux, puis nous adaptons et apportons ces changements à l'avenir. Ce qui nous amène au numéro quatre, qui est l'amélioration progressive du produit et du procédé. Pour que nous puissions améliorer le produit, c'est-à-dire ce que nous livrons, nous devons toujours améliorer nos processus. Donc, au cours de cette communication ouverte et honnête, de l'inspection et de l'adaptation, nous voulons améliorer nos processus afin améliorer le produit que nous livrons à votre équipe. Parlons donc de vos attentes. Quelles attentes avez-vous lorsque vous travaillez sur une équipe Agile ? Quels changements et l'état d'esprit doivent être faits lorsque vous passez de la cascade à une approche agile. L' une des choses pour moi, probablement la plus grande chose pour moi était de comprendre et d'être d'accord avec le fait que je ne vais pas tout savoir à la fois. Donc, lorsque vous travaillez avec, dans un environnement de cascade, vous remplissez toutes les exigences. Vous pouvez donc travailler dans la phase d'analyse d'un projet. Quatre. Certainement pendant des semaines à la fois, parfois des mois à la fois, selon la taille du projet. Et au moment où vous arrivez à la fin de la phase d'analyse, vous connaissez ce produit à l'intérieur maintenant. Vous y travaillez depuis si longtemps que vous êtes maintenant devenu CMMI pour le produit. Et avec Agile, vous n'allez pas être là à la fin d'une itération, à la fin d'un sprint, n'est-ce pas ? Tout ce que vous allez vraiment être à l'aise avec et connaître ce sont les exigences, c'est-à-dire les histoires qui ont été terminées et travaillées pendant ce sprint. Donc, vous construisez vos connaissances en même temps, l'équipe de développement développe ses connaissances. Et c'était probablement le plus grand changement que j'ai dû faire dans mon état d'esprit était d'être accord avec le fait que je n' allais pas savoir tout ce que j'allais apprendre en cours de route, avec tout le monde. L' autre chose avec laquelle vous devez être à l'aise est la flexibilité. Donc sauter là où on a besoin de vous. Une des choses qui fonctionne vraiment bien dans un environnement agile que nous n'avons pas beaucoup d' occasions de faire dans un environnement de cascade est de sauter et d'aider dans d'autres domaines. Parce que dans un environnement de chute d'eau, vous êtes tellement concentré sur tout faire en un seul temps. finissez toutes les exigences, vous faites, toute votre documentation. Donc, vous avez toutes vos sessions de besoins. Vous créez toutes vos exigences. Vous créez tous vos flux de processus. Vous créez tous vos diagrammes de flux de données, n'importe quel type de documentation que vous avez à le faire, des cas d'utilisation, peu importe ce qu'il est, vous faites le tout. Donc, vous êtes très concentré sur tout ça. Ce qu'il faut faire dans ce monde. Et vous avez des oeillères parce que vous devez, pour passer à travers tout ça. Cependant, dans un monde agile, vous avez un peu plus de flexibilité parce que vous êtes seulement concentré sur un certain morceau de travail à la fois. Et cela vous laisse la capacité d'ouvrir les yeux et de voir ce qui se passe autour de vous et ce sur quoi le reste de l'équipe est concentré et d'entendre les défis que vous avez et peut-être comprendre comme s'ils avaient un barrage routier ou un défi avec cette chose. Même si cela ne fait pas partie de mes tâches quotidiennes, je sais comment vous aider. Je peux les aider à surmonter ce barrage. Et tu peux parler et dire, tu sais quoi, je peux t'aider avec ça. Donc, être flexible et prendre cela en considération et prendre ces mesures pour aider vos coéquipiers est une autre chose que vous apprenez à faire et à vous mettre à l'aise dans un monde agile. Votre projet pour cette classe est de documenter les attentes que vous avez pour travailler sur un projet Agile et les changements et esprit que vous pensez personnellement devoir faire si vous passez d'un environnement de cascade à un environnement agile ou si vous êtes nouveau à Agile et que vous n'avez pas travaillé sur Waterfall auparavant. Donc, vous n'avez pas forcément de changement à faire. Ensuite, listez trois choses que vous jugez nécessaires à un état d'esprit réussi, pour un environnement de travail agile.