アジャイルプラクティスを読んで得た教訓

アジャイルプラクティスと言う本を読んだ。ザッと。

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

この本、2007年の本なんですね。

開発方法論、プロセス、プラクティス、システムとか、戦術的な話に興味があります。 で、アジャイルプラクティスという本を読みました。

読んでいて、雑多に個人的なメモをとっていたので、あとで自分が見返すために文章に整形して書いておきます。

前置きですが、他の人が読むとわかりにくいかもしれません。

以下が個人的に本に書いてある達人開発者の習慣を読んで僕が得た教訓です。

• 時間がかかっても正しいことをすること。
• 古い習慣があることに気づくこと。また、習慣という理由で採用しないこと。ただし、古いという理由で不採用にしないこと。
• 問題の根本を理解するまで質問すること。質問をする前に、その質問に意味のある根拠を考えておくこと。
• 設計は様々な選択肢を考えて話し合う場であることを理解すること。やったことのないことを厳密に定義しても意味がないことに気づくこと。コーディングに入ったら設計は白紙に戻ったと考えること。
• どんな設計になったか、どんな計画になったか、より、設計や計画をメンバーとともに行ったことが大切であることに気づくこと。
• 必要になるまで実装しないこと。作る前からどう使うかを考えること。
• 複雑さは、努力の成果ではないことに気付こう。良い設計は見ていて気持ちが安らぐものであることを知ろう。
• コードは少しずつ書くこと。常にコーディングをきれいにできないか考えること。
• オブジェクト指向は、オブジェクトに処理を命ずる、というのを理解すること。
• アーキテクトもコーディングをすること。設計はコーディングの段階で成長していく。アーキテクトがコーディングしないというのは成長機会を失っていることに気付こう。
• アーキテクトの仕事は、ソフトウェアから不可逆性を排除する方法を見つけて、アーキテクチャを取り除くということを理解すること
• コードを共有するときは段取りがあることを理解しよう。まず、週単位や月単位にコミットするのはおかしい。コミットは意味のあるまとまりですること。
• 人を責めても成果は出ないし、プロセスに従えば成果が出るわけでもないことに気付こう。そして、仕事は、人を責めることでもプロセスに従うことでもなく、成果をあげることであると気付こう。
• 自分が学んだことをチームに共有しよう。チームの身の丈にあった方法で情報教諭しよう。ほんとうにパワポが必要かを考えよう。

よし、書いた。

2007年の本だし、ちょっと話が古いなと思う部分もあると思うけど書いた。

ここに書いてあることなんて当たり前でしょ。と思うように成長していきたい気持ち。