私のチームは、日々の進行状況を追跡するためにかんばんシステムを使用しており、機能（ユーザーストーリーとしてキャプチャ）の進行状況を理解するために非常にうまく機能しています。最近までうまく機能していた機能を開発するにつれて、システム設計の出現をほぼ許可しました。過去2週間で、パフォーマンスと変更可能性の品質属性に特に関連するアーキテクチャのトレードオフについていくつかの議論がありました。
私が思うに、機能を実装してシステムを設計するときに、アーキテクチャについて暗黙的に決定を下しますが、既知の品質属性要件に関してはそれらの決定を考慮していません。これらの重要な設計上の決定がどのように行われているのかを追跡/キャプチャ/視覚的に表現できれば、チームメンバーが実装中にシステムのアーキテクチャにさらなる緊張を生じさせないようになります。そしてもちろん、より複雑なものに、私たちのボード上の機能はありません、排他的、機能的で、時には建築の複雑さを隠します！
チームのかんばんの品質属性（またはその他のアーキテクチャに関連する決定）の進捗を視覚的に追跡するにはどうすればよいですか？
回答:
アーキテクチャに関する暗黙の決定を行っていますが、既知の品質属性要件の観点からそれらの決定を考慮していません。
ワークフローに「アーキテクチャレビュー」ステップを作成すると、これを視覚化できると思います。このステップは、独自のWIP制限があるKanbadボードの列で表されます。WIPの制限は、これらのレビューに参加する必要があるアーキテクト/デザイナーの数によって異なります。
開発チームは、ユーザーストーリーの水平方向の左から右への流れを担当します。ほとんどの場合、アーキテクトは、それらが建築/技術レビューの列にあるときにのみストーリーに触れます。列と水平スイムレーンの交差点は、開発者と建築家の出会いを視覚化します。
私が働いているチームの1つには、チーフデータアーキテクトとデータベーススキーマのレビューを行う同様のステップがあります。彼らはかんばんを使用しませんが、使用した場合、ボードにこの列がある可能性が非常に高くなります。
既知の品質属性は、次のように表すことができます。
追加：「建築レビュー」ワークフローステップは、コモンズの悲劇と呼ばれる問題の疑いがあるかもしれません。 かんばんの視覚化がカンバンの視覚化にどのように役立つか、および可能な解決策についての素晴らしいブログ投稿があります。
この質問には本当に2つの部分があります。1つは、アーキテクチャが変更されたときをどのように知るかです。2番目の部分は、アーキテクチャがまだ良好であることをどのように知るかです。
この最初の部分：アーキテクチャが変更されたとき、どのようにして知るのですか？
ここでの目標は、暗黙的に行われていることを取り上げ、それを明示的にすることです
多くのカードがレビューを必要とする場合、アーキテクトがチームの一部ではなくハンドオフが必要な場合、またはレビューが追跡するのに時間がかかるほど詳細になりそうな場合は、おそらく前者を使用しますボード。後者は、アーキテクチャに触れるカードが少ない場合のオプションであり、オンデマンドで簡単にペアを見つけることができます。
次に2番目の質問に進みます。アーキテクチャがまだ良好であることをどのようにして知ることができますか？
私は視覚化の大ファンです。ホワイトボード上に、コンポーネントとアーキテクチャを説明するポストイットのメモ付きのチャートを作成できます。
コードベースを分析し、さまざまなコンポーネントの依存関係グラフを含むイメージを生成する静的アナライザーもあります。あなたはそれを実行し、印刷物を取り出して、週に1回程度壁に貼り付けることができます。おそらく、最新の2つの印刷物が壁に貼られている可能性があるため、先週に何か変更があったかどうかを確認できます。
これらがあなたにできることは、あなたのアーキテクチャとデザインを見えるようにすることです。チームメンバーは時々それを一見し、何かが変更、リファクタリング、またはより良い方法で行われる可能性がある場合はコメントします。
私もこの問題を見ました。暗黙の意思決定！暗黙性が問題である場合、可能な限り明示的にすることで問題は解決しますか？私が提案するのは、アーキテクチャプロセスを少し微調整して、進行して決定になる暗黙の考えを「明示的に開始」することです。プロセスの追加ステップの目的は、チームメンバーに、誰もが暗黙的なアーキテクチャ上の決定を下す傾向があることを理解させることです。このステップは、暗黙の決定を軌道に乗せないようにします。
各シナリオのかんばんの一部として「暗黙の決定を明示する」を維持することが役立つ場合があります。
私が提案することは面倒かもしれません。しかし、プロセスが一連のかんばんアイテムにマップされており、これが各アーチシナリオのボードに搭載されている場合、追跡に役立ちません。また、6部構成のシナリオテンプレートにマップし、調査結果に合わせてかんばんボードを即興で作成することをお勧めします。QAを追跡できます。
ヴィクラム。
これは、アジャイルチームのアーキテクチャの決定を遅らせるリスクの1つです。明らかにアジャイルであることに対する最も責任のあることは、最後の責任がある瞬間まで建築決定を遅らせることです。しかし、チャンスは、早期に発生する可能性がある（または必要な）最後の責任の瞬間です。
役立つことの1つは、重要な運転要件を早期に明確に示すことです。持っている必要があることが明確にわかっているもの（ただし、必ずしも今すぐ実装する必要はありません。）進化するアーキテクチャ（最小化と柔軟性を試みる）は、そのような要件に対する既存または将来のサポートに対応する必要があります。
ただし、さらに重要なことは、進化しているアーキテクチャが、そのような重要な駆動要件をサポートする方法で取得する（または取得できる）アーティファクトを実装してはならないことです。このようなアーティファクトは、干渉アーティファクト、実際の価値を提供するアーティファクト（既存の要件に対するソリューションを実装するもの）と呼ばれますが、その存在によって将来の主要な駆動要件の実装が困難/コストがかかります。
干渉するアーティファクトを実装する必要がある場合、タスクは、ある時点でその除去を計画することです（そのため、干渉されている主要な駆動要件を実装できます）。
明らかに、これは実際の具体的なコンテキストのない難解なものです（実際のプロジェクトのように）。しかし、多かれ少なかれ、開発プロセスモデルと進化するアーキテクチャでは、これらの考慮事項を考慮する必要があります。
暗黙の要件はアーキテクチャの死です。重要な推進要件と補助的な要件の両方を明示する必要があります。早い段階で要件を実装する必要はありません。あなたはそれを説明できる必要があるだけです。
PS。要件とは、システムレベルのアーキテクチャ要件を意味し、必ずしもアーキテクチャを大幅に変更することなく対応できる一時的なアプリケーションレベルの要件ではありません。それが役に立てば幸い。