大馬猴隊-事後諸葛亮分析
阿新 • • 發佈:2018-11-15
科學 後臺 正式 有感 管理 諸葛 們的 目的 效能 3.是否每一項任務都有清楚定義和衡量的交付件?
2. 我們采用了什麽辦法決定“推遲”和“必須實現”的功能?
3. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實現?這些工具有效麽?
-
設想和目標
1.我們的軟件要解決什麽問題?是否定義得很清楚?是否對典型用戶和典型場景有清晰的描述?
解決我們隊員提出的設想:微信能否更加簡潔,給用戶提供更純凈的聊天服務。定位很清楚。
2.是否有充足的時間來做計劃?
時間較充足。
3.團隊在計劃階段是如何解決成員對於計劃的不同意見的?
求同存異,以大佬意見為主。
-
計劃
1. 你原計劃的工作是否最後都做完了? 如果有沒做完的,為什麽?
原計劃中的兩個功能沒有完成,主要是因為時間問題,項目期間碰到考試,復習占用了大量時間。
2. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
沒有。
3.是否每一項任務都有清楚定義和衡量的交付件?
大部分部分沒有,導致後面出現很多問題。
4. 是否項目的整個過程都按照計劃進行?
基本按照計劃進行。
5.在計劃中有沒有留下緩沖區,緩沖區有作用麽?
有緩沖期,也起作用了。
-
資源
1. 我們有足夠的資源來完成各項任務麽?
有。
2. 各項任務所需的時間和其他資源是如何估計的,精度如何?
精度基本沒有,都是有時間就幹活。
3. 用戶測試的時間,人力和軟件/硬件資源是否足夠?
足夠。
4. 你有沒有感到你做的事情可以讓別人來做(更有效率)?
沒有,我們的分工還是挺科學的。
-
變更管理
1. 每個相關的員工都及時知道了變更的消息?
是的,隊員平時關系比較好,新消息流傳得很快。
2. 我們采用了什麽辦法決定“推遲”和“必須實現”的功能?
討論決定。
3. 項目的出口條件(Exit Criteria)是否得到清晰的定義?
清晰,我們的出口條件是程序能穩定且流暢的運行,能完成基礎的聊天軟件功能,包括註冊登錄、好友搜索添加、好友聊天。
4. 對於可能的變更是否能制定應急計劃?
沒有,誰有空誰上。
5. 員工是否能夠有效地處理意料之外的工作請求?
能,隊裏我說了算。
-
設計/實現
1. 設計工作在什麽時候,由誰來完成的?是合適的時間,合適的人麽?
設計工作在項目一開始由開發人員完成,時間和人員都合適。
2. 設計工作有沒有碰到模棱兩可的情況,團隊是如何解決的?
技術決定話語權。
3. 團隊是否運用單元測試(unit test),測試驅動的開發(TDD)、UML, 或者其他工具來幫助設計和實現?這些工具有效麽?
沒有。
4. 什麽功能產生的Bug最多,為什麽?
APP聊天功能。新手上路是這樣的。
5. 代碼復審(Code Review)是如何進行的,是否嚴格執行了代碼規範?
沒有代碼規範。因為覺得沒必要。
-
測試/發布
1. 團隊是否有一個測試計劃?為什麽沒有?
有測試計劃。
2. 是否進行了正式的驗收測試?
應該算有吧。
3. 團隊是否有測試工具來幫助測試?
沒有。
4. 團隊是如何測量並跟蹤軟件的效能的?從軟件實際運行的結果來看,這些測試工作有用麽?應該有哪些改進?
在實際使用中跟蹤軟件的效能。
5. 在發布的過程中發現了哪些意外問題?
沒有。
團隊成員在Alpha階段的角色和具體貢獻:設總分20*5=100
名字 | 角色 | 團隊貢獻分 | 可驗證的貢獻 |
黃曉彬 | PM | 20 | 博客書寫&測試 |
黃鈺城 | Dev | 20 | app |
黃梓塏 | Dev | 21 | 後臺&app |
李樹 | Dev | 20 | 頁面 |
蔡海傑 | Test | 19 | 輔助&測試 |
(討論照片明天上傳)
大馬猴隊-事後諸葛亮分析