従来のやり方では時間がかかりすぎる
出来たころには、要求が変化
64％の機能は使わない
顧客満足度を最優先し、
価値あるソフトウエアを
早く継続的に提供する。
スクラム
複雑で変化の激しい
問題に対応するための
仕事の進め方
同じペースで
大事なものは先に
欲しい物をリスト化する
欲しいものは状況によって変わる
小さくても使えるものを作る
短いスプリントタイムで、確認と調整を行う
1..反復
2.メタファー
3.作業空間
4.ふりかえり
5.テスト駆動開発
6.ペアプロ
7.リファクタリング
8.コードの共有所有
9.継続的インテグレーション
10.YAGNI
11.責任
12.擁護
13.四半期毎の見直し
14.ミラー
15.持続可能なペース
16.ストーリー作成
17.リリース計画
18.受け入れテスト
19.短期リリース
YAGNI (You ain't gonna need it)
機能は実際に必要となるまでは追加しないのがよい
「そんなの必要ないって」
・あとで使うだろうとの予測の元に作ったものは、実際には10%程度しか使われない。したがってそれに費やした時間の90%は無駄になる
・余計な機能があると我々の仕事が遅くなり、リソースを浪費する
・予期しない変更に対しては設計を単純にすることが備えとなるが、今必要とする以上の機能を追加すると設計がより複雑になってしまう
・あなたの人生の時間は貴重である。あなたの能力は単にコードを書くためではなく、現実の問題に集中するために使うべきである
・結局はその機能は必要ないかもしれない。もしそうなったら、あなたがその機能を実装するのに費やした時間も、他のみんながそれを読むのに費やした時間も、その機能が占めていたスペースも、すべて無駄になってしまうだろう
・コードをすばやく実装するために最も良い方法は、あまりコードを書かないことである。バグを減らすために最も良い方法も、あまりコードを書かないことである