新しいコードを作成する前に、仕様を作成し、バグを修正する必要があることをパートナーに説得したいと思います。Joelテストを参照する必要がありますか?ジョエルのテストは最新だと思いますか?仕様を持たないことは、プロジェクト管理が悪いと思う。ジョエルのテストに同意しますか?何か追加してもらえますか?インスタンスのオープンソースについては言及していません。
新しいコードを作成する前に、仕様を作成し、バグを修正する必要があることをパートナーに説得したいと思います。Joelテストを参照する必要がありますか?ジョエルのテストは最新だと思いますか?仕様を持たないことは、プロジェクト管理が悪いと思う。ジョエルのテストに同意しますか?何か追加してもらえますか?インスタンスのオープンソースについては言及していません。
回答:
Joelのテストは最新のものだと思います-それは、「時代を超越した」他のソフトウェア記述と同じくらい最新のものです。
仕様なしで製品開発(ソフトウェア開発を含む)を行うことは、単なる狂気です。
行きたい場所をどうやって知るのですか?
仕様を書くことについて、私が指摘するポイントは1つだけです(実際、Joelの仕様は非常に優れているとは思いません...何よりも優れていますが、可能な限り優れていません)。そのポイントは:
仕様を作成するときは、製品の実行方法ではなく、製品が実行する必要があることだけを伝えます。
これは、仕様で実装の詳細を指示しないことを意味します。それはデザインアクティビティであり、デザイナーの経験と創造性に任せます。
[この規則の唯一の例外があります:時々 、特定の実装の詳細や方法が義務付けや必要とされ、場合は、それを入れているソフトウェアは、たとえば、。しなければならない PHPで書かれており、これは交渉ではないこと、それはに行きますスペック。これのインスタンスは非常に少ないはずです。]
私は追加するかもしれません:バグ追跡を持たないことは平等な狂気の行為です。それは単に最も専門的で愚かな操作方法であり、大きな痛みと苦痛をもたらします。
ここで悪魔の擁護者を演じ、ジョエルテストが最新ではないことを提案します。あまりにも一般的です。技術が成熟するにつれて、質問は彼がテストを書いたときよりも具体的になるはずです。
ユーザーストーリーとアジャイル開発プロセスがあるため、仕様文書、少なくとも大きな先行仕様文書は必要ありません。この質問は、「設計されているソリューションに適したドキュメントのレベルですか?」に変更する必要があります。ほとんどの場合、2週間ごとに配信される、より小さく、よりタイトなユーザーストーリーは、製品を詳細に説明する大きな先行ドキュメントよりもはるかに役立ちます。ただし、次のMars Roverを構築する場合は、詳細な事前設計ドキュメントが必要になる場合があります。会社に設計仕様があるかどうかを尋ねられた場合、「実際にはそうではありません。代わりにアジャイルプロセスとユーザーストーリーを使用します」という応答を聞いても驚かないでしょう。
第二に、「毎日のビルド」の質問は、継続的な統合に関する質問に変更する必要があります。構築に数時間かかるソフトウェア(99.99%の場所では実行されない)を構築する場合を除き、企業は継続的インテグレーションを使用しているかどうかを質問する必要があります。
Joelテストのほとんどは、実際にはまったく日付がありません。作業環境を示す良い方法です。