起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識淺談軟件項目規模估計：估什么？
預測是一件非常困難的事情，尤其是預測未來?！?尼爾斯.玻爾
定制化軟件開發是一件復雜的事情，尤其是目前我們主要提供的端到端軟件交付，它極大拓寬了軟件開發的生命周期，更加著眼于業務價值，但這也增加了整個設計、分析、交付過程中的復雜度。軟件交付已不僅僅是傳統意義上的技術交付，更包括了體驗設計、業務分析、測試、管理、運維、運營支持、以及流程管理的內容。
基于筆者幾年淺薄的軟件交付經驗，嘗試總結在初期進行規模估計的時候，應該考慮的范圍會有哪些。
體驗設計
在筆者看來，在互聯網產品的影響下，目前客戶對體驗設計的要求已經到了“奢侈”的程度，經常對僅有幾十個、甚至幾個用戶的系統提出很多關于體驗式上的較高要求。但人畢竟是視覺動物，好的展示效果、使用體驗往往是產品的加分項，能帶來比較大的口碑收益。同時，這也是最容易跟客戶（尤其是業務客戶）產生交流和互動的地方，有利于跟客戶的深入溝通，特別是這些終端用戶還經常是項目重要的 Stakeholder。
在端到端交付中，設計人員會參與項目的整個交付過程，從最開始的 Discovery 一直到產品的上線，從與客戶溝通設計需求，到方案設計、方案確認，再到開發過程中與開發人員、業務人員協同方案落地，從源頭到落地保證方案的準確性。
功能性需求
在敏捷軟件開發中，系統的業務功能會從終端用戶的業務價值交付出發，被拆解為一個個用戶故事，形如：
故事卡模板
全部的業務功能會形成一個用戶故事列表，來從更細的粒度上描繪業務全景。 這部分是項目規模估計中最重要的一部分。所以業務分析和拆分的整個過程要非常非常非常的仔細，因為初期的這個故事列表很可能會成為對客戶的一個承諾，未來如果發現不在故事列表中，但也必須要做的重要支撐功能時，就需要增加跟客戶協商談判的成本，或者默默的認了。
在拆分完成進行復檢時，敏捷團隊（而不僅僅是BA），可以問自己下面這幾個問題：
- 客戶所處的行業是什么？本行業有沒有固定的業務領域模型？客戶想做的是哪個模型的擴展？
- 有沒有類似的競品可以參考？
- 有沒有考慮系統交互的全部的用戶角色？
- 有沒有系統自動推進、不需要用戶交互的任務？
- 有沒有考慮全部的業務場景？正常的場景和異常的場景？
- 每個場景的每一步是如何對接的？具體的詳情是什么？是否可以進行進一步拆分？
- 每個環節使用的用戶數量是多少，會有性能要求么（精確到每個指標）？
- 系統邊界是什么？待開發系統和待集成系統各自完成的業務功能是什么？
- 是全新的系統，還是需要與舊有系統做數據遷移，逐步替代？是否有逐步替代的計劃和方案？
拆分方法可以參考《庖丁解牛：產品需求分析》，在這里就不展開了。
非功能需求
除了功能需求外，非功能需求更要引起重視，這往往是項目容易忽略、掉到坑里的地方。
考慮到我們開發的往往是 Web 或者 Mobile的產品，最基本的，要考慮：
- 瀏覽器的兼容性問題：兼容哪些瀏覽器，兼容版本。
- 移動端的兼容性問題：兼容哪些手機設備，操作系統，版本號。
除此之外還包括：性能，可維護性，可測試性，可用性，可移植性，可擴展性等，項目太多就不展開了，這里單說下性能。
性能是個比較容易量化的需求，比如同時并發訪問的人數、頁面讀取時間等。對于一些用戶量較大、高并發的場景，可能需要做多級的性能調優：從應用代碼級別、到數據庫級別，再到部署架構級別，甚至CDN緩存級別，都可能成為需要考慮的部分。
這部分根據項目的情況不同，差異會很大。有的項目可能并不需要投入太多精力在這上面，只需要對其中明顯的性能問題進行一些修復，但有的項目可能整個項目都在滿足性能上的要求，所以不可不察。
技術架構
有些項目，客戶會比較看重我們對產品架構的設計能力。這個時候，技術架構不僅僅需要簡單滿足短期項目的訴求，還需要有更長遠的規劃。在這種情況下，前期 Inception 的時間不能支撐整個項目技術架構的設計和搭建，可能是需要更長時間的設計和演進，這部分可以作為獨立的工作來進行估計。部署架構亦然。
開發部署環境
同時，為了能夠支撐持續集成/持續交付，整個交付過程往往需要一系列的開發、測試、上線的環境，包括但不限于：CI環境、開發環境、QA環境、SIT環境、UAT環境、Pre-Prod和Prod環境。如果這些沒有預先準備好的話，這些環境的準備工作也會花不少時間，尤其是當同時涉及客戶內網和外網的情況下，甚至會成為項目的嚴重風險。
與三方的集成
集成往往不是個小問題。目前的軟件項目，往往都是基于現有的系統進行開發，所以集成的工作必不可少。如何進行契約的制定、數據的遷移、其它供應商三方系統開發工作的推進、接口的集成聯調等，往往都是項目全周期的工作重點。一定從項目第一天開始就要思考持續集成、持續交付，萬不可把這部分工作留到最后處理，血淚經驗之談。
測試
敏捷項目中的測試，跟傳統的先開發、再測試的這種方式極為不同的一點是：沒有固定的 Tester，而是全員來保證軟件的質量。測試包括的范疇也比較廣，目前項目中的標配包括了：
- 自動化測試：單元測試/集成測試/功能測試
- 迭代內探索性測試
- 業務回歸測試
- 性能測試
- 安全測試
- 代碼質量測試
- …
這些測試根據項目規模、復雜度的不同，規模估計上會有較大差距。就比如安全測試，有的系統是面對企業內部用戶使用的，僅部署在內網，這樣僅實現內部權限控制即可，一般不會有安全問題，安全測試的粒度也可以適當放粗；但有的系統要部署在互聯網上，供終端用戶使用，此時安全測試不僅僅要考慮應用層面的權限隔離，還要考慮網絡層面的防火墻、防攻擊策略等。這部分可以由專業的安全專家提供建議方案，看如何合理的將測試任務放到總的規模估計中，并與客戶提早達成一致。
驗收交接流程
這部分是比較容易忽略的，主要包括了軟件的整個驗收流程、代碼交接、文檔撰寫工作，根據情況不同，可能會使項目延長1周~4周不等的時間，在項目之初也要考慮到。
總結
在初期進行規模估計絕不是一件容易的事情，需要跟客戶的深度溝通，敏銳的洞察力，多角色的思考，以及快速的判斷，否則后面……
作者：張久坤，ThoughtWorks高級咨詢師。程序員出身，參與過多個國內外大型項目的交付工作，對敏捷有深入的理解，目前專注于敏捷項目的業務分析和項目管理的工作。
題圖來自unsplash，基于CC0協議
- 目前還沒評論，等你發揮！
