Comment puis-je suivre les attributs de qualité sur le Kanban de mon équipe?

Mon équipe utilise un système Kanban pour suivre les progrès au jour le jour et il a très bien fonctionné pour comprendre les progrès sur les fonctionnalités (capturées en tant que user stories). Nous avons largement laissé émerger la conception de notre système à mesure que nous développions des fonctionnalités qui fonctionnaient bien jusqu'à récemment. Au cours des deux dernières semaines, nous avons eu plusieurs discussions sur les compromis architecturaux spécifiquement liés aux attributs de qualité de performance et de modifiabilité.

Je pense que ce qui se passe, c'est que lorsque nous implémentons des fonctionnalités et concevons le système, nous prenons implicitement des décisions concernant l'architecture, mais ne considérons pas ces décisions en fonction de nos exigences d'attributs de qualité connues. Ce serait vraiment génial si je pouvais suivre / capturer / décrire visuellement comment ces importantes décisions de conception sont prises afin que les membres de l'équipe aient une meilleure chance de ne pas créer de tension supplémentaire dans l'architecture du système lors de sa mise en œuvre. Et bien sûr, pour compliquer davantage les choses, les fonctionnalités de notre carte ne sont pas exclusivement fonctionnelles et cachent parfois la complexité architecturale!

Comment puis-je suivre visuellement la progression des attributs de qualité (ou d'autres décisions pertinentes sur le plan architectural) sur le kanban de mon équipe?

nous prenons implicitement des décisions concernant l'architecture, mais nous ne considérons pas ces décisions en fonction de nos exigences d'attributs de qualité connues.

Je pense que vous pouvez visualiser cela en créant une étape de "révision architecturale" dans votre flux de travail. L'étape serait représentée par une colonne de tableau Kanbad avec sa propre limite WIP. La limite WIP dépendra du nombre d'architectes / designers que vous devrez participer à ces évaluations.

L'équipe de développement est responsable du flux horizontal de gauche à droite des user stories. Dans la plupart des cas, le ou les architectes ne toucheront les histoires que lorsqu'elles se trouvent dans la colonne de revue architecturale / technique. L'intersection de la colonne avec un couloir horizontal permet de visualiser la rencontre du (des) développeur (s) et architecte (s).

L'une des équipes où je travaille a une étape similaire où ils font un examen du schéma de base de données avec l'architecte en chef des données. Ils n'utilisent pas Kanban, mais s'ils le faisaient, ils auraient très probablement cette colonne sur leur tableau.

Les attributs de qualité connus pourraient alors être représentés comme:

• la définition de fait pour l'étape de revue architecturale.
• tests d'acceptation autour des user stories déjà réalisées représentant des exigences non fonctionnelles. Ensuite, la définition de terminé pour une nouvelle user story comprendrait la non-rupture de ces tests.

AJOUT : L'étape du flux de travail "revue architecturale" peut être suspecte d'un problème appelé tragédie des communs . Voici un excellent article de blog sur la façon dont la visualisation Kanban peut aider à y faire face et les solutions possibles.

Il y a vraiment deux parties à cette question. Une partie est: comment savoir quand l'architecture est modifiée. La deuxième partie est: Comment savons-nous que l'architecture est toujours bonne.

Pour cette première partie: Comment savoir quand l'architecture est modifiée?

Le but ici est de prendre quelque chose qui se fait implicitement et de le rendre explicite

• La suggestion d'Alexei est une option. Créez une colonne sur le tableau pour la révision de l'architecture. Déplacez ensuite une carte là-bas si cela nécessite des décisions architecturales
• Une autre option consiste à créer une politique explicite sur la façon de gérer cela: "Si nous devons changer d'architecture, nous devons nous associer à quelqu'un d'autre" est un exemple d'une telle politique. Dans un projet, nous avions une politique selon laquelle les modifications de code de certains modules spécialisés devaient être effectuées en associant des personnes spécifiques. Quand quelqu'un voulait changer de code là-bas, il appelait une paire et faisait équipe. Le reste du travail s'est fait en solo. Vous pouvez faire quelque chose de similaire avec l'architecture.

Vous iriez probablement avec la première, si de nombreuses cartes nécessitent une révision, ou si l'architecte ne fait pas partie de l'équipe et qu'un transfert est nécessaire, ou la révision sera suffisamment détaillée pour prendre un certain temps sur lequel vous souhaitez effectuer le suivi. le tableau. Ce dernier est une option si seulement quelques cartes touchent l'architecture, et il est facile d'en trouver une paire à la demande.

Venons-en maintenant à la deuxième question: comment savons-nous que l'architecture est toujours bonne?

Je suis un grand fan de visualisation. Vous pourriez avoir un tableau sur le tableau blanc avec des notes post-it décrivant les composants et l'architecture.

Il existe également des analyseurs statiques qui analyseront la base de code et généreront une image avec un graphique de dépendance de divers composants. Vous pouvez l'exécuter, prendre une impression et la coller sur un mur une fois par semaine environ. Peut-être que les deux dernières impressions pourraient être sur le mur, vous pouvez donc voir si quelque chose a changé au cours de la semaine dernière.

Ce que cela vous permet de faire, c'est de rendre votre architecture et votre design visibles. Les membres de l'équipe y jetteront un coup d'œil de temps en temps et le commenteront si quelque chose pourrait être changé ou refactorisé ou fait d'une meilleure manière.

J'ai vu ce problème aussi. Prise de décision implicite! Si l'implicite est le problème, le rendre aussi explicite que possible résoudra-t-il le problème? Ce que je suggère, c'est de modifier un peu le processus d'architecture pour «commencer à expliquer» les pensées implicites qui progressent pour devenir des décisions. L'étape supplémentaire du processus a pour but de faire comprendre aux membres de l'équipe que tout le monde est enclin à prendre des décisions architecturales implicites. Cette étape ne fera que maintenir la décision implicite hors de la piste.

Garder les «décisions explicites implicites» comme partie du kanban pour chacun des scénarios pourrait aider.

Ce que je vais suggérer pourrait être lourd. Mais si le processus est mappé à un ensemble d'éléments de kanban et si cela est ajouté au tableau pour chaque scénario d'arc, cela ne vous aidera-t-il pas à le suivre. Je suggère que vous puissiez également les mapper au modèle de scénario en six parties et improviser le tableau kanban pour tenir compte des résultats, les AQ peuvent être suivis.

Vikram.

C'est l'un des risques de retarder les décisions architecturales des équipes Agile. De toute évidence, la chose la plus responsable pour être agile est de retarder les décisions architecturales jusqu'au dernier moment responsable . Mais les chances sont que le dernier moment responsable peut (ou doit) se produire tôt.

Une chose qui aide est de définir clairement au début de vos principales exigences de conduite; des choses que vous savez clairement que vous devez avoir (mais que vous n'avez pas nécessairement à implémenter pour le moment.) Votre architecture évolutive (qui tente d'être minimaliste et flexible) devrait s'adapter à la prise en charge actuelle ou future de ces exigences.

Plus important encore, cependant, votre architecture en évolution NE DOIT PAS implémenter des artefacts qui obtiennent (ou peuvent obtenir) de la manière de prendre en charge ces exigences de conduite clés, même si ces artefacts sont destinés à résoudre les exigences actuelles. Nous pouvons désigner ces artefacts comme des artefacts interférents , des artefacts qui fournissent une valeur réelle (car ils implémentent une solution aux exigences existantes) mais dont la présence rend difficile / coûteux la mise en œuvre d'une future exigence de conduite clé.

Dans les cas où vous devez implémenter un artefact interférant, votre tâche serait de planifier sa suppression à un moment donné (afin que vous puissiez implémenter l'exigence de conduite clé qui est interférée.)

Évidemment, tout cela est ésotérique sans contexte réel et tangible (comme un vrai projet). Mais plus ou moins votre modèle de processus de développement et votre architecture évolutive doivent tenir compte de ces considérations.

Les exigences implicites sont au cœur des architectures, tout doit être rendu explicite, à la fois les principales exigences de conduite et celles qui sont accessoires. Vous n'avez pas besoin de mettre en œuvre une exigence dès le début. Il vous suffit de pouvoir en rendre compte.

PS. Par exigence, j'entends les exigences architecturales au niveau du système et pas nécessairement les exigences éphémères au niveau de l'application qui peuvent être satisfaites sans modifications substantielles de l'architecture. J'espère que cela aide.