設想和目標

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

• 解決問題：主要為了解決微信上微商泛並且不安全的問題，為社群交易提供了一個便利的平臺。
• 典型使用者：需要出售二手商品，在購買物品時需要資訊交流的人。
• 典型場景：瀏覽，出售，購買商品

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

• 原計劃：完成基本介面，實現瀏覽，釋出，購買，更改個人資訊的基本功能
• 實現情況：
  • 完成瀏覽頁面，但是資料庫用例較少，會出現重複
  • 基本完成購買介面，在微信支付結構有比較大的問題，付款功能暫時無法實現
  • 完成釋出介面，能夠上傳文字和圖片
  • 能夠更改個人資訊，包括使用者暱稱頭像更改，郵箱號碼手機號碼的繫結

3. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?

•  暫時還是開發階段，沒有投入使用，使用者體驗未知
• 功能已經基本實現，離目標更近了！

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

• 在功能實現過程中有一些急，可能在一些程式碼部分留下了問題，如果能重來。會更加註重程式碼結構和規範問題。

計劃

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

• 雖然在開始的時候做了計劃，但是時間越來越緊，一部分的計劃無法實現被拋棄，到後面就是一邊計劃一邊做。

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

• 在計劃的過程中有很多次的討論，目的就是聽取每個組員的意見，出現了一些分歧，在整合了所有人的意見的情況下由pm做決定。

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

• 只有在微信支付問題上有一些問題，微信支付需要企業驗證，我們做專案設計無法做到。

4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

• 目前來說暫時沒有。

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

• 是的，我的工作就是將前端頁面設計的功能實現，要做到前後臺有效的對接必須要清楚埠的功能和實現。

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

• 關於微信小程式與服務期通訊的過程，需要備案域名，備案域名花費了較多時間

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

• 留下了一天左右天做緩衝，修改了一些可見的bug，做了一些當初沒有計劃到的頁面。

8. 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）

•  可能會在deadline之前就儘量將計劃做完，熬夜寫程式碼的效率是真的不高

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

•  如果重來一遍，我會早點吧功能實現，deadline之前熬夜真是太痛苦了

資源

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

• 關於技術資源，網上基本都能找到
• 關於時間資源，真的是需要珍惜的一項資源，到最後才發現時間根本不夠用

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

• 估計主要基於任務量和難度
• 精度基本不存在，從表面看和實際做出來根本不一樣，其中還有突發情況發生

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

• 測試的時間可能是不太夠，這個階段幾乎沒什麼時間測試
• 關於介面的設計看起來簡單，但是做起來確實要花大量時間。

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

• 對於頁面設計可能我做起來就比較吃力交給別人做可能比較好。

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

• 如果能重來，我覺得應該留下一些時間給測試。

變更管理

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

• 我們小組還說基本上會花很多時間來聚在一起程式設計，交流的效率比較高，在線上更改了什麼內容也會即使在qq群裡通知。

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

• 我們在確定需求的時候就基本確定了必須實現的功能，在主體功能之外想到的功能都是屬於可以推遲的。

3. 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

• 能在手機上流程的執行想要的功能，就是做好了。

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

• 在發生需要的變更的時候，會聚在一起開會確定。

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

• 在自己做的部分出問題之後，基本上會立刻停下手頭工作做出修改。

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

• 做專案的時候，及時有效的交流是非常有用的。如果能重來，我基本不會在這方面做太多改變，還是要有及時的溝通，

設計/實現

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

• 需求分析階段，由全組成員和指導老師一起商討確定。

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

• 暫時沒有碰到這類問題。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？ 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？

• 使用到了uml
• 對專案結構的設計，過程的明確有很大的過程
• 在專案的進行中，文件需要及時更新

4. 什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

• bug主要發生在前後臺介面的問題上，原因是在對接之前沒有考慮到全面的情況。
• 之後有一些輸入格式控制的問題，主要還沒有考慮全所有錯誤情況。

5. 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

•  程式碼複審使用小組互審的過程。
• 由於時間緊，在程式碼規範的問題上還是有很大的改進空間。

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

• 程式碼規範是非常重要的一部分，可能不規範的程式碼再出了錯之後都沒有辦法修改。
• 如果能重來，在一開始就應該確定程式碼規範，按照規範來寫。

測試/釋出

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

• 在完成一部分功能之後，就進行基本的實機測試。

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

• 進行了。

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

• 暫時沒有使用。

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

• 暫時沒有考慮使用這些工具。基本上是 小組成員實際體驗。

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

•  支付功能未解決，暫時不考慮釋出。

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

•  測試還是比較重要的，可能在自己普通測試的時候沒有錯誤，但是別人就能發現錯誤。如果時間允許，還是要留下時間測試。

團隊的角色，管理，合作

1. 團隊的每個角色是如何確定的，是不是人盡其才？

• 主要因素是個人的意願，之後再進行協商確定。

2. 團隊成員之間有互相幫助麼？ 

• 互相幫助是一定的，一個人是沒有辦法完成全部工作的。
• 在小組成員暈倒bug沒有辦法解決時，其他組員會盡可能地進行幫助。

3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？

• 出現這種問題的時候，我們會聚在一起討論和程式設計解決問題。

我感謝所有組員對我的幫助， 沒有每個組員的幫助我們就沒有辦法完成這個專案。

我感謝pm， 完成了我們專案中的大部分文件的整合和寫作。

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

•  在專案製作的過程中，一個人的努力是沒有用的，必須要所有小組成員一起努力，一起互幫互助才能最終完成專案。

總結:

你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?

• 屬於CMMI一級，完成級

你覺得團隊目前處於萌芽/磨合/規範/創造階段的哪一個階段?

• 目前正在處於規範階段。

你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?

•  目前來說小組成員已經很熟悉了，能夠相互配合完成工作。

你覺得目前最需要改進的一個方面是什麼?

• 主要就是程式碼結構和規範的問題。

對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

• 我們小組在交流方面做得比較好，經常線下討論，程式設計，溝通非常及時。
• 其次就是相互幫助的情況，一個人出了bug，就會有人一起幫他改bug。