アジャイル開発
アジャイル開発について簡単にまとめてみた。
ツッコミ、補足、なんでも歓迎です。
1）はじめに
アジャイルソフトウェア開発宣言
アジャイルの本質はすべてここに書かれている。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
左を軽んじるのではなく、右のことをもっと重んじる。
アジャイルって？
Agile（形容詞）
- 機敏な、すばしこい
- 頭の回転の速い、鋭敏な
アジャイルとは、すばやく機敏に動く事が出来るという意味。
チームでよく話し合い、動くソフトウェアを常に作りながら、顧客の要求に柔軟に対応するのがアジャイルな開発といえる。
2）アジャイル開発は銀の弾丸ではない
2-1）銀の弾丸って？
銀の弾丸とは、
狼男や悪魔を一発で撃退できるという意味から転じた比喩表現。
のこと。すなわち、
全ての問題に通用する万能な解決策などは存在しない
という意味。
そして、アジャイル開発は銀の弾丸ではない。
アジャイル開発は柔軟性と品質を重視した開発手法であり、「問題は起こるもの」と過程したうえで、それに柔軟に対応しようという考え方である。
2-2）既存の問題点とアジャイルな開発
- ウォーターフォールモデル
- プロトタイプモデル
- スパイラルモデル
三つの開発手法には、共通する問題点がある。
2-2-1）作った結果「コレジャナイ」
今までの開発モデルでは、開発プロセスを並行して行うことになる。
その結果、「完成して持っていく⇒++俺が欲しかったのコレジャナイ++」が発生する。
⇒ 要求は当然変化するもの。
また、システムの価値はシステムの20％で評価される（常に利用する＋よく利用する）。
つまり、顧客からの要求のうち80％はそのシステムの本質ではなく、システムの価値にはならない。
2-2-2）予定は未定
既存の開発手法はいずれもプロジェクトの初期段階で開発計画を立てる。
- しかし、予定はあくまで予定。
- プロジェクトの途中で予定が変わることはよくあること。
- 予測は当然変化する。
- 重厚長大な計画を順守することのムダ
- 綿密すぎる計画を立てることのムダ
2-2-3）ポイント
アジャイル開発以前の問題
- 手順の標準化
- 最初に作った手順に従うことが目的になる
- 当然、従えない時はどうしたらいいか？は手順には存在しない
- ドキュメント重視
- 絵にかいた餅で議論する
- そして絵に描いた餅で作業する
- 契約の順守
- 人や組織の壁、契約がムダを生む
- 契約したのちに内容が変わることもある
- 計画が絶対
- 計画がいつでも正しいというのは誤解
- 「これいらなくね？」と思いながら作るハメになる
2-3）アジャイルな考え方
価値を決めるのは開発者じゃなくて顧客です
- 機能の20％がシステムの価値を決めるという現実を認めよう。
- そして、システムの価値を決めるのは顧客という現実も認めよう。
- 顧客の要求通りに作っても、顧客が「コレジャナイ」といえばダメなプロダクト
変化は避けられません
- 初期にすべての要求を洗い出すのは無理。要求は後から増えるもの。
- なぜなら、分析・設計・開発をしてると新しい要求が出てくるから。
- 顧客が自分の要求を全部わかってるとは限らない
- 顧客のいう要求が全部正しいかもわからない
- そして、作ってしまってから言われても遅い
現実的な予測にしか意味はない
- 動くソフトウェアこそが進捗そのもの
- 「ここはまだ出来てないですけど○○までにはできます！」とか、
- 「今のペースなら人を○人追加すれば期限を○か月短くしてもいいよね」とか、
- まだ出来てないことや希望的観測は信用できないし、しちゃいけない。
- エンジニアは機械じゃない。
- 計画は死守するものではない
- あくまでも予定は未定。
- 要求の半分ぐらいは使われない機能
- そこよりも、重要なとこをちゃんと作りこんだほうがよくね？
- 完成を決めるのは顧客。
- 金出すのも顧客
- システムの価値を決めるのも顧客
- 期限を決めるのも顧客
- どこまで作るかも顧客
- つまり、完成したかどうか判断できるのは顧客だけ
3）アジャイル開発って？
- まず最初に、アジャイルかどうかを判断するのは、自分たち自身だということ。
- 「アジャイルにやれているか？」「アジャイルな開発とはなにか？」ということを考えるのは、チームである。
3-1）開発プロセスよりも個人との対話を
アジャイルな開発にとって、開発プロセスはツールに過ぎない。
ツールとはチームにあったものを取捨選択するものである。
そして、そのために必要なのはチームメンバーとの対話である。
なぜなら、ツールを実際に使うのはチームのメンバーだからだ。
⇒ 自分たち／プロジェクトにあったやり方を、自分たちで選ぶ／考える
3-2）ドキュメントよりも動くソフトウェア
アジャイルでは、ドキュメントは必要なものだけを作ればいい。
必要なものとは、「動くソフトウェアを作るのに必要なもの」だ。
⇒ 動くソフトウェアこそが進捗
3-3）契約よりも顧客との交渉を
アジャイルでは、契約内容に従うことよりも、実際に顧客に参加してもらって開発を行う。
一つのイテレーションという単位での開発が終わるたびにデモをし、ソフトウェアの評価をしてもらう。
それをフィードバックすることで、より要求に近いソフトウェアの開発を行う。
⇒ システムの価値を決めるのは顧客
3-4）計画よりも変化への対応を
最初に立てた計画は、いつか変化するものである。
ならば、最初にすべての計画を立てる必要はない。
大体の計画を立てておき、必要になれば綿密な計画や見積もりをすることで柔軟な対応を目指す。
⇒ 計画は立てるが、変化に対応できるように立てる
まとめ
すなわち、
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
ということだ。