Alpha版本過後諸葛亮

目錄

• 設想和目標
• 計劃
• 資源
• 變動管理
• 設計/實現
  • 測試/發佈
  • 團隊的角色，管理，合做
• 總結:
• 本小組和其餘組的評分
• 分工和貢獻分
• 全組討論的照片
• 問題
  • 第一組提問回答：爸爸餓了隊
  • 第二組提問回答：拖鞋旅遊隊
  • 第三組提問回答：很行隊
  • 第四組提問回答：火箭少男隊
  • 第五組提問回答：起牀一塊兒肝活隊
  • 第七組提問回答：第三視角隊
  • 第八組提問回答：小白吃隊
  • 第九組提問回答：個人頭髮呢隊
• 我的PSP
• 我的學習進度條

組長博客連接：http://www.javashuo.com/article/p-buzkaxpo-gk.html

設想和目標

1.咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

• 咱們軟件解決的問題是：人們平常並行事項愈來愈多，而人的記憶是有限的，咱們的記憶罐頭這款
  備忘錄能夠有效的提醒和安排平常事務，而且提供衆多便捷、智能、實用的功能。

• 已經定義的十分清楚。（詳情可參見需求分析報告）

• 典型用戶爲：學生黨和工做黨。（在需求分析課堂展現中已有描述。）

• 典型場景：佩佩和小柯的故事。（在需求分析課堂展現中已有描述。）

2.咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？)

• 已達到目標，原計劃功能已完成6個：備忘錄的基礎使用、天氣分析、智能提醒、App使用分析、語音輸入、智能識別短信。剩下1個需在Beta版本完成：造成語音輸入小浮標。

• 在Alpha版本規定時間完成交付。並進行Alpha版本課堂展現。

3.原計劃達到的用戶數量達到了麼?

• 原定計劃中未對用戶數量作出明肯定義。用戶量還須要在Beta版本完成以後進行推廣獲取。

4.用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?

• 暫時還未進行推廣，所以尚未用戶量。離目標更近一步。

5.有什麼經驗教訓? 若是歷史重來一遍,咱們會作什麼改進?

• 應該在開始的時候目標定得更明確一些。若是重來一遍的話，咱們會加上對後期用戶量的明確目標以及設想的更加細緻。

計劃

你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

• 在alpha版本的原計劃的數據庫初始化和接口的實現任務最後都完成了，剩下的是beta版本的用戶登入和雲端備份的實現；原計劃的前端功能都已經實現，如今缺乏的是頁面的精修，在美觀上還須要改進。

有沒有發現你作了一些過後看來不必或沒多大價值的事?

• 在android stdio的下載上花費了很長時間，至少有兩天，出現各類問題。以及在代碼整合的過程當中，出現有些人代碼能夠運行，可是有些不能運行的狀況。在軟件的問題上出現不少錯，可是有很費時。項目初始計劃是作服務器上的數據庫和接口，可是這樣會致使手機在沒有網絡的狀況之下，加載不出數據，整個軟件會處於不能使用的狀態，這和咱們這樣一個備忘錄app的用戶使用場景出入很大。發現問題以後決定將數據庫部署在本地。還有就是接口設計的時候，其實有些功能前端能夠直接實現的，不須要對應的接口，經常設計出前端不須要的接口；

是否每一項任務都有清楚定義和衡量的交付件?

• 在後端部分，數據庫和接口的設計咱們是有在需求文檔中作了詳細的規劃，根據軟件的原型和需求，規範地設計數據庫和細緻地設計接口的，數據庫表結構和接口需求明確以後才進行的代碼實現，因此在於整個項目的開發中，任務和進度是很精確的，也提供測試樣例做爲參考。

是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?

• 後端部分，是先根據原型和需求，數據庫表結構和接口需求明確以後才進行的代碼實現的，按照文檔一步步實現的，期間因爲對java和AndroidStudio開發的不熟悉，有時在數據庫初始化和sql語句上出現問題；風險的話由於作的功能是相對簡單和基礎的部分，可能在安全係數和數據庫版本升級的部分沒有作的詳盡；對於未來服務器安所有分會考慮增強安全性的途徑；

