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