specifications - プロジェクト仕様書を最新の状態に保つのは誰ですか?

Question

はい、私たちは皆、プロジェクトの仕様について読んだり、それらがプロジェクトを時間通りにスコープ内に保つのにどのように役立つかなどを読むと、暖かくて曖昧な気持ちになります.

最新の仕様を保持している会社で実際に働いているのは誰ですか?

もしそうなら、その理由は何ですか？あなたが大規模なチームを持っている主な理由は何ですか?

Answer 1

Cor..プロジェクト仕様とは何ですか?

私たちはタイムラインなどを明確に定義したアイデアから始める傾向があります。その後、営業チームは顧客と話し、地球を約束します。私たちのプロジェクトの仕様は窓の外に出ます!

そのため、主に次の理由により、プロジェクト仕様を維持していません。

• 販売の約束が多すぎる。
• 私たちのチームは小規模であり、ドキュメントのコーディングに多くの時間を費やすことはできません。
• 多くの場合、変更を非常に迅速に (多くの場合できるだけ早く) 反映する必要があります。

これはすべて良いと思いますか？いいえ！しかし、現時点では、それから抜け出す方法を見つけるのは難しいです! やるべきことはたくさんあります（仕事の賢明さとプロセスの改善の両方）。

私のホームプロジェクトははるかに優れているように見えますが、スペックもかなり緩く、自分の仕事の仕方を知っています。

Answer 2

TDDを使用する場合は、定義上常に最新の仕様が必要です。

Answer 3

チーム ミーティングを行うホワイトボード上にある場合は、最適です。

Answer 4

プロジェクトの仕様が最新に保たれることはめったにないという事実は、少なくとも印刷されたドキュメントとして提示される場合は、その形式を再考する強力な理由です。そのようなものに関する私の非常に苦痛な経験は、それらが印刷され配布される前に、通常は時代遅れであるということです。その後、手作業で注釈を付けた後は、全員が異なるバージョンを使用する可能性があります。

とにかく「プロジェクト仕様」の目的は何ですか？私はそれがいくつかまたはすべてを含むかもしれないと思います

• 建築
• ビジネス要件
• パフォーマンスの制約
• 外部インターフェース
• 法的制約

潜在的にはさらにいくつか。コーディングを開始する前に上記のすべてを修正しようとする（疑わしい）知恵に立ち入ることなく、仕様がまったく記述されていないほど大きなプロジェクトについて、プロジェクトの存続期間中にこれらのカテゴリのいずれかが変更されなかった場合は驚きます。

与えられた要件を実行可能テストの形で提供できる方法はありますか？要件が満たされていることを定義する一連のテストの形で表現できない場合、それはおそらく十分に表現された要件ではないため、仕様は不完全です。

ウォード・カニンガムのFITフレームワークのようなものが、物事を行うためのより良い方法ではないのではないかと思います。したがって、基準はWikiに保持され、同じページで受け入れを定義するテストが行​​われます。

どのような種類のシステムまたはプロジェクトがそのアプローチの影響を受けないでしょうか？

Answer 5

これを行う最善の方法は、func の関連ビットを抽出することです。/ デザインスペック そして、それらを実際のコードに「ヘッダー」として含めます。

これらのヘッダーは、Javadoc などを使用して抽出できます。

そうすれば、開発者はコードを更新するときに「ヘッダー」を更新でき、プロジェクト全体の同期が保たれます。

私たちのためにかなりうまくいきます。