アジャイルソフトウェア開発の基本
JSTQB Foundation Level アジャイルテスト担当者シラバスの「1.1 アジャイルソフトウェア開発の基本」について、テスト担当者の視点で要約します。
アジャイルプロジェクトでは、テスト担当者は従来とは異なる方法で作業し、開発者やビジネス代表者と一体となって品質を追求する必要があります。
アジャイルソフトウェア開発とアジャイルマニフェスト
Section titled “アジャイルソフトウェア開発とアジャイルマニフェスト”2001年に合意された「アジャイルマニフェスト」は、4つの価値宣言に基づいています。
- プロセスやツールよりも個人と対話を: ツールよりも継続的なコミュニケーションを重視します。
- 包括的なドキュメントよりも動くソフトウェアを: 早期から動くものを提供し、市場参入を早めます。
- 契約交渉よりも顧客との協調を: 定期的かつ緊密な協調が成功率を高めます。
- 計画に従うことよりも変化への対応を: 変化を避けるのではなく、柔軟に適応することを重視します。
これらは、右側の概念をより高く評価するという考え方です。また下記の、12の原則によって補完されています。
アジャイルの12の原則
Section titled “アジャイルの12の原則”マニフェストの核となる価値は、以下の12の原則によって具体的に定義されています。
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する。
- 要求の変更はたとえ開発の後期であっても歓迎する。アジャイルプロセスは変化を利用してお客様の競争力を引き上げる。
- 動くソフトウェアを、2~3週間から2~3ヵ月というできるだけ短い時間間隔でリリースする。
- ビジネス側の人と開発者は、プロジェクト全体を通して日々協力して働かねばならない。
- 意欲に満ちた人々を集めてプロジェクトを構成する。環境と支援を与え、仕事が無事終了するまで、開発チームメンバを信頼する。
- 開発チームに対する情報伝達の最も効率的で効果的な方法はフェイスツーフェイスの対話である。
- 動くソフトウェアこそが進捗の最も重要な尺度である。
- アジャイルプロセスは、持続可能な開発を促進する。スポンサ、開発者およびユーザは、一定したペースを継続的に維持できるようにしなければならない。
- 技術的卓越性と優れた設計に対する不断の注意が、機敏さを高める。
- シンプルさ(やらない仕事を最大化する技)が本質である。
- 最良のアーキテクチャ、要求および設計は、自己組織的なチームから生み出される。
- もっと効率を高めることができるかを開発チームは定期的にふりかえり、それに基づいて自分たちのやり方を最適に調整する。
チーム全体アプローチ (Whole-Team Approach)
Section titled “チーム全体アプローチ (Whole-Team Approach)”プロジェクトに必要な全スキルを持つ人を巻き込み、全員が品質に責任を持つ文化です.
- 三人の力 (Power of Three): テスト担当者、開発者、ビジネス代表者が各ステップで協力するコンセプトです。
- 品質の全員責任: テスト担当者は開発者にテスト知識を伝達し、プロダクトの開発に良い影響を与えます。
- 小規模なチーム: 理想的には3〜9人のクロスファンクショナルなメンバで構成されます。
早期かつ頻繁なフィードバック
Section titled “早期かつ頻繁なフィードバック”短いイテレーションを通じて、品質に関するフィードバックを継続的に得ることができます。
| 利点の例 | 具体的な内容 |
|---|---|
| 修正コストの低減 | 要件の誤解を開発サイクルの終盤まで放置することを防ぎます。 |
| 顧客満足の向上 | フィーチャを早く使うことで、顧客の希望がより正しく反映されます。 |
| 品質問題の早期発見 | CI(継続的インテグレーション)を介して問題を早期に解決できます。 |
| 進捗の可視化 | チームの生産性やベロシティを把握し、一貫した推進を促します。 |
早期フィードバックによって、チームはビジネスバリューの高いフィーチャやリスクに集中することが可能になります。