機能仕様を記述することはどれほど重要ですか？

https://stackoverflow.com/questions/409156

03-07-2019
|

質問

機能仕様を書いたことはありません。コードに飛び込んで、デザインを進めていきます。これまでのところうまくいきましたが、最近の個人的なプロジェクトのために、製品のすべての機能と、実装方法の詳細に入らずにどのように「機能する」べきかを説明するいくつかの仕様を書いていますとても貴重だと思います。

あなたの考えは何ですか、仕様を書きますか、それともコーディングを開始して計画を立てますか？

解決

自宅から最寄りの食料品店まで運転している場合、おそらく地図は必要ありません。しかし...

以前に他の州に行ったことのない場所に運転している場合は、おそらくそうします。

運転の楽しみのためにランダムに運転している場合、おそらく地図は必要ありません。しかし...

最も効果的な方法（距離の最小化、時間の最小化、途中で3つの特定の停止など）でどこかに到達しようとしている場合は、おそらくそうします。

自分で運転していて、おもしろいものを見つけたらいつでも停止したり、目的地やルートを再検討したりするために、好きなだけ長く取ることができる場合、地図は必要ないかもしれません。しかし...

コンボイの一員として運転していて、全員が食事と宿泊を一緒にやる必要があり、一緒に到着する必要がある場合は、おそらくそうします。

プログラミングについて話していないと思うなら、おそらく機能仕様、ストーリーカード、物語、CRCなどは必要ないでしょう。しかし...

あなたが私だと思うなら、上記の少なくとも1つを検討することをお勧めします。

;-）

他のヒント

「コードにジャンプ」する人向けおよび「設計どおりの設計」など、機能仕様を含む何かを書く方が現在の方法よりも優れていると思います。時間をかけて考え、設計を開始する前に設計すれば、多大な時間と労力を節約できます。

要件は、作成する必要があるものを定義するのに役立ちます。
デザインは、あなたが計画しているものを定義するのに役立ちます。
ユーザーのドキュメントは、作成した内容を定義します。

ほとんどの場所には、これら3つのドキュメントのバリエーションがあることがわかります。機能仕様は設計文書にまとめられます。

確信がない場合は、迅速な開発を読むことをお勧めします。計画と設計により多くの時間を費やせば、本当に速く仕事を終わらせることができます。

「コードをまっすぐに」ジャンプ大規模なソフトウェアプロジェクトの場合は、ほぼ間違いなく失敗につながります（ブリッジを構築するためにレンガのポーズをすぐに開始するように）。

37 Signals のメンバーは、紙に短い文書を書く方が、複雑な仕様。これは、新しいWebサイト（設計とアイデアが厳格なスキーマよりも優れている可能性がある）をすばやくモックアップする場合には当てはまりますが、他の現実の状況では常に受け入れられるとは限りません。

顧客によって署名された仕様書が持つことができる（合法、さらには）重要性を考えてください。

士気はおそらく次のとおりです。プロジェクトのシナリオに従って、柔軟であり、機能的または技術的な仕様を必要に応じて計画します。

1回限りのハッキングや小さなユーティリティの場合は、気にしないでください。

しかし、真剣で大規模なアプリケーションを作成していて、要求の厳しい顧客がいて、長時間実行しなければならない場合、それは必須です。主題に関するJoelのすばらしい記事を読んでください-良いスタートです。

両方の方法で行いますが、テスト駆動開発から何かを学びました...

ロードマップを使用してコーディングを開始すると、途中で分岐する方法がわからないまま道路を歩き始めた場合よりも、はるかに速く旅行の終わりに到達します。

すべての機能が実行することの詳細をすべて書き留める必要はありませんが、すべてを適切に機能させるために何をすべきかを理解できるように、基本を定義します。

以上のことはすべて、昨日、一連の例外ハンドラーを作成する必要がありましたが、まったく設計しようとせずに、そのままハマっていました。たぶん私は自分のアドバイスを読み直すべきです;）

多くの人が認めたり気づいたりしたくないのは、ソフトウェア開発はエンジニアリングの分野だということです。それらがどのように物事に近づくかについて多くを学ぶことができます。アプリケーションで何をするかを計画することは、小さなプロジェクトでは必ずしも重要ではありません。通常、すぐに戻ってミスを修正する方が簡単だからです。システムが最初に行うことを書き留めるのに比べて、どれだけ時間が無駄になっているかはわかりません。

