Agileについての基礎を学びたかったので。
技術書みたいなものなので、いつものBookReviewとは違いますが。
要望を把握できているのか？
要望は変化する。受け入れきれない。 始めに来る要望が正しいことも、それを開発者が正しく理解できることも多くないので、柔軟にしておく（初めに全て決めない）。 ※きちんと要件定義できて突き詰めきれる規模なら問題はない。
アジャイルのデメリットは多少効率が落ちることと、お客様の言うとおりにせずに考えなきゃいけないので難しいこと。
お客様と主従関係になるのではなく、対等な関係として位置する。
ドキュメントを書くよりも動くものを見せていくほうが理解が早い。 コードを読んだほうが人にも誤解なく伝わる。
分割して分担する
機能を細かく分けて組み合わせていく。
一気通貫で組み上げない分効率が悪くなるかもしれないが、 変更・再利用しやすく、コードの一部だけ抜き出しても理解できる。 （上から下まで通すロジックを書くと、脳内OoMするのでは？）
そのためにはペアプロやコードレビューをもっと徹底的に。
お客様に見せることですりあわせられる。
顧客に提供するのは価値。 そのためにはどういった仕様にすればいいのか。 （SaaS化する、キチンと説明した上で製品を納品する）
出来上がってみないと顧客の要望を把握しきれなかったりするので、 Mockや完成品を見せて、ズレていたら説明・理解・修正を繰り返していく必要がある。
（私見ですが、パラダイムシフトや知識不足にはモノを見せるのが早かったりするのではないでしょうか？ いくら説明しても抽象的な部分は理解しきれないと思うので。）
変化を抱擁せよ
その時の最大を求めて変化していきたい。
変更は改善を意味する。変化に強い設計を。 そのためにはソフトウェアを柔軟に。 技術・ニーズの変化にも対応しやすい。
タイムボックス・スプリント
期間を短く切って、その期間内に完結する修正を入れていく。
半ば強制的に設計が分割される。
短い期間でPDCAを回すことで、改善のスピードが向上する。
タイムボックス完了時には、実働するソフトウェアを組み上げている。 それを顧客に見せつつ、ズレがあれば次に即座に修正を加えていく。
CI
早くフィードバックしたほうがコストが低いと言われている。
ビルドだけでなくてテストやデプロイまで回したい。
シンプルに yagniに
YAGNI（You ain’t gonna need it）
その時に必要な最小構成で組み上げていくことで、結果として変更に強くなる。
同じことは二度しない。拡張しにくくなるから。
振り返る
PDCAを回さないと何が悪かったのかわからない。 指標をおいてそれをクリアしていくこと
見える化
データが見えることとと見える化することは違う。 次の行動を誘発するのが見える化。 データを羅列するだけでは意味がない。