第一次叠代總結和思考
阿新 • • 發佈：2018-12-10
實現 騰訊 學會 如何解決 重要 服務 過程 roi 折線圖
第一次叠代上周結束了，總的來說相比較有一開始收獲是非常大的。重新開始學習一種語言，熟悉相應的開發環境，掌握編碼規則，都是不可多得的體驗和收獲。
設想和目標
- 我們的軟件要解決什麽問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
- 我們軟件很明確的定義，就是一個統計實時噪聲數據並繪制區域噪聲地圖，同時提供給用戶需要的信息，之後政府也可以根據噪聲數據采取針對性的措施
- 典型用戶：學生（目前只能局限在湖大這個群體範圍）
- 典型場景：交通，住房等人的活動區域
- 我們達到目標了麽（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麽？ 原計劃達到的用戶數量達到了麽?)?
- 原計劃功能：用戶可查看實時噪聲分貝，實時噪聲折線圖顯示，並在後臺顯示上傳數據
- 實現情況：
- 實時噪聲分貝功能已基本實現，數據上傳也基本實現
- 折線圖的繪制已經實現但未集成
- 查看所選擇時間的噪聲地圖功能因為涉及的算法比較多，實現起來也很有難度，還未實現
- 交付和用戶：軟件功能的核心功能-噪聲地圖顯示還未實現，暫時無法投入使用
- 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致麽? 我們離目標更近了麽?
- 暫未投入使用，用戶實際接受成度未知
- 產品完成度一般，不過下一階段目標已經明確，但是之後的壓力較大
- 有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?
- 由於我們的項目需要開發Android客戶端，ios客戶端和服務器網頁，整體工作量比較大，又加上大家都是之前沒有開發經驗的，所以項目開發起來相對緩慢，並且大量工作重復機械（垃圾工程很多）。這就導致我們第一次叠代計劃實現的功能較少，後續開發壓力比較大。
- 如果歷史重來一遍，我希望一開始就已經學會了相關的知識，不然邊學邊做太慢，這種過程非常痛苦。
計劃
- 是否有充足的時間來做計劃?
- 整個創新課程的團隊項目時間不太長，計劃的時間也不會太長。而且計劃總是趕不上變化，最開始的計劃也是根據進度不斷調整。
- 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
- 計劃階段討論很順利，大家的意見都很統一。
- 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麽?
- 第一次原計劃的內容比較少，alpha版本的計劃都超量完成了
- 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
- 設計交互界面的過程中采用了好幾種方式結果最後還是沒有用上，結合之前的學長SIT項目的經驗，結合了他們的數據庫設計了一下上傳數據的模塊結果也沒有太大作用。
- 是否每一項任務都有清楚定義和衡量的交付件?
- 小組聚在一起搞開發，所以已有問題就當場解決，所以比較清楚。
- 是否項目的整個過程都按照計劃進行，項目出了什麽意外？有什麽風險是當時沒有估計到的，為什麽沒有估計到?
- 組內第一次叠代沒有實現集成，都是各自做各自的模塊，導致驗收的時候很匆忙
- 風險的話就是各種線程的跳出，還有多個功能集合就會有一定的問題
- 在計劃中有沒有留下緩沖區，緩沖區有作用麽?
- 留有緩沖區，第一次叠代差不多在驗收前一個星期已經實現，這一周應該可以算做緩沖區。
- 緩沖區主要是針對第一次叠代的內容完成一定的集成，並開始學習有關後臺開發和網絡編程協議有關的內容
- 將來的計劃會做什麽修改？（例如：緩沖區的定義，加班）
- 繼續加強組內聯系吧，多開會討論，加強協作，繼續加強修仙和爆肝
- 我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
- 不做前端，因為另外一門課程的原因，需要我寫一個後臺程序，所以真不如第一次叠代開發的時候規劃任務時選擇後端開發
- 如果歷史重來一遍，一定在創新課程開始之前就把相關知識學好！
資源
- 我們有足夠的資源來完成各項任務麽?
- 時間和資金的資源限制，alpha版本任務也基本實現
- 各項任務所需的時間和其他資源是如何估計的，精度如何?
- 時間主要是按任務量估計，時間按各自的安排估計
- 精度還不錯，課本能保持高效且時間安排還比較合理
- 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
- 測試沒有系統、詳細的安排，做了簡單的測試，沒有花費很多時間
- 人力資源比較少，不太足夠。
- 美工做的一般，各種文檔的撰寫基本由PM負責了，應該還是很難寫的
- 你有沒有感到你做的事情可以讓別人來做（更有效率）?
- 沒有，有問題大家就討論，什麽問題當場就解決了，不存在滯後的問題
- 有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?
- 如果能重來，要把分工做的更加明確。
- 如果能重來，我要寫ｗｅｂ
- 如果能重來，我一定在加強熬夜力度
變更管理
- 每個相關的員工都及時知道了變更的消息?
- 我們組每周都會多次開會，在著手開發以後只要一有時間大家就都在公寓內咖啡店集中開發，所以溝通比較多。
- 我們采用了什麽辦法決定“推遲”和“必須實現”的功能?
- 在第一次叠代計劃中有設置功能優先級
- 項目的出口條件（Exit Criteria – 什麽叫“做好了”）有清晰的定義麽?
- 根據之前的原型設計和需求文檔，基本功能和UI設計好了就算OK
- 對於可能的變更是否能制定應急計劃?
- 沒有提前制定應急計劃，小組計劃也沒有出現大的意外
- 員工是否能夠有效地處理意料之外的工作請求？
- 大家的及時調整都很棒，對於意外的發生也能做出迅速的反應
- 我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
- 我們小組的溝通非常多，這樣就能互相了解到相互的進度等，互相促進提高。
- 改進的話就是自己投入更多時間，把閑暇時間好好利用起來。
設計/實現
- 設計工作在什麽時候，由誰來完成的？是合適的時間，合適的人麽？
- 整個模式的設計是在項目初期，由pm和老師溝通商定的
- 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
- 開始時有一點模糊，後來大家一起討論得以最終確定
- 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麽？
- 網上大量的資源和相應的軟件，所以繪圖不是問題，主要是要理清之間的邏輯關系和相關的聯系
- 騰訊敏捷開發平臺幫助管理項目有巨大的便利性
- 這些工具都非常有效，幫助巨大。
- 比較項目開始的 UML 文檔和現在的狀態有什麽區別？這些區別如何產生的？是否要更新 UML 文檔？
- 文檔更加豐富了，會在項目推進中，不斷完善、更新文檔
- 什麽功能產生的Bug最多，為什麽？在發布之後發現了什麽重要的bug? 為什麽我們在設計/開發的時候沒有想到這些情況?
- 目前完成的功能比較少，所以bug還沒怎麽發現
- 還沒有發布
- 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
- 代碼復審主要是小組之間互相檢查，而我們組在檢查其他組時是分文件進行分工，各司其職
- 嚴格執行了代碼規範。函數命名，成員命名，代碼註釋，代碼組織等都嚴格查看了。
測試/發布
- 團隊是否有一個測試計劃？為什麽沒有？
- 沒有一個完善的測試計劃
- 受時間和資源的限制
- 是否進行了正式的驗收測試？
- 我們組由邊老師親自進行了第一次驗收，雖然結果不是很滿意但是應該也算完成了
- 團隊是否有測試工具來幫助測試？
- 暫未考慮
- 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用麽？應該有哪些改進？
- 暫未考慮
- 在發布的過程中發現了哪些意外問題？
- 噪聲地圖顯示功能未解決，暫時不考慮發布
- 我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
- 因為還是第一次做項目，經驗還不太夠，測試方面暫時沒有精力、時間考慮
團隊的角色，管理，合作
- 團隊的每個角色是如何確定的，是不是人盡其才？
- 小組比較民主，PM都是按照大家自己的意願分配角色，
- 基本人盡其才。
- 團隊成員之間有互相幫助麽？
- 當然，兩個客戶端各分配兩個人，這樣更加便於溝通交流。
- 客戶端也和服務器端正在加強協作溝通。
- 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
- 合作問題基本沒有，大家都很包容體諒對方。
- 小組成員之間也互相幫助，我們是一個很有愛又可愛的集體~
- 百度谷歌大法好
總結
1.你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
應該屬於可重復級(Repeatable)
2.你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
磨合基本完成，下一步就是規範和創造
3.你覺得團隊在這個裏程碑相比前一個裏程碑有什麽改進?
大家彼此更加熟悉，互相的配合會比之前更有效率.
4.你覺得目前最需要改進的一個方面是什麽
叠代計劃制定的不太合理，任務分配需要更加合理一些，現在後期開發壓力比較大
5.對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例
我們組做的最好的我覺得就是小組溝通很多，每周都會多次開會，在著手開發以後只要一有時間大家就都在公寓內咖啡店集中開發。
第一次叠代總結和思考