アジャイルチームで設計仕様を作成/更新する責任を負うべき人物
私はスクラムのようなアジャイルチームの一部として働いていますが、しばらく前に、チームがすべきだと私たちが確認したことの1つは、コードベースの設計ドキュメントの適切なセットを維持することです。私たちは機敏で、十分な量の議論とコミュニケーションがあるので、私たちのデザインは高いレベルに保たれ、一般に、メインクラスとその相互作用の一部を含むモジュールの一般的なレイアウトを説明するために使用されます。それ以来、それらは、議論の出発点として、またコードに飛び込む前に設計を検討する必要があることを人々に思い出させるためにも役立つことがわかりました。
これまでのところ、誰もが必要に応じて設計仕様を更新することが期待されていました。各チームの設計リードは、一般的な設計、SDSで何を更新するかについてのアドバイスを人々に提供し、すべての一貫性を保つために仕様をレビューする責任があります。
私が目にしている問題は、誰も、特に新しいメンバーは、新しいコンポーネントを学ぶとき、またはしばらく触れていないコンポーネントに戻るときにも、設計仕様が非常に役立つことに気付きますが、ほとんどの人はそれらを更新するためにドキュメントを更新するだけです（つまり、彼らは彼らがそれをしなければならないと言われるので、彼らはそれをします）。完全な文ではない場合があるワンライナーの説明になってしまうので、これを更新して入力する必要があると私が言ったとき、それらはさらに追加されますが、それはそれらが通知されたからです。したがって、現在、1行が1.5行になり、書き留めておくと役に立ちません。
明らかに異なるチームメンバーのスキル/強さは異なります。したがって、問題は、アジャイルチームの特定のチームメンバーが単に設計に責任を負わず、コーダーだけに削減されるべきかということです。それとも、チームメンバーに戻って、必要なだけ（そしてこれは本当に苦痛になっている）仕様を書き直させ、期待どおりの結果を生み出すのに十分なスキルを身につけるようにするのは、デザインリーダーの役割でしょうか？
皆さんに提案する私の基本的なガイドライン：会議に参加している場合、またはクラス図Xについてプレゼンテーションを行っている場合、視聴者がコードのしくみを知る必要があるとしたらどうでしょうか。代わりに、半分の時間で、クラス図に既に表示されている内容を簡単に説明します。 「クラスXはインターフェースYを実装します」。これはクラスの説明全体です。
修正：アウトソーシング/契約について非常に健全な食欲を持つ大企業で働いています。私が所属しているチームには常任メンバーがいますが、チームには非常に新しい（最近の合併により）常任メンバーもいます。また、現在のリリース後に他のプロジェクトに再度割り当てられる可能性が高いインドとポーランドの請負業者がいます。したがって、現時点ではメンバーによって賛同が異なります。ドキュメントは、前回のリリースでプロジェクトに参加しており、次のリリースでプロジェクトに参加する私たちにとって、間違いなく重要です。
読んだかどうかはわかりませんが、スコットアンブラーの Agile/Lean Documentation に関する記事を読むことをお勧めします。
私が目にしている問題は、誰も、特に新しいメンバーは、新しいコンポーネントを学ぶとき、またはしばらく触れていないコンポーネントに戻るときにも、設計仕様が非常に役立つことに気付きますが、ほとんどの人はそれらを更新するためにドキュメントを更新するだけです（つまり、彼らは彼らがそれをしなければならないと言われるので、彼らはそれをします）。
それは少し矛盾しているようです。チームのメンバーが実際にドキュメントが有用であるとわかった場合、それはそれらを最新に保つための動機づけ要因になるはずです。開発チームが意思決定を記録するためにドキュメントを積極的に更新していない場合、おそらく対処する必要のある問題があるでしょう。ドキュメントは適切ですか？ドキュメントの現在の形式はコミュニケーションを容易にしますか？あなたは目的のためにあまりにも良いまたはあまりにも形式化されたドキュメントを作成しようとしていますか？
したがって、問題は、アジャイルチームの特定のチームメンバーが単に設計に責任を負わず、コーダーだけに削減されるべきかということです。それとも、チームメンバーに戻って、必要なだけ（そしてこれは本当に苦痛になっている）仕様を書き直させ、期待どおりの結果を生み出すのに十分なスキルを身につけるようにするのは、デザインリーダーの役割でしょうか？
私の意見では、設計ドキュメントの更新を1人のチームメンバーに委任することは、アジャイルに反します。アジャイルのポイントの一部はリスクを減らすことであり、責任を分散させることでこれを実現します。誰もコードを所有していないように、誰もドキュメントを所有していません。チームメンバーに仕様を書き換えるだけでなく、ペアプログラミングなどを試して、適切なフィードバックを提供するために、より優れたドキュメントを書く方法や、作成されたドキュメントにレビューを導入する方法をこれらの人々に教えてください。
大学生の私の教授の一人が、「人々が彼らに重要であると言うことと彼らが実際に何をしているのかの間の矛盾を見つけて、あなたは彼らを完全に理解するだろう」と言いたがっています。
したがって、チームはドキュメントが好きだと言っていますが、適切なときに実際に作成しないのですか？彼らが大切にしているのは便利さです。コードを解読して理解するよりも、よく書かれたドキュメントを読む方がはるかに簡単です。ドキュメントを更新するよりも、ドキュメントの更新を無視する方がはるかに簡単です。したがって、チームの値のリストを保持し、ドキュメントを削除して（そこに配置した場合でも）、利便性の高い太字の文字を作成する必要があります。
したがって、ストーリーについて話し合い、タスクを作成するとき、チームは便利な要素に取り組む必要があります。これは将来のために書き留められるべきものですか？将来の価値は、現在のコストとのバランスが取れているのでしょうか？
あなたがあなたの質問を述べた方法にはすでに答えが含まれていると思います。あなたは、1種類の作業（ソフトウェアコードの設計と実装）にのみ関連する種類のドキュメントについて話しているので、その責任者は次の種類の作業を実行する人である必要があります：ソフトウェア開発者。アジャイルかどうか。
私はあなたの質問に矛盾を見つけ、それを解決することが役立つかもしれません。一方は「チームがすべきことを1つ確認しました」と言いますが、もう一方は「それを特定した」同じチームがこれらの設計ドキュメントの保守に消極的でずさんであることを示しています。これは、彼らが本当にそれに気に入らなかったと。
誰がこの文書化活動を必要として特定したのですか？チームはそれに賛成しましたか？彼らはそれを実行することにどの程度正確に同意しましたか？このトピックとこれらの質問を振り返ってみてください。
Agile について言及しているので、さまざまなアプローチを試し、チームに最適な方法を見つけるのは自然なことです。
これまでに提供された情報を考えると、あなたはそのために非常に良い立場にあるように見えます：
[設計仕様]は成果物であり、繰り返し追跡され、仕様の作成と仕様のレビューの両方のタスクが与えられます。受け入れ基準は、レビューが行われたときに期待される仕様が仕様に適合するというチームのコンセンサスです（デザインリードの重みが大きい）。
レビューミーティングがあります...
上記は、データを収集し、さまざまなアプローチの比較分析を実行するためのほぼ完璧なツールとして聞こえます。 QA検証をチームのコンセンサスしかし、それでも十分に良い感じです。
- 注意事項：実験を始める前に、アジャイルに対する理解を経営陣に明確に示すことをお勧めします。ご存じのように、彼らはたまに独自のアジャイルを持っているため、非常に 特別な見方 です。