アジャイルエンジニアリングの実践

実用技術

• 用户故事
• 结对编程
• TDD（测试驱动开发）
• 持续集成
• CodeReview
• 发布规则

ユーザーストーリー

ユーザーストーリーはユーザーとユーザーのニーズを特定するために使用される簡単な説明。
典型的な説明文は次のとおりです。XXXの顧客として、XXXのメリットをもたらすことができるXXX関数が必要です。
ユーザーストーリーはユーザーの観点から要件を説明する方法
各ユーザーストーリーには、対応する受け入れテストケースが必要です。
ユーザーストーリーは階層的および階層的であり、使用中に徐々に分解および改良されます。

キーポイント

I – Independent，可独立交付给客户
N – Negotiable，便于与客户交流
V - Valuable ，对客户有价值
E - Estimable ，能估计出工作量
S - Small ，分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成
T - Testable，可测试

メリット

ユーザーの観点からは、顧客とコミュニケーションを取り、顧客のニーズを正確に説明すると便利です。
ユーザーストーリーは、ユニット単位で小規模に個別に配信できるため、ユーザーから迅速なフィードバックを得るための反復型開発に適しています。
ユーザーストーリーは、受け入れ基準としての受け入れテストケースの準備を強調しています。これにより、要件アナリストは要件を正確に把握し、開発者が過剰設計を回避できるようになります。

ユーザーストーリーにより、チームはユーザーの観点から要件を分解および改良し、受け入れ基準を策定することが容易になります。

サンプルストーリー

ここに画像の説明を挿入

ストーリーの特徴

顧客（ユーザー）の価値を反映する、軽量のポイントシンボル
3Cの原則に従う

 卡片（Card）：作为XX，我希望XXX，这样可以XXX
 对话（Conversation）：不描述到细节，由团队通过持续对话细化，激发大家的深度理解
 确认（Confirmation）：有明确的验收标准

カード

ユーザーストーリーの説明の従来の形式は、手書きのユーザーストーリーカードです。要件の本質または目的を把握するために、カードには数文しか記載しないでください。

通常の形式：<役割>として、<関数>が<商業的価値>を促進するようにしたい
ここに画像の説明を挿入

会話

会話とは、カードに記録されているユーザーストーリーについて話し合い、洗練することができることを指します。これには、利害関係者（顧客/ユーザー）、製品所有者、および開発チームが含まれ、ユーザーストーリーの実現可能性についてより詳細に話し合います。セッションでユーザーストーリーが確認された後、開発段階（ユーザーストーリーの実現）に入ることができます。

アジャイル開発のプロセスは、ユーザーストーリーの流れを完全に反映しています（要件）

ユーザーストーリーの流通プロセス（例としてスクラムを取り上げる）

1.製品の担当者は、ユーザーストーリーを整理し、製品のバックログを作成する責任があります。
-ユーザーストーリーの仕上げ
2.リリース計画会議：製品の所有者は、ユーザーストーリーの説明、見積もり、および並べ替えを担当します。会議の出力は、この反復で完了するストーリーのリスト、つまりスプリントバックログを作成することです。
-ユーザーストーリーの確認
3.反復計画会議：プロジェクトチームは各ストーリーのタスクを分解します。分解基準はストーリーのすべてのタスクを完了することです。最終的に、各タスクには明確な担当者がいて、作業時間の初期見積もりを完了します。
-ユーザーストーリーの内訳
4.毎日のスタンドアップミーティング：スクラムマスターは毎日スタンドアップミーティングを開催し、チームメンバーは昨日何をしたか、今日何をする予定か、そして質問は何ですか。
-ユーザーストーリーの実現
5.デモンストレーションミーティング：イテレーションの後、デモンストレーションミーティングが開催され、関係者が参加するように招待されます。チームは、このイテレーションの結果を全員に示す責任があります。期間中、全員のフィードバックが記録され、poで並べ替えられて、新しいストーリーが形成されました。
-ユーザーストーリーの再編成

確認

ユーザーストーリーの確認は、ユーザーストーリーが受け入れ基準を満たしているかどうかのテストとして理解できます。ユーザーストーリーでは、ストーリー機能が完了し、ソフトウェアが期待どおりに実行されていることを確認するために、一連の受け入れテストが必要です。同時に、このユーザーストーリーの最終的な実現が商業的価値をもたらすことができることを保証する必要があります。
ユーザーストーリーの確認はテスターが行います。テスターは、テストバージョンに関連付けられたユースケースリストのユースケースを実行し、テストを完了してから、テストレポートを生成します。
テストレポートは、ユーザーストーリーの実現度を最も直接的に表したものです。ユースケースの実行に失敗した場合、バグはテストケースから直接作成される可能性があり、開発者はテストに合格するまで二次開発と修復を実行します。

ユーザーストーリーのサイズレベル

•エピックストーリー（1〜2か月）
•特徴的なストーリー（1〜2週間）
•スプリントストーリー（1〜2日）
•タスク（数時間）：タスクに分割できます

ユーザーストーリーINVESTスタンダード

独立：ストーリーは疎結合で独立しており、他のユーザーストーリーに依存してはなりません。
交渉可能：最初はプレースホルダーとしてのみ使用され、徐々に改良されていきます。
価値がある：ユーザーストーリーはエンドユーザーにとって価値があるため、ユーザーの観点から作成する必要があります。
見積もり可能：設計、開発、およびテストの各チームは、作業負荷とコストを見積もることができます。（推定できない理由：大きすぎて分解できない、または不完全な情報をさらに調査する必要がある）
小：ストーリーはできるだけ短くする必要があります（2週間のスプリントなど、ストーリーは通常2日以内です）
テスト可能（テスト）：対応するテスト受け入れ基準があります。