如何避免分析癱瘓？
摘要：
分析癱瘓是專案的可怕黑洞。那麼，如何認識到你可能處於分析癱瘓狀態呢？以下是一些可能提示你的症狀。
需求發展似乎永遠持續下去
新版本的系統需求文件不斷髮布，同時也伴隨著流失的感覺。
大量實質...
分析癱瘓是專案的可怕黑洞。那麼，如何認識到你可能處於分析癱瘓狀態呢？以下是一些可能提示你的症狀。
- 需求發展似乎永遠持續下去
- 新版本的系統需求文件不斷髮布，同時也伴隨著流失的感覺。
- 大量實質性變更被引入基準之後，很久才被引入到業務需求文件中。
- 為了“完整性”，所有需求都以多種方式使用許多不同的模型來記錄，但是並沒有增加任何清晰
- 該小組被指示，需求完成後才可進行編碼。
與其發現自己正陷於分析癱瘓中，不如從一開始就避免它，您可以執行以下操作：
- 記住，你的終端產品不是需求文件，而是軟體。
- 根據您的專案、時間表、團隊文化等選擇適當的SDLC。一些專案使用傳統的瀑布方法工作得很好，而另一些則不能。
- 你的要求永遠不會完美。爭取“足夠好”，同時確保你避免了需求上的重大差距。當需求被認為是“足夠好”和你將如何定義“足夠好”時，作為一個團隊來決定。問：在確定發展之前，什麼是可接受的風險量？確定誰將審查需求，併成為決策過程的一部分，他們是“足夠好”。這可能包括業務分析師、客戶、內部利益相關者、開發人員和測試人員。
- 不要用“因為”來描述事物。模擬事務是個複雜的事，避免書面語言卻過於簡單。
- 不要在需求部分的早期就進行UI設計。等到需求接近結束並進入SDLC的“設計”環節再開始。
這是一些能真正避免分析癱瘓的措施，但它也並不是萬無一失。來源於Karl Weigers關於軟體需求陷阱的一次演講。