histoires système pour l'architecture agile [fermé]

Question

Tout en essayant d'appliquer les principes agiles à notre processus de développement, en particulier les principes de Scrum et des histoires d'utilisateurs comme XP, nous avons fait face à un problème sur l'architecture.

Peut-être que nous sommes encore trop liés au développement de l'architecture centrée, mais nous essayons de maintenir un développement basé sur une forte composante, mélangé avec les principes de modélisation agile. Notre objectif est d'avoir une petite conception à l'avant, sujettes à des évolutions au cours du développement.

Qu'est-ce que je cherche quelque chose qui pourrait me laisser placer dans mes histoires de backlog sur mon architecture et les composants à l'intérieur de celui-ci: des histoires de développement, non seulement des histoires d'utilisation. histoire du système pourrait être un autre genre d'histoire d'utilisateur, qui raconte quelque chose qui est pas strictement liée à la valeur commerciale, mais est plutôt lié aux préoccupations de l'architecture et la qualité d'un système.

Edit: J'ai trouvé cette recherche de l'Université d'Aalborg au sujet de " histoires de développeur " .

Avez-vous une expérience, une idée ou opposition?

Merci d'avance! (Ce qui est ma première question: D)

Answer 1

OMI un carnet de commandes devrait pas inclure des histoires de développement. Il n'y a aucun moyen que tout propriétaire du produit peut donner la priorité sensiblement ces fonctionnalités aux côtés des entreprises. Et ce qui se passe si le propriétaire du produit juge l'un d'entre eux sans importance et donc tire le carnet de commandes? Si l'équipe insiste ensuite sur le maintien de l'histoire, vous êtes dans une situation où la propriété de l'arriéré devient pas claire.

Cependant, je ne pense vraiment que l'équipe a besoin de construire une architecture très tôt dans le projet. Un problème sur mon projet était que nous concentrons trop sur la fonctionnalité dans les premiers sprints.

Réfléchissons « dette architecturale » (semblable à la dette technique) que le temps qui doit être l'infrastructure et l'architecture bâtiment passé. Contrairement à la dette technique (qui commence à zéro et construit que l'équipe produit une fonctionnalité sans refactoring appropriée), une équipe commence avec la dette architecturale et doit travailler pour le réduire. Le temps passé réduction de la dette architecturale signifie que moins de temps est consacré à la production fonctionnalité, à savoir une vitesse d'équipe plus faible et réduit la production de sprint. De cette façon, la dette d'architecture est similaire à la dette technique. Si les exigences sont apparues qui ne correspondait pas à l'architecture actuelle, le niveau de la dette architecturale augmenterait.

Gardez à l'esprit que l'équipe doit décider (et être en mesure de justifier le propriétaire du produit) comment ils vont passer leur temps. Et ils peuvent partager leur effort entre la fonctionnalité, la dette technique et de la dette architecturale comme ils l'entendent.

Travaux d'architecture devrait encore être tirée par la fonctionnalité bien. En d'autres termes, l'équipe doit construire des infrastructures pour soutenir et permettre une histoire d'utilisateur particulier. Non seulement parce qu'ils pensent qu'il sera utile à l'avenir. Le principe YAGNI applique à ce genre d'approche.

Answer 2

Ma réponse applique.

Il y a un équilibre très difficile entre faire un travail d'architecture et plus caractéristique des travaux spécifiques. Techniquement les deux sont des approches valides et le travail, mais plus vous retardez une certaine quantité de produit utilisable (résultats de sprint) plus le risque que vous prenez que vous n'êtes pas la construction du produit droit (les besoins des utilisateurs, les exigences de performance, ect.). Dès que vous le pouvez, arriver à un point où vous pouvez effectuer des tests de niveau système pour prouver votre produit fonctionne et vous pouvez démontrer la valeur et la direction du produit avec vos parties prenantes.

Answer 3

Il 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 histoire, votre carnet « utilisateur » AURAIT système / développement histoires, aussi longtemps qu'il est sync'ed avec le désir du propriétaire du produit de cette mise en œuvre.

Voici comment nous l'habitude de mettre les exigences non fonctionnelles dans un carnet de commandes, comme « Le modèle de domaine doit fonctionner sur un centre de données différent sous équilibrage de charge » etc.

Answer 4

Un objectif que je trouve utile de prendre des histoires de développeurs est de penser à qui « l'utilisateur » pour une histoire donnée est. Tout simplement parce que vous n'êtes pas d'écrire une fonction qui sera vu par des personnes en dehors de votre entreprise ne veut pas dire qu'il n'y a pas un utilisateur pour ce morceau de travail. Vous pouvez écrire un code pour une équipe dans le couloir. Dans certains cas, l'utilisateur est vous-même. Cela est souvent le cas pour les histoires de développement. Pensez « En tant que développeur, j'ai une architecture évolutive pour que je puisse facilement ajouter de nouvelles fonctionnalités. » En appelant à l'utilisateur particulier, il donne le propriétaire du produit un aperçu qui verra la valeur de l'histoire. Et en soulignant le « pourquoi » est également utile de transmettre quel avantage l'histoire espère atteindre. Comme d'autres l'ont mentionné, la gestion du carnet de commandes ne se réduire à une négociation entre le propriétaire du produit et l'équipe. Et comme toujours, vous avez besoin de comprendre ce qui fonctionne le mieux pour votre équipe, quel que soit le dogme du processus. Chaque équipe a une situation différente, et des idées qui fonctionnent bien pour une équipe ne se traduisent pas toujours à l'autre.

Answer 5

Dans notre équipe, nous l'appelons « IT-cartes », ce qui est des cartes de la forme: «.. En tant que développeur, je wan't à factoriser la composante xyz Pour réduire les coûts d'entretien et d'accroître la flexibilité »

Les membres de l'équipe sont libres de choisir une carte informatique qu'ils jugent importante au lieu de sauter un « Feature carte » de l'arriéré prioritaire.

Je trouve que cette approche fonctionne assez bien pour maintenir la dette technique à un niveau acceptable et permettre à un bon rythme de l'innovation.

Je l'ai trouvé un peu comme manquant un moyen de re-architecturer le système bien. Il est difficile de justifier de longs départs de la fonction flux de production.

Comme j'écris cela, je pense que l'on pourrait aborder l'architecture par thématisation les histoires. Identifier les objectifs architectual avec épopées que vous décomposera en un thème de se concentrer sur.