アジャイルプラクティス を読んで

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

https://www.amazon.co.jp/dp/4274066940
この本、まだ半分ぐらいしか読んでいないのですが、いい言葉がたくさんあったのでメモしたところを書き出してみました。
(これまで結構いろんなアジャイルについての本を読みましたが、開発者視点で見たときにこれが一番わかりやすい本だなと感じています）

道を間違えたならどれだけ進んでいたとしても引き返せ (トルコのことわざ)

• 開発がアジャイルであるということは、協調性を重んじる環境で、フィードバックに基づいた調整を行い続けることである
• 始めるのに偉大である必要はない。だが、始めなければ偉大にはなれない。
• プロジェクトで仕事をする最大の目的は「顧客の要求に応えること」
  • 顧客にとっては誰がアイディアを出したかは関係ない
  • 成果こそが全て
    • だからこそ、感情は捨てて協力する
• 選んだ道が正しくても、座り込んでたら轢かれちまうぜ (ウィル・ロジャース)

設計について

• 自分でもよくわかっていない事を厳密にしても意味がない (フォン・ノイマン)
• 戦略的設計: 事前に行う前払い的な設計
  • この段階では詳細に決めすぎないことが大事
    • 河岸にいるわけでもないのに川を渡る方法を考えても意味がない
  • 要件を定義することに集中する
    • 責務の分離に着目する
    • CRCカードなどを使ってクラスの定義を行う
      • 誰がどの範囲に関係する？がわかればいい
• 戦術的設計: メソッドやパラメータ、フィールドの詳細などを定義する段階
  • 優れた設計は正確であっても精密ではない
  • 書いてあることは正しいが、変更されるかもしれない箇所や未決定部分の詳細に立ち入るような設計にしてはいけないということ
    • 設計とは目的や意図を示したもので、具体的な手順を示したものではない
    • 逆に、具体的な手順を書くのは仕様書
  • ニーズに裏打ちされた技術を選ぶ
    • ニーズを特定した上で、採用候補の技術が問題を解決可能か検討する
    • 使うことが目的の技術を使ってはいけない
    • 最新技術を詰め合わせただけの何かはいらない
      • それらしい理由を付けようとしていたら要注意

短いイテレーションでインクリメンタルにリリースする

• ビルド(毎日)
• イテレーション(デモなど。１週間〜１ヶ月)
• インクリメント（機能リリース。１ヶ月〜半年）
• 一年以上の見積もりが出たらそれはやり直し
  • 待ってるうちに市場が変化してしまう
    • この辺は「LeanとDevOpsの科学」を読むと良い
      • https://www.amazon.co.jp/dp/4295004901

ユーザーの声に耳を傾ける

• あらゆる不満に真実が潜んでいる
  • エラーが起こったときにできるだけ状況を出力する
  • ユーザーからのフィードバックが最も重要
    • 間違いを馬鹿にするような態度で対応してはいけない