いろいろ考えさせられる本。
ウソ5 - ソフトウエアには、もっと開発方法論が必要である。
というのはかなりドキっとさせられる。開発方法論が駄目だとどうすればいいのか。 (状況に応じて)自分なりのパターンを作って適用していくのも意味がないのか。 毎回毎回うんうん唸ってその場限りの作戦を立てなければならないのか…。
よく読むと
筆者の意見は、小文字の m の methodology は善である。 大文字の M の Methodology は悪であり、使う場合は相当の注意を払うべきだ。
とあり、なるほどと。
アジャイル開発、エクストリーム・プログラミングに対する話も随所で述べられていて興味深い。
真実23 - プロジェクトが途中打ち切りになる二つの原因のうち、一つは、仕様を凍結できないことだ。
もかなり納得。
技術者もそうだが、ぜひ上層部の人たちに読んでもらいたい。 「見積もり」とか「要求仕様」とか「保守」とか。
「スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。」で参照したのがきっかけで、ジョエルテストで有名な Joel on Software を読んだ。
ソフトウェアプロジェクトマネージャー・ソフトウェア開発者必読書の1つだね。
扱っているテーマは幅広くどれも気になる記事ばかり。 ここではメモがてら興味深かった主要な記事をピックアップ。
3分でできるソフトウェアチームの良さを評価する有名なテスト。
仕様書についての章が何章か続く。仕様書について実践的なことが書かれているのでとても参考になる。
サンプル仕様書が用意されている。 何をどのように書くべきかについて参考になる。
そしてなぜ誰も読まないかといえば、仕様書があまりに退屈でつまらないからだ。p.79
これを読んでからできるだけ話を具体的に書くように心掛けている。 適当に外国人の名前をつけてシナリオを書くとなぜか皆喜んだ(同僚も外注も社長も)。
ルール5: テンプレートは有害である p.86
ソフトウェアプロジェクトマネジメントでうまくいかない事が多い筆頭がスケジュール。
「そのコードのスケジュールを立てられるのは、それを書くプログラマだけ」「タスクの粒度を細かくすること (それによって、その機能をデザインすることを強いられる)」「スケジュールにデバッグ・結合・バッファ・休暇・祝日その他のことのための項目を入れる」「決してマネージャにプログラマの見積もりを減らさせない」
あたりが参考になる。なおこの記事は Web でアップデートされている。
開発するソフトウェアの種類によって使える開発方法論が異なるのだから、自分のプロジェクトで適用できるかよく考えること。
抽象化ばかり考えて意味のないところまでいかないこと。
つい最近うちの会社でも表彰式があったばかりなんだけれども……。
マネージャは賞与の提案を上位に送り、それは完全に無視され、ほとんどランダムに賞与が支給される。p.188
多くの人は、自分が非常に良い仕事をしていると思っている (実際はそうでない場合でも)。p.189
一つのプロジェクトに専念したいね。
人々に同時に1つより多くの作業をさせるべきではない。p.202
→ スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。
顧客は自分が何が欲しいか分かっていない。顧客が自分で何が欲しいか分かっていると期待するのはやめることだ。p.210
これを理解していないと何でも言うなりにソフトウェア化しようとして失敗する。
多くの人は自分が下っ端だと思ってモンモンとしている。
まずは不満を持つだけでなくて、個人ででも実行しようということ。
[ 読書ノート ] [ お薦めの本 ] [ ソフトウェアプロジェクトマネジメント ] [ マネージャー ]
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。