在計劃中有沒有留下緩衝區，緩衝區有做用麼?
未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

• 計劃的實施都是在你們都有空的時候，一塊兒進行的。各自在平時有空的時候自行學習和code，也會互相分享經驗，任務完成的也相對高效緊湊，沒怎麼須要加班；一塊兒code的時候，通常都是任務完成到預期進度才各回各家；未來的計劃，我以爲這種狀態挺不錯的（畢竟你們有不一樣的課業須要兼顧），可能會多一項在固定時間互相交流學習內容和實現思路，這樣對接下來計劃的實現思路會更加明確；不過在天天的任務中不免存在難度沒法作完的狀況，咱們會選擇熬夜完成項目。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

• 對於後端能實現來講，因爲第一次作，對於任務量的不熟悉，在分配任務的以後，會致使有的成員每天埋頭苦幹，有的則無所事事，還有就是不一樣成員在學習重複的知識，這樣使任務的完成度良莠不齊，也下降效率；若是歷史重來一遍，會對任務進行詳盡的分析，明確技術難點和工做量，而後進行任務分派，在提升效率上應該會有所成效；同時，咱們可能會選擇多增長代碼規範性的瞭解，在頁面的設計上也會稍加改進。

資源

咱們有足夠的資源來完成各項任務麼?

• 有足夠的資源來完成各項任務。團隊人才輩出。

各項任務所需的時間和其餘資源是如何估計的，精度如何?

• 各項任務所需時間及其餘資源是詢問前輩的經驗以及在開發過程當中不斷更新考量估計的，精度不太準確，出現超時完成任務的狀況。

測試的時間，人力和軟件/硬件資源是否足夠?對於那些不須要編程的資源 (美工設計/文案)是否低估難度?

• 並未低估文案和美工設計的難度，在最開始的時候便分配了專員負責這兩個模塊。測試時間安排不太合理，暫未分配測試時間。

你有沒有感到你作的事情可讓別人來作（更有效率）?

• 我以爲我作的事情，讓一個心思縝密的組員都能作的不錯。

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

• 分配任務的時候會對任務進行詳盡的分析，明確技術難點和工做量，而後進行任務分派，可以讓你們都輕鬆高效的完成項目

變動管理

每一個相關的員工都及時知道了變動的消息?

• 若是有變動的消息的話，員工們都能從員工羣裏面獲取實時的變動消息，此外在相關員工的小組羣裏面也會有變動消息的提醒，這樣保證了每一個相關的員工都可以及時知道變動的消息。

咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

• 在項目初期，員工們對於本身負責部分的功能有粗淺瞭解以後，員工們根據功能的實現難度判斷功能屬於「推遲」或「必須實現」的功能，而後在開會期間提出該議題（若無提出，默認「必須實現」），通過討論（參照功能是否爲必須實現的主要功能、關鍵功能）後，採起集體投票的方式最終決定該功能屬於「推遲」或「必須實現」的功能！

項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?

• 對於咱們的項目，咱們首先規定了一些基本功能，在最後完工時，這些基本功能就是咱們的項目的出口條件。

對於可能的變動是否能制定應急計劃?

• 是的！俗話說計劃趕不上變化，我要以不變應萬變，根據本身所學的和所看的書結合實際狀況，作出判斷。接着進行羅列出可行的計劃，而後進行選擇，選出比較好的幾個應急計劃，再對各個計劃、各類方案的優缺點以及成本進行篩選。

員工是否可以有效地處理意料以外的工做請求？

• 咱們的員工在收到意料以外的工做請求時，會先確認其來源的需求，在確認無誤並無異議的狀況下，可以合理協調本身的安排以知足目前的整體需求。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

