La méthode agile expliquée - Comprendre les principes de base du développement de logiciel agile

1. Introduction: Bonjour. m'appelle Stephen Holt accueille par cause que je John a expliqué que je suis un leader de développeur de logiciels qui est plus de 25 ans. Expérience comme une industrie. Je suis également formateur en ligne que chaque salle de classe ateliers partout dans le monde et ainsi que tout ce que je suis un poppet, conférencier et auteur récemment créé. Ce cours est dû à ma carrière. J' ai passé beaucoup de temps à travailler dans des entreprises qui croient être agiles. Tu y vas. Vous observez cela, en veillant à ce qu'ils ne défilent pas les restaurations, ce qui peut interdire les planches et les histoires. Mais alors, quand un changement devient une exigence, un peu de l'enfer se lâche. Et tu connais ce genre de panique. Alors, oh mon Dieu, les choses changent ce que nous allons faire. Les gens doivent aller voir les meilleurs départements pour obtenir leur approbation. Ils pourraient généralement être tout à fait un gâchis sur son pas ivre. Ce n'est pas le but de nos emplois. Donc, dans ce cours sur la bande loin. Beaucoup de méthodologie de gestion de projet est que ce cours n'est pas sur la mêlée. Il ne s'agit pas de programmation extrême. Que vous parliez brièvement, cette cour est en fait sur les principes fondamentaux de l'agile ce que signifie être une blague et à condition que vous suiviez ces valeurs fondamentales, alors vous pourriez être agile. Peu importe si tu fais de l'EXP de mêlée ou quoi que ce soit. Les dernières méthodologies préférées. Pourquoi suivez-vous ces quatre valeurs fondamentales ? Alors tu pourrais être un boulot. Alors avec ça, commençons. Si vous aimez le cours, je vous serais très reconnaissant si vous pouviez me suivre. Je vois certaines de mes causes futures. Aussi, si vous aimez le cours, je serais très reconnaissant si vous pouviez fermer sur Twitter quand il pour la taille des médias sociaux être fantastique. Alors avec ça, commençons. 2. Histoire des cascades: bonjour et bienvenue à ma cause, explique Agile. Je suis ton hôte, même les cornes dans son cours. Nous allons examiner les principes fondamentaux du développement de logiciels agiles et dissiper certaines idées fausses courantes. Ce n'est pas un cours sur le scrum ou le programme extrême dans, car ce ne sont que des techniques pour faciliter le développement de logiciels agiles. Ce cours porte sur les principes fondamentaux auxquels toutes les équipes agiles doivent adhérer. Commençons par regarder l'eau plus traditionnelle pour le processus de développement de logiciels et ses problèmes. Si vous ne travaillez pas dans une entreprise agile, probable que vous travailliez sur une forme d'eau pour le développement de logiciels dans sa première section. Nous allons examiner à quoi sert l'eau et identifier ses principaux problèmes, qui nous amènera à parler plus en détail de l'agile. La méthodologie de développement des chutes d'eau a été introduite par l'informaticien Winston Royce en 1970. Winston Royce a d'abord discuté de l'idée du développement logiciel agile dans un article intitulé Managing the Software Developments of Large Software Systems. Royce ne faisait pas directement référence au modèle dans ses papiers. Guerres pour les développements. Cet article était sur le processus qui était défectueux pour les développements logiciels, était sa conception originale en fait montré plus de répétition entre les étapes du modèle, ce qui était pour ne pas laisser You do Winston Voices. Modèle réel était plus intuitif dans la façon dont il fonctionne sur permis plus de marge de manœuvre entre les étapes. Nous discuterons d'une façon plus fréquente de travailler avec moi. Discutez d'Agile plus tard dans ce cours. Bien que la voix ne se réfère pas à ce modèle était des prix pour Model directement, il est crédité de la première description de ce que nous avons fait référence est le modèle de cascade. L' article original de la Russie se compose des étapes suivantes, qui iront plus en détail dans un instant. Les étapes sont les spécifications de l'étape de la conception détaillée, intégration de la phase de construction, essais et l'argent dans l'installation et la maintenance. Donc ce n'est pas le cas. Jetez un oeil à la façon dont le modèle de cascade fonctionne réellement. 3. Comment fonctionne la chute à l'eau ?: en cascade. Le processus est divisé en étapes distinctes, où le résultat d'une étape entrera dans l'étape suivante. La première étape dans l'eau a été commencée par des exigences couvrant toutes les exigences. Analyse. Lorsque toutes ces exigences pour le système en cours de développement sont consignées dans nos spécifications. Documents, exigences, spécifications. Ensuite, soyons signés par un autre intervenant du projet, généralement de l'entreprise. Il est de la responsabilité de l'analyste d'affaires sur le projet de créer les documents d'exigences . Si vous attendez sur une équipe plus petite, que cela pourrait être fait est une collaboration entre les membres de l'équipe à cette étape du cycle de cascade avec des analystes d'affaires ou des personnes directement dans un document, essayez de saisir toutes les exigences et caractéristiques du système provenant des principales parties prenantes de l'entreprise. Cela pourrait inclure l'ensemble complet des fonctionnalités Toute entreprise, n'était-ce pas l'automatisation et vous avez ensuite des processus opérationnels du point de vue de l'entreprise et de la réglementation . L' assistant de l'étape suivante concevoir les spécifications des exigences de la première étape ou inspecté et les concepteurs assistants mis en place. C' est Ryan qui a aidé à préciser les exigences de conception et a également contribué à créer dans l'architecture ovale des systèmes. Dans cette étape, ce sont des membres techniques de l'équipe, qui comprend des développeurs et des architectes qui décident comment le système global sera construit. Une fois qu'un système conçu face est terminé, nous passons à la phase de mise en œuvre. C' est là que les développeurs de l'équipe prennent la conception précédente du logiciel et commencent écrire le code pour le faire fonctionner après la face d'implémentation où ils passent à la phase d'intégration et de test. C' est là que l'équipe de test réunira tous les composants du système et le tester est un seul produit. À ce stade, l'équipe de test devrait disposer d'un plan de test détaillé auquel elle travaille même en effectuant des tests manuels ou en développant des tests automatisés. Une fois que l'équipe d'essai a terminé son travail et approuvé, le système est en bon état. Il est alors prêt à être déployé pour les utilisateurs finaux. Vous pouvez commencer à voir les avantages une fois qu'une solution a été déployée en production, puis passer à une phase de maintenance pendant cette période. Si les utilisateurs finaux signalent des défauts dont ils auront besoin pour être corrigés, les tests ont été redéployés en production. Si l'un de ces chiffres finit par avoir une portée très importante, on pourrait décider redémarrer la cascade en redéfinissant les exigences. La conception de l'implémentation, test puis le redéploiement si cela n'arrive que peut prendre beaucoup de temps, qui ne se prête pas à corriger cela a dû être fait de toute urgence. 4. Où les Waterfall sont adaptables ?: alors que dans le monde Adroll, on insiste beaucoup sur le fait que l'eau ne convient pas. Il y a, cependant, certains projets quand, quoi pour la méthodologie est appropriée. Jetons un coup d'oeil à quelques-uns. Tout d'abord, ce qui est approprié si les exigences de votre projet logiciel ont déjà bien défini documenté. Mais en réalité, quelle fréquence est-ce le cas de mes propres expériences ? Concepteur et développeur de logiciels, je ne me souviens pas d'aucun des nombreux projets que j'ai livrés où les exigences ont été claires dès le début afin qu'ils puissent être capturés dans le document qui ne change pas est un projet roule sur la prochaine la définition du produit doit être stable. Ok, et je ne peux pas penser à un seul projet où c'est le cas pour May. En tant que facteurs externes comme le changement de marché ou le changement d'entreprise, les priorités signifient que votre produit évoluera. J' ai travaillé sur de nombreux projets où le produit final de livraison était complètement différent de ce qui était initialement spécifié sous l'eau, car cela ne devrait pas se produire. Mais en réalité, ce que vous construisez ne peut rien changer de mal avec ces bébés. C' est la lutte contre un processus de livraison de logiciels. Ensuite, la technologie devrait être bien comprise. Cela signifie que les développeurs doivent comprendre la technologie qui va être utilisée et comment ils fonctionnent. Une fois que vous êtes allé à la mise en œuvre de la phase de construction du projet, les développeurs doivent généralement travailler vers des délais très rigides et fixés. Selon mon expérience, travailler sur l'eau pour le projet, beaucoup d'efforts sont expulsés des exigences et de la phase de conception, qui mange normalement dans le temps nécessaire pour réellement développer le code. Suivant cascade fonctionne mieux sur les projets sont à court. En bref, je veux dire des projets autour de 2 à 4 mois au total. le projet est long, plus il y a de chances que les exigences et la définition des produits deviennent obsolètes . Enfin, quoi pour Works le mieux. Lorsque toute votre équipe produit est disponible pour travailler ensemble, il est tout à fait normal qu'un développement semble avoir un port de ressources. Il pourrait être partagé entre de nombreux projets différents. Si un autre projet est terminé, exécuté pour une raison quelconque, alors vous pouvez ne pas avoir toutes les personnes disponibles à l'époque et maintenant nécessaire cela peut impact significatif sur les délais des projets dates de livraison amplement à risque 5. Avantages et inconvénients de la chute à la chute: Je veux maintenant jeter un oeil à certains des avantages et inconvénients du modèle de cascade. Le premier avantage est qu'en divisant votre projet, les livraisons en étapes plus petites sont plus faciles pour une organisation de garder le contrôle sur le processus de développement. Il est donc beaucoup plus facile de planifier les horaires à l'avance. Cela rend la vie des gestionnaires de projet beaucoup plus confortable. C' est pour cette raison que j'ai trouvé l'expérience. Les gestionnaires de projet ont tendance à privilégier le processus de chute d'eau car vous pourriez rendre leur vie beaucoup plus facile. Écoutons un projet dans les différents visages du processus de chute d'eau. Vous pouvez facilement départemental ISA livraison de votre projet. Vous pouvez attribuer différents rôles à différents services et les obtenir. Il est facile pour un gestionnaire de projet d'ajuster un plan de carabine si l'un de ces ministères ne peut pas livrer ses produits diverses raisons pour diverses raisons. Malheureusement, en réalité, j'ai vu la méthode adaptée là où la phase de mise en œuvre est serrée au chaud ou ce qui signifie que l'équipe de développement a moins de temps pour fournir une solution de travail et elle arrive. La qualité en souffre et les raccourcis ont tendance à être pratiqués. Ce sont généralement des unités basées sur le code et le test d'intégration qui sont affectés en premier. Cela a un effet sur les équipes de test dans la phase de test car elles obtiennent une solution. Il contient plus de problèmes, ce qui rend leur vie très difficile. Alors que l'intégration ministérielle est perçue comme un avantage, elle peut rapidement devenir un inconvénient si une autre équipe est en retard dans la réalisation de sa part du projet vers un modèle complet ne laisse pas de temps pour la réflexion ou la vision d'un conception. Une fois que les exigences ont été signées, elles ne sont pas censées changer. Ils devraient signifier que l'équipe de développement a un design fixe, que leurs glandes, mots, mots. En réalité, cela ne se produit pas, et les changements dans les exigences peuvent souvent entraîner le chaos, car les documents de conception doivent être mis à jour et approuvés par les parties prenantes. Au moment où l'équipe de développement commence Donc, le travail est à peu près attendu pour le faire correctement la première fois et ils n'ont pas beaucoup de temps pour faire une pause pour réfléchir sur le code que j'ai implémenté. Mais le temps où vous arrivez au point où vous pensez qu'un changement de direction technique est normalement trop tard pour faire quoi que ce soit à moins que vous ne vouliez effectuer les jours de livraison. Cela pourrait être tout à fait motivant pour l'équipe de développement avec laquelle ils doivent procéder. 10 comprennent des mises en œuvre, pleines de compromis et de dettes techniques. Une fois que le produit est entré, l'étape de test change pratiquement impossible. Que ce soit à la conception globale ou l'eau de mise en œuvre réelle pour était un processus simple . Comprendre le non-papier. Cela semble être une bonne idée pour exécuter un projet. La cascade est également plus facile à gérer vos chefs de projet. Tout est livré par étapes. Il pourrait être prévu sur les plans. trésors sont complétés un à la fois où la sortie d'une face est introduite dans l'entrée de l'étape suivante. Waterfall fonctionne bien pour les petits projets où le risque de changer les exigences et la portée est plus faible, chaque étape dans l'eau pour un très clairement défini. Cela facilite l'attribution de rôles clairs. Deux équipes et départements que vous devez alimenter dans le projet parce que chaque étape est bien à trouver. Il fait un jalon mis en place par le chef de projet. Plus facile à comprendre. Si vous travaillez sur une analyse des besoins par étape, vous devez savoir ce que vous devez livrer à l'étape suivante en cas de sous-marin pour le processus et les résultats de chaque étape de tous les documents. Chaque état a des livrables clairs documentés et signés par les principaux intervenants du projet vers pour le modèle correspond très bien, INS a commencé Charles, Donc un gestionnaire de projet est plus heureux quand ils se plaignent de tout. Kautz et voir le projet Chronologie en application Cela fonctionne des projets. L' un des prix les plus grands inconvénients pour les modèles. Vous n'obtenez aucun logiciel de travail avant la fin du processus. Cela signifie que vos utilisateurs finaux ne voient pas leur vision prendre vie tant qu'il n'est pas trop tard pour changer quoi que ce soit. Il peut être difficile et pour les techniciens d'être clair sur la façon dont ils veulent qu'une application fonctionne, et c'est normalement jusqu'à ce qu'ils puissent visualiser une application qu'ils peuvent donner une bonne rétroaction . Vous pouvez atténuer cela en faisant du prototypage dans la face de conception du système pour aider les utilisations, visualiser leur système. n'y a rien de tel que de donner un code de travail réel, et les logiciels à essayer pour le modèle pourraient introduire un niveau élevé de risque et incertitude pour tout autre chose que les petits projets. C' est parce qu'un ensemble d'exigences et de conception a été signé ne signifie pas que les conditions ne changeront pas vers pour était d'obtenir les exigences, la conception et la mise en œuvre correcte. Première fois, ce qui est une grande idée dans un monde parfait mais dans le monde réel est très rarement le cas, et c'est un grand risque pour un projet. Une complexité accrue accroît le risque de commerce nécessaire plus loin. La complexité du système est également très difficile à mettre en œuvre et le tester peut souvent causer des retards dans les étapes ultérieures de l'eau pour le développement de logiciels. Cycle de vie Si vous travaillez sur un projet où des changements sont attendus, leur désir n'est pas le bon modèle pour vous. J' ai travaillé sur des projets de sociétés de services financiers où des variations dans le droit financier parce que dans la conformité ou la réglementation à changer. Malheureusement, ces règles sont très ouvertes à l'interprétation, ce qui signifie que l'équipe juridique a été impliquée très tôt. Cela signifie que l'interprétation a changé à quelques reprises pendant le projet. Si cela avait été des prix pour le projet, nous avons eu de gros ennuis. Les produits sont souvent assortis de délais fixes. C' était un ajustement parfait pour un projet naturel. Si vous travaillez sur un projet de grande envergure dans la portée change, l'impact de cela pourrait être si coûteux et coûteux que l'avantage commercial initial pour le projet et s'évapore. Et puis le projet a conseillé. J' ai vu cela arriver plusieurs fois, et c'est une vraie honte, car les projets qui montrent de vraies promesses s'arrêtent en raison de restrictions dans le processus. Enfin, l'intégration et la réalisation d'un projet avaient fait un grand coup sur les prix pour Project. Cela signifie que vous allez introduire des quantités massives de changements ou à la fois, il va rapidement déborder les équipes de test et les équipes opérationnelles. 6. Qu'est-ce qu'Agile ?: maintenant que nous jetons un coup d'oeil Une eau plus traditionnelle pour le processus de développement de logiciels. Commençons maintenant à étudier les développements logiciels alternatifs et agiles. Après tout, le développement de logiciels est un ensemble de pratiques de développement de logiciels qui favorisent une conception évolutive avec des équipes qui peuvent s'organiser eux-mêmes. Chez notre logiciel. développement inspire le développement de logiciels de blessures maléfiques, des méthodes de planification adaptatives, une livraison rapide de la valeur de votre logiciel aux clients de l'urine. Le mot agile a été lié pour la première fois au logiciel de développement en 2001 lorsque le manifeste agile a été conçu par un groupe de leaders visionnaires et de développeurs de logiciels. Je ne suis pas le cadran traditionnel et les pratiques comme les méthodologies agiles cascade. Une telle mêlée et une programmation extrême sont centrées sur des équipes interdisciplinaires auto-organisées qui ont pratiqué la planification et la mise en œuvre continues pour offrir de la valeur à leurs clients. Le principal objectif du développement de logiciels agiles est de fournir des logiciels de travail qui donnent la valeur plus rapidement à l'utilisateur final. Chacune de ces méthodes met l'accent sur l'association continue entre la technologie et l'entreprise pour laquelle vous développez le logiciel, après tout, méthodologie logicielle, est un léger considéré qu'ils s'efforcent d'imposer un processus minimal et des frais généraux au cours du cycle de vie du développement. Les méthodes Adroll sont adaptatives, ce qui signifie que je supporte les changements dans les exigences et les priorités métier . Pour l'ensemble du processus de construction du logiciel change. Les exigences naturelles doivent être prises en compte et accueillies avec un projet de développement logiciel agile . L' accent est également mis sur l'autonomisation des équipes de décision collaborative. Faites-le. Plus tôt, j'ai parlé de la façon dont le processus de développement basé sur la cascade suit une série d'étapes qui traduit par un grand bang de logiciels déployés à la fin du processus. L' une des principales idées derrière le développement logiciel agile est qu'au lieu de livrer une grande version Bang en production dans le projet, vous avez publié plusieurs versions de codes de travail vos parties prenantes en permanence. Cela vous permettra de hiérarchiser les fonctionnalités qui apporteront le plus de valeur aux utilisateurs rapidement afin que l'organisation puisse obtenir un retour sur investissement anticipé. À cet égard, l'investissement prend la forme d'argent et de temps consacré au développement et la planification du nombre de livraisons en production. Cela dépend de la durée du projet compliqué, mais idéalement, mais idéalement, vous aimeriez livrer un logiciel de travail à la fin de chaque sprint ou itération. J' aime une bonne façon de visualiser la prémisse de notre Joe est dans le diagramme que vous dissimuler écran. Maintenant, ce que ce diagramme montre est si un logiciel agile vous livrez incrémentalement au lieu de tout à la fois. Vous devriez garder sa faute dans votre esprit pendant que nous progressons dans le reste de ce cours. 7. L'histoire de l'Agile: Il y a eu de nombreuses tentatives pour améliorer les méthodologies de développement de logiciels au fil des ans , et beaucoup d'entre elles ont cherché à travailler de manière intrusive. Ces nouvelles pratiques ne sont pas allées assez loin en essayant de faire face aux changements dans les exigences des clients. Dans les années 90, un groupe de logiciels industriels Fort Leaders s'est réuni dans une station de ski de l'Utah pour voir que vous pouvez définir une meilleure façon de développer des logiciels. Le terme « développement logiciel agile » a émergé de cette cavalerie. Le terme a d'abord été utilisé à sa manière et à sa publication. Le célèbre manifeste Agile Manifesto Theater a été conçu pour promouvoir les idées de fournir une valeur commerciale régulière à vos clients et a rendu nécessaire que vous vous concentriez sur une équipe collaborative et interfonctionnelle pour réaliser ce arriver. 8. Les valeurs de base de Manifesto 4: le manifeste fédéral est probablement l'artéfact le plus important que nous puissions examiner lorsqu'il s'agit de développer des logiciels agiles. Peu importe votre influence dans la programmation extrême Squam quand Si vous avez une méthodologie de gestion de projet, vous ne suivez pas les valeurs dans le manifeste agile, alors vous ne faites pas adroll correctement. Jetons donc un coup d'oeil aux quatre valeurs fondamentales. Il s'agit d'individus et d'interactions sur les processus et les visites, logiciels de travail sur une documentation complète, collaboration client sur la négociation de contrats et enfin de réponse au changement sur suite d'un plan pour le premier noyau valeur. Nous avons des individus et des interactions sur les processus dans les écoles. Les gens construisent des systèmes logiciels et encore cela correctement, ils seulement pour travailler ensemble et avoir une bonne communication entre toutes les parties. s'agit pas seulement de développeurs de logiciels, mais comprend un analyste d'affaires Q A, des chefs de projet, sponsors commerciaux et des cadres supérieurs et toute autre personne impliquée dans le projet ou le produit au sein de votre organisation. processus et les outils sont nécessaires, mais ils ne sont pas pertinents pour les personnes qui travaillent sur les produits ne peuvent pas communiquer et travailler ensemble efficacement pour une seconde des valeurs fondamentales. Nous avions un logiciel de travail sur une documentation complète. Allons-y, qui lit 100 pages produits de retour. Certainement pas. Les utilisateurs de votre entreprise étaient beaucoup préférés si petits éléments de fonctionnalité qui sont livrés rapidement afin qu'ils puissent ensuite fournir des commentaires. Ces éléments de fonctionnalité peuvent même suffire à la production pour en tirer profit . La documentation ancienne est mauvaise, cependant, cependant, lorsque mes équipes pourquoi c'est sur un projet, elles utilisaient des outils de diagrammes visuels sur physio pour produire des diagrammes tels que des diagrammes de déploiement, des schémas de base de données dans les couches logicielles et diagrammes de cas d'utilisation. Nous les imprimons généralement sur trois empreintes et les posons sur le mur afin qu'elles soient visibles pour tout le monde. Petits morceaux utiles de documentation là-bas si précieux produits de 100 pages, dos ou non. Neuf fois sur 10 documents importants sont invalides et obsolètes avant même que vous ayez fini de les écrire. Rappelez-vous l'objectif principal est de développer des logiciels qui offrent des avantages commerciaux et non une documentation exhaustive. Je préfère les valeurs fondamentales. Nous avons une collaboration client sur la négociation de contrats. Eh bien, le logiciel que vous avez développé devrait être écrit. Si vos clients sont impliqués avec succès dans le développement de logiciels, vous devez travailler avec lui tous les jours. Cela signifie inviter régulièrement vos stands up démo et l'inviter à toutes les réunions de design. Seul le client peut vous dire ce qu'il veut. Ils peuvent ne pas être en mesure de vous donner tous les détails techniques, mais c'est ce que votre équipe est, par conséquent, collaborer avec eux, comprendre leurs exigences et de livrer pour eux. Mais un quatre de la valeur finale de l'appel que nous avons répondu au changement sur la suite à un plan parrainé par votre client ou votre entreprise peut former vos esprits sur ce qui est en cours de construction. Cela peut être dû au fait que vous leur avez donné de nouvelles idées à partir du logiciel que vous avez fourni dans une situation antérieure. C' est peut-être parce que les priorités de l'entreprise ont changé ou que de nouveaux changements réglementaires sont entrés en vigueur. La chose la plus importante, c'est que tu devrais l'embrasser. Oui, certains codes peuvent être jetés et parfois être perdus. Mais si vous travaillez dans de brèves modifications et que ce temps perdu, il minimise le changement est une réalité des développements logiciels, une réalité que votre processus logiciel doit refléter. n'y a rien de mal à avoir un plan de projet. En fait, vous êtes inquiet pour tout projet qui n'en avait pas. Cependant, un plan de projet doit être suffisamment souple pour être modifié 9. Présentation de la méthodologie: Maintenant que nous comprenons les principales valeurs fondamentales du manifeste agile, elles sont couramment utilisées pour étayer différentes méthodologies, c'est pourquoi Adroll devient plus pratique. Prenons un niveau très élevé. Regardez quelques-unes des méthodologies courantes utilisées par Aaron aujourd'hui. Ce cours n'est pas sur une méthodologie particulière, mais les problèmes vont prendre un verre de méthodologies quelqu'un qui sont là avec succès nous avons Scrum Scrum est un cadre de gestion de projet léger qui est basé sur un modèle de travail. Ken Schwab pourrait être Door Jeff Succulent et offre a contribué aux développements décrits au cours des années au cours des dernières années. Screamers possèdent une popularité croissante dans la communauté de développement de logiciels en raison de sa simplicité, succès éprouvé et d'améliorer la productivité et sa capacité à travailler avec des pratiques d' ingénierie très souffrir promus par notre fragile méthodes telles que la programmation extrême. Donc, ensuite, nous avons la programmation Extreme ou Ex Pays est également neuf programmation Extreme a été initialement conçu par Ken retour et a émergé l'une des méthodes agiles plus populaires et controversées . La programmation extrême est une approche disciplinée qui consiste à fournir des logiciels de haute qualité plus rapidement et met constamment l'accent sur l'engagement client, les sauts de retour rapides, tests continus, la planification continue du travail d'équipe pour fournir des logiciels de travail. Cadence de diffusion fréquente généralement de 1 à 3 semaines lorsqu'une mêlée est un cadre de gestion de projet . Exp est plus une discipline d'ingénierie. Il est très fréquent que les équipes adoptent un gommage, tout en empruntant différentes pratiques d'ingénierie à la programmation extrême. La recette originale de programmation Extreme était basée sur des valeurs simples de fourche, la simplicité, la communication, rétroaction, encourager. Il y a aussi 12 pratiques de soutien. Ce sont les petites versions de jeu de planification, tests d'acceptation des clients, programmation de paire de conception simple, développement piloté par les tests, le facteur de re dans l'intégration continue, codage de propriété de code collectif normes, métaphores et rythme durable. Comme je l'ai déjà dit, cependant, ce cours n'est pas sur la mêlée ou la programmation extrême, Le message important pour vous d'apprendre dans ce cours est ce que Pageau lui-même est tout au sujet. J' ai vu certaines équipes penser qu'elles font de la mêlée, mais en fait quand il s'agit de regarder les quatre valeurs fondamentales, si un changement arrive sur le projet et doit ensuite aller à certains conseils consultatifs être discuté, approuvé sans papiers, même s'il semble que vous faites agile, quoi dans la mêlée ? En fait, tu ne l'es pas. Donc, ce sont les quatre valeurs fondamentales sur lesquelles je veux que vous vous concentriez dans ce cours 10. Rôles dans une équipe Agile: chez les anciennes équipes faisait partie d'un département d'une entreprise axée principalement sur leurs objectifs de développement de logiciels . Chaque équipe devrait également se concentrer sur la vision globale de son équipe. Cela signifie qu'une équipe devrait être très réactive en faisant tout ce qui est nécessaire pour faire le travail . Cela signifie que les membres de l'équipe peuvent également devoir travailler en dehors de leurs compétences normales. Ils devraient être embrassés et encouragés. Une équipe adaptative multifonctionnelle est beaucoup plus susceptible de réussir. La plupart des équipes, bien sûr, auront des domaines d'expertise standard et des ISM spéciaux, et vous pouvez également avoir des personnes dans un domaine particulier ou une connaissance de produit. Mais il devrait s'agir de souplesse et les membres de l'équipe s'attendent à ce que les rôles et responsabilités Vous devriez également être courant car les membres de l'équipe ont accès à l'entreprise dans son ensemble, et ils ne devraient pas être limités à quelques uns seulement. Vous devriez avoir des personnes qui sont chargées de s'assurer que l'équipe a suivi le processus de développement , et quelqu'un qui coordonne la collecte des exigences avec l'entreprise pour laquelle elle est, en général être référé comme le propriétaire du produit. Si vous travaillez dans le cadre de scum, cadre de scum, équipes auront normalement un rôle de leadership au sein de l'équipe dans la mêlée, cette personne est le maître de mêlée dans les équipes agiles. Sa personne a pour but de permettre et d'assurer le succès de l'équipe, le type de leaders souvent appelé chef de serviteur. Ce rôle est tout à fait différent d'un responsable transactionnel direct sur un projet de cascade. Une équipe agile va four devrait être d'améliorer en tant qu'équipe tous les jours. Plus l'organisation est grande, plus les structures de groupe sont compliquées. Les équipes interprojets, les services partagés, opérations, gestion de la configuration et l'administration de bases de données pourraient également entrer en jeu. Mais l'objectif reste le même. Trouver un projet logiciel et une équipe interfonctionnelle capable de mettre en œuvre un plan et habilitée une équipe à le faire. 11. Misconceptions agiles communes: quand une équipe doit être agile, il pourrait être la moitié d'entre eux pour s'adapter à une nouvelle façon de travailler, surtout pour avoir l'habitude de travailler sous des prix pour une méthodologie basée. Lorsqu' une équipe est confrontée à des changements, façon dont elle travaille est courante pour que les membres de l'équipe puissent se prémunir pour résister au changement. Aucune équipe comme celle-ci, mais d'après mon expérience, il est assez courant d'entendre de nombreuses idées fausses différentes dans cette section discuteront de bon nombre de ces idées fausses et de la raison pour laquelle elles se produisent. Ouais, Joe est à Hark sans contrôle de processus. Pour être agile, vous devez adhérer au manifeste agile. Mais suivre le manifeste ne signifie pas que vous utilisez un processus défiant. Le manifeste décrit un ensemble d'idées. Il existe différents processus et modèles de gestion de projet que vous pouvez appliquer à vos projets pour les aider à devenir agiles. programmation extrême dans la mêlée sont deux des plus populaires, mais maigre et Cambon sont également très populaires. Lorsque vous essayez de mettre en œuvre les éléments du manifeste, vous Allemagne avez besoin d'appliquer la perte de bon sens et de pragmatisme pour espérer que vous arrivez à votre objectif avant d'envelopper un processus plus formel autour de la façon de l'agile par opposition au pourquoi. Et vous devez informer quelque chose comme la mêlée ou la programmation extrême, ce qui vous donne un processus plus formel, comme des histoires, des altérations, stuptions, des démos , rétrospectives, développement piloté par test et programmation par paire. Ensuite, nous avons agile est gaspillage sans jusqu'à la planification de ces extrêmes, votre client sait que les tours de toutes leurs exigences à l'avance. Si cela est vrai, alors par tous les moyens entreprendre une planification complète. Cependant, en réalité, cela est rare et généralement moins un gaspillage plus important d'avoir pris des travaux de développement de concepteur qui était finalement inutile. Ensuite, nous avons le développement agile n'est pas prévisible américain. Au sein d'une équipe établie et agile. Vous pouvez apporter un niveau de prévisibilité. Votre cycle de vie de développement est-il sur l'entreprise Comme vous livrez directement des logiciels de travail à vos clients, la fréquence de ces versions sera définie avec vos parties prenantes. Dans une situation idéale, vous devriez avoir, code libérable à la fin de chaque sprint ou itération. Ensuite, nous avons agile est plus rapide et moins cher. Diriger une équipe agile ne signifie pas que vous finirez votre projet plus rapidement ou pour moins d'argent. Ce n'est pas un économiseur d'argent direct à cet égard, ce qu'est un procès. Il apporte de la valeur à l'entreprise plus tôt que vous avez eu vers les versions de travail de votre code plus rapidement et la fin de chaque itération de développement. Vous êtes supposé avoir un logiciel de travail pour démo à l'entreprise. Vous n'avez peut-être pas toutes les exigences en place, mais ce qui est là fonctionnera. Cela signifie repenser la façon dont vous planifiez votre charge de travail dans chaque situation. Au lieu de fournir des tranches horizontales, par exemple, l'accès aux données couche votre situation sur l'interface utilisateur dans une situation de cou, vous pouvez penser en segments verticaux. Cela signifie que vous avez fourni pour trouver des éléments de fonctionnalité dans une inspiration qui peut englober le travail sur l'interface utilisateur et une couche d'accès aux données. C' est un changement d'esprit. Sont vus les équipes luttent avec. Si je travaillais horizontalement quand ils l'obtiennent enfin, l' efficacité d'une équipe a augmenté remarquablement. Être à l'extérieur, c'est aussi être capable de réagir au changement. exigences peuvent varier, et les entreprises peuvent changer d'avis à part pour votre livraison. Je me battrai là où tu traites les équipes. C' est une chose vraiment négative. Si vous voulez être agile, vous devez vous attendre. L' étreinte des choses changera les outils et les processus de mêlée , par exemple, conçus pour vous aider à réagir plus efficacement à ces changements. Donc prochaine idée fausse nous avons ses équipes agiles. N' écrivez pas de documents ou planifiez-vous. Pratiquer leur John dans votre équipe n'est pas une excuse pour éviter la planification ou la documentation. Writing Agile est un acte de faire ce qui est nécessaire au moment de l'exiger, il encourage la planification et la documentation continues, mais seulement lorsque cela est nécessaire pour une exigence spécifique du client. Cela permet aux équipes, ainsi qu'à leurs clients, de décider si le plan ou le document ajoute de la valeur au produit. Selon le type d'entreprise pour lequel vous travaillez. La documentation officielle peut ne pas être quelque chose que vous pouvez éviter. Par exemple, si vous travaillez dans un environnement très dense, il y a beaucoup de documents initiaux. Il peut être nécessaire pour des preuves, une présentation à un organisme de réglementation. Si c'est le cas au sein de l'équipe de livraison, nous devons tenir compte de cette documentation. Je préfère travailler de grands diagrammes au lieu des derniers documents de l'impôt. Si vous pouvez obtenir ces diagrammes imprimés sur le papier libre et ensuite les mettre sur tous les murs, sorte que vous pouvez vous référer à quelque chose dans vos stand. Avec le côté planification de cela, vous devez toujours le faire. Comment le début de chaque sprint interational. Vous devriez avoir une séance de planification. Lorsqu' une équipe alloue elle-même des histoires pour l'altération, le nombre d'histoires qui sont allouées est basé sur les estimations données sur les vitesses des itérations précédentes. L' idée fausse suivante est que l'agilité signifie qu'aucun engagement est une croyance commune que les gens sont agiles. Les équipes ne veulent pas faire des promesses que vous avez des équipes de développeurs barattent jusqu'à ce que quelqu'un crie, Nous avons terminé. Un succès de notre équipe enfant devrait être très transparent sur ce qu'ils ont l'intention de livrer Leurs utilisations. Lorsque vous utilisez des méthodologies sont la mêlée ou la programmation extrême, vous avez un concept d'un arriéré qui contient un examen. Heil sur les utilisateurs. Histoires et tâches ont été donnés sprint ou itération que vous pour trouver la charge de travail pour un sprint. Ils devraient être considérés comme un guide de ce que l'équipe a l'intention de faire. Une fois qu'une répétition Spencer est configurée, elle ne changera pas, mais vous devrez peut-être modifier votre plan en partie pour son impression. Cela pourrait entraîner une replantation partielle de ces sprints, répétition ou attendre jusqu'au prince suivant. La programmation extrême n'aime pas changer un sprint une fois est. Vous le volez dessus. C' est plus acceptable et mêlée, mais aucune loi ne dit que vous pouvez aussi l'engagement si nécessaire. Ce qui est important, c'est qu'il y ait un niveau de confiance entre l'équipe et les parties prenantes de l'entreprise . Ensuite, nous avons un projet agile ne se terminera jamais. Cela peut être vrai dans certaines situations. Il devrait continuer à travailler sur un projet pendant que le client continue d'obtenir de la valeur commerciale . La plupart des produits dans toutes les industries ont un point de baisse des rendements. C' est le moment idéal pour un produit naturel et un développement. Cette décision devrait provenir de l'entreprise, mais c'est eux que vous apportez de la valeur à des travaux agiles pour des projets, équipes et des organisations de toute taille, pas seulement pour de petits projets. Cela ne signifie pas que vous travaillez nécessairement pour toutes les équipes, mais la taille est vraiment un facteur. Des projets et des organisations de grande envergure et complexes, souvent d'excellents candidats pour la transformation naturelle, soulèvent difficile ou impossible de connaître à l'avance toutes les exigences de vos clients. Ensuite, nous avons agile est les solutions pour vos problèmes. Le naturel est un changement d'approche et de culture qui vient avec ses propres avantages et enjeux. Si vous travaillez dans une équipe bien établie, il n'y a pas eu de processus agiles que de les changer ne sera pas une transformation instantanée. Vous devez le faire lentement et vous assurer que tout le monde a son mot à dire dans le processus décisionnel. Si vous ne le faites pas, vous faites la résistance des membres de l'équipe qui craignent le changement, ce qui est une caractéristique humaine parfaitement normale. Convaincre votre équipe n'est pas le plus gros obstacle . Votre plus grand défi est de vous assurer que votre équipe de direction comprend et souhaite adopter. Agile comme une façon de travailler. Une fois que vous avez réalisé cela et eu le leadership par dans le reste de l'adoption prend juste du temps et de la patience est tout le monde ajuste. L' idée fausse suivante est qu'il n'y a qu'une seule façon de faire un travail. Le manifeste original et agile se compose des quatre valeurs fondamentales. Il ne documente pas les détails d'implémentation réels là-bas. De nombreuses interprétations d'agile qui forment différentes méthodologies comme Scrum extreme programmation cam interdiction sur le développement piloté par fonctionnalité, pour n'en nommer que quelques-unes. Chaque style a ses avantages et ses faiblesses, et vous devez évaluer votre situation pour décider quelle méthodologie correspond à votre équipe de programmation extrême débrouiller deux des méthodes les plus populaires en usage aujourd'hui, mais aussi leader Cambon sont très populaire, aussi. Comme toujours, nous respectons les manifestes d'adroll, les valeurs et les principes et fournissons régulièrement des logiciels de plus grande valeur à vos clients. Vous devriez être considéré comme agile. Qui enfin, la dernière idée fausse que nous avons est Adul Development ne nécessite pas de conception initiale. C' est une idée fausse commune. Les équipes agiles inventent tout simplement au fur et à mesure qu'elles avancent. Ce n'est pas vrai. Ce qui est plus réaliste, c'est que les équipes agiles doivent veiller à ce que leurs décisions soient prises au dernier moment responsable des activités de revêtement. Ses ensembles de marques avec du code est conçu comme un développeur travaille dessus, tous les facteurs à une meilleure conception au fur et à mesure qu'ils vont le long. C' est ce qu'est le design évolutif. Plus à l'échelle du système. Une conception architecturale pourrait être brisée par un ou plusieurs sprints à l'avance, seulement la conception comme vous le voyez, vous pouvez réagir aux changements dans les exigences plus efficacement lorsqu'il essaie de concevoir l' ensemble du système à l'avance. Toutes les décisions de conception que vous faites beaucoup, il est redondant au moment où vous venez de les mettre en œuvre 12. Avantages et inconvénients d'Agile: comme vous l'avez vu dans les vidéos précédentes. Le développement logiciel agile est une approche entièrement différente du développement logiciel par rapport au modèle plus traditionnel de l'eau pour le développement. Jetons un coup d'oeil à certains avantages de l'utilisation. Agile est une approche. Tout d'abord, la satisfaction du client par la livraison rapide continue de logiciels utiles. Vos clients des utilisateurs seront satisfaits parce que vous continuez à leur fournir de la valeur. Logiciel réutilisable. C' est un contraste frappant par rapport à celui de l'eau traditionnelle utilisée pour la livraison des produits . Maintenant, si vos clients sont habitués à la chute d'eau, ils peuvent le trouver. Un étranger. Justin a un logiciel de travail plus tôt. Le gros inconvénient de l'eau pour les mots que vous offrez aux grands patients de fonctionnalités vers la fin du cycle de vie du projet en fournissant des éléments fonctionnels Tôt ou plus fréquemment, vous donnez à vos utilisateurs un possibilité d'obtenir un retour sur leur investissement plus tôt. Bien sûr, ils peuvent ne pas avoir toutes les fonctionnalités dont ils ont besoin à l'avance, mais ils pourraient commencer à utiliser la solution pour faciliter leur vie et commencer en tirer parti. Plus tôt, nous avons des gens et les interactions sont privilégiées plutôt que des processus et des visites . J' ai essayé son attention très fortement sur les gens et les interactions entre les gens plutôt que les processus dans les tournées. C' est une valeur fondamentale du manifeste. La raison pour laquelle cela est important est que ce les importations de votre équipe et les clients qui finiront par faire votre produit de succès par opposition à ce qui est toujours utilisé. Continuer la collaboration pour tout le cycle de développement de votre projet permet à toutes les personnes impliquées d'établir une bonne relation de travail basée sur la confiance. Cette relation de travail basée sur la confiance est cruciale lors de la construction progressive de logiciels. Ensuite, nous avons une attention continue au code de haute qualité. On travaille avec notre boulot. Vous travaillez de courtes modifications sur seulement construire ce qu'il est nécessaire pour satisfaire aux exigences de son aération, et rien n'appelle. Cela vous oblige à garder votre design simple, ce qui est essentiel car la simplicité vous aide à développer des systèmes testables et donc plus fiables . Les développeurs comprennent et choisissent de nombreuses solutions pour résoudre les problèmes d'entreprise. Ce sont des choix qui reflètent un métier qui équilibre la conception, l'utilisation et le soutien. Les développeurs fournissent l'assistance technique de l'équipe qui les voisins pour toujours maintenir la qualité de co supérieure. Les développeurs aiment utiliser les dernières technologies pour garder leur implémentation simple et propre sans avoir à retravailler aucune de leurs solutions. Certaines de ces techniques comprennent re usine. L' usine est un processus d'amélioration de la conception du code existant sans changer son comportement. Il a apporté des modifications à la structure du code. La salle des faits utilise une succession rapide de petites étapes bien définies, il pourrait être vérifié est sûr ou équivalent fonctionnel. Le refactoring est souvent fait en conjonction avec le développement piloté par des tests. Où, Unit dit, et la conception simple rendent plus facile de re facteur en toute sécurité. Le prochain avantage est la conception simple. garder votre conception simple ou de ne pas répéter le code vous aide à conserver un niveau de capacité de maintenance pour votre système. Si vous concevez votre code pour être modulaire, vous pouvez réduire Coplin entre les objets. Habituellement, un système global, plus robuste grâce à des avantages. Développement piloté par des tests. développement piloté par des tests est un moyen d'améliorer la conception de votre code en écrivant des tests unitaires , ce qui exprime ce que vous avez l'intention de faire passer ce test et de continuer à affacturage Pour garder le processus de conception aussi simple que possible, le développement piloté par les tests peut être appliqué à plusieurs niveaux, par exemple, tests unitaires et d'intégration. développement piloté par des tests suit un cycle rigoureux. Vous commencez par écrire un test échoue, puis vous implémentez que ma solution simple ne fait pas passer ce test. Ensuite, vous définissez pour la duplication dans le code et supprimez-le. Il est souvent appelé rouge vert. Red Factor est devenu presque un mantra pour de nombreux praticiens de la conception basée sur des tests. Comprendre et intérioriser ce cycle est essentiel pour pouvoir utiliser des tests conçus pour résoudre vos problèmes. Merci avantages. Adopter les changements dans les exigences, vos clients ou partenaires commerciaux. Nous voulons changer d'avis sur le logiciel en cours de construction. C' est peut-être parce que vous les avez inspirés avec de nouvelles idées de la vague douce livrée dans une situation antérieure. C' est peut-être parce que les priorités de l'entreprise ont changé. La chose clé ici, c'est que vous devriez accepter le changement. Oui, code peut être jeté et parfois durer. Si vous travaillez en assurance, ce temps a été réduit au minimum. changement peut être terrifiant au début, tant pour les clients que pour les partenaires. Mais quand les deux parties se sont préparées à partir, vous ne pouvez pas être mutuellement gratifiant. À certains égards, au procès est une idée simple, mais la réalité est que cela peut signifier des choses différentes pour différentes personnes, en particulier en fonction de leur rôle dans le processus de développement logiciel. L' une des choses clés, cependant, est d'être ouvert au changement, non seulement de se déplacer dans les méthodes traditionnelles d'organisation des projets, mais c'est donc votre utilisation de l'agile elle-même. Ensuite, nous avons un retour sur investissement anticipé. Une autre avancée vers la libération des fonctionnalités tôt est que vous sortez tôt. Retour sur vos placements. La gestion d'une équipe de développement de logiciels est coûteuse. Vous avez des développeurs permanents et des testeurs ainsi que des consultants avec des tarifs journaliers coûteux. Est également analyste d'affaires chefs de projet, ainsi que d'autres coûts de logiciels matériels. Ce sont tous les coûts de l'entreprise. En libérant tôt pour générer des revenus de votre produit, vous pourriez commencer à compenser certains des coûts d'investissement et de développement initiaux. l'autre côté de cela, si vous toujours plus d'eau pour une approche basée où vous vous retrouvez avec un big bang déploiements après un an ou deux, vous aurez déjà dépensé une quantité importante d'argent pour financer un développement sans rien pour montrer pour elle jusqu'à la fin. Ensuite, nous recevons les commentaires de vos clients si vous sortez tôt. Cela signifie que vous pouvez commencer à solliciter les commentaires de vos clients beaucoup plus tôt. Ses clients pourraient être des clients publics ou des commanditaires d'affaires. J' ai travaillé sur de nombreux projets où les clients professionnels spécifient les exigences, qu'il construit ensuite uniquement pour les clients veulent des changements. Une fois que j'ai vu quelque chose qu'ils peuvent utiliser, cela semble toujours arriver. Il est difficile pour quelqu'un de spécifier un système sans avoir quelque chose à jouer avec. Vous pouvez utiliser un logiciel de prototypage pour vous aider, mais il n'y a rien de tel que leur donner des fonctionnalités réelles pour commencer à utiliser tôt. L' un des principes de notre travail est d'accepter le changement des exigences. Cela devrait donner à vos clients quelque chose sur lequel ils peuvent faire des commentaires plus tôt et la possibilité d'apporter des changements sans causer beaucoup de perturbations plus tard. bas de la ligne dans l'avancée finale que nous avons est la foi de retour de vrais clients. Une fois que vous commencez à recevoir les commentaires de vos clients, vous pouvez commencer à incorporer les modifications. nouvelles idées issues du flux dans le produit sont beaucoup plus rentables pour apporter changements tôt dans le cycle de développement du produit qu'il ne l'est d'attendre jusqu'à la fin. Une fois qu'une grande version a été obtenue, ne sont pas seulement les commentaires des clients qui vous aident à créer la bonne protestation de produit dans vos produits. Dès le début du marché, vous engagez la participation des clients et voyez à quel point les produits seront populaires et vous continuez à offrir une meilleure qualité. Tout ce que nous avons discuté jusqu'à présent présente des avantages commerciaux ou aboutit au fait que vous devriez fournir un produit de meilleure qualité pour chaque version en publiant des commentaires en insistant tôt . Vous pouvez tirer les leçons des performances du produit dès le début et utiliser ces informations pour créer quelque chose de développement de produits et de systèmes de meilleure qualité, tout cela sur l'apprentissage continu et les améliorations. C' est beaucoup plus facile à faire lorsque vous livrez un produit en étant agile. Peu importe où jamais. Utilisation d'un programme extrême dans le cristal de mêlée développement piloté par Fish bande Lean Cam Vraiment, si vous avez un cadre de gestion de projet , si vous vous en tenez aux valeurs fondamentales du manifeste agile, je suis régulièrement de vivre une valeur plus élevée dès le début à vos clients. Surveiller leur utilisation n'est pas là ? Les commentaires peuvent appliquer cet apprentissage au développement en cours. Augmentez la qualité au fur et à mesure que vous allez maintenant jeter un oeil à certains avantages, regardons quelques inconvénients. Tout d'abord, c'est difficile à évaluer. L' effort a nécessité le début du cycle de développement logiciel, on se plaint. J' ai souvent entendu des chefs d'entreprise et des chefs de projet est-il comparé à l'eau, pour ? Il est difficile de quantifier l'effort total et le coût de livraison d'un produit. D' un côté, je pouvais voir ce que je pensais. Ceci, surtout ils viennent d'un monde de processus régimenté était complet. En effet, il est plus difficile de quantifier le temps que prendra le total des produits. Mais une atténuation pour cela est qu'un produit sera livré incrémentalement en leur donnant utilise les exigences les plus précieuses d'abord, ce qui signifie que vous vous plaindre pour les sprints à venir ou peut-être quelques sprints à l'avance pour fournir des quantités de fonctionnalités. Avantages racistes. Il peut être très exigeant sur les utilisations. Temps participation active de l'utilisateur en collaboration avec les utilisations de votre système sont nécessaires pour le cycle de développement avec agile. Cela peut être très gratifiant. Garantit que vous livrez les bons produits pour vos utilisations. C' est un principe essentiel de l'agile. Pour s'assurer que les expériences des utilisateurs sont bien gérées sur une définition de l'échec ne répond pas aux attentes des utilisations. Cependant, ce niveau de participation peut être très exigeant pour l'utilisateur et nécessite un grand engagement de temps pour la durée de ce produit. Ont été dans cette situation plusieurs fois où les utilisateurs d'affaires aiment l'idée de ce qu'une blague pourrait leur apporter. Mais je n'aime pas le temps supplémentaire qu'ils ont à passer sur le projet, car je dois toujours adapter la même de leurs charges de travail communes le dernier jour. Survit jeans regarder est un coût peut augmenter. testeurs sont requis tout le temps plutôt qu'à la fin d'un projet. Les tests sont une partie essentielle du projet naturel Jordan sprints, et ce sont des orations qu'ils servent. Nous montrons la qualité dans l'ensemble des produits sans la nécessité de 11 frais et la phase de test imprévisible il fin de votre produit. Cependant, cela ne signifie pas que le test est un besoin pour tout le cycle de vie du développement des produits, et cela peut augmenter considérablement le coût des ressources de votre équipe. Ces coûts externes supplémentaires vous font économiser de l'argent à long terme, cependant, cependant, car vous avez continuellement des gens qui testent votre code. Une combinaison de tests manuels et automatisés est la meilleure façon d' améliorer la qualité de vos produits 13. Êtes-vous prêt à Agile ?: pour certaines organisations sait être plus grandes et plus anciennes. La réponse à la question que je prépare au changement sera probablement non. L' idée de mettre en œuvre des méthodologies encourage l'évolution des exigences commerciales au lieu de s'appuyer sur une documentation extérieure. autonomisation de l'équipe de projet au lieu de contrôler ses activités quotidiennes sur le remplacement signifie qu'une documentation sans communication face à face peut sembler un peu intimidante pour certains employés. C' est particulièrement la phase de cas que je suis devenu à l'aise avec leurs dates normales. Ils routines et juste vivre avec les problèmes dans leur code sur les solutions qui vont le développer. Une grande débilitation en essayant agile est que les gens disent que c'est la façon dont nous l'avons toujours fait . Ces types d'individus, généralement très résistants au changement si vous commencez son hésitant au début, vous pouvez trouver que donner agile pour essayer un projet de donateur dans votre équipe aidera à les familiariser et motivé par agile. Si je dois essayer un ou deux projets agiles, vos affaires sont toujours mal à l'aise de travailler directement avec les domaines d'activité, forçant des changements dans les exigences à mesure que le projet progresse et auto-gérant leur travail. Il se peut que les approches agiles ne soient tout simplement pas adaptées à vos organisations. Culture du travail. Si, autre côté, votre équipe réagit bien aux projets d'essai que ses pavés, la façon pour vous de passer plus complètement à adopter dans ces méthodologies devient agile ne nécessite pas de changement d'attitude pour les managers et à la tradition, il pourrait être plus courant d'avoir un contrôle direct sur ce que les membres de votre équipe travaillent. Mais si elle est agile, vous devez adopter une approche différente. styles de gestion doivent ressembler davantage au leadership des serviteurs, où les gestionnaires sont là pour éliminer les obstacles au progrès de l'équipe et encourager une équipe à penser par eux-mêmes et à organiser sa propre charge de travail. Après tout, les développeurs sont très bien payés. Elle a besoin d'avoir un niveau de confiance plus réaliste qu'ils feront la bonne chose, pas pour une chose intéressante sur la dynamique des équipes auto-organisatrices. Au fur et à mesure qu'ils progressent, ils améliorent la motivation continue du projet des employés. Les membres de l'équipe savent que leur capacité continue à s'autogérer. Leur travail dépend de leur prestation régulière de résultats commerciaux de grande valeur, plus parce que ce sont eux qui déterminent ce qui peut ou ne peut pas être réalisé dans la situation. Ils sont motivés par leur responsabilité d'atteindre ces résultats. Cette combinaison de facteurs est accentuée par la situation et la fierté que les membres du personnel Phil, lorsqu'ils produisent des résultats tangibles, répondent véritablement aux besoins de leur organisation. 14. Merci: Merci d'avoir regardé Might cause que je conduis explique. Et j'espère qu'il a trouvé que l'information soit discuter de la qualité va vous être utile dans la compréhension de la prime agile pour les organisations. Si vous avez apprécié le cours sera très reconnaissant. Vous me suivez. Et aussi, si vous pouviez connaître la cause sur Twitter chaque fois que les sites de médias sociaux sont absolument fantastiques sur Vous pouvez également laisser des commentaires ici de ce côté. Donc je pense beaucoup pour regarder. Je ne te reverrai plus bientôt.