專案：基於Android的汽車租賃平臺——快租車APP

隊伍：2班3組 表面隊

第一次迭代開發思考與總結

設想和目標

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

• 我們快租車APP的目標是讓使用者隨時隨地、方便快捷地獲得汽車租賃服務，同時讓租車公司拋開繁瑣的租賃手續，提高辦公效率。
• 典型使用者：租車消費者以及中小型汽車租賃公司
• 典型場景：租車使用者在中小型租車公司進行汽車租賃消費

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

• 原計劃第一次迭代要求實現使用者能夠完成一次完整的租車的所有功能,已完全實現
• 已按原計劃交付時間交付
• 暫未投入使用

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

• 暫未投入使用，使用者評價未知
• 第一次迭代順利完成，離目標更近了一步

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

• 對租車行業瞭解還不夠充足，如果重來一遍，會實際體驗一次租車消費過程

計劃

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

• 計劃時間不充足，一開始定義的計劃與實際實現有所出入，後面時間不足只能隨機應變，加快專案實現進度以按時完成第一次迭代

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

• 首先是組內討論，經討論後意見還是不統一的問題向專案導師尋求建議

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

• 原計劃第一次迭代的工作已全部完成

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

• 在介面UI設計上花費了大量時間，其實完全沒必要重複造輪子，網上開源的漂亮的介面有很多都可以直接呼叫

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

• 專案組會每週開會，並經常在討論群中積極線上討論，所以任務的定義都比較清楚，完成度也很高

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

• APP的部分資料庫連線，以及APP首頁部分與訂單部分的對接出現了問題，未按預計的時間完成
• 未估計的風險就是上面的部分工作未按期望順利完成，原因還是開發經驗太少所導致

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

• 有留下緩衝區,我們專案組在前期的工作中，幾乎都是在要求時間的前一個星期到半個星期就完成了，留下的時間都是緩衝區
• 緩衝區的作用就是為沒有估計到的風險留下時間來處理

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

• 專案組成員之間聯絡更加緊密一些，會定時在組裡彙報自己的開發進度和問題以防止專案進度的延後

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

• 首先是資料庫設計對實際的實現的考慮還不充足，如果重來一遍，資料庫設計會更充分的考慮程式設計師功能實現的難易度
• 然後學到了一些專業開發之外的東西，比如團隊成員之間的相互磨合，如果重來一遍會更注重與團隊成員之間的交流

資源

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

• 時間資源比較緊張，但仍然可以完成任務

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

• 各任務所需時間和資源都是憑感覺估計的，精度較差

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

• 沒有詳細的測試計劃，團隊成員都是完成各種的部分後各自進行測試，然後合併後再進行整體測試，各資源都較為充足
• 低估了需求文件等文件的撰寫難度

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

• 感覺團隊的分工都很合適

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

• 對任務分工不夠細緻，如果重來一遍會將分工劃分得更細並估計每個任務完成的時間

變更管理

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

• 每次變更都會在團隊討論群裡通知，所以各成員都會及時接到通知

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

• 我們的迭代計劃都對每個功能都有對應的優先順序，會優先實現優先順序高的功能

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

• 按照需求文件的要求實現了，並與產品原型設計相同或更好，就是“做好了”

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

• 對可能的變更會制定相應的應急計劃，我們會根據變更調整團隊的分工和進度安排

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

• 團隊成員都能有效的處理意料之外的工作請求，因為我們留有足夠的緩衝區

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

• 團隊之間的交流以及相應計劃的制定對專案的進度影響很大，如果重來一遍會依舊按原來的樣子進行，因為原來一切都很順利

設計/實現

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

• 產品的原型設計是在開發之前，由PM完成

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

• 產品原型設計由一人完成，並沒有模稜兩可的情況

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

• 使用了UML，UML文件已有幾個版本，變更的原因是在於開始時UML知識的不足，以及後續產品功能的調整，每次都會更新UML文件

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

• 要與伺服器資料庫連線的功能的bug最多，原因在於對資料庫連線操作的不熟練，產品還未釋出

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

•  程式碼複審是團隊成員各種檢查各自的程式碼，是按照程式碼規範執行的

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

• 產品原型設計應付出更多的時間和人力，如果重來一遍會付出更多的時間進行產品原型設計
• 程式碼複審應更加嚴格，如果重來一遍會再進行一次團隊成員之間交換的程式碼複審

測試/釋出

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

• 沒有測試計劃，初次專案開發經驗不足，時間也較緊張

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

• 在助教的幫助下進行了第一次迭代的驗收測試

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

• 沒有

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

• 暫未考慮

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

• 暫未釋出 

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

• 未制定相應的測試計劃，如果重來一遍會制定測試計劃並運用相關測試工具來對專案進行測試

團隊的角色，管理，合作

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

• 角色的確定是結合每個人的意願由PM分配的，大家都對自己的角色感到較為滿意

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

• 團隊成員之間經常互幫互組，相互提升

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

• 都是在組內討論解決問題
• 我感謝劉天賽對我的幫助，他幫助我解決了許多安卓開發上的一些問題

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

• 團隊之間的磨合特別重要，如果再來一次我會更加註重團隊成員之間的交流

總結:

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

• 我覺得還屬於CMMI 的初始級

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

• 我覺得團隊正處於磨合階段，但已磨合的差不多了

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

• 大家相互之間有了更深的瞭解，合作效率也大大提高

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

• 最需要改進的還是團隊成員之間的交流，我覺得可以更深入更頻繁一點

       對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 

• The best architectures, requirements, and designs emerge from self-organizing teams.
  • 我們團隊成員自我管理能力都特別強，故團隊也是自我管理的團隊
•  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
  • 我們團隊每週結束時都會對上週的工作進行討論，並計劃下週的任務，所以能時時總結如何提高團隊效率，並付諸行動