• 首先，每一個員工在技術知識方面都或多或少有所收穫，或是前端頁面方面、或是後端接口編寫方面等，此外咱們的每一個員工都對一個app的開發流程有了必定的瞭解，而不是負責某一部分就只瞭解該部分的內容；其次，咱們積累了一些開發經驗，在某些問題的解決上有了解決方法；此外，咱們還認識到了軟件開發團隊中員工之間的團結協做和交流溝通是十分重要的，若是一個團隊可以團結協做並積極地交流溝通，那麼這個團隊的狀態是健康積極的，軟件的開發便能順利愉悅地進行，相反地，若是一個團隊有大大小小的各類矛盾，那麼這個團隊的狀態是不健康的，甚至極可能影響到軟件開發的進度。若是歷史重來一遍，咱們會請教有過項目開發經驗的學長或學姐更具體的開發流程細節，更好更快地完成咱們項目的分工部分，爲開發過程當中的「bug」留下更充足的時間；其次，咱們會更加註重開發的「規範化」，好比每兩天寫學習總結，將開發過程當中遇到的問題的可行解決方法寫成技術文檔等；此外，咱們會在團隊成員之間的團結協做和積極交流方面作得更好！

設計/實現

設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

• 原型的設計工做是卉卉作的，以後迭代是丹丹完成的。原型的設計工做在團隊選題報告以後從新設計的，一方面讓新隊員卉卉熟悉了咱們的項目，咱們認爲讓她來作是比較合適的。（卉：界面醜實際上是個人鍋orz）

• 數據庫和接口的設計是由後端部分的家燦和卉卉在選題報告以後一塊兒討論完成的。

設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

• 負責的原型設計的同窗在羣裏發佈了不少版本，其餘組員也提了許多意見，最終肯定了最終版本。

• 後端的設計工做在後面的代碼實施階段遇到了一些分歧，也是經過後端組內討論解決的。

團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？

• 後端是在Androidstudio裏進行的單元測試，後端同窗表示Androidstudio自帶的測試環境比較方便也挺好用的。

比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

• 差距仍是比較大的，區別是在開發過程當中發現UML文檔的東西不適應項目的開發，須要改變。須要更新UML文檔以適應。

什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

• 基礎功能中的備忘錄展現，由於對android開發不熟悉，自定義控件的使用不熟悉，致使書寫的過程出現不少問題。發佈以後，語音插入以後完成時間是已過時，刪除功能不完善。開發的時候由於alpha版本時間有點趕，未進行完整的測試。

代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

• 無，並未嚴格執行代碼規範。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

• 學到了如何開發一個項目的所有流程，以及如何有效的分工。同時，每一個組員對先後端的交接有了完整的理解。若是歷史能重來，咱們會在一開始就進行代碼規範，以及代碼複審，這纔是軟工實踐的最大意義。以及合併時採用GitHub，讓合併更加高效。

測試/發佈

團隊是否有一個測試計劃？爲何沒有？

• 測試計劃分爲四個方面：

1. 測試壁紙是否能夠自動生成
   可自助選擇壁紙格式，字號大小，字號顏色，自動生成桌面壁紙
2. 測試快遞，車票信息是否能夠自動生成
   接受車票，快遞信息，生成備忘信息
3. 測試是否能夠新建備忘信息
4. 測試語音轉文字功能
5. 測試刪除選中功能
6. 測試反饋功能
7. 測試桌面控件功能
   在測試過程當中，及時消除bug和解決軟件閃退問題。

是否進行了正式的驗收測試？

• app在桌面可安全開啓，並完成測試計劃提到全部功能，有視頻展現。

團隊是否有測試工具來幫助測試？

• 測試計劃分爲前端，後端兩個部分。
  前端測試利用Android studio進行build，build成功後按三角運行按鈕，電腦與安卓機利用數據線相連，授予USB訪問權限，運行成功後，創做界面會在安卓機自動顯現。
  後端利用Android studio裏的junit進行測試，測試失敗會顯示錯誤。

團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？

• 咱們的後端已經寫了一份單元測試來進行測量並跟蹤軟件的效能。從實際運行結果來看，這些測試工做是很是有用的。咱們應該適當地豐富測試文件的內容。

