Tout en essayant d'appliquer des principes agiles à notre processus de développement, en particulier des principes de Scrum et des histoires d'utilisateurs de type XP, nous avons rencontré un problème de l'architecture.
Peut-être que nous sommes toujours trop liés au développement centré sur l'architecture, mais nous essayons de maintenir un développement solide basé sur des composants, mélangés aux principes de modélisation agiles. Notre objectif est d'avoir un petit design à l'avant, sujet aux évolutions pendant le développement.
Ce que je cherche, c'est quelque chose qui pourrait me laisser placer dans mes histoires d'arriéré sur mon architecture et mes composants à l'intérieur: des histoires de développement, non seulement des histoires d'utilisation. L'histoire du système pourrait être un type d'usure différent, qui indique quelque chose qui n'est pas strictement lié à la valeur commerciale, mais qui est plutôt liée à l'architecture et aux préoccupations de la qualité d'un système.
EDIT:
J'ai trouvé Cette recherche de l'Université Aalborg à propos de " Histoires de développeurs " .
Avez-vous une expérience, une idée ou une opposition?
Merci d'avance! (Ceci est ma première question !: D)
5 Réponses :
Ma réponse ici s'applique.
Il y a un équilibre très difficile entre faire du travail d'architecture et plus de travail spécifique. Techniquement, les deux sont des approches et des travaux valides, mais plus vous retardez la quantité de produit utilisable (résultats de sprint) plus volumineux que vous prenez le risque que vous prenez que vous ne construisez pas le bon produit (exigences de l'utilisateur, exigences de performance, ECT.). Dès que vous pouvez, accédez à un point où vous pouvez effectuer des tests de niveau système pour prouver vos travaux de produit et vous pouvez démontrer la valeur et la direction du produit avec vos supports de pieu.
Je crois que cela a plus à voir avec une approche "Sprint 0", où vous identifiez les goulots d'étranglement et les défis techniques possibles et les mettre en cours de test avant de commencer le développement. Cela n'a pas zéro le risque mais le minimisera considérablement.
C'est aussi simple que de mettre un Assurez-vous que le composant d'adhésion peut être testé débranché de tous les autres composants «Utilisateur», votre arriéré doit avoir des histoires système / développement, aussi longtemps que cela est synchronisé avec le désir du propriétaire du produit de cette mise en œuvre.
C'est ainsi que nous mettons généralement les exigences non fonctionnelles dans un arriéré, comme "Le modèle de domaine doit exécuter sur un autre centre de données sous la charge d'équilibrage", etc.
IMO Un arriéré doit pas inclure des histoires de développeurs. Il n'existe aucun moyen que tout propriétaire de produit puisse les hiérarchiser judicieusement de ces fonctionnalités commerciales. Et que se passe-t-il si le propriétaire du produit estime l'un d'entre eux sans importance et tire ainsi l'arriéré? Si l'équipe insiste alors sur la conservation de l'histoire, vous êtes dans une situation où la propriété de l'arriéré devient peu claire.
Cependant, je pense certainement que l'équipe doit construire une architecture tôt dans le projet. Un problème sur mon projet était que nous nous concentrions trop fortement sur la fonctionnalité dans les premières sprints.
Pensons à "la dette architecturale" (semblable à la dette technique) que le temps nécessaire à la construction d'infrastructures et d'architecture consacrées à la construction. Contrairement à la dette technique (qui commence à zéro et s'accumule à mesure que l'équipe produit des fonctionnalités sans refactorisation appropriée), une équipe Gardez à l'esprit que l'équipe devrait décider (et être capable de justifier au propriétaire du produit) Comment ils vont passer leur temps. Ils peuvent donc diviser leurs efforts entre la fonctionnalité, la dette technique et la dette architecturale à leur guise.
Les travaux d'architecture devraient encore être motivés par la fonctionnalité. En d'autres termes, l'équipe devrait construire des infrastructures à soutenir et à permettre une histoire d'utilisation particulière. Pas seulement parce qu'ils pensent que cela sera utile à l'avenir. Le principe Yagni s'applique à ce type d'approche.
Enchantant un commentaire! Merci! Tu as vraiment effacé mon esprit :). J'ai eu une recherche et j'ai trouvé des articles intéressants avec des définitions de dettes tacchniques ( blogs.construx.com/blogs/stevemcc/archive/2007/11/01/... - codeartisan.blogspot.com/2008/08/... ). Je pense que la conservation des dettes de contrôle, mélangée à une petite approche de conception peut être le bon choix pour nous.
Une lentille que je trouve utile pour prendre des histoires de développeurs est de penser à qui "l'utilisateur" pour une histoire donnée est. Ce n'est pas parce que vous n'écrivez pas une fonctionnalité qui sera vue par des personnes extérieures à votre entreprise ne signifie pas qu'il n'y a pas d'utilisateur pour ce travail. Vous pouvez écrire du code pour une équipe dans la salle. Dans certains cas, l'utilisateur est vous-même. C'est souvent le cas pour les histoires de développeurs. Pensez "en tant que développeur, j'ai une architecture évolutive afin que je puisse facilement ajouter de nouvelles fonctionnalités." En appelant l'utilisateur en particulier, il donne au propriétaire du produit un aperçu de l'OMS qui verra la valeur de l'histoire. Et soulignant le "pourquoi" est également utile pour transmettre ce qui profite à l'histoire espère atteindre. Comme d'autres l'ont mentionné, la gestion de l'arriéré se présente à une négociation entre le propriétaire du produit et l'équipe. Et comme toujours, vous devez déterminer ce qui fonctionne le mieux pour votre équipe, quel que soit le dogme de processus. Chaque équipe a une situation différente et des idées qui fonctionnent bien pour une équipe ne se traduisent pas toujours vers une autre.
Dans notre équipe, nous l'appelons "cartes it-cartes", qui sont des cartes de la forme: "En tant que développeur. Je ne voudrais pas refacturer le composant XYZ. Pour réduire les coûts de maintenance et augmenter la flexibilité."
Les membres de l'équipe sont libres de choisir n'importe quelle carte informatique qu'ils jugent importants au lieu de faire apparaître une "carte de fonctionnalité" de l'arriéré prioritaire.
Je trouve cette approche pour travailler raisonnablement pour conserver la dette technique à un niveau acceptable et permettre un rythme sain de l'innovation.
Je l'ai trouvé quelque peu manquant de moyen de ré-archiver le système. Il est difficile de justifier de longs départs à partir du flux de production de fonctionnalités.
Comme je vous écris, je pense que l'on pourrait approcher de l'architecture en présentant les histoires. Identifiez les objectifs d'architecture avec des épopées que vous tombez dans un thème pour vous concentrer sur.