book
職人気質・プロのミームを伝染させてくれる本」
「いつ終わる?」「〇〇日に終わります」
このやり取りで合意が取れれば完了。
それ以上のマネジメントは不要であるのが、プロのやり取り。
<-> マイクロマネジメント
機能に危害を加えてはならない。具体的には、テストを怠ってはならない。
構造に危害を加えてはならない。具体的には変更が難しい構成にしてはならない。
これらは最優先である。
納期に間に合わせるために勝手にテスト工程を短縮したりすることは、優先度を見誤った行動である。
最初に伝えた期日通りに作業を完了するなど。
期待は調整可能である。第一の規律を守るために第二の規律を守れない際は、そのことを伝えることによりインパクトを和らげることができる。
何も伝えずに合意を裏切ることは、危害を加えるに等しいため注意。
当たり前のことだけどなかなか実践できないやつ。
自分がヒーローになることを目的にしない。
顧客のことを第一に考えて意思決定する。
この考え方は、個人的な責任が欠如している。
誰かが手伝うのをやめても、自分でそれをやり遂げるというレベルの決意が必要である。
期日に間に合わない可能性があることがわかった時点で、関係者に連絡する
コミットメントに齟齬が生じるため。約束する際は、絶対に間に合うと約束する。
実質的に集中力が落ちている状態である(ボブおじさん論)。
大局的にみれない。
-> 今では同意。定期的に日記をつけるなど立ち止まって振り返りを行ったほうがよい。
最悪の態度。
終わっていないのに、「完了」と勝手に定義すること。
きちんと責務を果たすことが大事。
大事だけど省略
現在、PCの処理速度よりもそれを扱う人間の処理速度のほうがネック
-> タイプミスによる引っかかりなどによる集中力の低下、テンポの乱れがパフォーマンス低下の原因となる
-> そのため、練習が必要である。練習による自身のパフォーマンスの向上が必要である。
要求を行う
-> 機能ができる
-> 新しい情報が得られる
-> 要求が変化する
詳細を適切に詰めたところで、どのみち詳細はかけ離れていく。
確実な見積もりを行うために仕様の詳細化を行おうとするが、上記の理由で早すぎる詳細化は無意味な物となり、それに基づいた見積もりも無意味なものとなる。
そのため結局、確実な見積もりというものは不可能である。
ただし、見積もりは必要であるので、その不確実性についてビジネスに同意を求める。
現在動くが変更できないプログラムよりも、今動かなくても変更が容易なプログラムの方が中長期的に見て優れている。
テストはバグが存在しないことではなく、バグが存在することを示すものである。(p.57)