~ my tech diary ~

Steve McConnell氏のRapid Developmentを読みました。90年代の書籍。日本語訳はこちらに。ラピッドデベロップメント―効率的な開発を目指して Rapid Developmentは、短いスケジュールで開発をどんどん回していく、という考え方を持った開発スタイルです。最近のAgileの風潮に対して、以前からそういう開発スタイルが提唱されていた、という参考になりました。 ただ、読書を進めていくと、開発プロセスに関するところは大学で教授から学んだことと大半が重なってて、なんか講義を見直している感じがしました。 Part1. Effective development For every complex problem, there is an answer that is short, simple, and wrong. — H.L. Mencken 人に関する問題が、最もソフトウェア開発や品質に影響を与える、と早い段階で書いています。また、”Motivation”が強く影響する、とも書いています。 Classic mistakeとして幾つか実例を挙げています。分類として、人、プロセス、製品、技術に関わるところから。いずれも、昨今のAgileの文脈で言われることの多い従来の開発における問題やらなんやら書かれています。これを見ると、結局は問題は古くからあって気づいた人はどうにかしようとしている、ということを知ることができます。 ソフトウェア開発に関わる活動のプラクティスを、Management、Technical、Quality-Assurance の面から色々紐解いています。その中では、例えばエラーが出やすいモジュールに対する言及や、Testing、レビュー活動など、現在やっているプラクティスがもろもろ含まれていました。 リスクマネジメントのことも。リスクを識別し、分析、優先度をつけて可能な領域で制御する。そこらへんも書いていたり。 ここら辺を書いていますが、個人的に良かったのはそれらをまとめ、体験としてまとめているところでした。昨今の開発全体を書いている書籍を読むよりは、これを読んだ方が有益な感じがします。 Part2. Rapid Development Part2では、今までの一般的な効率的な開発の説明のなかから、Rapid developmentとしてのプラクティスをまとめています。 Agileのプランニングポーカーみたいなタスクのサイズの計測とか、そういう話に似たものも出てきます。いずれも、時間に対してどこまでやるか、を現実としてどうするかに関する話を交えています。 変えることができるところ、できないところを分けて、いろいろ試行錯誤している感じですね。 ただ、現在とは使える周辺ツールにより当時では時間がかかっていたことも短時間で実施できるようになっていることもあり、書籍の数値が完全に正しいというわけでもありません。一方で、考慮しなければいけない要素自体は、ソフトウェア開発という文脈ではとても参考になるものです。 ここには 時間、コスト、実装する機能の量に関するトレードオフ に関しても、すべて書かれています。なので、昨今のAgile開発に類する開発本を読むよりは、この書籍を読む。その上で、当時問題だったところから現在までに変わったところ(例えば、自動化されたテスト環境とか)を把握していく方が、しっかりとした考えを備えることができそう、と感じました。 というか、90年代の書籍に開発の根本的な要素がまとめられた書籍が多く、それらが現在の開発においても色あせていないところが多い。それは逆に、ツールが発展しつつも、そのコアとなる問題は変わっていないし、 その問題解決は簡単ではない ということなのですかね。 このRapid developmentの開発プロセスのwaterfallとか、spiralとか読んでいると、大学の頃に学んだことに近い、そのまんまなところが頭に浮かんできた。。。 要求分析の話とかも。 面白かったのは、high-performance teamというように、チームで高い成果を出すための大事な要素もまとめられていたところです。人やチームに対する考察も、しっかり書かれているのは素敵ですね。その中で、特に 楽しもう!! が1つのトピックで書かれていたところが印象的。アンチパターンも多くのっているところも良かったです。ここらへんは昨今のAgileの文脈とか、開発プロセスの話でよくでますね。時代は回る〜。 Silver-Bullet…More