團隊作業9-事後分析
設想和目标
- 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
幫助使用者不用懂網站前端代碼就可以自定義美化自己的部落格園網站。針對典型使用者比如擁有部落格的人，典型場景比如控件選擇均有清晰的描述。
- 我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?）
原計劃的功能包括部落格預覽，基本前台展示，主界面布局，菜單欄展示等功能均已完成，按照原計劃時間傳遞，使用者數量也達到了。
- 和上一個階段相比，團隊軟體工程的品質提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
提高了。主要展現在對不同子產品的代碼更加熟悉，修改和擴充起來也很快，用時間衡量。
- 使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
與事先預想基本一緻，離目标更近了，後期要擴充的話，直接在原先的架構上添加就好了。
有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
就是一開始的知識儲備不夠，對前端的代碼不是很熟悉，還好有其他項目的基礎，花了些時間學習。
如果曆史重來一遍，我們會專門去學一下前端的知識，可以看看書，看看部落格，到做項目的時候就很快。
計劃
- 是否有充足的時間來做計劃?
有充足的時間做計劃。
- 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
我們采取扁平化管理，如果是技術的實作方式上有不同意見的，投票決定，如果是一些瑣事的，由組長決定。
- 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
原計劃的工作都做完了。
- 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
沒有，都很有價值。
- 是否每一項任務都有清楚定義和衡量的傳遞件?
沒有做到每一項十全十美，還有一些可以改進的點。
- 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
基本按照計劃進行，如果說有什麼麻煩就是在修複Bug的時候多花了點時間，但是最終都解決了。
- 在計劃中有沒有留下緩沖區，緩沖區有作用麼?
沒有留下緩沖區。
- 将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
在将來的計劃中，會更注重團隊中個人能力與工作量成正比，讓有能力的人充分發揮自己的才華。
我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
溝通是非常重要的，不管是意見不同還是遇到不會的問題，提出來可以更快解決。如果曆史重來一遍，我們會再開一些會總結和分享。
資源
- 我們有足夠的資源來完成各項任務麼?
有
- 各項任務所需的時間和其他資源是如何估計的，精度如何?
首先依據個人所擅長的領域劃分工作，在領域一緻的時候再根據個人能力配置設定工作量。
- 測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
足夠，确實低估了網站的美工設計，花了不少時間設計。
- 你有沒有感到你做的事情可以讓别人來做（更有效率）?
沒有這種感覺，因為團隊中每個人都被配置設定了最适合的工作。
在項目開始之前如果準備好了一些美術資源就更好了，如果曆史重來一遍，我們會對美術的需求考慮地更加周到。
變更管理
- 每個相關的員工都及時知道了變更的消息?
是的。
- 我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
必須實作的功能在項目确定的那一天就定下來了，是大家一起提出的目标，推遲是組長根據時間和目前項目進度決定的。
- 項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
由測試人員決定是否做好了達到要求。
- 對于可能的變更是否能制定應急計劃?
可以
- 員工是否能夠有效地處理意料之外的工作請求？
可以。
有時候需求會臨時改，要做好修改的準備，如果曆史重來一遍，很多地方我們會留有餘地，不寫死代碼。
設計/實作
- 設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
大家都有參與設計，在項目開始之前做好的，參與設計的人越多，想法也就越多，就越容易得到新穎的想法。
- 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
沒有遇到。
- 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？ 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
運用了單元測試，沒有用一些工具測試，不是非常專業。
-
什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
切換css時産生的bug最多，因為這個功能要做一些替換原網站css代碼的操作，調試也花了些時間，後期解決了，
在釋出之後發現了背景傳回的頁面顯示為手機版網頁的Bug，之前預設是電腦版網頁，一些細節沒有考慮到，這個Bug後面也解決了。
- 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
由寫相應代碼子產品的同學完成各自子產品的審查；是
測試/釋出
- 團隊是否有一個測試計劃？為什麼沒有？
- 是否進行了正式的驗收測試？
是
- 團隊是否有測試工具來幫助測試？
沒有
- 在釋出的過程中發現了哪些意外問題？
沒有發現意外問題。
軟體測試其實也是很嚴謹的一門技術，不是自己随便測測就可以的，
如果曆史重來，我們會專門去學習和應用軟體測試的知識。
團隊的角色，管理，合作
1. 團隊的每個角色是如何确定的，是不是人盡其才？
根據每個組員擅長技術和個人能力決定，是人盡其才。
2. 團隊成員之間有互相幫助麼？
有。
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
先溝通交流，發現問題所在，如果無法決策的，由組長決定。
團隊溝通交流非常重要，如果曆史重來，我們會更加注重這一方面。
總結:
你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
你覺得目前最需要改進的一個方面是什麼?
處于磨合階段，我覺得團隊在這個裡程碑和前一個相比有了很大的進步，每個人都在學習，在進步，每天都會有經驗的積累，
還有就是和隊友之間的溝通交流，一起發現問題，解決問題，是非常有趣的事情。
仍需要改進的就是大家的程式設計能力，如果每個人的程式設計水準提升一個等級，我相信我們會很快完成任務，甚至擴充更多的功能。
名字 角色 貢獻分 可驗證的貢獻
林清榮 組長 10 設計和測試
黃冠 隊員 30 前後端架構搭建和主要子產品實作
許曉烽 隊員 30 所有子產品前端的展示
蔡少杭 隊員 10 背景子產品的實作
許鴻洋 隊員 10 按鈕子產品的實作
黃明炜 隊員 10 部落格預覽界面的設計