実際には、大規模なプロジェクトでは、システムの仕組みと機能のロードマップを作成することがほぼ必要です。必要に応じて機能仕様と呼びますが、通常、手順aの後に手順bが続く理由を示すことができるものが必要です。私たちは皆、それをその場で考えることができると思います（私も間違いなくこれを犯しています）が、実際には問題を引き起こします。考えてみて、何かに遭遇して自分に言った回数を考えてみてください。または、他の誰かがあなたがやったことを見て、あなたが10をしたタスクを達成するために3つのステップを取ることができることを示しました。

それを紙に書き留めることは、あなたが何をしようとしているのかを考えることを本当に強制します。一旦それが紙の上にあるならば、それはもう曖昧な考えではありません、そして、あなたはそれを見て、あなたが考えていたことが本当に意味があるかどうか評価することができます。 5000ページのコードを変更するよりも、1ページのドキュメントを変更する方が簡単です。

XP（または同様の）環境で作業している場合、ストーリーを使用して、多くのユニットおよび廊下の使用可能性テストとともに開発をガイドします（ Kool-Aid 。

ただし、仕様が絶対に必要な領域が1つあります。外部チームと調整する場合です。特定のプログラムの動作、データベース設計のいくつかの側面、および多くのファイルレイアウトについて合意する必要がある大規模な保険会社とのプロジェクトがありました。仕様がなければ、私は私たちが約束したことの創造的な解釈に対して広くオープンでした。これらは良き人々でした-私は彼らを信頼し、彼らと働くことが好きでした。しかし、それでも、その仕様がなければ、死の行進だったでしょう。仕様では、合意されたレイアウトから逸脱した場所、または追加のカスタム作業（$$！）を要求している場所を常に指摘できました。半拮抗的な関係で作業している場合、仕様はさらに悪いことからあなたを救うことができます：訴訟。

ああ、そうです、Kieveliに同意します：「コードへのジャンプの権利」決して良いアイデアではありません。

完全に「依存する」と言います。問題のタイプについて。私はそれのために、またはあなたの上の層のためにそれを書いているのかと自問する傾向があります。私もこれについて議論しましたが、私の個人的な経験では、（コースを離れるのではなく）期待どおりにプロジェクトを軌道に乗せておくべきだと言います。

私は、いくつかの理由で、コードに飛び込むのではなく、紙の上で些細でない問題を最初に大まかに分解するのが好きです。

私が紙に書くものは、コンパイルしたり、コンピュータにとって意味をなさないでください
紙の上で任意の抽象化レベルで作業できます
本当に簡単に写真や図を追加できます
概念を非常にすばやく考えてデバッグできます

私が扱っている問題がかなりの時間または他の多くの人々のいずれかを含む可能性が高い場合、アウトラインの機能仕様としてそれを書きます。ソフトウェアを開発するために他の誰かから報酬が支払われており、あいまいさが生じる可能性がある場合は、このあいまいさを取り除くために十分な詳細を追加します。また、ソフトウェアが作成されたら、このドキュメントを自動テストケースの開発の出発点として使用したいと思います。

別の言い方をすれば、自分が書いているソフトウェアを適切に理解し、関係する他の人に起こりうる曖昧さを解決するのに十分な機能仕様を書きます。

機能仕様の必要性を感じることはめったにありません。 OTOH私はいつも電話をかける機能に責任があるユーザーを持っているので、私は行くときに常に機能要件のためにそれらを照会することができます。

私にとって、機能仕様は技術的というよりも政治的なツールです。仕様を作成したら、後で実装の問題を発見した場合、いつでも仕様を非難できると思います。しかし、誰が責任を負うかは私には本当に興味がありませんが、スケープゴートを見つけたとしても問題はまだあります。実装を再検討し、それを正しく行うことをお勧めします。

適切な仕様を作成することは事実上不可能です。なぜなら、問題を解決するのに十分な問題やツール、または環境の将来の変更を本当に知らないからです。

したがって、アジャイルなアプローチを開発に適応させ、必要に応じてリソースを再検討し、リファクタリングするのに十分なリソースと時間を費やすことが非常に重要だと思います。

これらを記述しないことが重要です：機能仕様について機能的なものはありません

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow