1樓：
首先功能點估算是以邏輯為出發點評估的，對於軟體專案技術層面的工作量幾乎沒有納入估算範圍，我們單位正在搞這個功能點估算藉此來考核大家的工作量，怨聲載道，功能點估算無法量化所有的需求，並且本身越大的專案估算出來的工期結果往往出入很大。個人認為此估算法還是一種理想狀態的評估方法，不推薦以此來進行工期估算。
2樓：老耿
軟體專案目前還是乙個很依賴個人經驗的領域，對於軟體功能點估算法，採用熟悉某一領域的專家估算法是相對比較靠譜的方式。專家估算法一般可採用德爾菲法，即對多位專家採用匿名提問的方式，獲取專家的個人判斷後，再將別的專家提供的回答提供給其他專家進行匿名評審，經過幾輪這樣的過程後，得出乙個相對靠譜的估算。還有乙個更簡便的方式是使用三點估算，對於領域中最有經驗的三位專家，分別給出最樂觀，最悲觀，平均的資料，並做貝塔分布的加權平均後，得出的資料相對靠譜。
3樓：禪悟逍遙
功能點估算，首先要找到乙個大家達成共識的基準功能點，然後估算其它功能點相對基準功能點的倍數。功能點估算只能是相對的，評估功能需求的相對大小，便於在需求變化或專案管理過程中等價替換開發的功能時使用。不太建議把功能點作為工期估計的方法。
4樓：Gino
你讓乙個對相關系統實現完全沒有概念的人來估，怎麼也不會靠譜的。想更靠譜一些，就需要有相關經驗的人來估算，越有經驗越準一些。這是乙個前提，即人的問題。
另乙個前提是功能的劃分粒度問題，這個是要做久了才能有效把握的。
5樓：
你的疑問你好好看下功能點估算的具體方法吧。要注意的是功能點估算的時候基本軟體需求，業務規則是相當明確的了，包括demo介面，否則很難真正使用起來。
AFP(調整後功能點)= UFP
(未調整功能點數目)* AF
(影響因子)
這裡UFP相對容易，更加難的是AF影響因子，需要根據使用的開發技術，軟體產品本身的特點多次修正才能夠達到目標。
還有FP是功能點，是規模。而不是工作量。即使有了規模，還得考慮生產率的問題，最後才能夠得到我們真正需要的工作量。
軟體專案的敏捷開發適合國企嗎？
張晨 哈哈哈，什麼是敏捷開發？先交付什麼，再交付什麼，然後交付什麼，到達這個里程碑之後再如何規劃路線圖，其中從設計到開發到測試到運維所有的崗位如何規劃等等等等。咱們大部分企業怎麼做敏捷？讓市場 需求 設計 測試和運維都玩兒蛋去吧，塗塗改改一張草圖，下週就要這個效果，程式猿，給老子上！請記住，敏捷開發...
針對軟體開發專案的專案管理系統有哪些？
田小姐 排行榜前十有天翎 禪道bai teambition等等，多個中du小型專案同時使用的話，可zhi以使用禪道 teambition這之類的dao,如果是科研專案的話可以選擇天翎 說一下這類軟體的特點 支援SaaS雲端，如果預算足夠可以直接買斷私有化部署 具體功能如下 支援專案組合與專案策略管理...
乙個軟體專案的專案經理不懂技術 能當好專案經理麼？
唔講粗口 要看情境，專案經理有偏業務側的也有偏IT開發側的。業務側專案經理對業務負責，推動產品設計，模組劃分 推動開發的對接人 專案經理 落實工作。顆粒度較大。T開發側專案經理對產品和業務都要負責，分析實現產品設計的工作 制定實施計畫和分工，推動落實等等。 半半 專案經理是協調資源，訂製總體計畫，把...