一、作業描述
| 這個作業屬於哪個課程 | 2019秋福大軟件工程實踐Z班 |
|---|---|
| 這個作業要求在哪里 | 團隊第六次作業——事后諸葛亮 |
| 團隊名稱 | 碎閱創造營 |
| 這個作業的目標 | 項目事后諸葛亮 |
| 作業正文 | 碎閱創造營——事后諸葛亮 |
| 參考資料 | 項目管理之事后諸葛亮會議 |
二、設想和目標
1. 我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
- 軟件項目要解決的問題：收集分類整理各種碎片化信息，定時督促用戶瀏覽
- 定義清晰
- 對典型用戶和典型場景有相對清晰的描述
2. 我們達到目標了么？
- 原計划的功能基本實現
- 按照原計划的交付時間交付了
- 原計划中沒有列出用戶數量要求
3. 和上一個階段相比，團隊軟件工程的質量提高了么？ 在什么地方有提高，具體提高了多少，如何衡量的？
- 團隊軟件工程的質量有明顯的提高
- 團隊會議效率、團隊成員配合完成度、任務計划和分配合理情況等方面都有所提高
- 標准衡量：各功能完善情況及對應的花費工作量
4. 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?
- 原計划中沒有列出用戶數量要求，且目前只在開發測試階段，因此還沒推廣，沒有用戶量
- 我們已經實現了大部分基礎功能，距離目標已經更近一步了
5.有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
- 應該提早進行開發，前期寫文檔和學技術花費的時間較多，導致沖刺的時候時間緊張
三、計划
1. 是否有充足的時間來做計划?
- 有，在需求分析、系統設計和數據庫設計期間已經定制了初步計划，在項目沖刺開始前完善具體了任務計划和分配情況
2. 團隊在計划階段是如何解決同事們對於計划的不同意見的？
- 開會期間一起討論，團隊成員們積極提出各自的意見，若有分歧，大家一起分析商量出最優方案
3. 原計划的工作是否最后都做完了? 如果有沒做完的，為什么?
- 基本完成原計划的工作
4. 有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
- 基本沒有，每份付出都會在將來以不同的形式體現其價值，有的是教訓，或是經驗積累
5. 是否每一項任務都有清楚定義和衡量的交付件?
- 是，每一項任務都有基本的明確目標，沖刺階段會做每日匯報和演示，且各自測試驗收后，最后統一驗收測試
6. 是否項目的整個過程都按照計划進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?
- API版本不兼容，配置花費了大量時間
- 沒有Android開發經驗，且屬AS導入項目的常見問題
7. 在計划中有沒有留下緩沖區，緩沖區有作用么?
- 沖刺時間緊張，沒有留下緩沖區
8. 將來的計划會做什么修改？（例如：緩沖區的定義，加班）
- 將來會根據任務的難度和團隊成員可安排的時間適當調整每天的工作量情況，並預留1-2天的緩沖區
9.我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
- 細化分工，在任務安排和分配時綜合考慮，在一個合理的情況下達到最優的目標，按照計划時間及時測試和驗收。
四、資源
1. 我們有足夠的資源來完成各項任務么?
- 技術資源較為短缺，基本花費大多的時間來學習，邊學習邊開發
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
- 有一個初步計划，任務進行中根據實際情況進行調整
- 精度開始時較為粗略，實現過程中逐步討論完善
3. 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
- 測試方面，各模塊及時自行測試，沒問題后，會再進行統一測試，硬件方面基本滿足
- 美工設計/文案方面低估了難度
4. 你有沒有感到你做的事情可以讓別人來做更有效率?
- 沒有，基本根據團隊成員想要學習的方面進行分工
5.有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
- 團隊資源安排上需充分考慮到任務難度及實現情況，團隊內及時交流進行情況，盡量避免成員任務分配不均、實現難度相差甚大
五、變更管理
1. 每個相關的員工都及時知道了變更的消息?
- 是的，有每日會議，也會在團隊群內進行交流討論
2. 我們采用了什么辦法決定“推遲”和“必須實現”的功能?
- 根據功能重要性及任務實現難度和實際進度，團隊交流討論統一意見
3. 項目的出口條件（什么叫“做好了”）有清晰的定義么?
- 在需求報告里的界面需求、功能驗收等模塊中有比較清晰的定義
4. 對於可能的變更是否能制定應急計划?
- 能，隊員響應速度快，團隊能及時提出突發情況，並及時進行相應的調整
5. 員工是否能夠有效地處理意料之外的工作請求？
- 基本沒有意料之外的工作請求，大多在計划中進行
6.我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
- 經常溝通交流，群內及線下及時通知變更消息，盡快討論制定出應急計划
六、設計/實現
1. 設計工作在什么時候，由誰來完成的？
- 在項目需求分析的時候完成的，由團隊成員一起完成的
2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
- 沒有，基本都是成員統一意見的結果，都能在工作開展前做好決定
3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？ 比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
- 有運用單元測試、UML等工具來幫助設計和實現
- 都有顯著的效果。單元測試有效地保證了每個部分的正確性，使用uml更好地理清類、對象等之間的關系。
- UML圖有更新補充，需要更新UNL文檔。
4. 什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
- 剪貼板檢測功能由於開發難度較大Bug較多
- 發布后部分界面沒有返回鍵，影響頁面間交互
- 原型設計存在缺陷，后期開發沒進行統一整理
5. 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
- 代碼復審比較倉促，由專人負責檢閱
- 有提前統一代碼規范，整合時再進行檢查，但部分命名不規范未修改
6.我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
- 設計工作時需要盡可能的接近團隊實際情況，盡量合理的安排任務。要統一代碼規范，並且嚴格執行
七、測試/發布
1. 團隊是否有一個測試計划？
- 有,文檔工作以及沖刺階段皆有定制詳細計划
2. 是否進行了正式的驗收測試？
- 已進行正式的驗收測試
3. 團隊是否有測試工具來幫助測試？
- 無
4. 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
- 人工手動測試，模擬器調試
- 有用，可以在開發過程中查找不足
5. 在發布的過程中發現了哪些意外問題？
- 版本不兼容，Android版本低的部分手機無法運行
6.我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
- 需要制定完整有效的測試計划，運用適當的測試工具提高測試效率
八、團隊的角色，管理，合作
1. 團隊的每個角色是如何確定的，是不是人盡其才？
- 基本時根據團隊成員想要學習的方面或者擅長的部分確定的
- 基本上是人盡其用
2. 團隊成員之間有互相幫助么？
- 有，無論是線上線下都樂於幫助隊友解決難題
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
- 團隊成員及時討論交流、匯報實際進度和完成情況，基本沒有出現問題
感謝環節
-
蘇傑隆：我感謝林震對我的幫助，因為他在隊長最困難的時候擔起了團隊的領導任務
-
陳毅東：我感謝蘇傑隆對我的幫助，因為他幫我找到了實用的教程和范例
-
林濤：我真心感謝陳毅東對我的幫助，因為他在Android studio的使用上給予了我幫助，讓我更快的入門
-
劉新耀：我感謝陳毅東對我的幫助，因為他在代碼調試上幫助了我很多
-
盧昱妃：我感謝全體成員對我的幫助，一個項目的完成與團隊中每個成員的努力都不可分割。從互不認識的八個人，到一起合作完成項目，感謝每個成員對我的耐心和幫助。
-
藍飛鵬：我感謝蘇傑隆對我的幫助， 因為他在我不知怎么做項目時為我指明了方向
-
林震：我感謝蘇傑隆對我的幫助，因為他借我手機進行調試，並且對我的代碼提出了一些有益的建議
-
黃淑雲：我感謝全組隊員對我的幫助，組內學習交流氛圍很好，互相學習，互相分享，為求更好地實現項目。這八個人是一個整體，缺了誰都是不完整的，缺了誰都很難會達到目前的完成情況，再次感謝全組同學。
九、總結:
1.你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
- CMMI二級，管理級。對項目有一系列管理程序，避免了軟件組織完成任務的隨機性，保證了軟件組織實施項目的成功率。
2.你覺得團隊目前處於 萌芽/磨合/規范/創造 階段的哪一個階段?
- 規范階段
3.你覺得團隊在這個里程碑相比前一個里程碑有什么改進?
- 大家的配合更加默契
4.你覺得目前最需要改進的一個方面是什么?
- Github 版本控制
十、事后諸葛亮會議照片
十一、各組員對於最終項目成果的貢獻度
| 組員 | 工作量比例 |
|---|---|
| 蘇傑隆 | 12% |
| 陳毅東 | 12% |
| 林濤 | 10% |
| 劉新耀 | 10% |
| 盧昱妃 | 10% |
| 藍飛鵬 | 10% |
| 林震 | 18% |
| 黃淑雲 | 18% |