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

隊伍：2班3組 表面隊

第一次迭代開發(fā)思考與總結(jié)

設(shè)想和目標

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

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

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

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

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

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

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

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

?

計劃

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

• 計劃時間不充足，一開始定義的計劃與實際實現(xiàn)有所出入，后面時間不足只能隨機應變，加快項目實現(xiàn)進度以按時完成第一次迭代

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

• 首先是組內(nèi)討論，經(jīng)討論后意見還是不統(tǒng)一的問題向項目導師尋求建議

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

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

4.?有沒有發(fā)現(xiàn)你做了一些事后看來沒必要或沒多大價值的事?

• 在界面UI設(shè)計上花費了大量時間，其實完全沒必要重復造輪子，網(wǎng)上開源的漂亮的界面有很多都可以直接調(diào)用

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

• 項目組會每周開會，并經(jīng)常在討論群中積極線上討論，所以任務(wù)的定義都比較清楚，完成度也很高

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

• APP的部分數(shù)據(jù)庫連接，以及APP首頁部分與訂單部分的對接出現(xiàn)了問題，未按預計的時間完成
• 未估計的風險就是上面的部分工作未按期望順利完成，原因還是開發(fā)經(jīng)驗太少所導致

7.?在計劃中有沒有留下緩沖區(qū)，緩沖區(qū)有作用么?

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

8.?將來的計劃會做什么修改？（例如：緩沖區(qū)的定義，加班）

• 項目組成員之間聯(lián)系更加緊密一些，會定時在組里匯報自己的開發(fā)進度和問題以防止項目進度的延后

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

• 首先是數(shù)據(jù)庫設(shè)計對實際的實現(xiàn)的考慮還不充足，如果重來一遍，數(shù)據(jù)庫設(shè)計會更充分的考慮程序員功能實現(xiàn)的難易度
• 然后學到了一些專業(yè)開發(fā)之外的東西，比如團隊成員之間的相互磨合，如果重來一遍會更注重與團隊成員之間的交流

?

資源

1.?我們有足夠的資源來完成各項任務(wù)么?

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

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

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

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

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

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

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

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

• 對任務(wù)分工不夠細致，如果重來一遍會將分工劃分得更細并估計每個任務(wù)完成的時間

?

變更管理

1.?每個相關(guān)的員工都及時知道了變更的消息?

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

2.?我們采用了什么辦法決定“推遲”和“必須實現(xiàn)”的功能?

• 我們的迭代計劃都對每個功能都有對應的優(yōu)先級，會優(yōu)先實現(xiàn)優(yōu)先級高的功能

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

• 按照需求文檔的要求實現(xiàn)了，并與產(chǎn)品原型設(shè)計相同或更好，就是“做好了”

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

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

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

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

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

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

?

設(shè)計/實現(xiàn)

1.?設(shè)計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？

• 產(chǎn)品的原型設(shè)計是在開發(fā)之前，由PM完成

2.?設(shè)計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？

• 產(chǎn)品原型設(shè)計由一人完成，并沒有模棱兩可的情況

3.?團隊是否運用單元測試（unit test），測試驅(qū)動的開發(fā)（TDD）、UML,?或者其他工具來幫助設(shè)計和實現(xiàn)？這些工具有效么？ 比較項目開始的 UML 文檔和現(xiàn)在的狀態(tài)有什么區(qū)別？這些區(qū)別如何產(chǎn)生的？是否要更新 UML 文檔？

• 使用了UML，UML文檔已有幾個版本，變更的原因是在于開始時UML知識的不足，以及后續(xù)產(chǎn)品功能的調(diào)整，每次都會更新UML文檔

4.?什么功能產(chǎn)生的Bug最多，為什么？在發(fā)布之后發(fā)現(xiàn)了什么重要的bug? 為什么我們在設(shè)計/開發(fā)的時候沒有想到這些情況?

• 要與服務(wù)器數(shù)據(jù)庫連接的功能的bug最多，原因在于對數(shù)據(jù)庫連接操作的不熟練，產(chǎn)品還未發(fā)布

5.?代碼復審（Code Review）是如何進行的，是否嚴格執(zhí)行了代碼規(guī)范？

• ?代碼復審是團隊成員各種檢查各自的代碼，是按照代碼規(guī)范執(zhí)行的

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

• 產(chǎn)品原型設(shè)計應付出更多的時間和人力，如果重來一遍會付出更多的時間進行產(chǎn)品原型設(shè)計
• 代碼復審應更加嚴格，如果重來一遍會再進行一次團隊成員之間交換的代碼復審

?

測試/發(fā)布

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

• 沒有測試計劃，初次項目開發(fā)經(jīng)驗不足，時間也較緊張

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

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

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

• 沒有

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

• 暫未考慮

5.?在發(fā)布的過程中發(fā)現(xiàn)了哪些意外問題？

• 暫未發(fā)布?

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

• 未制定相應的測試計劃，如果重來一遍會制定測試計劃并運用相關(guān)測試工具來對項目進行測試

?

團隊的角色，管理，合作

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

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

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

• 團隊成員之間經(jīng)常互幫互組，相互提升

? ? 3. 當出現(xiàn)項目管理、合作方面的問題時，團隊成員如何解決問題？

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

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

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

?

總結(jié):

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

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

??????你覺得團隊目前處于?萌芽/磨合/規(guī)范/創(chuàng)造?階段的哪一個階段?

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

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

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

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

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

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

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

轉(zhuǎn)載于:https://www.cnblogs.com/jiangjiangjiang/p/10088229.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。