Joel on Software - やさしい機能仕様 - パート 4: ヒント
Joel Spolsky ジョエル・スポルスキ 翻訳: 2000/10/15 さて、私たちはなぜ仕様書が必要なのか、仕様書の中身は何か、そして誰がそれを書くべきかについて話してきた。このシリーズの最後のパートでは、良い仕様書を書くためのアドバイスをお話ししよう。 仕様書を実際に書いているチームから聞く最大の不平は、「誰も読まない」ということだ。誰も仕様書を読まない場合、それを書いている人たちはひがみっぽくなる。エンジニアが4インチの厚さの仕様書の山を使ってキュービクルを拡張している昔のディルバートの漫画みたいなものだ。典型的な官僚的大企業では、みんな何ヶ月もかけて退屈な仕様書を書いている。仕様書が出来上がると、それは棚に収められ、再び取り下ろされることはなく、製品は仕様書に書かれていることとは無関係にスクラッチから実装される。それは誰も仕様書を読まないからで、そしてなぜ誰も読まないかと言え
Joel on Software - やさしい機能仕様 - パート 3: だけど･･･どうやって書くの?
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/4 あなたはなぜ仕様書を書く必要があるのかと仕様書に書くべきことは何かについて学んだ。では誰がそれを書くべきかについて話すことにしよう。 誰が仕様書を書くか? こごでMicrosoftの歴史について少し話をさせてほしい。Microsoftが急速に成長し始めた1980年代のことだが、ソフトウェアマネジメントの古典である人月の神話はみんな読んでいた(あなたがまだ読んでいないのなら、ぜひともお勧めする)。この本の要点は、遅れているプロジェクトにプログラマを増員すると、プロジェクトはよけい遅れるということだ。その理由は、チームにn人プログラマがいるとき、コミュニケーション・パスの数はn(n-1)/2で、これはO(n2)で増加するからだ。 そのためMicrosoftのプログラマたちは、どんどん大
Joel on Software - やさしい機能仕様 - パート 2: 仕様書とはどんなものか?
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/3 (パート1はもう読んだ? 読んでなければ、ここにある。) このアーティクル･シリーズで扱っているのは機能仕様であって、技術仕様ではない。人々はこの2つを混同している。標準的な用語があるのかどうか知らないが、私がこれらの用語を使うときに意味しているのは以下のことだ。 機能仕様書は、ユーザの観点から製品がどのように動くか記述する。それはどのように実装されるかは問題にしない。それは機能を話題としており、画面とか、メニューとか、ダイアログとかいったものの仕様を定める。 技術仕様書は、プログラムの内部の実装について記述する。それはデータ構造、関係データベースモデル、プログラミング言語や開発ツールの選択、アルゴリズムといったものを話題としている。 あなたが製品を隅から隅までデザインするとき、最
Joel on Software - やさしい機能仕様 - パート 1: なぜわざわざ書く必要があるのか?
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/2 The Joel Testを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければならないということだった。仕様書はデンタルフロスみたいなもので、みんな書かなきゃいけないと思ってはいるが、誰も書かない。 なぜ人々は仕様書を書きたがらないんだろう? 人々は仕様書作成フェーズを飛ばせば時間を節約できると主張している。彼らは仕様書作成がNASAのスペースシャトルのエンジニアか巨大な保険会社で働いているような人たちのための贅沢品であるかのように振舞っている。戯言だ。何よりも仕様書を書かないというのは、あなたがソフトウェアプロジェクトに持ち込む、最大かつ不必要なリスクである。それは着替えだけリュックに詰めて、その場になれば何とかなることを期待してモハーベ砂漠の横断に出発するの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
