編寫功能規格有多重要？

Question

我從來沒有寫過功能規格說明，我更喜歡跳進代碼並在設計時進行設計。到目前爲止，它的工作很好，但對於最近的個人項目，我寫出了一些描述產品所有功能的規範，以及它如何「工作」而不涉及如何實現的細節，而且我發現它非常有價值。

你有什麼想法，你是否寫規格，或者你剛開始編碼和計劃，你去哪，以及哪種做法更好？

Answer 1

如果你從你家開車到最近的雜貨店，你可能不需要地圖。但...

如果你開車去的地方你以前從未去過另一個州，那麼你很可能會這樣做。

如果您隨意駕車駕車，您可能不需要地圖。但是......

如果你想以最有效的方式（儘量減少距離，最小化時間，沿途三次停止等等）進入某個地方，你可能會這樣做。

如果你自己開車，只要你喜歡，可以隨時停下來看看有趣的事情，或者重新考慮你的目的地或路線，你可能不需要地圖。但是...

如果你是作爲車隊的一部分駕駛，並且所有需要在一起的食物和一夜之間停下來，並且需要一起到達，那麼你很可能會這樣做。

如果你認爲我說的不是編程，你也許並不需要的功能規格，顯卡的故事，敘事，社區康復中心等，但...

如果你覺得我是，你可能至少要考慮以上其中一項。

;-)

Answer 2

重要的是不要把它們寫：There's Nothing Functional about a Functional Spec

Answer 3

我做到兩者兼得，但我已經學會從測試驅動開發的東西......

如果你進入一個路線圖，你將得到的編碼到旅程結束時，如果你只是開始在路上走，而不知道它如何在中間分叉，那麼速度會比你快。

你不必寫下每個函數將要做什麼的每個細節，而是定義你的基本知識，這樣你就知道你應該做些什麼才能使所有的東西一起工作。所有的說法，我需要寫一系列的異常處理程序昨天，我只是在沒有嘗試構建它的權利。也許我應該重讀我自己的建議;）

Answer 4

對於那些「跳進代碼」和「設計」的人來說，我會說寫任何東西，包括功能規格都比現在的方法要好。如果在開始之前花時間考慮並設計它，則可節省大量時間和精力。

• 需求幫助定義你需要做什麼。
• 設計有助於定義您正在制定的計劃。
• 用戶文檔定義您所做的。

你會發現大多數地方會有這些文件的一些變化。功能規格可以集中到設計文檔中。

如果您不服氣，我建議您閱讀Rapid Development。如果你花更多的時間來規劃和設計，你真的可以更快地完成工作。

Answer 5

對於一次性黑客和小公用事業，請不要打擾。

但是，如果您正在編寫一個嚴肅的大型應用程序，並且要求苛刻的客戶並且需要長時間運行，那麼這是必須的。閱讀喬爾關於這個問題的偉大的articles - 他們是一個好的開始。

Answer 6

爲大型軟件項目跳轉「直接輸入代碼」幾乎肯定會導致失敗（因爲立即開始冒充磚塊來搭建橋樑）。

在37 Signals的傢伙會說，寫一篇簡短的文檔比寫一篇複雜的規範更好。我可以說，這對於快速模擬新網站（設計和想法可能比僵化的模式更好）來說可能是正確的，但在其他現實生活中並不總是可以接受的。

只要想一下由客戶簽署的規範文檔（法律，甚至）的重要性。

士氣可能是：是靈活，並計劃與功能或技術規格儘可能多的，因爲你需要，根據項目的情況。

Answer 7

我會說完全「取決於」問題的類型。我傾向於問自己，我是爲了它還是爲了你上面的圖層而寫它。我也曾經討論過這個問題，而且我個人的經驗說，你應該保持項目符合預期（而不是脫離課程）。

Answer 8

很多人不想承認或意識到的是軟件開發是一門工程學科。關於他們如何處理事情，可以學到很多東西。在小型項目中繪製出您在應用程序中要做什麼並不一定非常重要，因爲通常更容易快速返回並修復錯誤。與寫下系統首先要做的事情相比，您看不到浪費了多少時間。

實際上，在大型項目中，幾乎必須具有系統工作原理和功能的路線圖。如果你願意的話，可以稱之爲功能規範，但通常你必須有一些能夠告訴你爲什麼步驟b遵循步驟a。我們都認爲我們可以實時進行思考（我對此也一定感到愧疚），但實際上這會給我們帶來問題。回想一下，問問自己，你曾經遇到過多少次，並對自己說：「我希望我早一點想到這件事？」或者別人看到你做了什麼，並告訴你，你可以採取3個步驟完成一項任務，你花了10個。

把它放在紙上確實會迫使你去思考你要做什麼。一旦它在紙上，它不再是一個模糊的想法，然後你可以看看它，並評估你的想法是否真的有意義。更改單頁文檔比更改5000行代碼更容易。

Answer 9

如果您在XP（或類似）的環境中工作，你會使用故事指導發展，有很多單位和走廊使用性測試以及（我已經喝了Kool-Aid，我猜）。

但是，有一個領域絕對需要一個規範：在與外部團隊進行協調時。我與一家大型保險公司有一個項目，我們需要就某些程序行爲，數據庫設計的某些方面和一些文件佈局達成一致。沒有這個規範，我開始對我們所承諾的東西進行創造性的解釋。這些人都是好人 - 我信任他們，喜歡和他們一起工作。但是，如果沒有這個規格，它將會是一場死亡遊行。根據規範，我總是可以指出他們偏離了商定的佈局或他們要求額外定製工作的地方（$$！）。如果使用半對抗關係，規範可以讓你免於更糟糕：一場官司。

噢，是的，我同意Kieveli的觀點：「跳到代碼」幾乎從來都不是一個好主意。

Answer 10

我很少覺得需要功能規格。 OTOH我總是讓用戶負責該功能的通話，所以我隨時可以隨時查詢他們的功能要求。

對我來說，功能規範更多的是一種政治工具而不是技術。我想，一旦你有了規範，如果你後來發現實現中的問題，你總是可以責怪規範。但是，誰應該責怪我並不感興趣，即使找到替罪羊，問題依然存在，更好的是重新審視實施並嘗試做對。

寫出一個好的規格幾乎是不可能的，因爲你真的不知道問題或工具或未來環境變化是否足夠。

因此，我認爲將敏捷方法應用於開發並投入足夠的資源和時間來重新訪問和重構就顯得尤爲重要。

Answer 11

我喜歡首先在紙上鬆散地分解任何非平凡的問題，而不是跳入代碼中，原因很多;

• 我寫在紙上的東西沒有編譯或任何意義，計算機
• 我可以在抽象的任意水平的工作，在紙上
• 我可以添加圖片和圖表確實容易
• 我想通過和調試概念很快

如果我負責的是有可能的問題涉及的時間或者是顯著量，或其他一些人，我要把它寫上去作爲大綱功能規格。如果我被別人支付來開發軟件，並且存在任何潛在的歧義，我會添加足夠的額外細節以消除這種模糊性。一旦軟件編寫完成，我還希望將此文檔作爲開發自動化測試用例的起點。換句話說，我寫了足夠的功能規範來正確理解我自己編寫的軟件，並解決任何涉及其他人的任何可能的含糊之處。