在發佈的過程當中發現了哪些意外問題？

• 因爲咱們在打包APK的過程當中，想要將全部的部分調整到最好，致使沒有將APK打包好。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

• 咱們對前端，後端的部分從一無所知或者只知道大概，到對整個開發流程和APP有了很詳細的瞭解。而且明白瞭如何融入一個團隊中，將團隊變得更好。
  咱們會對隊員分工進行更詳細得調整，將全部人都加入到開發工做的熱情中。

團隊的角色，管理，合做

團隊的每一個角色是如何肯定的，是否是人盡其才？

• 角色是在先自由選擇以後再由pm進行分工。儘可能按照你們熟悉的且有意向的角色進行分配。整體上作到了人盡其才。

團隊成員之間有互相幫助麼？
當出現項目管理、合做方面的問題時，團隊成員如何解決問題？

• 互相幫助是確定存在的，常常面對面互相交流的時候就須要互相幫助，好比前端就是前端小組長
  和pm比較熟悉一些幫助另外兩位隊友。

每一個成員明確公開地表示對成員幫助的感謝：

我感謝一好對個人幫助， 由於在合併語音輸入和主頁面的功能的時候出現了bug，咱們找了很
久沒有解決，最後是一好回宿舍以後解決的。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

• 鴻傑
  大部分時候你要作的功能網絡上並無完整的代碼能夠「搬運」，須要你看懂網上的代碼，而後根據你的功能需求本身修改代碼（這步驟能夠藉助相關的開發文檔）；
  若是歷史重來一遍，咱們會在分工在作的更好，合理分配人力資源到各個部分。

• 家燦
  分配任務的時候會對任務進行詳盡的分析，明確技術難點和工做量，而後進行任務分派，可以讓你們都輕鬆高效的完成項目

• 一好
  若是能重來一遍，我會對不一樣廠家的語音轉文字API進行測試，選擇最優秀的API加入到咱們的APP中。我還會在Alpha版本開發時，調整本身的時間安排，完成屬於本身的全部任務。

• 卉卉
  雲端本地要同時進行orz

• 政演
  提早考慮應用一些前沿的技術，增長亮點

• 青元
  對任務的分配須要更加詳細，學習的時間分配須要更多一點。若是重來，會增長更多的學習時間。

• 丹丹
  我在這門項目裏確實學到了不少東西，對視頻剪輯軟件有掌握，在後面也有接觸到前端學習。
  教訓就是必定要下一個下一個正規的剪輯軟件。前期由於電腦和安裝軟件不正規，致使電腦真的變得很卡。
  重來一遍的話，我必定會更加認真的完成這份工做，更加珍惜現有的資源，好好學習前端。

• 家偉
  相比於一步步按源碼用到的知識片面學習Android知識，先系統的學習Android基礎知識會對在app中實現功能有很大的幫助。
  重來一遍的話，我將前期的任務設爲系統地學習Android基礎。

• 宇恆
  若是歷史重來一遍, 咱們會作什麼改進? 答：在時間安排上過於集中，若是再來一遍，會把任務分配到天天。

• 緒佩
  在開始作以前應該多問一下有開發經驗的前輩，詢問清楚不懂的地方，這樣開發的時候能夠節省不少時間和多餘的工做。

• 愷琳
  在瞭解本身的任務同時也瞭解別人的任務，在交流中能更好地理解

總結:

你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

• 可重複級(Repeatable)
  在一次次團隊項目中，咱們團隊創建了較明確的管理制度和貢獻分分配規則。每次項目結束後都會進行反思和總結，且可以據此作出改進並較爲詳細地肯定下一階段應實現目標。

你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?

• 處於規範階段
  通過alpha衝刺和團隊現場git後，團隊成員已經進行了足夠多的磨合，有了充足的協做編程經驗；目前咱們所欠缺的是相互之間代碼等達到「規範」這一要求。

你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?

• 目前（alpha階段）相比於上一個里程碑（需求分析），團隊總體的技術水平有了很大程度的提高，團隊協做能力++。

