第一次迭代心得
設想和目標
1.我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
- 軟件主要解決穩定期慢阻肺患者的護理問題，旨在為患者提供護理計劃和提醒，以及提供咨詢醫生的途徑。
- 典型用戶有：穩定期慢阻肺患者，將通過軟件獲取穩定器的護理計劃以及提醒，能夠通過手機綁定設備并通過手機獲取設備采集的體征數據和環境數據，通過向簽約的家庭醫生求證，詢問病情并獲取建議。
? ? ? ? ? ? ?平臺認證家庭醫生，將通過軟件簽約患者，為患者提供咨詢服務，并向患者提供護理計劃等服務以謀取報酬。 - 典型場景：接受治療后，回到家中進行后續的穩定護理的患者，通過軟件實時查看體征數據，對病情有一個大體的掌握；查看護理計劃，并在按照軟件的提醒按時服用藥物，進行一系列的護理措施；詢問醫生，實時掌握病情，并接受最符合自身的護理計劃。
2.我們達到目標了么（原計劃的功能做到了幾個？? 按照原計劃交付時間交付了么？ 原計劃達到的用戶數量達到了么?)
alpha階段我們計劃實現登錄模塊，患者端和醫生端的聊天模塊以及護理計劃模塊，并按照原計劃交付時間進行交付，由于不是完整的軟件，因此沒有上線。
3.用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?
離目標肯定是更近了。但是和預想存在著較大的差別。可能是因為我們所有人對Android都比較陌生，編程過程較為艱難，為了按時交付代碼，沒有做過多的界面相關的優化。盡管沒有花費很多的時間在界面上，功能實現也依舊存在瑕疵，可能時間緊張以及能力的問題，總之各方面原因導致成果與預想存在較大差別。
4.有什么經驗教訓? 如果歷史重來一遍,?我們會做什么改進?
教訓有很多，首先，任務分配應該合理。起初，我們錯誤估計了工作量，使得在第一周出現了忙閑兩級分化的現象；其次，團隊之間應該多交流，多溝通。alpha階段，我們在開發過程中缺少交流，每個人都在忙著完成自己的模塊，而沒有和其他人進行溝通，使得在最后進行代碼整合的時候出現較多的問題。再其次，編寫代碼要有統一的分工，統一的規范。盡管提過代碼規范的問題，但是每個人似乎都沒有放在心上，代碼的風格都不一樣，最后整合的時候就很浪費時間；最后，要善用代碼管理平臺。在alpha驗收的幾個小時前，我們還在調試代碼，結果驗收前一個正常的代碼被改出了問題，因為沒有使用git，沒有一個正常的代碼能用，心情可想而知。
如果歷史重來，希望能在迭代開始前抽出跟多的時間去了解android，提前熟悉免得開發的時候手忙腳亂；對任務進行合理的分工，這樣才能節省時間；約組員出來一起自習，多進行交流才能使工作更輕松；使用代碼管理平臺，嚴格要求代碼規范，這樣能大大的提高工作效率。
?
計劃
1.是否有充足的時間來做計劃？
做計劃的時間相對充裕，但是沒有實際的經驗，考慮的少了一些，所以計劃，分工制定的有些不合理。
2.團隊在計劃階段是如何解決同事們對于計劃的不同意見的？
都沒有經驗，所以都沒有意見。
3.你原計劃的工作是否最后都做完了??如果有沒做完的，為什么?
沒有。因為代碼風格以及時間的原因，有些代碼沒有來得及整合。
4.有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
沒有。
5.是否每一項任務都有清楚定義和衡量的交付件?
是
6.是否項目的整個過程都按照計劃進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?
不是。首先任務分工的問題使得時間很緊張，接著代碼規范的問題使得整合出現了困難，最后，沒有使用管理平臺使得最后驗收的代碼并不是最好狀態的。至于原因，可能是因為之前的編程都是個人的，獨立的，不需要考慮這么多，突然進行多人合作，思維沒有調整過來，考慮的少了。
7.在計劃中有沒有留下緩沖區，緩沖區有作用么?
沒有
8.將來的計劃會做什么修改？（例如：緩沖區的定義，加班）
計劃并沒有出現什么大的問題，因此不需要修改，只是其他的，諸如代碼規范，工具的使用，溝通交流之類的要求會吸取這次教訓進行調整。
9.我們學到了什么??如果歷史重來一遍,?我們會做什么改進?
通過alpha階段最后幾天的經歷，大家對alpha階段的工作狀態都有了一個慘痛的認識，明白了從一開始就應該全力以赴，而不是以一種悠閑自在的心態對待任務。
?
資源
1.?我們有足夠的資源來完成各項任務么?
有
2.各項任務所需的時間和其他資源是如何估計的，精度如何?
按照模塊平分總的工作時間，精度還行，基本符合實際情況。
3.測試的時間，人力和軟件/硬件資源是否足夠? 對于那些不需要編程的資源 (美工設計/文案)是否低估難度??
測試的時間預留的有點少，資源足夠，沒有美工和文案。
4.?你有沒有感到你做的事情可以讓別人來做（更有效率）?
沒有，都是剛接觸Android，沒有差別。
5.有什么經驗教訓??如果歷史重來一遍,?我們會做什么改進?
早點整合代碼，早點進行測試。
?
變更管理
1.?每個相關的員工都及時知道了變更的消息?
對
2.我們采用了什么辦法決定“推遲”和“必須實現”的功能?
先完成各模塊基礎功能，不影響使用的功能推遲實現。
3.項目的出口條件（Exit Criteria –?什么叫“做好了”）有清晰的定義么?
沒有
4.對于可能的變更是否能制定應急計劃?
沒有
5.員工是否能夠有效地處理意料之外的工作請求？
似乎不能
6.我們學到了什么??如果歷史重來一遍,?我們會做什么改進?
完全沒有考慮這方面的東西，如果歷史重來，會考慮的更加周全吧。
?
設計/實現
1.?設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
在迭代開始前一二周，有團隊共同進行，協商討論，合適的時間。
2.?設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
有，接著討論，直到確定一個為止。
3.?團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML,?或者其他工具來幫助設計和實現？這些工具有效么？ 比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
使用了uml，幫助不大，體現不了，其他沒有使用。
4.?什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
沒有統計過，不清楚，但是基本都有很多bug。沒有發布。因為我們太菜了，想不到這么多。
5.?代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
小組互查。并沒有，寫著寫著就放飛自我了，每個人，包括審查代碼的人，都對代碼規范沒有一個完整的定義，現階段的代碼規范更多的是一個評分標準，而不是一個工具。
6.我們學到了什么??如果歷史重來一遍,?我們會做什么改進?
完全沒有考慮這方面的東西，如果歷史重來，會考慮的更加周全吧。
?
測試/發布
1.?團隊是否有一個測試計劃？為什么沒有？
沒有，對于我們而言，更多的是代碼能否正常運行，之后遇到什么問題就解決什么問題，至于測試計劃，考慮的沒有那么多。
2.?是否進行了正式的驗收測試？
是
3.?團隊是否有測試工具來幫助測試？
沒有
4.?團隊是如何測量并跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
沒有考慮效能問題。
5.?在發布的過程中發現了哪些意外問題？
沒有發布。
6.我們學到了什么??如果歷史重來一遍,?我們會做什么改進?
完全沒有考慮這方面的東西，如果歷史重來，會考慮的更加周全吧。
?
團隊的角色，管理，合作
1. 團隊的每個角色是如何確定的，是不是人盡其才？
每個人都參與開發。
2. 團隊成員之間有互相幫助么？?
有。
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
先溝通，在編碼，出現問題一起解決
?
總結:
你覺得團隊目前的狀態屬于 CMM/CMMI 中的哪個檔次?
屬于CMMI一級，完成級
??????你覺得團隊目前處于?萌芽/磨合/規范/創造?階段的哪一個階段?
磨合基本完成
??????你覺得團隊在這個里程碑相比前一個里程碑有什么改進??
都吸取了教訓，并更加投入到工作中來
????? 你覺得目前最需要改進的一個方面是什么?
代碼規范的問題
?
希望能一直這樣保持下去，知道項目結束。
轉載于:https://www.cnblogs.com/marinmoring/p/10094319.html
總結
- 上一篇： 电脑系统修复有多重要？
- 下一篇： 【算法】约瑟夫环