機能仕様はあなたの期待を助けますか、それとも妨げますか? ウォーターフォールの方法論を実践するプログラマーは、機能仕様に対してオープンですか? 私は 5 人のプログラマーのチームで作業している Web デザイナー/開発者であり、作業を開始するときに、同じ目標に向かって取り組んでいることがわかるように、必要なものを説明する機能仕様を書きたいと考えています。
2007 次
15 に答える
24
設計仕様と機能仕様を作成してサインオフするまで、フリーランスのプロジェクトを開始しません。あなたがそれを持っていない場合、不正なクライアントがニッケルを使ってあなたを死に至らしめる余地が多すぎます。機能仕様により、ターゲット/フォーカスを維持でき、作業するための自然なチェックリストが提供されます。
機能仕様がない場合は、すべての「what if」が忍び寄り始め、開発者が考え始めます。これは便利で、1時間しかかかりません。プロトタイプをコーディングして基本的に機能させるには1時間かかります。さらに、すべてのテストを設計してすべてのテストケースがカバーされていることを確認する日、さらに2、3日かけてすべてのバグを修正し、ドキュメントを作成します。仕様がない場合に、些細な追加のように見えるものを挿入する余地が多すぎます。悪名高い「スコープクリープ」について聞いたことは間違いありません。また、あなたがそれを配達し、あなたにお金を払わないように躊躇するとき、クライアントが「それは私が望んでいたものではありません...」と言う余地があまりにもあります。
開発の前に設計仕様と機能仕様を作成し、基本的な詳細だけでなく、使用される言語のすべてのニュアンスについての理解が同じであることをあなたとクライアントの両方が承認した場合-そうして初めて、実際の作業を開始できます。
そこにはいくつかの逸話があります。最初の逸話は非常に真実ですが、もう1つは一般的な誤解です。
- ソフトウェア開発はコードに関してわずか15％であり、残りはリソース/人の管理です。
- プロジェクトの最初の80％を完了するには20％の時間がかかり、最後の20％を完了するには残りの80％の時間がかかります。
誤解は、実用的なプロトタイプがそこにある道の80％であるということです-だまされてはいけません、そうではありません。そのため、クライアントは「何がそんなに時間がかかっているのか、ほぼ完了したと思いました」と言うのは簡単です。そして、数ヶ月前に終わっていたはずの何かに彼らが多額のお金を払っていることを不平を言います。そこにある設計方法論のいくつかは、この一般的な誤解に非常に役立ちます。ウォーターフォールの設計方法は、正しく使用されていない場合の1つです。
私の見解は、あなたの理解が同じであることを確認し、両方ともサインオフすることです。マイルストーンを設定し、プロトタイプがプロジェクトの完了から遠く離れていることをクライアントに最初から認識させ、それらのマイルストーンが何であるか、そしてクライアントがいつそれらが配信されることを期待できるかについて、最初から期待を設定します。
開発チームのプロジェクトマネージャーにとって、ドキュメントと期待がすべてです。それなしでは生きていけません。それは、「それは私が言ったことではない」または「それは私が意味したことではない」に対してあなたが持っている唯一の頼みの綱であり、「私はあなたにお金を払っていない」と言います。
私よりもはるかに有能な開発者が犯した多くの間違いから学び、それが彼らに何をしたかを見ました。プロジェクトで最も重要な2つのドキュメントは、設計仕様と機能仕様です。それらなしで家を出ないでください、さもないとそれは戻ってきてあなたをお尻に噛む可能性があります。
補遺re：ユーザーストーリー：
ユーザーストーリーについての追加の注意は、彼らが何であるかについて素晴らしいということです。それらは機能仕様に含まれている必要がありますが、機能仕様であってはなりません。
ユーザーストーリーは、単一のタスクのみを説明します。非常に軽量で、過度のディテールが含まれていません。一般的な推奨事項として、3x5カードに収まるはずです...プロジェクトマネージャーとして私に3x5カードを渡して、私が読んだものに基づいてソフトウェアを作成するように言われた場合、間違いなく最後にユーザーと彼らはプロジェクトマネージャーに彼らが望んでいたものではないことを伝えます。
機能仕様には、はるかに詳細なレベルが必要です。基本的なワークフローに限定されるべきではありません。機能仕様は、それらのユーザーストーリーの解釈に関するメモ、それらに加えることができる改善、効率を改善するために組み合わせることができる一般的なタスクとともに、一連のユーザーストーリーです。リストは続きます。
したがって、ユーザーストーリーは良い始まりですが、機能仕様に代わるものではなく、機能仕様の箇条書きです。
于 2008-12-19T15:35:26.690 に答える
7
私は主にウォーターフォールモデルを使用し、機能仕様のみを使用しています。自分で作業する場合（自分のモデルとプログラムを好きなように設定できる場合）、機能仕様を作成してから実装することから始めます。それは私に仕事のサイズと範囲についてのより良い考えを与え、私が関係する時間を見積もるのを助け、そして私が何かを逃さないことを確実にするのを助けます。
また、このドキュメントを次の宛先に渡すこともできます。
- 要件を明確にするためのユーザー
- 機能を作成する開発者
- テスターが正しいことをテストしていることを確認する
- 要件を分析できるようにするアーキテクト
ユーザーストーリーよりも機能要件を使用することは、好みとプロジェクトの範囲の問題です。ユーザーベースが小さい場合は、ユーザーストーリー（ユーザーが行う可能性のあるさまざまなイベントシーケンスの概要を示します）を回避できる場合がありますが、大規模なプロジェクトの場合は、機能要件を使用する必要があります。誤解。それらは、プロジェクトに関係するすべての人々とのコミュニケーション手段と考えてください。
于 2008-12-19T15:21:21.257 に答える
5
率直に言って、機能仕様はすでにBig-M（ウォーターフォール）手法の一部になっているはずです。機能仕様は、構築しようとしているものです。必ずしもそれをどのように構築するかではありません（これは、詳細な設計/仕様であり、ウォーターフォールの次のステップになります）。
まだ書いていない場合は、やめて書いてください。そうしないと、時間の無駄になります。ここからJoelの記事から始めることができます。
于 2008-12-19T15:23:56.260 に答える
3
コードを実行する前に機能仕様を書くのに頭を悩ませるのに10年以上かかりました。今、私は書くのに1日以上かかるもののために1つを書きます。詳細のレベルと仮定のレベルは、何をする必要があるかを明確に定義し、それを他の人に伝える（または思い出させる）ために必要なだけにする必要があります。それ以上のことは無駄です。
他の人はユーザーストーリーを好みます...あなたが何らかの計画をしている限り、これも問題ありません。
于 2008-12-19T15:37:03.690 に答える
2
これを実現するもう 1 つの方法は、ユーザー ストーリーを使用することです。
于 2008-12-19T15:10:46.520 に答える
1
2番目にCodeslaveの痛みのない機能仕様への参照を行います。 仕様に関する良いシリーズの記事です。機能仕様に含めるコンテンツについては、このStackoverflowの投稿も参照してください。
私はいくつかの大規模なプロジェクトを実施しました。その中には、数百人年の総努力を伴うプロジェクトも含まれます。プロジェクトチームが大きくなるにつれて、非公式のコミュニケーションチャネルの数は二次の上限で増加します。仕様がなければ、この非公式のコミュニケーションメカニズムは物事がコミュニケーションされる唯一の方法です。仕様では、通信チャネルはハブアンドスポークに近づき、プロジェクトチームサイズの線形関数のように成長します。
スペックは、チームが「同じ賛美歌のシートを歌う」ための唯一のスケーラブルな方法です。仕様についてはある程度のレビューと交渉が必要ですが、プロジェクトが自由に使えるようになるのを避けるために、最終的には誰かがこれの所有権を取得する必要があります。
于 2008-12-19T15:45:36.637 に答える
1
よく書かれた機能仕様は非常に便利だと思います。適切に編成された機能仕様は、テストの編成にも役立ちます（個々の要件からテストケースへの多対多のマッピング）。
<p style="tongue: in-cheek">また、大規模な組織での指差しにも役立ちます（要件が不正確でした！実装が要件に準拠していませんでした！QAがこの要件を適切にテストしていませんでした！など）</p>
于 2008-12-19T15:32:35.243 に答える
1
素敵なアイデアだと思いますし、試してみるべきです。
于 2008-12-19T16:01:46.840 に答える
1
私の経験では、機能仕様については、十分に語っていないことと多すぎることの間に微妙な境界線があります。
彼らが十分に語らなければ、誤解を招きやすい領域を残してしまいます。
彼らが言いすぎると、解決策を改善するための十分な「小刻みに動く余地」を残せなくなります。
そして、彼らは常に修正のプロセスに対してオープンであるべきです。
于 2009-01-19T22:28:43.717 に答える
1
ここでの回答のいくつかについてのほんの少しのコメント...
まず第一に、適度に複雑な要件 (そして非常に複雑な要件) については、優れた仕様書が重要であると私は信じています。ただし、それが優れた仕様であることを確認してください。つまり、明白なことを述べるだけでなく (すでに言及されているポスターのように)、あなた (または開発者) にとって些細なことと思われる部分を除外しないでください。より多くの知識がある可能性があるからです。システムのその部分を他の関係者 (テスターやドキュメンターなど) よりも重要視する必要があります。
そして、あなたの仕様が良ければ、それは読まれます - 私の経験では (そして私は過去数年間に多くの仕様を書いたり読んだりしてきました)、ダンプされるのは悪い仕様であり、フォローされるのは良い仕様です。
ユーザー ストーリー (またはユース ケースと呼ばれることもあります) について: これらはシナリオのアイデアを得るために重要だと思いますが、通常は詳細を置き換えることはできません (例: 画面のモックアップ、機能がどこでどのように構成可能か、データ モデル) 、移行の問題など）、より複雑な要件ではおそらく両方が必要になるでしょう。
于 2009-01-19T22:09:38.563 に答える
0
私が提唱している機能仕様やユーザーストーリーの興味深い代替案の1つは、最初にソフトウェアのユーザーマニュアルを作成することです。
これが単なる概念的なものである場合でも（つまり、マニュアルを出荷するつもりがない場合-誰も読まないのでおそらく読むべきではありません）、ソフトウェアが何をするかについての一般的な理解に到達するための便利で適度に軽量な方法です。して、のように見えます。そして、それはあなたに前もって設計をすることを強制します。
于 2008-12-19T15:45:52.270 に答える
0
それらを機能仕様、ビジネス要件、またはユーザーストーリーと呼んでも、それらはすべて開発プロセスにとって非常に有益です。
それらの問題は、それらが石に彫られ、システムがユーザーの実際のニーズに最終的に適合しないときに非難を渡すためのデバイスとして使用されるときに発生します。私は、システムが完了したときにシステムがどのように見えるかを正確に示すためのバイブルとしてではなく、反復プロセスの開始点として機能または要件を使用することを好みます。物事は変化し、ユーザーは通常、現実の世界でどのように機能するかを紙に概念化する代わりに、作業できるもの（おそらく実用的なプロトタイプ）を手に入れるまで、自分が何を望んでいるのかを理解していません。 。私が最も成功したプロジェクト
もちろん、以前の回答の1つが指摘したように、固定入札タイプの状況にある場合、このプロセスは機能しません。
于 2008-12-19T15:48:37.020 に答える
0
機能仕様によります。私は、ライターがシステムの内外を知り、そのように仕様を書いた機能仕様を持っていました。また、他のライターに、ユーザーとして期待したとおりにそれを書いてもらいました。
前者の場合、何を書く必要があるのか、どこに書く必要があるのかが正確にわかっているので簡単ですが、見積もりではこの機能だけが考慮されており、既存のコードはリファクタリングされていないため、既存のコードをリファクタリングするのは簡単ではありません。触れます。
後者の場合、（最終機能が同じである限り）リファクタリングする自由がありますが、それが私がよく知らないシステムである場合、時間の見積もりを行うのは困難です。
全体的に、私は機能仕様が大好きです。また、曲がる紙に書かれているので、柔軟でなければならないことを人々に思い出させたいと思います。
于 2008-12-19T15:22:22.377 に答える
0
機能仕様を書いたとしても、あなたが対処しようとしている人の詳細が失われることがあります。機能仕様がある種の UI モックアップと一緒に書かれている場合、それは大きな違いを生みます。UI モックアップは、ユーザーが何を思い描いているかを示すだけでなく、ユーザーが最初は思いもよらなかったことを思い出すきっかけにもなります。
于 2009-02-25T04:44:30.330 に答える
-2
私は多くの仕様を見たり書いたりしましたが、いくつかは非常に優れていましたが、ほとんどはそうではありませんでした。彼ら全員に共通していた主なことは、彼らが決して従われなかったということです。それらはすべて、コーディングの3日目までにクモの巣を持っていました。
必要に応じて仕様を作成します。それを行うのに最適な時期は、プロジェクトの最後です。開発者が従うことは無意味ですが、少なくとも何が行われたかを正確に表したものになります（私は実際には仕様ではありません）。しかし、仕様があなたのために書かれたコードを取得することを期待しないでください。それが本当の仕事です。何を書くべきかわからない場合は、利害関係者やユーザーに話しかけ、優れたユーザーストーリーを入手して、それを続けてください。
于 2008-12-19T15:45:32.720 に答える