第一次迭代已經結束，總的來說收穫很大。小組每個人都學習了自己從未接觸過的語言，從一開始的試探性程式設計，到後面逐漸理解，想到一個功能知道從何下手，大家的收穫還是很大的。

設想和目標

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

我們軟體要解決的問題和目的在需求階段已經定義明確：統計實時噪聲資料，繪製區域噪聲地圖，提供給使用者需要的資訊，政府也可以根據噪聲資料採取針對性的措施，首先我們選取學校作為試驗點。

典型使用者：在校學生

典型場景：人行道，馬路等人的活動區域

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

原計劃功能：使用者可檢視實時噪聲分貝，實時噪聲折線圖顯示，檢視所選擇時間的噪聲地圖

實現情況：

• • 實時噪聲分貝功能已基本實現，
  • 除實時折線圖的繪製還有難度未實現
  • 檢視所選擇時間的噪聲地圖功能因為涉及的演算法比較多，實現起來也很有難度，還未實現

交付和使用者：軟體功能的核心功能-噪聲地圖顯示還未實現，暫時無法投入使用

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

暫未投入使用，使用者實際接受成度未知

產品完成度一般，和開始的啥也不知道比起來，離目標當然更近了

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

由於我們的專案需要開發Android客戶端，ios客戶端和伺服器網頁，整體工作量比較大，而大家都是之前沒有開發經驗的，所以專案開發起來相對緩慢。這就導致我們第一次迭代計劃實現的功能較少，後續開發壓力比較大。

如果歷史重來一遍，我一定在創新課程開始之前就把相關知識學好，不然邊學邊做太慢，而且非常痛苦。後面還有兩三週要實現難度比較大的β版本，壓力也比較大。

計劃

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

整個創新課程的團隊專案時間不太長，計劃的時間也不會太長。而且計劃總是趕不上變化，最開始的計劃也是根據進度不斷調整。

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

計劃階段討論很順利，大家的意見都很統一。

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

第一次原計劃的內容比較少，alpha版本的計劃都做完了

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

設計互動介面的過程中採用了好幾種方式結果最後還是沒有用上，結合之前的學長SIT專案的經驗，結合了他們的資料庫設計了一下上傳資料的模組結果也沒有太大作用。

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

小組開會討論比較多，還是比較明確的。

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

組內沒有太理解老師所說的第一次迭代的定義，相對來說，開發進度也有一定滯後

風險的話就是熬夜+時間

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

留有緩衝區，第一次迭代差不多在驗收前一個星期已經實現，這一週應該可以算做緩衝區。

緩衝區主要是放鬆，畢竟開發比較累。勞逸結合，才能事半功倍。

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

　　在計劃中可能要更加細緻，第二次迭代需要的功能比較多，因此計劃中的完成時間要提前預想並定義好。

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

如果歷史重來一遍，我們會將第一次迭代開發計劃調整，更多地關注功能，儘量多實現功能，有選擇地忽略佈局，在後期補充。

資源

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

時間和資金的資源限制，alpha版本任務也基本實現。

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

時間主要是按任務量估計，時間按各自的安排估計

精度還不錯，課本能保持高效且時間安排還比較合理

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

測試沒有系統、詳細的安排，做了簡單的測試，沒有花費很多時間

人力資源比較少，不太足夠。

美工做了一些嘗試，在後期因為時間限制有選擇地擱置了，各種文件的撰寫也需要花一些心思，需要全盤考慮整個專案，做一些技術上的預想。

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

沒有，有問題大家就討論，什麼問題當場就解決了，不存在滯後的問題。

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

 分工不夠仔細、明確，很多時候沒有給每個人分配好周任務，對大家配合效率有一定影響。

人員分配有些不合理，對伺服器端的工作量有些預估失誤，如果歷史重來一遍，我們會讓正在學javaee的同學去配合做伺服器端。

變更管理

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

　　我們組每週都會多次開會，在著手開發以後只要一有時間大家就都在公寓內咖啡店集中開發，所以溝通比較多。

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

　　在第一次迭代計劃中有設定功能優先順序。

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

　　應該還比較清晰，主要是根據之前的原型設計和需求文件，基本功能和UI設計好了就算OK。

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

沒有提前制定應急計劃，小組計劃也沒有出現大的意外。

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

 大家的及時調整都很棒，對於意外的發生也能做出迅速的反應。

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

我們小組的溝通非常多，這樣就能互相瞭解到相互的進度等，互相促進提高。

改進的話就是希望大家在自己一個人的時候也能有集中開發時的效率。

設計/實現

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

整個模式的設計是在專案初期，由pm和老師溝通商定的。

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

開始時有一點模稜兩可，後來大家一起討論得以最終確定

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

網上大量的資源和相應的軟體，所以繪圖不是問題，主要是要理清之間的邏輯關係和相關的聯絡

騰訊敏捷開發平臺幫助管理專案有巨大的便利性

這些工具都非常有效，幫助巨大。

4.比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？

文件更加豐富了，會在專案推進中，不斷完善、更新文件。

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

目前完成的功能比較少，所以bug還沒怎麼發現

還沒有釋出

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

程式碼複審主要是小組之間互相檢查，而我們組在檢查其他組時是分檔案進行分工，各司其職

嚴格執行了程式碼規範。函式命名，成員命名，程式碼註釋，程式碼組織等都嚴格查看了。

測試/釋出

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

沒有一個完善的測試計劃

受時間和資源的限制

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

我們組由邊老師親自進行了第一次驗收，雖然結果不是很滿意但是應該也算完成了。

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

暫未考慮。

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

暫未考慮。

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

噪聲地圖顯示功能未解決，暫時不考慮釋出。

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

 因為還是第一次做專案，經驗還不太夠，測試方面暫時沒有精力、時間考慮。

團隊的角色，管理，合作

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

小組比較民主，按照大家自己的意願和特長分配角色，基本人盡其才。

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

兩個客戶端各分配兩個人，這樣更加便於溝通交流。同時客戶端也和伺服器端有協作。

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

合作問題基本沒有，大家都很包容體諒對方。小組成員之間也互相幫助，我們是一個很有愛又可愛的集體~

總結:

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

應該屬於可重複級(Repeatable)

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

磨合基本完成，接下來是規範

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

大家彼此更加熟悉，互相的配合會比之前更有效率。

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

任務分配。

需要將Android客戶端的一位同學分配給伺服器端開發。

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

我們組做的最好的我覺得就是小組溝通很多，每週都會多次開會，在著手開發以後只要一有時間大家就都在公寓內咖啡店集中開發。

在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。