Bonjour les Habitants! Toute entreprise souhaite atteindre une plus grande efficacité dans le développement de logiciels, car cela affecte directement les bénéfices. Une grande partie de la littérature Agile est destinée aux grandes entreprises à forte croissance, mais que faire si votre entreprise n'est pas à la pointe de l'informatique? La bonne nouvelle est que chaque organisation peut améliorer ses performances, et ce livre vous aidera à trouver des chemins et des solutions spécifiques pour tirer le meilleur parti d'Agile. «Je ne suis pas un évangéliste Agile. Je suis un partisan de ce qui fonctionne et un adversaire de ce qui promet beaucoup mais n'apporte pas de résultats. Dans ce livre, la méthodologie Agile n'est pas présentée comme un mouvement qui nécessite une conscience accrue, mais comme un ensemble de méthodes managériales et techniques spéciales, dont l'effet et l'interaction sont compréhensibles pour tout homme d'affaires ou informaticien.Les passionnés d'agilité peuvent critiquer ce livre pour ne pas promouvoir les meilleures pratiques Agile. Mais c'est le point - un accent sur les méthodes pratiques qui ont prouvé leur efficacité. L'histoire d'Agile regorge d'idées qui ont été mises en œuvre avec succès par quelques passionnés dans certaines organisations, mais qui ne peuvent pas être utilisées par tout le monde », déclare Steve McConnell. Le nouveau livre de Steve McConnell, auteur des livres légendaires Code Complete et Software Estimation, rassemble l'expérience de la vie réelle de centaines d'entreprises. Utilisez un guide simple et direct des pratiques Agile modernes et les plus efficaces.qui ont été mis en œuvre avec succès par quelques passionnés dans certaines organisations, mais qui ne sont pas utilisés par tout le monde », déclare Steve McConnell. Le nouveau livre de Steve McConnell, auteur des livres légendaires Code Complete et Software Estimation, rassemble l'expérience de la vie réelle de centaines d'entreprises. Utilisez un guide simple et direct des pratiques Agile modernes et les plus efficaces.qui ont été mis en œuvre avec succès par quelques passionnés dans certaines organisations, mais qui ne sont pas utilisés par tout le monde », déclare Steve McConnell. Le nouveau livre de Steve McConnell, auteur des livres légendaires Code Complete et Software Estimation, rassemble l'expérience de la vie réelle de centaines d'entreprises. Utilisez un guide simple et direct des pratiques Agile modernes et les plus efficaces.
Exécution de projet encore plus efficace
Dans le chapitre précédent, nous avons examiné comment organiser et soutenir les développeurs lorsqu'ils travaillent en Agile. Ce chapitre explique comment organiser et maintenir correctement le processus de développement lorsque vous travaillez en Agile.
La plupart des développements logiciels sont organisés en projets. Les organisations utilisent une grande variété de termes pour décrire les concepts liés à un projet, y compris le produit, le programme, la version, le cycle de lancement, la fonction, la chaîne de valeur, le flux de travail, etc. ...
La terminologie varie considérablement. Certaines entreprises pensent que la publication est synonyme de projet. D'autres pensent que la libération fait référence au développement progressif, alors ils ont arrêté de l'utiliser. D'autres encore définissent le concept de «fonction» comme la quantité de travail prévue pour 3 à 9 personnes et 1 à 2 ans. Dans ce chapitre, j'entends par le mot «projet» n'importe lequel des types de travail énumérés, c'est-à-dire le travail d'un certain nombre d'employés pendant une longue période.
Principe clé: petits projets
Au cours des 20 dernières années, les cas les plus connus d'application réussie d'Agile dans de petits projets. Pendant les 10 premières années de son existence, Agile a prêté une grande attention à garder les projets petits, c'est-à-dire 5 à 10 personnes dans une équipe (par exemple, 3 à 9 développeurs, un propriétaire de produit et un scrum master). L'accent mis sur la petite taille des projets est très important car les petits projets sont plus faciles à gérer que les grands, comme le montre la Fig. 9.1.
Capers Jones postule depuis 20 ans que les petits projets réussissent mieux que les grands [Jones, 1991; 2012]. J'ai résumé la plupart des recherches sur la réussite des projets par rapport à leur taille dans mes livres Code Perfect [McConnell, 2004; SPb.: Peter, 2007] et Software Estimation: Demystifying the Black Art [McConnell, 2006].
Les petits projets sont plus sûrs pour plusieurs raisons. Les grands projets nécessitent l'implication de plus de spécialistes et le nombre de relations entre les personnes en équipe et entre les équipes elles-mêmes augmente dans une progression non linéaire. Et plus la relation devient complexe, plus il y a d'erreurs dans l'interaction. Les erreurs d'interopérabilité entraînent des erreurs dans les exigences, la conception, le codage - en général, d'autres erreurs.
Par conséquent, plus le projet prend de l'ampleur, plus les erreurs sont commises (Figure 9.2). Cela signifie non seulement que le nombre total d'erreurs augmente, mais qu'il y a infiniment plus d'erreurs dans les grands projets!
Plus le taux d'erreur est élevé, plus l'efficacité des stratégies de détection des défauts est faible. Cela signifie que le nombre de défauts dans le produit fini augmente de manière disproportionnée.
Il faut également plus d'efforts pour éliminer les erreurs. Par conséquent, comme le montre la Fig. 9.3, les petits projets ont une productivité par personne plus élevée, mais plus la taille du projet est grande, plus la productivité diminue. Ce phénomène est connu sous le nom de coût d'échelle.
Cette relation inverse entre la taille et la performance a été largement étudiée et testée pendant plus de 40 ans. Fred Brooks a discuté du coût d'échelle dans le développement de logiciels dans la première édition de son livre The Mythical Man-Month [Brooks, 1975; SPb.: Peter, 2021]. Les travaux de Larry Putnam sur l'estimation des coûts de développement de logiciels ont confirmé les observations de Brooks [Putnam 1992]. L'étude du modèle des coûts de développement (Cocomo) a confirmé empiriquement l'existence de coûts d'échelle à deux reprises - dans une étude de la fin des années 1970 et dans une étude actualisée de la fin des années 1990 [Boehm, 1981; 2000].
Le point à retenir est que pour maximiser les chances de réussite d'un projet Agile, essayez de garder le projet (et l'équipe) de petite taille.
Bien sûr, il est impossible de faire de chaque projet un petit. Le chapitre 10, «Exécution encore plus efficace de grands projets», décrit les approches pour les grands projets, y compris des suggestions sur la façon de les réduire.
Principe clé: Sprints courts
La conclusion naturelle que les projets de petite taille sont préférables est que les sprints ne devraient pas durer longtemps. Vous pourriez penser qu'un petit projet est déjà la recette du succès. Mais de courts sprints de 1 à 3 semaines contribuent à une gestion de projet réussie. Ceci est décrit dans les prochaines sections.
Des sprints plus courts réduisent le nombre d'exigences intermédiaires et améliorent la réactivité aux nouvelles exigences
Dans Scrum, de nouvelles exigences peuvent être ajoutées entre les sprints. Mais une fois que le sprint a commencé, vous ne pouvez pas ajouter d'exigences avant le prochain sprint. Cela a du sens si le sprint dure de 1 à 3 semaines.
Si les cycles de développement prennent plus de temps, les parties prenantes demandent de plus en plus avec insistance d'ajouter des exigences en cours de route, de sorte que les demandes de report d'ajout d'exigences ne sont plus aussi justifiées. Si le cycle avec un modèle de développement séquentiel dure six mois, alors demander à la partie prenante de reporter la mise en œuvre de la nouvelle exigence au cycle suivant signifie que le travail sur l'exigence ne commencera que dans le cycle suivant - c'est-à-dire qu'au début du cycle, cette exigence ne sera ajoutée, puis vous devrez attendre la livraison du produit à la fin de celle-ci. cycle. En moyenne, cela prend 1,5 cycle, soit 9 mois.
En revanche, les sprints Scrum normaux durent deux semaines. Cela signifie qu'une partie prenante qui souhaite ajouter une nouvelle exigence devra attendre en moyenne trois semaines.
Demander à un intervenant d'attendre 9 mois pour qu'une exigence soit mise en œuvre est souvent inapproprié. Et trois semaines sont presque toujours appropriées. Cela signifie que l'équipe Scrum travaille tranquillement, sans craindre de nouvelles exigences au milieu du sprint.
Les sprints courts offrent une plus grande réactivité lorsque vous travaillez avec les clients et les parties prenantes
Chaque sprint présente une nouvelle opportunité de présenter des logiciels fonctionnels, de valider les exigences et de générer des commentaires des parties prenantes. Avec des sprints standard de deux semaines, les équipes se donnent l'opportunité d'être plus rapides 26 fois par an! Avec un cycle de développement de trois mois, cette opportunité n'est présentée que quatre fois par an. Il y a quinze ans, un projet de trois mois était considéré comme court. Aujourd'hui, un tel calendrier signifie que vous ne serez pas en mesure de répondre rapidement aux commentaires des parties prenantes, des clients et du marché.
Des sprints plus courts renforcent la confiance des parties prenantes
Au fur et à mesure que les équipes fournissent des résultats plus souvent, les progrès deviennent plus transparents, de sorte que les progrès sont visibles pour les parties prenantes, ce qui renforce la confiance entre elles et l'équipe.
Les sprints courts accélèrent le développement grâce à des cycles d'apprentissage et d'adaptation.
Plus le taux d'itération est élevé, plus l'équipe a l'occasion de réfléchir aux leçons apprises, de tirer des conclusions et d'appliquer les résultats à des méthodes de travail pratiques. La logique de ce domaine est la même que celle de la réactivité client: vaut-il mieux laisser vos équipes apprendre et s'adapter 26 fois par an, ou juste quatre? Les sprints courts aident votre équipe à s'améliorer plus rapidement.
Les sprints courts aident à réduire le temps d'expérimentation
Dans le contexte des problèmes enchevêtrés de Cynefin, les problèmes doivent d'abord être étudiés avant que la portée complète du travail puisse être comprise. Une telle recherche doit être caractérisée comme suit: «Pour obtenir une réponse à telle ou telle question, faites le moins de travail nécessaire». Malheureusement, la loi de Parkinson dit que le travail prend tout le temps disponible. Et jusqu'à ce que l'équipe développe une discipline de fer, la solution du problème, si un mois lui est alloué, prendra exactement un mois. Mais s'il n'y a que deux semaines, la solution du problème prend le plus souvent deux semaines.
Les sprints courts permettent une détection rapide des coûts et des risques
Les sprints courts vous permettent de suivre les progrès plus fréquemment. Après quelques sprints, lorsque vous travaillez sur une nouvelle tâche, la «vitesse» de l'équipe ou le rythme de progression sera déterminé. La possibilité de suivre l'avancement des travaux permet de prédire plus facilement le moment de la sortie du produit. Si le travail prend plus de temps que prévu, cela deviendra clair en quelques semaines. Les sprints courts sont un outil puissant pour rester informé. Le chapitre 20, «Encore une meilleure prévisibilité», donne plus de détails à ce sujet.
Les sprints courts favorisent la responsabilisation de l'équipe
Si une équipe est chargée de fournir des fonctionnalités de travail toutes les deux semaines, elle n'a pas la possibilité de travailler longtemps dans le noir. Elle montre les résultats de son travail lors de réunions de revue de sprint et rend compte aux parties prenantes toutes les deux semaines.
Le propriétaire du produit voit encore plus souvent les fruits du travail.
Le propriétaire du produit accepte ou rejette le travail, l'avancement du travail est clairement visible. Ainsi, les équipes sont mieux responsables de leur travail.
Les sprints courts favorisent la responsabilisation
Pendant des générations, les équipes de développement ont souffert des «étoiles» enfermées dans une pièce sombre pendant des mois, et on ne savait absolument pas si le travail progressait. Dans le cas de Scrum, ce problème n'existe plus. Tout le monde travaille pour soutenir les objectifs de l'équipe dans le sprint.De plus, il est nécessaire de venir tous les jours debout et de parler du travail qui a été fait hier - vous ne pourrez plus vous enfermer. Soit le développeur commence à coopérer, ce qui résout le problème d'une certaine manière, soit il ne supporte pas les conditions et quitte l'équipe, ce qui résout toujours le problème, quoique d'une manière différente. D'après ma propre expérience, je peux dire que n'importe lequel des résultats est plus favorable que dans le cas où quelqu'un travaille sans rapport pendant des semaines ou des mois, et en fin de compte, il s'avère que rien n'a vraiment été fait.
Les
sprints courts favorisent l'automatisation Les équipes effectuant souvent des rapprochements, les sprints courts peuvent automatiser des tâches qui seraient autrement répétitives et chronophages. L'automatisation est répandue dans l'assemblage, l'intégration, les tests et l'analyse de code statique.
Des sprints plus courts sont plus susceptibles de générer un sentiment de satisfaction Une
équipe qui fournit des logiciels fonctionnels toutes les deux semaines est plus susceptible d'être satisfaite de son travail et aussi plus susceptible d'avoir l'occasion de célébrer ses réalisations. Cela contribue à un sentiment de professionnalisme qui favorise la motivation.
Sprints courts. Sommaire
En général, les avantages des sprints courts peuvent être résumés comme suit: "La rapidité de livraison à tous égards aide à faire face au volume de travail." La fourniture de fonctionnalités en petits lots et à des cadences courtes apporte un grand nombre d'avantages par rapport à la fourniture de fonctionnalités en grands lots et à de longues cadences.
Planifier en fonction de la vitesse des tâches
Les unités de difficulté de l'histoire mesurent la taille et la complexité d'une tâche. La vitesse est une mesure de la progression basée sur la fréquence à laquelle les tâches sont terminées et mesurée en unités de difficulté de l'histoire. La planification basée sur la vitesse consiste à planifier et à suivre le travail en fonction des unités de difficulté de l'historique et de la vitesse de travail.
La planification et le suivi de la vitesse ne font pas partie du tutoriel Scrum, mais d'après mon expérience, je pense que ce serait une bonne idée de les inclure. Ensuite, je parlerai de la façon dont les unités de difficulté de l'histoire et les estimations de vitesse sont appliquées.
Estimation de la taille du backlog produit
La notation de la difficulté est utilisée pour déterminer la taille du backlog de produit. La taille des problèmes dans le backlog de produit est généralement estimée en termes d'unités de difficulté des histoires, puis les unités de complexité des histoires sont ajoutées pour calculer la taille totale du backlog de produit. Cela doit être fait au début du cycle de publication et au fur et à mesure que le travail est ajouté ou supprimé du backlog. Ceci est fait dans la mesure où l'équipe doit être prévisible. Pour en savoir plus, consultez le chapitre 20, «Une meilleure prévisibilité».
Calcul de la vitesse
La quantité de travail accomplie par l'équipe à chaque sprint est calculée en unités de difficulté de l'histoire. Le nombre d'unités de difficulté d'histoire atteint dans chaque sprint représente la vitesse de l'équipe. La vitesse est calculée en fonction des résultats de chaque sprint en calculant la moyenne.
Planification du sprint
L'équipe planifie la portée du travail par sprint, également mesurée en unités de difficulté de l'histoire, en fonction des observations de la vitesse de l'équipe.
Si une équipe a terminé 20 unités de difficulté d'histoire en moyenne par sprint et que le prochain sprint se fixe comme objectif de terminer 40 unités, elle doit réduire ses plans. Si un membre de l'équipe part en vacances ou si plusieurs membres de l'équipe participent à des événements d'entraînement, l'équipe doit prévoir moins de difficultés d'histoire par sprint qu'elle ne l'a fait en moyenne. Si l'équipe a réussi à atteindre 20 unités de difficulté des histoires grâce aux nuits blanches et au travail le week-end, la barre devrait également être abaissée. Si votre équipe atteint régulièrement et sans effort ses objectifs de sprint, essayez de planifier plus de difficulté d'histoire que la moyenne. Dans tous les cas, l'équipe planifie en fonction de sa vitesse réelle.
Suivi des versions
En fonction de la vitesse moyenne, vous pouvez calculer ou prédire le temps qu'il faudra pour terminer les tâches du backlog du produit. Si le backlog du produit comporte 200 unités de difficulté d'histoire et que la vitesse moyenne de l'équipe est de 20 unités de difficulté d'histoire par sprint, l'équipe aura besoin de 10 sprints pour terminer toutes les tâches du backlog. J'expliquerai plus en détail comment cela fonctionne dans le chapitre 20, «Encore une meilleure prévisibilité».
Prise en compte de l'impact des changements de processus, de composition de l'équipe et d'autres changements
En fonction de la vitesse, vous pouvez suivre l'impact des changements de processus, de composition de l'équipe et d'autres changements. Les spécificités de ceci sont discutées au chapitre 19, Améliorer encore mieux le processus.
Principe clé: livraison du produit en tranches verticales
Pour que les sprints soient efficaces, l'équipe doit développer la capacité de fournir fréquemment de petits lots de fonctionnalités fonctionnelles. L'approche de conception qui facilite cela s'appelle «utiliser des tranches verticales», ce qui signifie modifier chaque couche architecturale pour gagner en incrément ou en valeur.
La tranche verticale représente la fonctionnalité complète de la pile, comme l'ajout d'un champ à un relevé bancaire ou la confirmation de transaction d'un utilisateur une seconde plus rapide. Chacun de ces exemples nécessite généralement l'exécution de l'ensemble de la pile technologique, comme illustré à la figure 1. 9.4.
Les tranches verticales ont tendance à aider les parties prenantes non techniques à mieux comprendre, observer et mesurer la valeur commerciale. Ils donnent à l'équipe la possibilité de publier des versions plus rapidement et de réaliser la valeur réelle du produit pour l'entreprise, et d'obtenir de vrais commentaires des utilisateurs.
Les équipes utilisant des tranches horizontales courent le risque de plonger dans la jungle pendant plusieurs sprints d'affilée, travaillant sur des histoires qui reflètent certains progrès, mais n'apportent pas de valeur commerciale visible.
Les équipes hésitent parfois à utiliser des tranches verticales, généralement en raison d'une efficacité moindre. Ils soutiendront, par exemple, qu'il est plus efficace de travailler davantage dans la couche de logique métier, puis de passer à la couche d'interface. Cette approche s'appelle l'utilisation de tranches horizontales.
Dans certains cas, d'un point de vue technique, il peut être plus efficace de travailler sur des couches horizontales, mais une telle efficacité technique conduit en règle générale à l'optimisation des différentes parties du produit, ce qui n'est pas aussi important que l'obtention de fonctionnalités précieuses. Contrairement aux affirmations selon lesquelles l'utilisation de tranches horizontales conduit à une efficacité accrue, notre société a constaté que lors de l'utilisation de tranches horizontales, de nombreuses équipes sont confrontées à la nécessité d'apporter des corrections importantes.
Les tranches verticales fournissent des commentaires plus précis
Les tranches verticales vous permettent de fournir rapidement des fonctionnalités aux utilisateurs professionnels, ce qui vous aide à obtenir des commentaires rapides sur le fonctionnement correct de la fonctionnalité.
Parce que les tranches verticales nécessitent un développement de bout en bout, les membres de l'équipe sont obligés de travailler ensemble sur la conception et la mise en œuvre, ce qui fournit des commentaires techniques utiles à toute l'équipe.
L'utilisation de tranches verticales facilite également les tests de bout en bout, ce qui permet de garantir un retour d'information précis.
Les tranches verticales offrent plus de valeur commerciale
Les tranches verticales sont mieux comprises par les parties prenantes qui ne connaissent pas les détails techniques, ce qui conduit à de meilleures décisions de qualité que l'entreprise prend concernant la priorité et l'ordre de mise en œuvre des fonctionnalités nouvelles et révisées.
Étant donné que les tranches verticales fournissent un incrément fonctionnel complet, elles offrent souvent la possibilité de présenter des fonctionnalités de travail aux utilisateurs, ce qui augmente la valeur commerciale.
L'utilisation de tranches horizontales conduit les développeurs à percevoir l'architecture comme un produit. Et cela peut conduire à des activités gratifiantes totalement inutiles pour la fourniture de fonctionnalités, et à d'autres méthodes qui conduisent à une diminution de la valeur.
Ce dont une équipe a besoin pour utiliser des tranches verticales
Fournir des fonctionnalités avec des tranches verticales peut être difficile. Cela dépend de la composition de l'équipe, de ses capacités commerciales, de développement et de test, qui incluent des compétences sur l'ensemble de la pile technologique.
Les équipes peuvent également avoir besoin de modifier leur conception et leur mise en œuvre pour travailler avec des tranches verticales, ce qui sera différent du travail par composants ou par couches horizontales. Certaines équipes manquent de compétences en conception pour ce faire et devront développer (et soutenir le développement) des compétences pour y faire face.
Enfin, les équipes doivent effectuer leur travail par tranches verticales. Le propriétaire du produit et l'équipe de développement doivent trouver une approche pour affiner le backlog afin que le résultat soit des tranches verticales.
Principe clé: gérer la dette technologique
La «dette technologique» fait référence à l'accumulation de travail de mauvaise qualité dans le passé qui ralentit le rythme du travail dans le présent. L'exemple classique est une base de code fragile où chaque tentative de correction d'un bogue en génère un ou plusieurs nouveaux. Même la correction d'une simple erreur prend du temps et la correction d'erreurs supplémentaires.
La dette technique peut inclure un code de mauvaise qualité, une conception de mauvaise qualité, une suite de tests faible, une approche de conception difficile, un environnement de construction encombrant, des processus manuels lents et d'autres façons dont une équipe sacrifie les performances à long terme au profit de gains à court terme.
Conséquences de la dette technique
La dette s'accumule généralement sous la pression de donner la priorité aux rejets à court terme au détriment de la qualité. Une vision holistique des ressources investies et des rendements obtenus comprend la prise en compte de l'impact de la dette technique dans le temps.
Les équipes techniques et commerciales peuvent avoir des raisons impérieuses d'accumuler cette dette. Certaines versions sont suffisamment sensibles au temps pour justifier un travail supplémentaire plus tard en raison du désir d'accomplir le travail plus rapidement dans le présent.
Cependant, un modèle qui permet à la dette technique de s'accumuler au fil du temps sans plan pour régler cette dette réduira finalement la vitesse de l'équipe. L'équipe doit élaborer un plan de gestion de la dette pour maintenir ou augmenter sa vitesse.
Kruchten, Nord et Ozkaya ont développé un excellent diagramme de la façon dont la dette technique naît, de la valeur commerciale (probable) qu'elle a et de la manière dont elle devient finalement plus un passif qu'un actif (graphique 9.5).
En travaillant à partir de zéro, les équipes peuvent éviter d'accumuler des dettes techniques en premier lieu. Lorsqu'elles exécutent un travail déjà commencé, les équipes n'ont souvent d'autre choix que de travailler avec la dette technique déjà accumulée. Dans tous les types de travail, si l'équipe ne se débrouille pas bien avec la dette technique, la vitesse diminuera avec le temps.
Remboursement de la dette technique
Différentes équipes ont des approches différentes pour rembourser la dette technique . Certaines équipes, afin de rembourser la dette, la répartissent en actions à chaque cycle de développement (sprint ou release). D'autres équipes ajoutent des dettes à l'arriéré de produits ou à la liste des lacunes et priorisent la dette et le reste du travail. Dans tous les cas, la principale caractéristique est que la dette technique est gérée ouvertement.
Types de dette et comment y faire face
Toutes les dettes techniques ne sont pas identiques et il existe différentes classifications. Je trouve ces catégories utiles:
- Dette intentionnelle (à court terme). Dette dérivée de considérations tactiques ou stratégiques, telles que la publication d'une publication urgente à temps.
- Dette intentionnelle (à long terme). Dette dérivée de considérations stratégiques, telles que la prise en charge initiale d'une plate-forme unique au lieu de la prise en charge de plusieurs plates-formes.
- Dette non intentionnelle (mauvaise foi). Dette qui survient par hasard en raison de méthodes de développement de mauvaise qualité. Ce type de dette ralentit le travail à la fois dans le présent et dans le futur, il faut donc l'éviter.
- Dette non intentionnelle (bonne foi). Dette accidentelle due à des erreurs naturelles de développement logiciel («Notre approche de conception n'a pas fonctionné aussi bien que prévu» ou «La nouvelle version de la plate-forme présentait de graves défauts de conception»).
- Dette héritée. Dette héritée par la nouvelle équipe de l'ancienne base de code.
Le tableau 9.1 montre les approches recommandées pour répondre à ces types de dette.
Avantages de discuter de la dette technique
D'après mon expérience, la métaphore «dette technique» a été utile pour faciliter les discussions entre les professionnels de la technologie et des affaires. Les professionnels des affaires ne savent généralement pas quels sont les coûts de remboursement de la dette technique, et les techniciens ne connaissent généralement pas les intérêts commerciaux. Dans certains cas, il peut être judicieux de laisser délibérément la dette technique s'accumuler, et dans d'autres, ce n'est pas le cas. La dette facilite l'échange de vues sur des considérations techniques et commerciales, ce qui le rend plus significatif, ce qui améliore la qualité des décisions concernant le moment et le pourquoi de l'endettement et le moment et la manière de le rembourser.
Construisez votre structure de travail pour éviter l'épuisement professionnel
La vision puriste d'Agile suppose la même durée de sprint (appelée «cadence partagée»). Si l'équipe s'adapte bien à la cadence globale, il ne sert à rien de faire des changements. Les cadences partagées facilitent le calcul de la vitesse et d'autres facteurs lors de la planification d'un sprint.
Une plainte courante lors de la mise en œuvre de Scrum est qu'une séquence sans fin de sprints conduit à la fatigue et à la sensation de courir dans la roue. Avec un développement constant, il y a des échecs naturels dans la performance, en particulier entre les disciplines, et l'équilibre pendant les périodes de haute intensité.
Les sprints constants ne laissent pas le temps de se reposer si chaque sprint se déroule effectivement à un rythme de sprint.
L'un des antidotes à la fatigue après les sprints est de modifier la durée des sprints selon les besoins. La manière systématique de le faire est d'utiliser un modèle 6x2x1, six sprints de deux semaines, plus un sprint d'une semaine, pour un total de 13 semaines, soit exactement un quart.
Une alternative serait d'utiliser des sprints raccourcis après les versions majeures, les jours fériés et à d'autres moments où la vitesse de l'équipe ne sera toujours pas stable. Au cours d'un sprint d'une semaine, une équipe peut travailler sur une infrastructure ou des outils, assister à des événements de préparation ou d'équipe, des hackathons, travailler sur la dette technique, travailler sur des améliorations trop importantes pour être complétées dans un sprint, ou autre chose.
La durée variable de la cadence de sprint est cohérente avec le concept de rythme soutenu utilisé en Agile. De nombreuses recherches Agile assimilent un rythme régulier à un manque de soirées et de week-ends gratuits. Mais je pense que c'est une simplification exagérée ennuyeuse qui ignore les différences de préférences pour les conditions de travail de différentes personnes. Certains suggèrent une semaine de travail de 40 heures comme rythme régulier, mais pour d'autres, c'est une route vers l'ennui. Personnellement, j'ai fait l'essentiel de mon meilleur travail en mode explosif - 55 heures sur deux semaines puis 30 heures sur les deux semaines suivantes. En moyenne, il peut travailler environ 40 heures de travail par semaine, mais différentes équipes n'ont pas toujours 40 heures de travail. La compréhension d'un rythme régulier est différente pour chacun.
Autres considérations
Développement de logiciels hors conception
Tous les développements de logiciels ne sont pas organisés en projets, même avec les nombreuses définitions au début de ce chapitre. Parfois, il existe des situations dans lesquelles une personne travaille généralement, par exemple, il est courant de gérer les appels au support technique, de résoudre les problèmes de publication, de créer des correctifs, etc.
Un tel travail est bien entendu lié au développement logiciel et se prête également aux pratiques Agiles. Ils peuvent être réalisés de manière plus efficace, qualitative et méthodique grâce à la mise en œuvre de méthodes Agiles pratiques telles que le Lean Manufacturing et Kanban. Mais d'après mon expérience, les entreprises ont tendance à avoir beaucoup moins de problèmes avec ce type de travail qu'avec le développement de logiciels à l'échelle du projet, de sorte que ce livre se concentre sur le travail sur des projets plutôt que sur des travaux ponctuels.
Étude de recommandations :
- Passez en revue l'historique des totaux du projet. L'expérience de votre entreprise est-elle cohérente avec le consensus général selon lequel les petits projets ont plus de chances de réussir que les grands?
- Parcourez votre portefeuille de projets. Lequel de vos grands projets peut être divisé en plusieurs plus petits?
- , . ? ?
- , .
- , .
- . ?
- .
- , , .
- .
- [ , 1975]. -. , , .
- [ , 2019]. Understanding Software Projects Lecture Series. Construx OnDemand. (2019 ). ondemand.construx.com. .
- [ , 2012]. Essential Scrum: A Practical Guide to the Most Popular Agile Process. , .
- [ ., 2019]. Managing Technical Debt. .
»Plus de détails sur le livre peuvent être trouvés sur le site de la maison d'édition
» Table des matières
» Extrait
Pour Habitants un rabais de 25% sur le coupon - Agile
Lors du paiement de la version papier du livre, un e-book est envoyé à l'e-mail.