Thunder-Beta發布-事後諸葛亮會議-2017秋-軟件工程第十一次作業
小組名稱：Thunder
項目名稱：愛閱APP
小組成員：王航 李傳康 翟宇豪 鄒雙黛 苗威 宋雨 胡佑蓉 楊梓瑞
一、設想和目標
1、我們的軟件要解決什麽問題?是否定義得很清楚?是否對典型用戶和典型場景有清晰的描述?
在alpha發布中，我們組開發的軟件組要解決在線閱讀和本地導入1閱讀。功能領域定義的很清楚，通過典型用戶和典型場景有清晰的描述。在Bata發布中，我們主要解決的問題包括增加處理文本數量、增加上網查看小說、增加 用戶反饋等功能。
2、我們達到目標了麽（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麽？ 原計劃達到的用戶數量達到了麽?)?
本階段我們原計劃做9個功能，每項任務都按照交付時間交付的。原計劃的用戶數量為18人（包括組內成員8人），最終實現了22人的用戶量，有部分新增用戶。
3、用戶量, 用戶對重要功能的接受程度和我們事先的預想一致麽? 我們離目標更近了麽?有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?
用戶量和用戶對重要功能的接受程度和我們事先預想的一致。我們離目標更近了。通過用戶的反饋情況來看，我們的需要做以下改進：
1、在計劃實現具體功能之前，多采納用戶的意見和建議，這樣可以提高用戶的滿意度。
2、沒有明確了解用戶對軟件的真實想法，也沒有很好的了解用戶的需求。
二、計劃
1、是否有充足的時間來做計劃?
是，我們組有充足的時間來做計劃。
2、團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
在Scrum master 的帶領下，每位組員發表自己的觀點和建議，將觀點分類，再對這些分類進行探討，找出每一個分類的優缺點，最後將矛盾化整為零，意見統一。
3、你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麽?
原計劃的工作都做完了。共共有7個計劃，都是按時完成。
4、有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
沒有，做了的工作都有價值，盡管看起來是沒有用處的功能，但它依舊是有意義的。
5、是否每一項任務都有清楚定義和衡量的交付件?
有比較清楚的定義和衡量的交付件。
6、是否項目的整個過程都按照計劃進行，項目出了什麽意外？有什麽風險是當時沒有估計到的，為什麽沒有估計到?
整個過程都按照計劃進行，項目沒有特別的意外。在“本地導入”功能的實現中，將本地的很多文檔掃描出來，沒有具體的分類，導致查找文檔費時費力。在進行新功能“識別人臉”的開發過程中，遇到了技術難題，這是考慮到的可能出現的問題。
7、在計劃中有沒有留下緩沖區，緩沖區有作用麽?
沒有留下緩沖區。計劃的時候沒有考慮緩沖區。
8、將來的計劃會做什麽修改？（例如：緩沖區的定義，加班）
所有計劃要具體落實到每一位成員上，按時完成任務，整體計劃中加入緩沖區進行測試，提前發現問題並解決問題。
9、我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
首先，制定好所有計劃，嚴格按照計劃實施。每天都要開Scrum會議，每位組員都要好好總結自己遇到的困難，分享經驗。杜絕一切消極態度。
三、資源
1、我們有足夠的資源來完成各項任務麽?
沒有足夠的資源。因為大部分小組成員對安卓開發完全不知，都在不斷的努力學習。
2、各項任務所需的時間和其他資源是如何估計的，精度如何?
根據大家自我陳述的學習能力和對安卓知識掌握程度來估計所需時間。基本都能在規定的時間內完成。
3、測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
沒有緩沖區，所以沒測試。
低估了難度，美工其實不簡單啊，結果和預期不一致。發布的模式及設計也是很重要的一部分。
4、你有沒有感到你做的事情可以讓別人來做（更有效率）?
有。熟悉安卓開發的同學實現一些功能要比我實現這些功能的效率高很多。
5、有什麽經驗教訓? 如果歷史重來一遍, 我們會做什麽改進?
了解自己擁有的資源，好好分配資源，了解相關的技術難度和重點。
四、變更管理
1、每個相關的員工都及時知道了變更的消息?
變更的消息是小組成員在一起時討論的，所以變更的消息大家都能及時了解。但有的時候同學不一定能及時的看到消息，所以只能在立會的時候再次說明
2、我們采用了什麽辦法決定“推遲”和“必須實現”的功能?
根據實現功能的難度和用戶需求來決定。簡單的必須要實現，用戶需求度不高且難度大的推遲實現。基礎功能不推遲實現，時間不夠的情況下才會推遲實現。
3、項目的出口條件（Exit Criteria – 什麽叫“做好了”）有清晰的定義麽?
有，預期功能都基本實現就算做好了。
4、對於可能的變更是否能制定應急計劃?
未能做出應急計劃，因為我們未想到一些緊急情況。
5、員工是否能夠有效地處理意料之外的工作請求？
按照原計劃實施，無意外的工作請求。
6、我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
提前考慮到變更情況，並作出相應的應急計劃。對意外情況進行防範，並考慮是否添加心計劃。
五、設計/實現
1、設計工作在什麽時候，由誰來完成的？是合適的時間，合適的人麽？
設計工作是由小組成員一起討論得出的。是合適的時間，合適的人。
2、設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
有，設計“實現翻頁效果”功能時出現模棱兩可的情況。在Scrum Master的帶領下，討論出該功能的存在價值，最終決定實現該功能。
3、團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麽？ 比較項目開始的 UML 文檔和現在的狀態有什麽區別？這些區別如何產生的？是否要更新 UML 文檔？
沒有用過。
4、什麽功能產生的Bug最多，為什麽？在發布之後發現了什麽重要的bug? 為什麽我們在設計/開發的時候沒有想到這些情況?
“實現翻頁效果”功能Bug最多。因為要涉及到觸屏，所以具體實現起來有很多困難。剛開始單純的認為，該功能特別簡單。
5、代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
沒有進行代碼復審，代碼不規範。
6、我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
考慮好各種Bug出現的情況，要對程序進行單元測試，要進行代碼復審，要讓代碼規範。
六、測試/發布
1、團隊是否有一個測試計劃？為什麽沒有？
沒有測試計劃，未考慮到。
2、是否進行了正式的驗收測試？
沒有進行正式的驗收測試，僅在課堂上演示了一下實現的功能。
3、團隊是否有測試工具來幫助測試？
虛擬機、手機。
4、團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用麽？應該有哪些改進？
只在虛擬機和手機上進行了測試，未進行測量並跟蹤軟件。有用，多運用測量和跟蹤軟件，提早找出問題並能及時解決。比如現在就發現在部分版本的安卓手機上存在界面顯示不全的問題。
5、在發布的過程中發現了哪些意外問題？
沒有足夠多的客戶參與互動（發送反饋意見到後臺贏取獎品）。課前準備的安裝連接剛好失效。
6、我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
測試很重要，要學會用一些有助於優化功能的軟件幫助我們改進。計劃也非常重要，每一部分的功能最好都分配給一個同學負責測試。
七、團隊的角色，管理，合作
1、團隊的每個角色是如何確定的，是不是人盡其才？
根據每個人的學習能力和擁有的技術能力，做到人盡其才。
2、團隊成員之間有互相幫助麽？
團隊成員有相互幫助。
3、當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
各自表述自己的想法，取利益最大的方案。
4、每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的博客裏）：
王 航：http://www.cnblogs.com/wangh013/p/7793276.html
李傳康：http://www.cnblogs.com/lick468/p/7793159.html
代秋彤：http://www.cnblogs.com/120626fj/p/7794426.html
鄒雙黛：http://www.cnblogs.com/szjzsd/p/7793124.html
胡佑蓉：http://www.cnblogs.com/huyourongmonkey/p/7793293.html
楊梓瑞：http://www.cnblogs.com/vector121/p/7792963.html
4、我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
做到人盡其能。做到更好的協商統計。做好計劃
八、總結
1、你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
屬於CMM階段。
2、你覺得團隊目前處於 萌芽/磨合/規範/創造階段的哪一個階段?
我們團隊處於規範階段。
3、你覺得團隊在這個裏程碑相比前一個裏程碑有什麽改進?
知道要用軟件來對程序進行測試，多溝通，人盡其能。
4、你覺得目前最需要改進的一個方面是什麽?
設計計劃方面，關註用戶需求，根據他們的需求和意見修改計劃。
5、對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
“以有進取心的人為項目核心，充分支持信任他們”。我們都在規定的時間完成任務，互相信任。
九、全組討論的照片
Thunder-Beta發布-事後諸葛亮會議-2017秋-軟件工程第十一次作業