https://m.media-amazon.com/images/I/41KjBkHO6uL.jpg
- はじめに
アジャイルとは、小さなことをしている小さなプログラミングチームの小さな問題を扱う小さなアイデアである アジャイルとは、大きなことをしている大きなプログラミングチームの大きな問題を扱う大きなアイデアではない 大きなことは大きなチームなんかじゃできない。小さなことをする小さなチームがいくつも集まり、コラボレーションしながら大きなことを成し遂げるのだ。 - チームトポロジーに通じるものがある。
- 第1章
- 科学的管理法
- ゴールを達成するための最適な手順を特定し、部下が厳密に計画に従うようにする（事前に作られる大きな計画とそれに続く慎重で詳細な実行）
- プレ・アジャイル
- 短期間のリアクティブな手順を使用
- ウォーターフォール
- 科学的管理法の子孫
- 科学的管理法
プロセスやツールよりも個人と対話を 包括的なドキュメントよりも動くソフトウェアを 契約交渉よりも顧客との協調を 計画に従うことよりも変化への対応を
- アジャイル開発とは、フィードバック駆動のアプローチ
- 第2章
- 権利章典
- 顧客の権利、開発者の権利
- 顧客：ビジネス側の人たち
- 権利章典
あなたのタスクを見積もれる人はあなた以外にはいない - これそうだよな〜〜。見積もりはコミットメントにはならないというのもそう。
- 第3章
- ユーザーストーリー：INVESTというガイドラインに従う
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
- QAがテストを書いて、プログラマーが実行するというのは理にかなってる気がする。
- ユーザーストーリー：INVESTというガイドラインに従う
- 第4章
- 継続的ビルドを「絶対に壊してはいけない」というのはよくわからない。壊れることはあるだろう。大事なのは「壊れた状態で放置しないこと」じゃないかなあ。
- スタンドアップミーティング、つい議論に発展してしまうことがあって、そうなってないチームをこれまでまだ見たことがない。
- 第5章
- テクニカルな話が多かった
- TDD、まだできてないなあ
- 第6章
- 価値基準
- 勇気、コミュニケーション、フィードバック、シンプリシティ
- 価値基準
品質と規律が速度を上げる
- 第7章
- プラクティスではなく価値にフォーカスする
- とても大事
- プラクティスではなく価値にフォーカスする
人生を2つに分けてしまうと、その2つが常に対立することになる。どちらを選ぶにしても、いずれかを犠牲にしなければいけない気持ちになる - 「ワークライフバランス」だ