002_アジャイルプラクティス

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

【Refference】
http://d.hatena.ne.jp/dem8185/20090502/1241257124

【To】
ビジネスパーソン（IT業界に限らず）

【Descpiction】
ソフトウェア開発の現場で生じる様々な問題に対し、"アジャイルに対応すればこのように改善できる"という説明を端的にしているアジャイルの入門書。
ソフトウェア開発に留まらず、一般的にビジネスパーソンとして心得ておくとよいことも多く記載されている。
開発手法に対する知見よりも、一般的にチームで何かを行うときに身につけておくべき視点がてんこ盛りだった。

【Point】

◆名言

• 「どんなバンドで演るときも、一番下手なプレイヤーでいろ。もじ自分が一番上手いんだとしたら、それは別のバンドに移るときだ。」（パット・メセニー）
• 熟練の家具職人は失敗しない。そんな印象をもっているかもしれないね。でも全然そうじゃないんだ。プロは自分のやらかしたヘマにどう対処すべきかをしているだけさ。（ジェフ・ミラー）

◆問題解決

• 小さな問題は、小さなうちに対処する
• 問題が起きたらすぐに解決するのが一番簡単かつ安上がり
• 未知なる課題は深入りする前によく調べる
• 二分探索は問題の切り分けに有効である。問題がありそうな領域を二分することを繰り返す。

◆チームプレイ

• 最悪なチーム
  • ミスに対し、犯人探しで手一杯
  • チームとしての成長は見込めず、チームとしての成果は出ない
• アジャイルなチーム
  • ミスに対し、「OK。で、私が力になれることはある？」
• 自分が助けを求めたのに適当にあしらわれるときどうする
  • 食い下がる。より具体的な説明を心がける
• スタンドアップミーティング（日本式の朝礼）
  • ミーティングを短時間で済ませられる効果がある。
  • 会議が脇道にそれないように、各参加者は次の３つの質問にだけ答えるようにする
    • 昨日やったことは？／今日やることは？／進捗を妨げている問題点は何？
  • よきメンターになろう
    • メンバーに毎日魚を与えるのではなく、釣り竿となるヒントを与える。それに対するアイディアが返ってきたら、アイディアの長所と短所を教えてあげる

◆仕事の進め方

• 新しく学んだAPIを嬉しがってやたら使うべからず
  • 目的の帰納をきちんとはたす実装に必要な最小限の作業を見つけること
• 作業時間をありのままに記録する。
  • 見積もり定より大幅に上回っていたとしても、それは次回の見積もりのインプットになる
• 「書きやすさ」よりも「読みやすさ」を重視すべき
  • ドキュメントは書いている時間よりも読まれる時間の方が長い
• 数分たりとも、正しい道か確信が持てないまま走ってはいけない
• 戦略上の意思決定は何マイル離れていても可能だろうが、戦術上の意思決定は違う。現場で起きていることを熟知していることが要求される。

◆IT

• 顧客のビジネスに重大な影響を与える決定は開発者が下すべきではない。顧客に決めさせる。設計判断の中で自分たちが決定すべきでない事項は何かを決定することが重要。
• 事前設計とはその時点での要件に対する理解のみに基づいて設計されている。設計とは洗練させ、発展させるもの
• どんな技術の採用においても、批判的な問いを立て、その問いに答えられるか検証する
• 成果物をイテレーティブかつインクリメンタルに顧客にリリースする
  • 早期にリリースすることで経験と洞察を得られる
• コードに手を加えていないとしても、少なくとも昨日までと同じように動くと確信できるように監視する
• ユニットテストをやりたくない人の言い訳は、実は設計の欠如を示していることが多い
• エラー報告は今後も含めたサポートコスト全体だけでなく、開発者の生産性にも大きく影響する。
• デバッグ情報は貴重で、めったに手に入らない。ぞんざいに扱わないこと。