你以爲目前最須要改進的一個方面是什麼?

• 編碼規範是咱們目前最須要改進的方面。

對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。

• 在團隊內部，最具備效果而且富有效率的傳遞信息的方法，就是面對面的交談
  我相信，在alpha衝刺階段中，咱們團隊的面對面交談/編碼時間可以在全部團隊中排在前幾甚至是第一。
• 每隔必定時間，團隊會在如何才能更有效地工做方面進行檢討，而後相應地對本身的行爲進行調整。
  即便除去alpha衝刺兩天一次的站立會議，咱們團隊仍可以保持平均每週1.5次以上的線下會議頻率，並在會議上對近期工做作出彙報、總結及相應調整。

本小組和其餘組的評分

分工和貢獻分

成員	比例
緒佩	13%
青元	13%
宇恆	7%
愷琳	7%
政演	6.5%
一好	6.5%
丹丹	7%
鴻傑	11%
家偉	11%
家燦	9%
卉卉	9%

全組討論的照片

問題

第一組提問回答：爸爸餓了隊

Q1：團隊沒有使用GIT進行版本管理,是否考慮在以後使用git進行版本控制

答:感謝提問，謝謝大家的提醒，咱們Alpha版塊尚未進行Git整合，在Beta版本這方面會選擇進行Git版本整合的。

Q2：備忘壁紙功能所選的壁紙彷佛會影響備忘內容的可讀性?

答:感謝提問!這個問題咱們咱們有考慮過，之前也有具體回答過，在壁紙方面咱們進行了多種設計來避免壁紙內容遮擋備忘錄，排版合理，儘量徹底清晰的展示備忘錄。

Q3：語音部分的功能在嘈雜環境中的表現有相應測試嗎?

答:感謝提問!語音功能有進行初步檢測，但由於咱們的主打功能不在此，並無具體的去加強語音識別功能，後續若是有時間精力的話，會考慮在這方面進行改善。

第二組提問回答：拖鞋旅遊隊

Q1：生活助手界面的優先級「無」是什麼意思？

你好，咱們對全部備忘都設置了一個可選填的優先級選項，若是備忘存存在優先級會按高低進行排序，不存在優先級的話按到期時間進行排序。

Q2：打開文件獲取圖片信息是用來編輯鎖屏界面的信息嗎？

你好，不是用於編輯屏鎖界面的，只是針對備忘保存圖片。

Q3：是否有用戶信息界面來展現信息以及對備忘錄記錄任務的完成度展現？

你好，咱們首頁設置了三個列表來展現備忘任務的完成狀況，分別是近期待完成、超時未完成、已完成任務，並可對這三個列表的已有備忘進行修改跟刪除。

第三組提問回答：很行隊

Q1：設計主界面採用流動的消息條,是否考慮會形成視覺疲勞？

後期咱們的美工和前端會對界面的美觀進行修繕。

Q2：說到算法,有想過提升一下算法嗎

咱們會對一些算法進行改進。

Q3：界面的總體風格好像有點普通,能夠考慮簡化一下界面,很好看？

前端在下一階段的任務就要包括對界面進行優化的任務。

第四組提問回答：火箭少男隊

因爲對方隊伍提交問題的時間太晚，故暫不作回答。

第五組提問回答：起牀一塊兒肝活隊

Q1：語言轉文字功能目前只能對接百度的，若是某天百度的接口取消了，要怎麼辦呢？

感謝提問！百度語音識別的功能如今已經和百度輸入法，魅族輸入法等手機品牌的輸入法在合做中，而且手機百度，愛奇藝等平臺的語音搜索功能也是創建在百度語音識別這個項目上的。若是有一天百度關閉了這個api那想必是百度搜索不想作下去了，放棄了這麼簡便的輸入方式。再者如今是人工智能飛速發展的時代，語音識別也處於這個範疇中，再加之百度近期將其api免費提供給開發者們使用，證實這個api還有很大的發展空間，是不會關閉的。

