スクラムでレビューデザインを文書化してピアリングする方法は？
私は、中規模のシステムに取り組んでいる中小企業（3人の開発者のチームと同様に小さなQAブランチ）の比較的新しい開発者です。現在の反復はまだ10万行のコード（サーバーとクライアントの合計）未満ですが、長期的には、合計サイズが200kLOC以上になる可能性があると想像できます。私たちは開発にスクラムを使用しようと試みており、CMMIレベル2の評価に向けて取り組んでいます。
ソフトウェアの設計とソースコードを検証するために、ピアレビュー手法を採用しています。スプリント計画会議中にソフトウェア要件を引き出し、マスターSRSにソフトウェア要件を文書化します。これはまた、ソフトウェア設計の出発点にもなりますが、OO設計、UI設計、再利用可能な設計パターンなど）などの設計概念を確認するための正式な方法はありません。 。ソースコードについては、スプレッドシートを使用して肩越しのレビューを文書化したり、パスアラウンドレビューを電子メールで送信したりするなど、新しい手法を試していますが、レビュー担当者が見ただけではデザインコンセプトを理解するのが難しい場合があります。ソースコード。
（私が概念を誤って伝えている場合は失礼します。私たちはこれを最初からたくさん試みています。）
UMLを使用してクラス、オブジェクト、ソフトウェアインターフェイス、イベントパターン、またはその他の設計概念を表現することは嫌いではありませんが、設計作業をいつどのようにピアレビューするかはわかりません。多くの場合、開発者はユーザーストーリーを70％以上完了し、基本的な設計要素を変更する必要があることに気付くことがあります（その後、ピアレビューが行われます）。
このトピックに関するオープンな議論を避け、簡潔な回答を促進するために、2つの具体的な質問を提案しようと思います。
- ピアレビューの設計概念のベストプラクティスに関する優れたリソース（本、論文、記事など）を知っている人はいますか？
- 私は、コード自体が（の実装）デザインであることを読みました。ソースコードのピアレビューをデザインのピアレビューとして利用できますか？
ありがとうございました。
私は良いデザインを助ける3つのことがあると思います：
- ペアプログラミング。このようにして、現在の要件に適さなくなった場合に、設計がどのように機能し、どのように変更するかを複数の人に確実に知らせることができます。
- 単体テスト。 TDDを実行することにより、設計が理解して後で変更できるほど単純であることを確認できます。
- 時間。反復的な開発では、設計は時間とともに進化します。デザインが作成された時点で、そのデザインが良いか悪いかは誰にもわかりません。デザインが数回変更されて初めて、デザインが理解しやすく、変更しやすいかどうかがわかります。
P.S.コードレビューがあなたに何を与えるかを自問してください。アジャイルとは、開発者が独自のプロセスを自由に定義できるようにすることです。ある種のプロセスから何を期待できるかわからない場合は、そのプロセスを必要としない可能性が高いです。
現在、デザインはUXのみで行われており、デザインレビューの方法に関する膨大なリソースがあります。
10分以内に、アジャイルを正しく実行していないと言う人がたくさんいます。忘れてください。ソフトウェアを正しく実行している、ソフトウェアは宗教ではない、アジャイルはそうです。優れたソフトウェアをすばやく作成できれば問題ありません。
個人的には、データフロー図など、必要なすべての情報がプロセスのどの時点でも確実に利用できるようにするためのものを使用します。データフローとその仲間（入出力処理が強化されたフローチャートなど）は、欠落している要素をキャプチャするための優れた方法です。
UMLのコラボレーティブテストも簡単です。最初に紙にそれを作成することで準備をしてから、チームを集めてホワイトボードに段階的に作成し始め、彼の考えの流れに問題がないか尋ねます。
このプロセスでは、必ず
- まず、特定の設計のエンドユーザーの目標を明確にします
- すべての要件を評価し、おそらくホワイトボードに書き込みます
- 絵を描く
- 描画中に問題のあるスポットを示し、それらを強調します。
私がスタートアップにいたとき、私たちはほぼ毎日これらのデザインセッションを行いました。
ソースコードでこれを行うこともできますが、常に覚えておいてください。ソースコードは問題をコンピューターに説明するためのものです。選択した言語と目前の問題に応じて、現在の言語は人間に説明するのにも効果的である場合とそうでない場合があります。