團隊作業三評分細則
阿新 • • 發佈：2017-11-11
計劃 工作 系統 條目 能夠 order 競爭 tab 產品
| 檢查項 | 分值 | 備註 | |
| 需求&原型改進 | 使用前的場景（痛點） 使用後的場景（痛點的解決） | 1 | 主要回答： 1.客戶的問題的場景我們是不是真的找到了？ 2.我們為產品設定的使用場景是否真的會發生？ 如果找不出有與目標用戶溝通的痕跡，比如只是單純的重復之前說過的用戶痛點，可給 0 分或給低分 |
| 描述上次規格說明書不足的地方 | 0.25 | ||
| 規格說明書具體改進的內容發布在隨筆上 | 0.75 | ||
| 用戶場景描述 | 1 | 以完成某個目的為導向，按順序描述各個操作步驟得1分。參照《構建之法》P212的例子。 對登陸註冊過於詳細而主要功能簡單扣0.5； 好幾項目的混合的用戶場景扣0.25分 | |
| 功能四象限 | 0.5 | 將登陸和註冊放到第一象限的不得分； 最能體現APP競爭力的功能沒放在第一象限扣0.25分； 將基本功能放在第一象限扣0.25分； 沒有使用四象限表格的形式扣0.25分； | |
| WBS | 1 | 子節點覆蓋父節點包含的所有內容 0.5分；完全見不到WBS結構的倒扣1分 | |
| 各成員估計完成任務需要的時間 | 0.5 | 沒有標註成員對應哪個部分扣0.25分； | |
| 系統設計 | 架構設計 | 1 | 有分層且與項目模塊結合0.5； 各種圖示建模0.5； |
| 數據庫設計 | 1 | 表結構 或 ER圖 至少要有一個 | |
| Alpha任務分配計劃 | 以需求分析為主，選擇和排序本次叠代需要實現的訂單條目 | 1 | 所列任務組合起來不能夠使應用達到差不多能用，扣0.25分； 缺少殺手功能的初步實現，扣0.25分； 任務粒度太大扣0.25分； 任務量過少，扣0.25分； 如果描述的不是 Alpha 版本的功能，該項不得分； |
| 以設計為主，確定系統設計方案和工作內容 | 1 | 沒有分配任務給團隊成員，扣0.25分； 沒有描述針對各個任務所要采用的技術方案，扣0.5分 | |
| 測試計劃 | 測試計劃 | 1 | |
| 合計 | 10 | ||
團隊作業三評分細則