事後諸葛亮分析

一.設想和目標

1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

我們的軟體預期在實現最基本的打卡工具的基礎上，新增番茄鐘專注功能和社交圈子吸引使用者，定位明確。但有些使用邏輯略顯累贅，後期稍有修改，但還有地方可以做到更好。

2. 我們達到目標了麼（原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?)

團隊前期計畫已經預料到團隊時間精力不足，制訂計畫的時候，我們把「社交圈子」功能模組定為待定實現模組.至今我們實現了預期的90%的功能，基本達到目標，只是實現時間稍有延遲。因沒有發布產品，故只有內部人員使用，沒有達到預期使用者量。

3. 和上乙個階段相比，團隊軟體工程的質量提高了麼？在什麼地方有提高，具體提高了多少，如何衡量的？

與alpha階段相比，團隊軟工的質量大大提高，隊員之間的交流明顯比上乙個階段要多得多。另外，上乙個階段大家比較不擅長利用時間，很多時候工作會拖延接近截至日期才加班加點完成，很倉促，這一階段明顯改進。

二.計畫

1. 是否有充足的時間來做計畫?

除考試時間外，大家都有充足的時間做計畫。

2. 團隊在計畫階段是如何解決同事們對於計畫的不同意見的？

中和大家的意見，少數服從多數。

3. 你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?

最終階段，後台有些介面還是沒能及時提供。由於前端和後台商量介面文件不夠及時，造成資料庫設計不夠恰當，後期開發的時候，造成浪費大量精力修改，但軟體的主要功能模組的介面都基本實現完畢。

4. 是否每一項任務都有清楚定義和衡量的交付件?

基本上符合，開發過程中會根據具體情況做出相應的修改。

5. 是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

6. 在計畫中有沒有留下緩衝區，緩衝區有作用麼?

沒有7，我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

對軟體開發的流程有更多的了解，隊員間的合作能力明顯提高。改進方面，在時間安排，與任務分配，以及人員安排等方面仍需要調整。

三.資源

1. 我們有足夠的資源來完成各項任務麼?

打卡工具在現實中已經有很多成熟的產品，我們有足夠的資源參考；

開發人員略顯不足；

開發時遇到需要備案網域名稱的問題，但備案所需時間過長，沒法提供。

2. 各項任務所需的時間和其他資源是如何估計的，精度如何?

計畫趕不上變化。

3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?

由於市面上的打卡工具較為成熟，且功能較為簡單，為了互動體驗、美觀效果，擁有我們團隊自己的特色，我們投入了相當可觀的設計人力資源。

4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?

在隊伍中，我的溝通組織能力不夠優秀，更偏向於默默開發，有時候由別人來組織會更有效率，但這次的作業也很好地鍛鍊了我的相關能力。

5，有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

溝通很重要，非常重要！！！

1. 每個相關的成員都及時知道了變更的訊息?

2. 我們採用了什麼辦法決定「推遲」和「必須實現」的功能?

根據我們制訂的功能模組優先順序，必須實現主要功能（打卡），次要功能可推遲實現。

3. 專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?

實現預期功能，沒有嚴重影響使用者體驗的bug，使用者反饋良好。

4. 對於可能的變更是否能制定應急計畫?

沒有特定去制定計畫，遇到問題立刻著手解決。

5. 成員是否能夠有效地處理意料之外的任務請求？

大部分能。有些意外情況自己實現不了，也會請教有經驗的同學的方式幫忙解決。

1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？

設計工作在需求分析和alpha衝刺階段都有設計，由大家共同討論，組長和負責產品的組員決定。

2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？

沒有出現，隊員覺得模糊的地方會及時提出疑問，相關人員會對應解答。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？

4. **複審（code review）是如何進行的，是否嚴格執行了**規範？

成員互相審核。

1. 團隊是否有乙個測試計畫？為什麼沒有？

功能模組測試都是先經過開發成員開發過程中發現問題、及時解決，再經過未參與開發的成員使用體驗，反饋情況給開發人員進行進一步地完善。

2. 是否進行了正式的驗收測試？

有對每一部分功能進行正式的驗收測試.

3. 團隊是否有測試工具來幫助測試？

有。4. 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？

各個模組的測試分配給各個相應的開發組員，這些組員進行用例測試。從軟體實際執行的結果來看，這些測試工作還是挺有用的。

5. 在發布的過程中發現了哪些意外問題？

未發布。

我們學到了什麼?如果重來一遍,我們會做什麼改進?

如果歷史重來一遍，我們會在前期計畫階段，更加認真地做計畫，全員參與計畫，充分理解產品需求。另外，作為組長，我應該更加積極與隊員溝通，帶動隊員工作積極性，監督大家的進度，從而避免出現大家接近截止時間才加班加點趕工，讓團隊有乙個更融洽的開發環境。

產品效果展示：

成員貢獻

姓名角色

團隊貢獻分

可驗證的貢獻

羅海屏（組長）

前端前端頁面開發

張妙馨後台

後台開發

劉昱君前端

前端頁面開發

潘蓓文ui設計

ui設計

鍾小敏產品

產品需求

鄭曉婷ui設計

ui設計

事後諸葛亮分析

事後諸葛亮分析

事後諸葛亮分析

事後諸葛亮分析報告

相關推薦