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