項目：基于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
  • 我們團隊每周結束時都會對上周的工作進行討論，并計劃下周的任務，所以能時時總結如何提高團隊效率，并付諸行動

轉載于:https://www.cnblogs.com/jiangjiangjiang/p/10088229.html

總結

以上是生活随笔為你收集整理的第一次迭代开发感想——快租车APP的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。