新しいプログラミングプロジェクトの仕様を作成する価値があり、時間（およびお金）を費やす価値がある場合、使用するメトリックと計算方法を教えてください。
4 に答える
2
プロジェクトの結果を決定的に予測または制御するために何らかの指標を使用しようとすると、不快なコーナーに追いやられると思います。最終的に、プロジェクトのスポンサー/所有者は、「どのくらいの期間/どのくらい」という質問をします。あなたができる最善のことは、現時点でのプロジェクトに関する現在の知識に基づいた予測です。これは、経験と文字通りの推測から得られたものです。
そして、ここに問題があります。あなたの見積もりは、数桁もずれている可能性があります。チームが問題のドメインを理解し、最大で 2 ～ 4 週間以内に見積もるにつれて、それらはより正確になります。Barry Boehm (および Steve McConnell) は、この効果を「円錐形の不確実性」の原則で説明しました。
システムまたは機能の実装から遠ざかるほど (左側)、見積もりの不正確さが大きくなります (-0.25x - 4x)。問題領域に近づき、理解を深めるにつれて、見積もりの精度が向上し始めます (0.8x - 1.0x)。これが、多くの「ノイズ」または「複雑さ」があるソフトウェア プロジェクト (つまり、ほぼすべてのプロジェクト) で、最後の責任ある瞬間まで具体的な見積もりを残したい理由です。
また、絶対的な確実性を期待できることも 1 つあります 。それは、仕様が時間の経過とともに変化するということです。その変化にどのように適応し、管理することを計画するかによって、成功が測られます。
したがって、作業範囲を決定するために行うことができる最善の判断は、プロジェクトに取り組むチームと「顧客」を集めて、プロジェクトの主要な機能である大きなブラシ ストロークを共同で作成することです。チームが相対的な重み付けポイントを使用して見積もるユーザー ストーリーとしてこれらを記述し (Mike Cohn のアジャイル見積もりと計画に関する本を参照)、何が期待されるかについての「ドラフト」予測を顧客に提供するリリース計画を考案します。投資は彼らが求めているリターンを生み出します。
もちろん、顧客がプロジェクトの継続的な評価に不可欠な、最終製品の機能的な増分を常に所有できるように、早期に/頻繁にリリースすることを想定しています。
于 2009-03-25T13:28:38.027 に答える
0
本質と顧客にとって最も重要なことに焦点を当てます。全体的なビジネス目標とビジョン。私は「エレベーターテスト」が好きです-2分以内にあなたの製品が何をするかを説明することができます：
（対象顧客）（必要性または機会の表明）（製品名）
が（製品カテゴリ）であり、（主要な競争力のある代替案）当社の製品（主要な差別化の表明）とは異なり、 （主な利点、購入する理由）
（GeoffreyMooreの本Crossingthe Chasmから）
おそらくこれはあなたの質問に答えませんが、そのような小さな「仕様」を書くことはどんなプロジェクトに対しても行うことができます。
于 2009-03-25T13:05:22.340 に答える
0
一般に、小さく、単純で、重要ではないプロジェクト：仕様はありません。大規模で複雑な重要なプロジェクト：間違いなく仕様。
ここには、カットアンドドライのメトリックはおそらくあり得ません。ソフトウェアエンジニアリングの判断に頼る必要があります。
于 2009-03-25T12:11:29.037 に答える
0
一般に、常に仕様を書き出す必要があります。そうしないように説得する必要があります。
- プロジェクトに複数の人がいる場合は、必ず仕様が必要になります。
- 1 人のプロジェクトに 1 週間以上かかる場合は、仕様書が必要になるでしょう。
- あなたとあなたのクライアントの間で混乱やコミュニケーションの問題が発生したことがある場合は、署名された仕様書が必須です.
于 2009-03-25T12:22:51.413 に答える