Information：
組長連結
作業連結
Thinking：
- 設想和目标
- 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
解決微信端上的輕便辦公，友善微信端上的辦公群體，例如共享編輯針對需要反複審閱修改的辦公情形，以及其他環境下面向組内的通知、投票等一系列辦公需求。
- 我們達到目标了麼（原計劃的功能做到了幾個？
原計劃的功能中基本完成投票功能、對象分組，接近完成共享編輯功能，半完成通知、想法功能，未完成簽到功能。
-
按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)?
使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼?我們離目标更近了麼?
距離目标我們還有一定的差距，這次的alpha未能夠達到我們原定的計劃，如上述所表述的，進度并不是令人滿意，目前所完成的效果也與前期設定的原型不論是風格上還是功能上相左，需要完善的地方有許多。
- 有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
柯奇豪：前踩工作需要做好，了解整體項目所需要的技術、軟硬體支援，才能是後續的項目進度有條不紊。
- 計劃
- 是否有充足的時間來做計劃?
因為種種原因(考試、黨課、個人等等)，每次計劃的都不是很完美，也沒有很及時的時間去補正，後續會注意。
- 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
通過了激烈的讨論，得到一個可行的方案并往這方面走。
- 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
楊禮亮：美工工作完成，輔助翔宇的工作還未完成，因為效率不高，能力不夠
丁水源：通知後端的工作完成，但是完成的速度比較慢
柯奇豪：共享編輯後期遇到許多之前沒有估計到的修改，例如存儲形式、功能增加等，是以導緻沒有及時的做好，隻完成了簡單的清單顯示功能。
黃毓明：投票、分組功能完成。
- 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
柯奇豪：有，花了大把的時間在ssm架構上，結果不太會用，轉用springboot+mybatis，但慶幸是能用了。
丁水源：過程中學到的東西都挺有價值的，時間花的挺值得
楊禮亮：學了很多但是都遺忘了
黃毓明：一開始寫的投票沒能融入架構，隻能使用裡面的部分函數，大部分未使用
- 是否每一項任務都有清楚定義和衡量的傳遞件?
所有人：很遺憾，沒有，許多東西都是在後續工作中不斷發現需要修修補補的地方，許多地方沒考慮到。
- 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
所有人：沒有固定的計劃，過程中遇到同伴的退出，沒有有效的資源共享，導緻每個人進度不一，許多人很無措。
- 在計劃中有沒有留下緩沖區，緩沖區有作用麼?
所有人：有過留取一段時間進行前後互動，但是每個人并沒有在這段時間前很好的将自己的任務及時完成，導緻後續進展不順，是以後來的緩沖區作用不大。
- 将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
柯奇豪：留出一段時間出來進行一個項目的整合，目前在過渡期内，我計劃分成兩部分人群分别負責部分功能的前後端一起完善，最後在緩沖區的時間段内整體的一個彙總，每兩天找個固定的時間段來一起程式設計。
- 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
柯奇豪：學到的就是需要在項目開展之前即搜集足夠多的資料來對整體的項目各部分有一個明确的方向，這樣在後續的進度中就不會因為卡殼而不停的調整，初步了解各部分細分下來所需要的技術支援。
- 資源
- 我們有足夠的資源來完成各項任務麼?
時間資源不足，基礎能力儲備不足。
- 各項任務所需的時間和其他資源是如何估計的，精度如何?
原先是按照每次部落格的送出時間為周期進行程式設計，後續可能會更加細化，因為還有許多工作需要完善。
- 測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
柯奇豪：測試階段基本上部署伺服器，暫時還在前期籌措階段，待後續回報。
- 你有沒有感到你做的事情可以讓别人來做（更有效率）?
在項目的規劃上以及對任務的布置上自己還是有缺失的，個人不怎麼善于言辭，是以在過程中表述上常常沒辦法解釋清楚，導緻組員出現一頭霧水的情況，在語言溝通上可能存在障礙。
技術資源共享不夠，如果重來或許可以借鑒其他組的思路，程式設計過程裡也整理問題及解決辦法，整合一份技術指南來便于小組開發。
- 變更管理
- 每個相關的員工都及時知道了變更的消息?
會有消息延遲的情況，部分時候會耽誤進度，後續可能采用固定時間段來集體完成并彙總送出。
- 我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
按照部落格送出的進度進行，但是發現不能很好的既定目标相符，需要調整一個合理的辦法，可能會增加組内的進度deadline。
- 項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
暫時沒有考慮到這個問題，後續以真機測試為準。
- 對于可能的變更是否能制定應急計劃?
目前沒有
- 員工是否能夠有效地處理意料之外的工作請求？
基于每個人的水準，部分成員沒辦法做到
deadline與驗收标準的确定需要完善，缺少壓力的團隊往往就會導緻項目的短期擱淺，自己也需要學會對隊員有更高的要求與督促。
- 設計/實作
- 設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
在項目的初期由組内共同讨論完成，是的。
- 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
原先在部分的功能上有歧義，基本通過各自表述自己的看法然後大家共同決定通過。
- 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？
主要使用processon、leangoo來對項目細則有一定的說明。
- 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
存在比較大的差異，是原先組内沒考慮到的，主要原因在于項目開發經驗不足，沒有細化到許多具體的地方，後續有時間會對之前的UML文檔進行修正。
- 什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
架構的使用上遇到較多的bug，因為原先并沒有考慮到會用架構，也是第一次嘗試使用。
- 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
暫時沒有代碼的複審，後續做完會對代碼的命名規範、注釋、項目具體的布局做一定的修改。
規劃上雖然沒辦法一開始就做到盡善盡美，但在後續的程序中，還是需要安排适當足夠的時間去做好這塊内容
- 測試/釋出
- 團隊是否有一個測試計劃？為什麼沒有？
暫時沒有，因為基礎性的開發并沒有及時完成，但是在後續會有一個測試版本階段。
- 是否進行了正式的驗收測試？
目前還沒有
- 團隊是否有測試工具來幫助測試？
沒有具體的規劃，後續會去請教一下其他組給出方案。
- 團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
暫未進行，設定的目标是想在周圍人群中進行一次推廣調查，然後收集意見酌情修改完善。
- 在釋出的過程中發現了哪些意外問題？
産品暫未釋出，還未遇到問題。
柯奇豪：有一個合理夠用的測試可以簡化項目後續的工作，減少bug的出現，盡可能考慮情況解決缺漏
- 團隊的角色，管理，合作
- 團隊的每個角色是如何确定的，是不是人盡其才？
按自己的意願進行職能的配置設定，基本上算是人盡其才，但還是存在部分成員存在空窗期的情況，例如在原型設計階段部分前後端不知所措，以及後續前後開發過程中美勞工員的不知所措等。
- 團隊成員之間有互相幫助麼？
柯奇豪：團隊成員在了解架構、具體程式設計等的過程中，基本上都是采取互幫互助的形式進行學習，互相指教的。
-
當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
每個成員明确公開地表示對成員幫助的感謝 （并且寫在各自的部落格裡）：
柯奇豪：我感謝 ++毓明++ 對我的幫助， 因為某個具體的事情: ++自己本身不太善于言辭，僅僅隻是自己會使用、程式設計，但經常給其他人解釋不清，毓明則能很好的幫我與其餘的人溝通，指導他們架構搭建，這是我未能做到的++。
柯奇豪：一個團隊最不能缺少的，就是團結一緻為共同目标而共同奉獻自我的決心，少一點借口，多做一點實事才是。帶領隊員一同進步的工作并沒有想象中的簡單，需要負責的地方有太多太多，對pm的責任多了一份敬重。還有就是努力改善自己的表述方式吧。
- 總結:
- 你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
柯奇豪：我覺得目前團隊還處于可重複級階段。
- 你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
柯奇豪：我覺得團隊暫時處于磨合階段，資訊與進度的不同步是目前遇到的最大問題。
- 你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
柯奇豪：更加的了解了軟解開發流程，逐漸提高了程式設計能力，學習的語言與技能都有很大程度的提升，整個團隊的合作觀念漸長。
- 你覺得目前最需要改進的一個方面是什麼?
柯奇豪：目前最需要改進的方面就是組内的責任意識，也希望後續大家能夠共同努力，齊心協力共同開發出能讓我們自己滿意的小程式來。
- 對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
柯奇豪：面對面交談原則：其中的站立會議以及leangoo進度的監督作用還是很顯而易見的。
- 部落格要附上全組讨論的照片
福大軟工 · 第十一次作業 - Alpha 事後諸葛亮（團隊）
Summary ：
| 姓名 | 得分（百分制比例%） |
|---|---|
| 柯奇豪 | 22 |
| 蔣雄 | 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 |
| 最終平均得分 |
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。
PSP Table：
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 20 | |
| · Estimate | · 估計這個任務需要多少時間 | ||
| Development | 開發 | 460 | 500 |
| · Analysis | · 需求分析 (包括學習新技術) | 40 | 50 |
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計複審 | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 30 | |
| · Coding | · 具體編碼 | 400 | 280 |
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | 100 | |
| Reporting | 報告 | ||
| · Test Repor | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | ||
| 合計 | 520 | 570 |
Schedule：
| 第N周 | 新增代碼（行） | 累計代碼（行） | 本周學習耗時(小時) | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| 1 | 15 | 學習VS2017，GitHub使用，複習C++相關知識 | |||
| 2 | 500 | 1000 | 35 | 閱讀《建構之法》，從零開始學Java語言 | |
| 3 | 2000 | 15 | 50 | 閱讀《建構之法》，學習Java，學習墨刀等工具使用 | |
| 4 | 700 | 2700 | 85 | 複習C++知識，學習STL的使用。 | |
| 5 | 300 | 3000 | 105 | 學習STL相關知識，以及使用VS，Process On 等工具 | |
| 6 | 140 | 學會如何設計軟體的相關細節。 | |||
| 170 | 學會如何寫一份完整的“需求分析報告”。 | ||||
| 190 | 入門java，學會分析任務 | ||||
| 7 | 205 | 熟悉了本軟體的架構，為接下來的代碼做好準備。 | |||
| 8 | 3050 | 12 | 217 | 熟悉了ssm架構、Java語言 | |
| 8 | 250 | 3300 | 220 | 熟悉了軟體開發過程、java語言 | |
| 200 | 3500 | 227 | 學會如何用Java實作軟體的某些架構和功能子產品。 | ||
| 3750 | 232 | 入門springroot | |||
| 4050 | 252 | 熟悉springboot，學會搭建架構，Java更加熟練，對架構更加熟悉 | |||
| 4450 | 272 | 熟悉java和Spring boot架構，對軟體項目的搭建流程更加熟悉。 | |||
| 4750 | 287 | 熟悉任務架構，java語言，架構。 | |||
| 4850 | 297 | 熟悉springboot，學會搭建架構，熟悉JavaScript。 | |||
| 5050 | 302 | 熟悉Springboot架構，明白架構的含義架構。 |