項目：基于Android的汽車租賃平臺——快租車APP

設想與目標

我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？

• 產品定義：提供給租車公司的用戶使用的租車app
• 典型用戶：有駕照，經常進行工作或商務活動的人士
• 典型場景：出差人士需要駕車出行

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

• 原計劃功能：做出app，實現用戶登錄，注冊，租車，還車，充值等實用功能，并且設置后臺管理界面
• 實現情況：基本實現功能
• 交付與用戶：無

用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么？?

• 未交付使用，所以沒有用戶量
• 離目標更近了

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

• 大家對app的理解不同，我比較喜歡線性布局，相對布局這些，隊友用的約束布局，在合并的時候，重寫了一遍布局，所以下次一定要溝通好要用的技術

計劃

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

　　? ? ? ?是的，一開始有兩周的時間去做迭代開發計劃，做了3個版本，同時還不斷改進數據表

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

　　　　團隊討論，互相說出自己的道理

? ? ? ? 3、你原計劃的工作是否最后都做完了??如果有沒做完的，為什么?

　　　　是的

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

　　　　有，我在設計布局的時候和隊友出現沖突，所以后來合并的時候隊友重寫了布局

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

　　　　是的，在迭代開發報告中寫清楚了

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

　　　　沒有什么意外，android和java web雖然比較花時間，但是學起來比較順利

　 　7、在計劃中有沒有留下緩沖區，緩沖區有作用么?

　　　　沒有

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

　　　　暫時沒有

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

我學到了關于android的很多知識，同時也了解了很多后臺的代碼，包括jquery,servlet等

歷史重來一遍，我們應該更明確的分工

資源

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

有，其實并不需要什么資源，至少目前為止

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

大致估計猜測的，然后邊做邊修改

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

測試的時間還好，有一周，人力也足夠，目前還沒有考慮UI設計

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

沒有

?

變更管理

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

大致是的，但是有時候突然發現一個bug,可能通知不及時，沒有在群上講，就直接改了

2、我們采用了什么辦法決定“推遲”和“必須實現”的功能?

必須實現的功能是第一次使用必要的，比如登錄注冊，租車還車，充值

推遲的是附加功能，比如地圖，常見問題，地圖，延長租車等

3、項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?

我認為是將實際需要的功能都完成，然后使用比較簡單，bug少就可以做好了

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

暫時沒有

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

可以，我覺得大家對學習的熱情很高，即使突然改需求，也能很快上手

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

做的時候要考慮到隨時變更的需求，所以在設計的時候一定要注意封裝，降低耦合性，提高代碼可重用性

?

設計/實現

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

在比較前期大概第4周的時候，有大家開會討論決定的，比較合適的時間

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

目前我覺得沒有

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

使用了uml工具，繪制了類圖，時序圖等，幫我們理清的思路，開發更有針對性，還有騰訊工蜂，方便記錄大家的進度

4、比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？

是有比較大的修改，比如類圖等，主要是在設計數據庫和java代碼時發現原來設計的不合理的地方，所以修改了很多uml圖

5、什么功能產生的 bug 最多，為什么？在發布之后發現了什么重要的 bug? 為什么我們在設計/開發的時候沒有想到這些情況?

目前沒有，但是我覺得可能在android連接數據庫那塊有bug，因為那里集中了比較多的線程，線程比較容易出錯

代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？

目前還沒有代碼復審

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

在做事前，先畫好圖，理清思路是很重要的，磨刀不誤砍材工

測試/發布

團隊是否有一個測試計劃？為什么沒有？

• 目前還沒有測試計劃

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

• 暫時沒有

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

• 沒有

團隊是如何測量并跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？

• 沒有

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

• 還沒有發布

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

• 在測試這一塊暫時沒有學到什么，不過按照老師課上的內容，我們也是在邊開發邊測試，調試bug

團隊的角色，管理，合作

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

• pm統籌安排，我寫的android，有3個Android開發人員，兩個后臺，我覺得大家都做出了自己的貢獻

團隊成員之間有互相幫助么？

• 有。

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

• 通過團隊討論解決的。

總結

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

• 我覺得接近了CMM/CMMI中的可重復級(Repeatable)

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

• 磨合。

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

• 大家的水平都有較大提高，而且功能實現得比較漂亮

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

• 代碼寫得比較冗余，在Android中大量的代碼重復

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

• 我們每周都會有開會，計劃接下來的內容，其實我們已經做了比較多第二期的功能，所以接下來大概會比較輕松

?

轉載于:https://www.cnblogs.com/chen-song/p/10100403.html

總結

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

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