福大軟工 · 第十一次作業 - Alpha 事後諸葛亮（團隊） Alpha 事後諸葛亮
Alpha 事後諸葛亮
Part 1 前言
Part 2 總結思考
- 設想和目標
- 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
解決微信端上的輕便辦公，方便微信端上的辦公群體，例如共享編輯針對需要反覆審閱修改的辦公情形，以及其他環境下面向組內的通知、投票等一系列辦公需求。
- 我們達到目標了麼（原計劃的功能做到了幾個？
原計劃的功能中基本完成投票功能、物件分組，接近完成共享編輯功能，半完成通知、想法功能，未完成簽到功能。
- 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)?
使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼?我們離目標更近了麼?
距離目標我們還有一定的差距，這次的alpha未能夠達到我們原定的計劃，如上述所表述的，進度並不是令人滿意，目前所完成的效果也與前期設定的原型不論是風格上還是功能上相左，需要完善的地方有許多。
- 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
柯奇豪：前踩工作需要做好，瞭解整體專案所需要的技術、軟硬體支援，才能是後續的專案進度有條不紊。
- 計劃
- 是否有充足的時間來做計劃?
因為種種原因(考試、黨課、個人等等)，每次計劃的都不是很完美，也沒有很及時的時間去補正，後續會注意。
- 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
通過了激烈的討論，得到一個可行的方案並往這方面走。
- 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
楊禮亮：美工工作完成，輔助翔宇的工作還未完成，因為效率不高，能力不夠
丁水源：通知後端的工作完成，但是完成的速度比較慢
柯奇豪：共享編輯後期遇到許多之前沒有估計到的修改，例如儲存形式、功能增加等，所以導致沒有及時的做好，只完成了簡單的列表顯示功能。
黃毓明：投票、分組功能完成。
黃志銘：原來計劃在12月份前把所有的前端介面做完，並和後端一起完成互動，然後好好準備期末考。過程一直都以為前後端互動應該就是一兩天的時間………結果出來當面互動的時候，就發現了問題好多呀……根本不是一兩天可以完成的。
蔣熊：沒有都做完，待得不斷開發，所發現的問題也越來越多，原型UI設計不完整，頁面需求隨著開發的深入不斷上漲 有很多原型設計裡沒有的頁面需要新增。一開始定的實現邏輯隨著開發的深入也發現後端一些演算法是無法完成的，因此前端頁面需要跟進後端演算法做出調整。再而對js不熟悉，與後端對接上來不及做完，且頁面過來，也來不及對接，工作量太大。
林翔宇：沒有。臨近考試，再加上轉專業課也很多，時間難以平衡。
- 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
柯奇豪：有，花了大把的時間在ssm框架上，結果不太會用，轉用springboot+mybatis，但慶幸是能用了。
丁水源：過程中學到的東西都挺有價值的，時間花的挺值得
楊禮亮：學了很多但是都遺忘了
黃毓明：一開始寫的投票沒能融入框架，只能使用裡面的部分函式，大部分未使用
黃志銘：確實做了很多好像根本就沒有幫助的事，比如自動跳轉圖片的介面風格以及程式碼之前幾乎都是自己寫，完全可以和網上照著改一下，再完善，延長了進度
蔣熊：覺得比較沒有必要的事情就是開發前期過多的投入於邏輯設計和各自分工，浪費了很多時間大家各做各的，到最後一對接才發現對不上。
林翔宇：學些java基本語法花了很多時間，才開始寫要做的小程式。其實完全可以邊學習語法邊寫的。
- 是否每一項任務都有清楚定義和衡量的交付件?
所有人：很遺憾，沒有，許多東西都是在後續工作中不斷髮現需要修修補補的地方，許多地方沒考慮到。對於大家每個人任務的總和要達到什麼結果很模糊。
- 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
所有人：專案初期是在按預期走，但是中後期已經偏離軌道了，出現的大問題有幾個，一個是研發小組隊員退出，不是簡單的n-1問題，再一個就是前後端對接。直到現在，後端仍有三個專案未開發成功，前後端能算比較完整對接的只有投票一塊。我覺得出現這樣的問題主要是大家溝通交流不夠吧，不然也不會再最後一週才想起來要出來一起做。沒有有效的資源共享，導致每個人進度不一。
- 在計劃中有沒有留下緩衝區，緩衝區有作用麼?
所有人：有過留取一段時間進行前後互動，是為了防止前後端互動後出現重大bug，或是介面邏輯有問題等，但是每個人並沒有在這段時間前很好的將自己的任務及時完成，導致後續進展不順，所以後來的緩衝區作用不大。
- 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
柯奇豪：留出一段時間出來進行一個專案的整合，目前在過渡期內，我計劃分成兩部分人群分別負責部分功能的前後端一起完善，最後在緩衝區的時間段內整體的一個彙總，每兩天找個固定的時間段來一起程式設計。
黃志銘：接下去計劃在一週之內，儘量能與分小組同學一起出來當面做一下，完善一下專案，在做前端介面的同時，也瞭解一下後端的具體操作，更好地實現互動。
蔣熊：其他小組專案都差不多完成了，接下來我們也得加快了，明白了問題所在，就不該再繼續下去了，加班生活正式開始。
林翔宇：分配時間的時候一定要考慮仔細，不要再因為時間分配不合理，導致計劃無法完成。
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
柯奇豪：學到的就是需要在專案開展之前即蒐集足夠多的資料來對整體的專案各部分有一個明確的方向，這樣在後續的進度中就不會因為卡殼而不停的調整，初步瞭解各部分細分下來所需要的技術支援。
黃志銘：這個可以早點出來當面做一下，討論一下具體的分工以及專案願景，讓大家更熟悉自己對應的部分，提高團隊整體效率。
蔣熊：如果能夠重來，第一週我們就會抱著這樣的態度，二話不說，直接加班，擼袖子就是幹。
林翔宇：做計劃的時候一定要合理，時間很緊湊的時候要儘量提高效率。
- 資源
- 我們有足夠的資源來完成各項任務麼?
時間資源不足，基礎能力儲備不足。
- 各項任務所需的時間和其他資源是如何估計的，精度如何?
原先是按照每次部落格的提交時間為週期進行程式設計，後續可能會更加細化，因為還有許多工作需要完善。
- 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
柯奇豪：測試階段基本上部署伺服器，暫時還在前期籌措階段，待後續反饋。
- 你有沒有感到你做的事情可以讓別人來做（更有效率）?
柯奇豪：在專案的規劃上以及對任務的佈置上自己還是有缺失的，個人不怎麼善於言辭，所以在過程中表述上常常沒辦法解釋清楚，導致組員出現一頭霧水的情況，在語言溝通上可能存在障礙。如果換一個表述更清晰一點的人或許在前期可以解決目標不明確的問題。
蔣熊：我覺得換一個人做我的事情不一定會更有效率。我覺得其他人也一樣，每個人都適合自己的工作，問題始終不在個人上，而是團隊上。
林翔宇：我們組人比較少，大家任務都很重，所以自己的部分還是自己努力做好吧。
- 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
技術資源共享不夠，如果重來或許可以借鑑其他組的思路，程式設計過程裡也整理問題及解決辦法，整合一份技術指南來便於小組開發。要注意隊內的溝通交流，一定要留好十分足夠的緩衝時間。
- 變更管理
- 每個相關的員工都及時知道了變更的訊息?
會有訊息延遲的情況，部分時候會耽誤進度，後續可能採用固定時間段來集體完成並彙總提交。
- 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
按照部落格提交的進度進行，但是發現不能很好的既定目標相符，需要調整一個合理的辦法，可能會增加組內的進度deadline。
- 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
暫時沒有考慮到這個問題，後續以真機測試為準。
- 對於可能的變更是否能制定應急計劃?
目前沒有
- 員工是否能夠有效地處理意料之外的工作請求？
基於每個人的水平，部分成員沒辦法做到
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
柯奇豪：deadline與驗收標準的確定需要完善，缺少壓力的團隊往往就會導致專案的短期擱淺，自己也需要學會對隊員有更高的要求與督促。
黃毓明：學到了很多東西，Java的springboot+mybatis框架使用，微信小程式前端開發，以及一些web服務的相關，如果可以重來的話，不應將時間都浪費在一個框架上，提前做好任務分配也許會更好
丁水源：如果歷史重來一次，我將會盡早的做規劃，儘量早地完成任務。
蔣熊：如果歷史重來，一定會先集中力量開發核心功能 先完成專案主模組。
林翔宇：當進度跟不上原先計劃時，要趕緊調整，反思原因。
- 設計/實現
- 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
在專案的初期由組內共同討論完成，是的。
- 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
原先在部分的功能上有歧義，基本通過各自表述自己的看法然後大家共同決定通過。
- 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？
主要使用processon、leangoo來對專案細則有一定的說明。
- 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
存在比較大的差異，是原先組內沒考慮到的，主要原因在於專案開發經驗不足，沒有細化到許多具體的地方，後續有時間會對之前的UML文件進行修正。
- 什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
框架的使用上遇到較多的bug，因為原先並沒有考慮到會用框架，也是第一次嘗試使用。
- 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
暫時沒有程式碼的複審，後續做完會對程式碼的命名規範、註釋、專案具體的佈局做一定的修改。
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
柯奇豪：規劃上雖然沒辦法一開始就做到盡善盡美，但在後續的程序中，還是需要安排適當足夠的時間去做好這塊內容
- 測試/釋出
- 團隊是否有一個測試計劃？為什麼沒有？
暫時沒有，因為基礎性的開發並沒有及時完成，但是在後續會有一個測試版本階段。
- 是否進行了正式的驗收測試？
目前還沒有
- 團隊是否有測試工具來幫助測試？
沒有具體的規劃，後續會去請教一下其他組給出方案。
- 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
暫未進行，設定的目標是想在周圍人群中進行一次推廣調查，然後收集意見酌情修改完善。
- 在釋出的過程中發現了哪些意外問題？
產品暫未釋出，還未遇到問題。
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
柯奇豪：有一個合理夠用的測試可以簡化專案後續的工作，減少bug的出現，儘可能考慮情況解決缺漏
- 團隊的角色，管理，合作
- 團隊的每個角色是如何確定的，是不是人盡其才？
按自己的意願進行職能的分配，基本上算是人盡其才，但還是存在部分成員存在空窗期的情況，例如在原型設計階段部分前後端不知所措，以及後續前後開發過程中美工人員的不知所措等。
- 團隊成員之間有互相幫助麼？
柯奇豪：團隊成員在瞭解框架、具體程式設計等的過程中，基本上都是採取互幫互助的形式進行學習，相互指教的。
丁水源：有相互幫助，比如我就會去請教同伴黃毓明不懂的問題。
- 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的部落格裡）：
柯奇豪：在此感謝一下 ++毓明++ ， 因為 ++自己本身不太善於言辭，僅僅只是自己會使用、程式設計，但經常給其他人解釋不清，毓明則能很好的幫我與其餘的人溝通，指導他們框架搭建，這是我未能做到的++。
黃毓明：在alpha版本中交流較少，基本上都是各做各的，出現問題也基本上是自己埋著頭解決
丁水源：我感謝黃毓明對我的幫助，因為當我在理解Spring Boot框架時遇到一些問題，詢問他，他能十分耐心地給我講解。
蔣熊：我感謝全組的人對我的幫助，因為某個具體的事情：其實不論是前期工作分配的不合理，還是大家後來學習程度不夠，問題已經發生了 現在大家都願意投身其中，我們之間互幫互助，其實就很值得感恩。
林翔宇：我感謝黃毓明對我的幫助， 因為某個具體的事情: 耐心的幫我配置好開發環境，並教我怎麼使用spring boot框架。
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
柯奇豪：一個團隊最不能缺少的，就是團結一致為共同目標而共同奉獻自我的決心，少一點藉口，多做一點實事才是。帶領隊員一同進步的工作並沒有想象中的簡單，需要負責的地方有太多太多，對pm的責任多了一份敬重。還有就是努力改善自己的表述方式吧。如果重來，以上都是我會改進的地方。
黃毓明：硬要說學到了什麼，只能說獨立解決問題的能力變強了吧。如果歷史重來，或許更多的交流會是比埋頭苦幹更好的選擇
丁水源：如果歷史重來一遍，我會提前學習好專案所需的框架，以及更早地學習java語言，更早的瞭解一個產品的研發過程。
蔣熊：如果歷史重來，學會感恩吧，每個人都不推卸責任，互幫互助。
林翔宇：在團隊合作中，只有大家都盡責，才能一起完成好任務。單靠一兩個人是不夠的
- 總結:
- 你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
柯奇豪：我覺得目前團隊還處於可重複級階段。
蔣熊：我覺得目前團隊處於可重複級向已定義級過渡的階段吧
- 你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
柯奇豪：我覺得團隊暫時處於磨合階段，資訊與進度的不同步是目前遇到的最大問題。
丁水源：我覺得團隊目前處於“規範”的階段。
蔣熊：應該是磨合階段，原先比較鬆散，直至這一次問題出現，促進了我們的磨合
- 你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?
柯奇豪：更加的瞭解了軟解開發流程，逐漸提高了程式設計能力，學習的語言與技能都有很大程度的提升，整個團隊的合作觀念漸長。
黃毓明：任務分工更加明確，目標更清晰，協作能力正在加強
丁水源：我覺得團隊相比於前一個里程碑而言，隊友們更加團結，更加明確了專案的方向，更有專案經驗了。
蔣熊：改進就是學會去發現問題和解決問題了，而不是順其自然
林翔宇：大家都比較熟悉了，溝通起來也越來越順暢
- 你覺得目前最需要改進的一個方面是什麼?
柯奇豪：目前最需要改進的方面就是組內的責任意識，也希望後續大家能夠共同努力，齊心協力共同開發出能讓我們自己滿意的小程式來。
黃毓明：程式碼規範
丁水源：我覺得團隊目前最需要改進的地方時“deadline拖延症”，不要把所有事情都拖到後期才完成。
蔣熊：最需要改進的就是分工合作，在原來的基礎上重新分工，創新合作。
林翔宇：可能溝通還是要增強，大家進度要及時反饋
- 對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
柯奇豪：面對面交談原則：其中的站立會議以及leangoo進度的監督作用還是很顯而易見的。
丁水源：我覺得我們小組做得最好的是"每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。"原則，比如：其實隊員們都不是很熟悉java和Spring Boot框架，同時大部分人也沒有專案的經驗，因此在研發過程當中遇到了許多技術上的問題，我們便會常常開會，相互交流，一起解決問題。從而對各自的下一階段的工作進行適當調整。
- 部落格要附上全組討論的照片
Part 3.答辯總結
| 姓名 | 得分（百分制比例%） |
|---|---|
| 柯奇豪 | 22 |
| 蔣雄 | 11 |
| 黃志銘 | 11 |
| 黃毓明 | 24 |
| 林翔宇 | 9 |
| 丁水源 | 10 |
| 楊禮亮 | 13 |
評審表格設計
Final Score：
| 小組 | 評分 |
|---|---|
| 第一組 | 53 |
| 第二組 | 75 |
| 第三組 | 73 |
| 第四組 | 45 |
| 第五組 | 70 |
| 第六組 | 77 |
| 第七組 | 68 |
| 第八組 | 76 |
| 第九組 | 62 |
| 最低分 | 77（第六組） |
| 最高分 | 45（第四組） |
| 有效分數 | 53，75，73，70，68，76，62 |
| 最終平均得分 | 68 |
Q&A
- 第一組的問題
Q1:是否考慮在beta和alpha這段期間繼續完成alpha未完成的任務?
A1: 當然會接著完成未完成的任務，我們在beta階段來臨之前盡力完成alpha階段落下的工作量。
Q2:組內前後端的任務分配似乎存在問題,有考慮相應的解決對策嗎?
A2: 前後端在人手分配上確實是存在著問題，導致現在前端需要的工作量太大，現在我們調整了策略，每個前端負責各自部分工作外再完成各種部分前端的程式碼。
Q3:是否考慮過高併發場景下的伺服器表現？
A3: 這個問題目前沒有考慮過，因為有些功能還沒有完成，不過考慮到各個小組內部的資料量並不會過大，而且伺服器的表現如何還和價格成正比，這方面目前不會去深究。
- 第二組的問題
Q1:簽到功能是否會被虛擬定位而進行不正確位置的簽到？
A1: 因為簽到功能的人手缺失，暫時延後開發，該問題其實之前有回答過，就是輔助加上ip地址的限制
Q2:PPT中的指定wifi簽到是什麼意思？
A2: 即通過連入wifi所分配的ip地址限制簽到
Q3:如果成員沒有開啟小程式，是否會提醒釋出的通知或者被邀請進的投票？
A3:可以做到的話會加入提醒的彈窗，配合已有的通知功能
- 第四組的問題
Q1:未提問
A1:
Q2:未提問
A2:
Q3: 未提問
A3:
- 第五組的問題
Q1:有沒有考慮美化一下介面，或則說換一個介面風格？
A1:
Q2:隊友退出沒留下任何程式碼，可以理解為該隊員沒有寫過程式碼嗎
A2: 。
Q3:共享編輯是你們的主要功能，為什麼在前端方面需要三十多個頁面呢？
A3:
- 第六組的問題
Q1:在隊友退出的情況下，你們組是怎樣調整分工的？
A1: 隊友退出，對應負責的功能目前我們是採用大家一起做，先做完對應功能的同學來負責
Q2:在後續的作業中有沒有想要採取哪種方法來避免程式碼丟失的情況？
A2: 對於程式碼丟失這個問題，我們目前程式碼是進行一更新一github的方法，及時對程式碼進行更新，以避免丟失
Q3:前端在頁面較多的情況下，有考慮什麼方法來使頁面更加方便自己製作來減輕壓力？
A3: 我們目前調整了工作方式，由對應功能的前端和後端一起負責該功能，一方面減小前端壓力，另一方面提高專案整體可行性。
- 第七組的問題
Q1:投票功能裡小組選擇，小組是指微信群聊嗎？如果是的話，即使該群聊不在通訊錄裡面，也能檢測到嗎？
A1: 小組是事先建好的工作小組，組別id是存在後端的，不是微信小組。發起人可建立小組，後來的人憑連結加入。
Q2:共享編輯，別人編輯的時候，是整篇編輯，還是隻能一次編輯一段？如果是整篇編輯，合併的時候只想合併某幾段，不想全部替換，要怎麼做？
A2: 對已釋出文章按段處理，會顯示更改日誌，不用改全篇。
Q3:現階段開發進度未涉及到核心，為什麼不優先開發核心功能。
A3: 核心功能其實也已經實現的差不多了，只是前後端未對接，演算法已經OK了。
- 第八組的問題
Q1:團隊分工有沒有值得總結的地方？可以分享下
A1:
Q2:對alpha版本的完成度如何自我評價？吸引
A2:
Q3:beta版本對分工和進度跟進有什麼改進的想法？
A3:
- 第九組的問題
Q1:你們覺得你們最重要的特色功能是什麼？你們打算怎麼實現？
A1: 共享編輯，使得文字內容共享可修改，類似於github的團隊提交模式，在此基礎上附帶上版本的回退功能。
Q2:你們對自己的進度有具體的把握嗎？分工和合作上是不是存在問題？
A2: 會根據具體的完成情況調整進度安排，但是總的來說危機感，緊迫感不夠，後續要加強。分工合作後續也會調整。
Q3:你們打算如何對程式碼進行管理不會丟失
A3: 程式碼有進展及時籤進github。
Part 4.PSP與學習進度條
- 個人PSP
| PSP | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | ||
| · Estimate | · 估計這個任務需要多少時間 | 10 | 10 |
| Development | 開發 | ||
| · Analysis | · 需求分析 (包括學習新技術) | 10 | 10 |
| · Design Spec | · 生成設計文件 | 10 | 0 |
| · Design Review | · 設計複審 (和同事稽核設計文件) | 10 | 0 |
| · Coding Standard | · 程式碼規範 (為目前的開發制定合適的規範) | 0 | 0 |
| · Design | · 具體設計 | 10 | 10 |
| · Coding | · 具體編碼 | 100 | 120 |
| · Code Review | · 程式碼複審 | 0 | 0 |
| · Test | · 測試（自我測試，修改程式碼，提交修改） | 10 | 20 |
| Reporting | 報告 | ||
| · Test Report | · 測試報告 | 0 | 0 |
| · Size Measurement | · 計算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事後總結, 並提出過程改進計劃 | 10 | 10 |
| 合計 | 180 | 190 |
- 個人學習進度條（每週追加）
| 第N周 | 新增程式碼（行） | 累計程式碼（行） | 本週學習耗時(小時) | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| 10 | N | N | 10 | 97 | 微信小程式前端資料互動，控制元件資訊提取 |
Part 1 前言
Part 2 總結思考
- 設想和目標
- 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
解決微信端上的輕便辦公，方便微信端上的辦公群體，例如共享編輯針對需要反覆審閱修改的辦公情形，以及其他環境下面向組內的通知、投票等一系列辦公需求。
- 我們達到目標了麼（原計劃的功能做到了幾個？
原計劃的功能中基本完成投票功能、物件分組，接近完成共享編輯功能，半完成通知、想法功能，未完成簽到功能。
- 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)?
使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼?我們離目標更近了麼?
距離目標我們還有一定的差距，這次的alpha未能夠達到我們原定的計劃，如上述所表述的，進度並不是令人滿意，目前所完成的效果也與前期設定的原型不論是風格上還是功能上相左，需要完善的地方有許多。
- 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
柯奇豪：前踩工作需要做好，瞭解整體專案所需要的技術、軟硬體支援，才能是後續的專案進度有條不紊。
- 計劃
- 是否有充足的時間來做計劃?
因為種種原因(考試、黨課、個人等等)，每次計劃的都不是很完美，也沒有很及時的時間去補正，後續會注意。
- 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
通過了激烈的討論，得到一個可行的方案並往這方面走。
- 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
楊禮亮：美工工作完成，輔助翔宇的工作還未完成，因為效率不高，能力不夠
丁水源：通知後端的工作完成，但是完成的速度比較慢
柯奇豪：共享編輯後期遇到許多之前沒有估計到的修改，例如儲存形式、功能增加等，所以導致沒有及時的做好，只完成了簡單的列表顯示功能。
黃毓明：投票、分組功能完成。
黃志銘：原來計劃在12月份前把所有的前端介面做完，並和後端一起完成互動，然後好好準備期末考。過程一直都以為前後端互動應該就是一兩天的時間………結果出來當面互動的時候，就發現了問題好多呀……根本不是一兩天可以完成的。
蔣熊：沒有都做完，待得不斷開發，所發現的問題也越來越多，原型UI設計不完整，頁面需求隨著開發的深入不斷上漲 有很多原型設計裡沒有的頁面需要新增。一開始定的實現邏輯隨著開發的深入也發現後端一些演算法是無法完成的，因此前端頁面需要跟進後端演算法做出調整。再而對js不熟悉，與後端對接上來不及做完，且頁面過來，也來不及對接，工作量太大。
林翔宇：沒有。臨近考試，再加上轉專業課也很多，時間難以平衡。
- 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
柯奇豪：有，花了大把的時間在ssm框架上，結果不太會用，轉用springboot+mybatis，但慶幸是能用了。
丁水源：過程中學到的東西都挺有價值的，時間花的挺值得
楊禮亮：學了很多但是都遺忘了
黃毓明：一開始寫的投票沒能融入框架，只能使用裡面的部分函式，大部分未使用
黃志銘：確實做了很多好像根本就沒有幫助的事，比如自動跳轉圖片的介面風格以及程式碼之前幾乎都是自己寫，完全可以和網上照著改一下，再完善，延長了進度
蔣熊：覺得比較沒有必要的事情就是開發前期過多的投入於邏輯設計和各自分工，浪費了很多時間大家各做各的，到最後一對接才發現對不上。
林翔宇：學些java基本語法花了很多時間，才開始寫要做的小程式。其實完全可以邊學習語法邊寫的。
- 是否每一項任務都有清楚定義和衡量的交付件?
所有人：很遺憾，沒有，許多東西都是在後續工作中不斷髮現需要修修補補的地方，許多地方沒考慮到。對於大家每個人任務的總和要達到什麼結果很模糊。
- 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
所有人：專案初期是在按預期走，但是中後期已經偏離軌道了，出現的大問題有幾個，一個是研發小組隊員退出，不是簡單的n-1問題，再一個就是前後端對接。直到現在，後端仍有三個專案未開發成功，前後端能算比較完整對接的只有投票一塊。我覺得出現這樣的問題主要是大家溝通交流不夠吧，不然也不會再最後一週才想起來要出來一起做。沒有有效的資源共享，導致每個人進度不一。
- 在計劃中有沒有留下緩衝區，緩衝區有作用麼?
所有人：有過留取一段時間進行前後互動，是為了防止前後端互動後出現重大bug，或是介面邏輯有問題等，但是每個人並沒有在這段時間前很好的將自己的任務及時完成，導致後續進展不順，所以後來的緩衝區作用不大。
- 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
柯奇豪：留出一段時間出來進行一個專案的整合，目前在過渡期內，我計劃分成兩部分人群分別負責部分功能的前後端一起完善，最後在緩衝區的時間段內整體的一個彙總，每兩天找個固定的時間段來一起程式設計。
黃志銘：接下去計劃在一週之內，儘量能與分小組同學一起出來當面做一下，完善一下專案，在做前端介面的同時，也瞭解一下後端的具體操作，更好地實現互動。
蔣熊：其他小組專案都差不多完成了，接下來我們也得加快了，明白了問題所在，就不該再繼續下去了，加班生活正式開始。
林翔宇：分配時間的時候一定要考慮仔細，不要再因為時間分配不合理，導致計劃無法完成。
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
柯奇豪：學到的就是需要在專案開展之前即蒐集足夠多的資料來對整體的專案各部分有一個明確的方向，這樣在後續的進度中就不會因為卡殼而不停的調整，初步瞭解各部分細分下來所需要的技術支援。
黃志銘：這個可以早點出來當面做一下，討論一下具體的分工以及專案願景，讓大家更熟悉自己對應的部分，提高團隊整體效率。
蔣熊：如果能夠重來，第一週我們就會抱著這樣的態度，二話不說，直接加班，擼袖子就是幹。
林翔宇：做計劃的時候一定要合理，時間很緊湊的時候要儘量提高效率。
- 資源
- 我們有足夠的資源來完成各項任務麼?
時間資源不足，基礎能力儲備不足。
- 各項任務所需的時間和其他資源是如何估計的，精度如何?
原先是按照每次部落格的提交時間為週期進行程式設計，後續可能會更加細化，因為還有許多工作需要完善。
- 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
柯奇豪：測試階段基本上部署伺服器，暫時還在前期籌措階段，待後續反饋。
- 你有沒有感到你做的事情可以讓別人來做（更有效率）?
柯奇豪：在專案的規劃上以及對任務的佈置上自己還是有缺失的，個人不怎麼善於言辭，所以在過程中表述上常常沒辦法解釋清楚，導致組員出現一頭霧水的情況，在語言溝通上可能存在障礙。如果換一個表述更清晰一點的人或許在前期可以解決目標不明確的問題。
蔣熊：我覺得換一個人做我的事情不一定會更有效率。我覺得其他人也一樣，每個人都適合自己的工作，問題始終不在個人上，而是團隊上。
林翔宇：我們組人比較少，大家任務都很重，所以自己的部分還是自己努力做好吧。
- 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
技術資源共享不夠，如果重來或許可以借鑑其他組的思路，程式設計過程裡也整理問題及解決辦法，整合一份技術指南來便於小組開發。要注意隊內的溝通交流，一定要留好十分足夠的緩衝時間。
- 變更管理
- 每個相關的員工都及時知道了變更的訊息?
會有訊息延遲的情況，部分時候會耽誤進度，後續可能採用固定時間段來集體完成並彙總提交。
- 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
按照部落格提交的進度進行，但是發現不能很好的既定目標相符，需要調整一個合理的辦法，可能會增加組內的進度deadline。
- 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
暫時沒有考慮到這個問題，後續以真機測試為準。
- 對於可能的變更是否能制定應急計劃?
目前沒有
- 員工是否能夠有效地處理意料之外的工作請求？
基於每個人的水平，部分成員沒辦法做到
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
柯奇豪：deadline與驗收標準的確定需要完善，缺少壓力的團隊往往就會導致專案的短期擱淺，自己也需要學會對隊員有更高的要求與督促。
黃毓明：學到了很多東西，Java的springboot+mybatis框架使用，微信小程式前端開發，以及一些web服務的相關，如果可以重來的話，不應將時間都浪費在一個框架上，提前做好任務分配也許會更好
丁水源：如果歷史重來一次，我將會盡早的做規劃，儘量早地完成任務。
蔣熊：如果歷史重來，一定會先集中力量開發核心功能 先完成專案主模組。
林翔宇：當進度跟不上原先計劃時，要趕緊調整，反思原因。
- 設計/實現
- 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
在專案的初期由組內共同討論完成，是的。
- 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
原先在部分的功能上有歧義，基本通過各自表述自己的看法然後大家共同決定通過。
- 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？
主要使用processon、leangoo來對專案細則有一定的說明。
- 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
存在比較大的差異，是原先組內沒考慮到的，主要原因在於專案開發經驗不足，沒有細化到許多具體的地方，後續有時間會對之前的UML文件進行修正。
- 什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
框架的使用上遇到較多的bug，因為原先並沒有考慮到會用框架，也是第一次嘗試使用。
- 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
暫時沒有程式碼的複審，後續做完會對程式碼的命名規範、註釋、專案具體的佈局做一定的修改。
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
柯奇豪：規劃上雖然沒辦法一開始就做到盡善盡美，但在後續的程序中，還是需要安排適當足夠的時間去做好這塊內容
- 測試/釋出
- 團隊是否有一個測試計劃？為什麼沒有？
暫時沒有，因為基礎性的開發並沒有及時完成，但是在後續會有一個測試版本階段。
- 是否進行了正式的驗收測試？
目前還沒有
- 團隊是否有測試工具來幫助測試？
沒有具體的規劃，後續會去請教一下其他組給出方案。
- 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
暫未進行，設定的目標是想在周圍人群中進行一次推廣調查，然後收集意見酌情修改完善。
- 在釋出的過程中發現了哪些意外問題？
產品暫未釋出，還未遇到問題。
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
柯奇豪：有一個合理夠用的測試可以簡化專案後續的工作，減少bug的出現，儘可能考慮情況解決缺漏
- 團隊的角色，管理，合作
- 團隊的每個角色是如何確定的，是不是人盡其才？
按自己的意願進行職能的分配，基本上算是人盡其才，但還是存在部分成員存在空窗期的情況，例如在原型設計階段部分前後端不知所措，以及後續前後開發過程中美工人員的不知所措等。
- 團隊成員之間有互相幫助麼？
柯奇豪：團隊成員在瞭解框架、具體程式設計等的過程中，基本上都是採取互幫互助的形式進行學習，相互指教的。
丁水源：有相互幫助，比如我就會去請教同伴黃毓明不懂的問題。
- 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的部落格裡）：
柯奇豪：在此感謝一下 ++毓明++ ， 因為 ++自己本身不太善於言辭，僅僅只是自己會使用、程式設計，但經常給其他人解釋不清，毓明則能很好的幫我與其餘的人溝通，指導他們框架搭建，這是我未能做到的++。
黃毓明：在alpha版本中交流較少，基本上都是各做各的，出現問題也基本上是自己埋著頭解決
丁水源：我感謝黃毓明對我的幫助，因為當我在理解Spring Boot框架時遇到一些問題，詢問他，他能十分耐心地給我講解。
蔣熊：我感謝全組的人對我的幫助，因為某個具體的事情：其實不論是前期工作分配的不合理，還是大家後來學習程度不夠，問題已經發生了 現在大家都願意投身其中，我們之間互幫互助，其實就很值得感恩。
林翔宇：我感謝黃毓明對我的幫助， 因為某個具體的事情: 耐心的幫我配置好開發環境，並教我怎麼使用spring boot框架。
- 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
柯奇豪：一個團隊最不能缺少的，就是團結一致為共同目標而共同奉獻自我的決心，少一點藉口，多做一點實事才是。帶領隊員一同進步的工作並沒有想象中的簡單，需要負責的地方有太多太多，對pm的責任多了一份敬重。還有就是努力改善自己的表述方式吧。如果重來，以上都是我會改進的地方。
黃毓明：硬要說學到了什麼，只能說獨立解決問題的能力變強了吧。如果歷史重來，或許更多的交流會是比埋頭苦幹更好的選擇
丁水源：如果歷史重來一遍，我會提前學習好專案所需的框架，以及更早地學習java語言，更早的瞭解一個產品的研發過程。
蔣熊：如果歷史重來，學會感恩吧，每個人都不推卸責任，互幫互助。
林翔宇：在團隊合作中，只有大家都盡責，才能一起完成好任務。單靠一兩個人是不夠的
- 總結:
- 你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
柯奇豪：我覺得目前團隊還處於可重複級階段。
蔣熊：我覺得目前團隊處於可重複級向已定義級過渡的階段吧
- 你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
柯奇豪：我覺得團隊暫時處於磨合階段，資訊與進度的不同步是目前遇到的最大問題。
丁水源：我覺得團隊目前處於“規範”的階段。
蔣熊：應該是磨合階段，原先比較鬆散，直至這一次問題出現，促進了我們的磨合
- 你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?
柯奇豪：更加的瞭解了軟解開發流程，逐漸提高了程式設計能力，學習的語言與技能都有很大程度的提升，整個團隊的合作觀念漸長。
黃毓明：任務分工更加明確，目標更清晰，協作能力正在加強
丁水源：我覺得團隊相比於前一個里程碑而言，隊友們更加團結，更加明確了專案的方向，更有專案經驗了。
蔣熊：改進就是學會去發現問題和解決問題了，而不是順其自然
林翔宇：大家都比較熟悉了，溝通起來也越來越順暢
- 你覺得目前最需要改進的一個方面是什麼?
柯奇豪：目前最需要改進的方面就是組內的責任意識，也希望後續大家能夠共同努力，齊心協力共同開發出能讓我們自己滿意的小程式來。
黃毓明：程式碼規範
丁水源：我覺得團隊目前最需要改進的地方時“deadline拖延症”，不要把所有事情都拖到後期才完成。
蔣熊：最需要改進的就是分工合作，在原來的基礎上重新分工，創新合作。
林翔宇：可能溝通還是要增強，大家進度要及時反饋
- 對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
柯奇豪：面對面交談原則：其中的站立會議以及leangoo進度的監督作用還是很顯而易見的。
丁水源：我覺得我們小組做得最好的是"每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。"原則，比如：其實隊員們都不是很熟悉java和Spring Boot框架，同時大部分人也沒有專案的經驗，因此在研發過程當中遇到了許多技術上的問題，我們便會常常開會，相互交流，一起解決問題。從而對各自的下一階段的工作進行適當調整。
- 部落格要附上全組討論的照片
Part 3.答辯總結
| 姓名 | 得分（百分制比例%） |
|---|---|
| 柯奇豪 | 22 |
| 蔣雄 | 11 |
| 黃志銘 | 11 |
| 黃毓明 | 24 |
| 林翔宇 | 9 |
| 丁水源 | 10 |
| 楊禮亮 | 13 |
評審表格設計
Final Score：
| 小組 | 評分 |
|---|---|
| 第一組 | 53 |
| 第二組 | 75 |
| 第三組 | 73 |
| 第四組 | 45 |
| 第五組 | 70 |
| 第六組 | 77 |
| 第七組 | 68 |
| 第八組 | 76 |
| 第九組 | 62 |
| 最低分 | 77（第六組） |
| 最高分 | 45（第四組） |
| 有效分數 | 53，75，73，70，68，76，62 |
| 最終平均得分 | 68 |
Q&A
- 第一組的問題
Q1:是否考慮在beta和alpha這段期間繼續完成alpha未完成的任務?
A1: 當然會接著完成未完成的任務，我們在beta階段來臨之前盡力完成alpha階段落下的工作量。
Q2:組內前後端的任務分配似乎存在問題,有考慮相應的解決對策嗎?
A2: 前後端在人手分配上確實是存在著問題，導致現在前端需要的工作量太大，現在我們調整了策略，每個前端負責各自部分工作外再完成各種部分前端的程式碼。
Q3:是否考慮過高併發場景下的伺服器表現？
A3: 這個問題目前沒有考慮過，因為有些功能還沒有完成，不過考慮到各個小組內部的資料量並不會過大，而且伺服器的表現如何還和價格成正比，這方面目前不會去深究。
- 第二組的問題
Q1:簽到功能是否會被虛擬定位而進行不正確位置的簽到？
A1: 因為簽到功能的人手缺失，暫時延後開發，該問題其實之前有回答過，就是輔助加上ip地址的限制
Q2:PPT中的指定wifi簽到是什麼意思？
A2: 即通過連入wifi所分配的ip地址限制簽到
Q3:如果成員沒有開啟小程式，是否會提醒釋出的通知或者被邀請進的投票？
A3:可以做到的話會加入提醒的彈窗，配合已有的通知功能
- 第四組的問題
Q1:未提問
A1:
Q2:未提問
A2:
Q3: 未提問
A3:
- 第五組的問題
Q1:有沒有考慮美化一下介面，或則說換一個介面風格？
A1:
Q2:隊友退出沒留下任何程式碼，可以理解為該隊員沒有寫過程式碼嗎
A2: 。
Q3:共享編輯是你們的主要功能，為什麼在前端方面需要三十多個頁面呢？
A3:
- 第六組的問題
Q1:在隊友退出的情況下，你們組是怎樣調整分工的？
A1: 隊友退出，對應負責的功能目前我們是採用大家一起做，先做完對應功能的同學來負責
Q2:在後續的作業中有沒有想要採取哪種方法來避免程式碼丟失的情況？
A2: 對於程式碼丟失這個問題，我們目前程式碼是進行一更新一github的方法，及時對程式碼進行更新，以避免丟失
Q3:前端在頁面較多的情況下，有考慮什麼方法來使頁面更加方便自己製作來減輕壓力？
A3: 我們目前調整了工作方式，由對應功能的前端和後端一起負責該功能，一方面減小前端壓力，另一方面提高專案整體可行性。
- 第七組的問題
Q1:投票功能裡小組選擇，小組是指微信群聊嗎？如果是的話，即使該群聊不在通訊錄裡面，也能檢測到嗎？
A1: 小組是事先建好的工作小組，組別id是存在後端的，不是微信小組。發起人可建立小組，後來的人憑連結加入。
Q2:共享編輯，別人編輯的時候，是整篇編輯，還是隻能一次編輯一段？如果是整篇編輯，合併的時候只想合併某幾段，不想全部替換，要怎麼做？
A2: 對已釋出文章按段處理，會顯示更改日誌，不用改全篇。
Q3:現階段開發進度未涉及到核心，為什麼不優先開發核心功能。
A3: 核心功能其實也已經實現的差不多了，只是前後端未對接，演算法已經OK了。
- 第八組的問題
Q1:團隊分工有沒有值得總結的地方？可以分享下
A1:
Q2:對alpha版本的完成度如何自我評價？吸引
A2: