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架構，同時大部分人也沒有項目的經驗，是以在研發過程當中遇到了許多技術上的問題，我們便會常常開會，互相交流，一起解決問題。進而對各自的下一階段的工作進行适當調整。
- 部落格要附上全組讨論的照片
Alpha 事後諸葛亮
Part 3.答辯總結
| 姓名 | 得分（百分制比例%） |
|---|---|
| 柯奇豪 | 22 |
| 蔣雄 | 11 |
| 黃志銘 | |
| 黃毓明 | 24 |
| 林翔宇 | 9 |
| 丁水源 | 10 |
| 楊禮亮 | 13 |
評審表格設計
Final Score：
| 小組 | 評分 |
|---|---|
| 第一組 | 53 |
| 第二組 | 75 |
| 第三組 | 73 |
| 第四組 | 45 |
| 第五組 | 70 |
| 第六組 | 77 |
| 第七組 | 68 |
| 第八組 | 76 |
| 第九組 | 62 |
| 最低分 | 45（第四組） |
| 最高分 | 77（第六組） |
| 有效分數 | 53，75，73，70，68，76，62 |
| 最終平均得分 |
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: 我覺得我們的界面風格是可以的，簡潔大方，符合辦公小程式的風格，後續會在beta版本考慮進一步美化界面
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 | · 估計這個任務需要多少時間 | ||
| Development | 開發 | ||
| · Analysis | · 需求分析 (包括學習新技術) | ||
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計複審 (和同僚稽核設計文檔) | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | ||
| · Coding | · 具體編碼 | 100 | 120 |
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | 20 | |
| Reporting | 報告 | ||
| · Test Report | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | ||
| 合計 | 180 | 190 |
- 個人學習進度條（每周追加）
| 第N周 | 新增代碼（行） | 累計代碼（行） | 本周學習耗時(小時) | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| N | 97 | 微信小程式前端資料互動，控件資訊提取 |