第一次迭代開發總結

2022-05-05 04:30:10 字數 3398 閱讀 7091

上週進行了alpha版本專案的驗收,為第一次迭代畫上了句號。以下是我對本組專案第一次迭代的思考與總結:

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

產品定義:我們軟體定義明確,是為需要使用車輛的使用者提供及時租車功能;

典型使用者:出差在外上班族;

典型場景:機場。

2. 是否有充足的時間來做計畫?

時間充足。每週每位成員都有本週必須完成的各自的任務,所以專案進度比較快。

3. 團隊在計畫階段是如何解決同事們對於計畫的不同意見的?

通過溝通解決。任何成員有問題都會直接提出來進行的商議,最後由pm做決定。

1. 你原計畫的工作是否最後都做完了? 如果有沒做完的,為什麼?

第一次迭代截止日期之前,本團隊所有成員都按時完成了計畫工作。

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

有一些。比如在第一次迭代時,網頁開發沒有使用框架,顯得比較麻煩。

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

沒有很明確。每個部分都是根據開發人員的意願,溝通之後不斷調整。

4. 是否專案的整個過程都按照計畫進行?

是的。每週我們都會有周任務並且按時完成了。

5. 在計畫中有沒有留下緩衝區,緩衝區有作用麼?

有緩衝區。緩衝區是在第一次迭代開發截止日期的前幾周,主要是在輕鬆學習。作用還是比較大,後續開發中效率很高。

6. 將來的計畫會做什麼修改?(例如:緩衝區的定義,加班)

應該會根據第一次迭代的情況做修改,緩衝區長度可能會減少。團隊工作模式延續。

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

我們完成了第一次迭代計畫的全部任務。但是由於資金、時間限制,一些介面等不會實現。

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

估計:總時間是根據前兩周開發具體情況估計,後續是自己調整安排

精度:一般。有事會出現臨時安排打亂計畫。

3. 使用者測試的時間,人力和軟體/硬體資源是否足夠?

目前使用者僅有開發成員和指導老師,所以各項資源完全足夠。

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

有!與我合作開發網頁的隊員很厲害,完全可以獨當一面。

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

有任何變更都會通過群訊息通知所有成員,所以比較及時。

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

有的部分實現方法相似,在第一次迭代中就先選擇實現乙個。但基於使用者體驗,所以第一次迭代完成了從註冊到租車完成所需要的大體功能。一些細節,例如聯絡客服就留到了第二次迭代。

3. 專案的出口條件(exit criteria)是否得到清晰的定義?

做到完成除接支付寶介面的其他功能。

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

基本沒有,會隨機應變,及時做出調整。

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

有臨時工作pm會根據本週的實際情況做出調整和具體部署。

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

大體的設計是在專案初期由pm根據老師的指導意見完成。後續開發根據實際進行調整。

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

在很多細節問題上都比較模稜兩可,主要是通過溝通交流解決,解決不了會請教指導老師。

3. 團隊是否運用單元測試(unit test),測試驅動的開發(tdd)、uml, 或者其他工具來幫助設計和實現?這些工具有效麼?

團隊運用了uml來幫助設計。畫完uml圖對整個專案的流程更加清晰。在網頁設計過程中,還用了阿里巴巴向量相簿等**。

4. 什麼功能產生的bug最多,為什麼?

管理員網頁部分訂單管理功能,因為它是綜合了客戶、車輛等所有資訊,任何乙個部分有問題都會影響它。

5. **複審(code review)是如何進行的,是否嚴格執行了**規範?

並未進行**複審。在寫**時就執行了**規範。

1. 團隊是否有乙個測試計畫?為什麼沒有?

只有驗收標準並未制定驗收計畫。

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

第一次迭代驗收初步測試。

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

暫未考慮。

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

暫未考慮。

5. 在發布的過程中發現了哪些意外問題?

只考慮如期完成專案。不考慮發布問題。

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

屬於cmmi一級,完成級。

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

磨合完成,規範初期。

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

團隊成員之間學會了溝通交流,效率有了明顯提高。

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

**規範需要嚴格執行並且管理員網頁要用框架來實現。

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

無論團隊內外,面對面的交流始終是最有效的溝通方式

我們團隊每週都會進行至少一次例會,把開發過程中遇到的問題提出來進行面對面溝通交流。

保持簡明 - 盡可能簡化工作量的技藝 - 極為重要

在進行實際開發之間我們都會指定明確的開發計畫,按照計畫一項一項完成工作。

只有能自我管理的團隊才能創造優秀的架構, 需求和設計

團隊成員尤其是pm,都十分自律,嚴格執行各項計畫。

總的來說,我們團隊整個進度和工作氛圍都比較好,也按期、順利、高質量的完成了各種工作,希望第二次迭代能夠繼續保持!

第一次迭代開發心得

設想和目標 1.我們的軟體要解決什麼問題?是否定義得很清楚?是否對典型使用者和典型場景有清晰的描述?典型使用者為買家和買家,場景按功能劃分,有首頁推薦商品,搜尋商品或心願,處理訂單,進入圈子發言,修改個人資訊,發布商品或心願 2.我們達到目標了麼 原計畫的功能做到了幾個?按照原計畫交付時間交付了麼?...

第一次迭代開發心得

我們的軟體要解決什麼問題?是否定義得很清楚?是否對典型使用者和典型場景有清晰的描述?典型使用者 配電站及其維修人員 典型場景 配電站 我們達到目標了麼 原計畫的功能做到了幾個?按照原計畫交付時間交付了麼?原計畫達到的使用者數量達到了麼?交付和使用者 軟體功能尚未完全實現,暫時無法投入使用 使用者量,...

第一次迭代開發心得

在本科時期第一次完整嘗試著去做自己的專案,而且也是以乙個team的方式,其中也出現了很多問題,然而還是在學長的幫助下和團隊的共同努力下,共同克服了這些問題。隊名 改不完bug不起名 成員 童天瑤,李斌,夏昊,李興皓,顧杰偉 me 設計乙個面向研究的rdf搜尋引擎,其次面向普通使用者。搜尋引擎的提出主...