上週進行了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搜尋引擎，其次面向普通使用者。搜尋引擎的提出主...