Q2：某些背景會影響閱讀，是否會考慮在用戶設置壁紙時提醒用戶的功能？
感謝提問！這個功能是經過用戶能夠選擇的開關來設置的，因此說這個功能的開關能夠由用戶本身決定。咱們後端和前端同窗在設計這個功能時會考慮到包括影響用戶體驗在內的各類狀況，盡努力使用戶體驗達到最佳。

第七組提問回答：第三視角隊

Q1：大家的訂單信息和快遞信息之間有什麼差異？

感謝提問！訂單信息指的是汽車票、動車票和飛機票等出行信息，而快遞信息即是字面上的快遞取貨信息。咱們在最後的對接過程當中沒有注意到這一細節，在以後的代碼整合時咱們會多加註意，避免這一失誤再次發生。

Q2：爲何大家展現的時候，生成壁紙那一塊，鎖屏的壁紙展現還留着「生成壁紙」按鈕和「取消」按鈕？還有，大家的生成壁紙支持預覽嗎？

咱們"生成壁紙"這一功能目前僅作到初步實現，在後續的版本迭代過程當中咱們會進行持續優化改進；生成壁紙支持預覽功能。

Q3：若是百度的接口哪一天不提供對外使用了那語音輸入是否是就廢了？
百度接口不予外用的話，考慮到自主實現效果不佳，咱們比較傾向先尋找其它接口進行代替；在以後算法能力提高後會考慮自主實現。

第八組提問回答：小白吃隊

Q1：對於算法方面是合理調用網上接口，後期會考慮本身來作語音識別嘛？

咱們語音識別是直接調用的百度提供的識別接口，因爲這個自主實現的效果和網絡上的接口出入很大，考慮到用戶體驗和識別的精確度，仍是傾向於直接使用百度接口。

Q2：如何統一美化ui界面？

對於ui界面，確實作的不夠美觀，改進思路是：參考如今發行的各類備忘錄類的軟件，博採衆長，進行組內討論和問卷調查等形式，肯定ui界面的美化方向；

Q3：對於識別快遞信息是直接經過單號來提取信息的嘛？

快遞信息的識別，是根據短信的內容，直接識別的，（正則表達式），咱們沒有作物流信息的同步，只是對收到到取貨信息的短信進行識別；

第九組提問回答：個人頭髮呢隊

因爲對方隊伍提交問題的時間太晚，故暫不作回答。

我的PSP

PSP2.1	header 2	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	50	30
· Estimate	·估計這個任務須要多少時間	20	30
Development	開發	150	120
· Analysis	需求分析（包括學習新技術）	60	60
· Design Spec	· 生成設計文檔	0	0
· Design Review	· 設計複審	0	0
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	0	0
· Design	· 具體設計	40	50
· Coding	· 具體編碼	30	20
· Code Review	· 代碼複審	0	0
· Test	·測試（自我測試，修改代碼，提交修改）	0	0
Reporting	報告	10	10
· Test Repor	· 測試報告	0	0
· Size Measurement	· 計算工做量	0	0
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	20	20
合計		240	300

我的學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時（小時）	累計學習耗時（小時）	重要成長
1	391	391	25	25	複習c++，學習單元測試和代碼覆蓋率，更熟悉Visual Studio的使用
2	100	491	5	30	在優化代碼和改bug
3	0	0	15	45	閱讀《構建之法》第三章和第八章，學習使用Axure RP8，對UI設計有進一步瞭解和認識，對項目開發架構進一步的理解
4	441	932	25	70	對爬蟲初步認識，還有待學習（隊友負責模塊），Debug能力++；
5	0	932	15	85	詳細瞭解需求規格說明書以及接口文檔書寫
6	232	1164	20	105	學習基礎前端界面佈局及學習思惟導圖製做
7	597	1761	20	125	學習前端交互，查資料能力++，對前端認識愈來愈深，恐懼愈來愈大，懂得作一個項目的艱難！
8	323	2084	40	165	前端細節控件監聽，checkbox等等的熟悉、頁面跳轉的學習