いちばんやさしいアジャイル開発の教本を読んだので、大事だなと思ったことをまとめておく。
大雑把には、『アジャイルの概要』を学べる。いくつか読んだアジャイル本（アジャイルサムライ, SCRUM BOOT CAMP THE BOOK）の中では、一番読みやすい本な気がした。
アジャイル開発とは
短い期間でリリースし、フィートバックをして、改善するというサイクルを基本として進める開発手法。
一度リリースして終わりではなく、リリースしたソフトウェアに対するユーザのフィードバック自体が開発サイクルに含まれる点が、アジャイル開発の原則であり特徴。
要求と要件
ソフトウェア開発は、『要求』からスタートする。要求は次のような方法で決めていくことが多い。
- 顧客から提示される
- 開発インサイト（ユーザ自身が気づいていない本音や動機を引き出し、サービス利用に引き込む）により開発側で要求を見つけ出す
要件は、要求を実現するために必要な機能、性能のこという。要件には大きく次の２種類がある。
| 項目 | 意味 |
|---|---|
| 機能要件 | 主目的に関する要件 |
| 非機能要件 | 性能や品質、セキュリティ等の主目的以外の要件 |
アジャイル開発においても、要件定義は重要な工程になる。
なぜアジャイル開発なのか
ウォーターフォールとアジャイルでも、要件定義や設計は行い、プロセスの共通部分は多い。
違いとしては、ウォーターフォールは、各工程が滝が流れるように進み、各工程の成果物を完成品とみなし、あと工程での手戻りが発生しないように進める。
一方、ジャイルでは反復的に開発が進み、スプリントごとに動くソフトウェアが作られ、次のスプリのではそのソフトウェアから得られた気づきを基に要件レベルから見直される。
ユーザが本当に欲しいものは『潜在的なニーズ』であることが多いため、実際に製品を使ってみるまでは、本音が得られることが少ない。
そうした状況において、ウォーターフォールでは全部できてからでないと製品を使えず最後になって、『なんか、これじゃない、、、😱』ということになってしまう。
アジャイルでは、小さいサイクルで動くものを少しずつ作っていき、都度ユーザにフィードバックしてもらい開発を進めるため、最終的にユーザの求めた機能が提供できる。
また、いくつかの要件を形にした後で、新しい要件に気づいたり、実装を進める中でより良い設計を思いついたりした場合にも、アジャイルではフィードバックで取り入れることが可能。
アジャイル開発のコア
３つのコンセプト
| コンセプト | 意味 |
|---|---|
| チーム | 自己組織化*1された職能横断的*2なチーム |
| インクリメンタル | 少しずつ作る |
| イテレーティブ | 反復的に作る |
アジャイル開発では、プロダクトを少しずつ繰り返し的に進めるために、『作成すべきもの』を一覧で管理する。一覧はその並び順を開発の優先順とする。
上記の一覧で管理する場合、各項目一つひとつが明確で、かつ他の項目と依存しないことが望ましい。理由は、項目同士の依存度が高いと、順番が入れにくくなるため。よって、各項目は、十分に小さい単位にすることが望ましい。
各項目を小さくすることの弊害としては、全体として何を目指していたかが見えにくくなる点。そこへの対応としては、ユーザ視点で全体像を把握する、次の方法がある。
- ユーザストーリマッピング
- ユーザ行動フロー
