Thunder-Beta發佈-過後諸葛亮會議-2017秋-軟件工程第十一次做業

小組名稱：Thunder
項目名稱：愛閱APP
小組成員：王航 李傳康 翟宇豪 鄒雙黛 苗威 宋雨 胡佑蓉 楊梓瑞
1、設想和目標
　　一、咱們的軟件要解決什麼問題?是否認義得很清楚?是否對典型用戶和典型場景有清晰的描述?
　　　　在alpha發佈中，咱們組開發的軟件組要解決在線閱讀和本地導入1閱讀。功能領域定義的很清楚，經過典型用戶和典型場景有清晰的描述。在Bata發佈中，咱們主要解決的問題包括增長處理文本數量、增長上網查看小說、增長 用戶反饋等功能。

　　　　#在alpha發佈中，咱們組開發的軟件組要解決在線閱讀和本地導入txt文本閱讀功能。在Bata發佈中，咱們主要解決的問題包括增長處理文本數量、增長上網查看小說、增長 用戶反饋等功能。
　　二、咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)?
　　　　本階段咱們原計劃作9個功能，每項任務都按照交付時間交付的。原計劃的用戶數量爲18人（包括組內成員8人），最終實現了22人的用戶量，有部分新增用戶。
　　三、用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?
　　　　用戶量和用戶對重要功能的接受程度和咱們事先預想的一致。咱們離目標更近了。經過用戶的反饋狀況來看，咱們的須要作如下改進：
　　　　一、在計劃實現具體功能以前，多采納用戶的意見和建議，這樣能夠提升用戶的滿意度。
　　　　二、沒有明確瞭解用戶對軟件的真實想法，也沒有很好的瞭解用戶的需求。

　　　　#用戶數量有微小增長，主要功能和本組預期一致。根據用戶反饋報告，咱們瞭解了不少不足的地方以及更新的需求。若是歷史重來一遍，咱們會針對用戶的需求，完成更多的功能。好比：增長對字體的修改、增長對其餘類型文件的識別+添加。
2、計劃
　　一、是否有充足的時間來作計劃?
　　　　是，咱們組有充足的時間來作計劃。

　　　　#對，咱們組討論完成哪些計劃、如何完成、分配任務的時間很充足，你們耐心細緻的作了任務完成計劃
　　二、團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？
　　　　在Scrum master 的帶領下，每位組員發表本身的觀點和建議，將觀點分類，再對這些分類進行探討，找出每個分類的優缺點，最後將矛盾化整爲零，意見統一。

　　　　#每次立會的Scrum master都不一樣，你們輪流擔任這個角色。除了商討之外，更多的時候按照「you can you up,no can no BB.」的原則進行。針對不一樣的功能，提出設想是好的，可是完成設想相對比較困難。因此，能夠完成代碼實際操做、完成視頻實際製做、完成文檔編寫的同窗，擁有更多的話語權。能夠有觀點，提出觀點的負責完成。
　　三、你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?
　　　　原計劃的工做都作完了。本階段總共共有7個計劃，都是按時完成。

　　　　#計劃中的事情都作完了，在Beta階段總共有7個大的計劃，（小的計劃過於零碎，沒有記錄數量），計劃中的任務都按時完成
　　四、有沒有發現你作了一些過後看來不必或沒多大價值的事?
　　　　沒有，作了的工做都有價值，儘管看起來是沒有用處的功能，但它依舊是有意義的。

　　　　#沒有。每一件事的存在必定是有意義、有價值的。可是有的價值大，有的價值小。也許不少用戶都沒有注意到不一樣格式文件讀取這個功能的添加，（由於他們手頭可能只有.txt類型的電子書，沒有其餘格式的）因此他們僅僅能從「新增功能列表」中發現咱們的軟件的完善。可是在開發團隊看來，咱們這麼作是有意義的，由於會有不一樣格式的文本文本件存在，咱們增長對同文本的支持就有必要，有意義。
　　五、是否每一項任務都有清楚定義和衡量的交付件?
　　　　有比較清楚的定義和衡量的交付件。

　　　　#每一件任務都有清楚的定義。和「能夠衡量」的交付件。

　　　　#這句話有歧義吧，應該是我語文沒有學好。個人第一個理解是這樣的：「清楚定義和衡量」做爲形容詞，修飾「交付件」；第二個理解是這樣的：「清楚」形容「定義」，「衡量」形容「交付件」。但無論怎麼說我依舊認爲應該是「可衡量」而不是「衡量」。
　　六、是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?
　　　　整個過程都按照計劃進行，項目沒有特別的意外。在「本地導入」功能的實現中，將本地的不少文檔掃描出來，沒有具體的分類，致使查找文檔費時費力。在進行新功能「識別人臉」的開發過程當中，遇到了技術難題，這是考慮到的可能出現的問題。

　　　　#在alpha階段發生的事情Beta階段沒有發生。咱們已經再也不提出「看起來十分困難」的計劃。全部計劃都是有計劃如何實現，才把它列爲計劃，而不是想到有新的功能就把它列爲計劃。不過在完成針對「pdf」等多種格式的支持後，忘記了增長對新增支持文本的添加書架操做。這在用戶體驗中被及時的指出了。這個緣由是咱們僅僅計劃「支持閱讀」，沒有「支持將其添加到書架」。可是用戶不這麼想，他們但願能夠看到本身喜歡的pdf文件也在書架上。

　　七、在計劃中有沒有留下緩衝區，緩衝區有做用麼?
　　　　沒有留下緩衝區。計劃的時候沒有考慮緩衝區。

               #在本階段的計劃過程當中，咱們依舊沒有考慮緩衝區。因此目前咱們沒有了解到緩衝區的做用。
　　八、未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）
　　 　 全部計劃要具體落實到每一位成員上，按時完成任務，總體計劃中加入緩衝區進行測試，提早發現問題並解決問題。

　　　　#未來的計劃，（當時）只有一週final發佈，你們根據分工完成總結+完成新分配的任務。不須要加班，你們都在期待的時間內完成任務就能夠了。
　　九、咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
　　　　 首先，制定好全部計劃，嚴格按照計劃實施。天天都要開Scrum會議，每位組員都要好好總結本身遇到的困難，分享經驗。杜絕一切消極態度。

　　　　#本次Beta發佈，對於咱們來說，學到的東西，主要在於「充分準備+應對突發狀況」。二維碼期限只有1天是咱們沒有發現的，因此纔出現了掃描二維碼找不到下載文件的狀況，當時及時在羣內上傳了app安裝包。
3、資源
　　一、咱們有足夠的資源來完成各項任務麼?
　　　　沒有足夠的資源。由於大部分小組成員對安卓開發徹底不知，都在不斷的努力學習。

　　　　#通過2周的開發，代碼主幹力量已經熟悉了安卓開發的知識，其他成員也不斷跟進。
　　二、各項任務所需的時間和其餘資源是如何估計的，精度如何?
　　　　 根據你們自我陳述的學習能力和對安卓知識掌握程度來估計所需時間。基本都能在規定的時間內完成。

　　　　#由完成該任務的成員肯定，資源主要是本身要用的電腦和相關的學習資料。優先必須使用的同窗使用：好比作視頻渲染過程就須要配置高的電腦。那這樣的電腦將不用於軟件開發。時間方面是根據本身能力進行估計和計算。精度在小時這個程度上。
　　三、測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?
　　　　沒有緩衝區，因此沒測試。
　　　　低估了難度，美工其實不簡單啊，結果和預期不一致。發佈的模式及設計也是很重要的一部分。

　　　　#人力是足夠的，硬件資源也是足夠的。美工的不一致體如今圖標、進入後界面背景、總體軟件主題等方面。這部分的難度低估了。　　
　　四、你有沒有感到你作的事情可讓別人來作（更有效率）?
　　　　有。熟悉安卓開發的同窗實現一些功能要比我實現這些功能的效率高不少。

　　　　#就撰寫這個報告這份工做來講，若是讓不一樣分工的同窗完成不一樣的部分效果會更好。可是總結全部同窗的感受，這樣的任務我仍是能夠勝任的。總體來說咱們沒有這樣的感受，由於任務不是硬性分配的，而是你們本身選擇的，因此你們都選擇的是本身想作的和認爲本身能作好的。
　　五、有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?
　　　 瞭解本身擁有的資源，好好分配資源，瞭解相關的技術難度和重點。

　　　　#經歷過的問題才知道以後如何避免。週三纔拿出了能夠用於展現的版本，生成了二維碼。因此距離展現不足二十四小時，這時候就沒有機會知道「二維碼有效期是24小時」這樣的問題存在。只有用戶反應了界面、圖標很差看，纔想到要修改。問題只有暴露出來纔會讓你們知道，若是再來一遍，咱們會減小這類的小失誤。
4、變動管理
　　一、每一個相關的員工都及時知道了變動的消息?
　　 　　 變動的消息是小組成員在一塊兒時討論的，因此變動的消息你們都能及時瞭解。但有的時候同窗不必定能及時的看到消息，因此只能在立會的時候再次說明。

　　　　#但有的時候同窗不必定能及時的看到消息，因此只能在立會的時候再次說明。
　　二、咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?
　　　　根據實現功能的難度和用戶需求來決定。簡單的必需要實現，用戶需求度不高且難度大的推遲實現。基礎功能不推遲實現，時間不夠的狀況下才會推遲實現。

　　　　#與以前的想法相同
　　三、項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?
　　　　有，預期功能都基本實現就算作好了。

　　　　#有，舉個例子，能夠正常讀取pdf文件，就算是該功能的「出口條件」。
　　四、對於可能的變動是否能制定應急計劃?
　　　　未能作出應急計劃，由於咱們未想到一些緊急狀況。

　　　　#作出了，可是效果很差。上傳app安裝包到用戶體驗羣，可是隻有「有app的」同窗纔在羣裏，因此傳了也沒用，當時沒有找到班級羣（羣太多了，時間緊沒找到）。這個是展現的過程當中的應急。代碼編輯階段沒有「忽然新增」等「須要應急」的狀況發生。
　　五、員工是否可以有效地處理意料以外的工做請求？
　　　　按照原計劃實施，無心外的工做請求。

　　　　#你們都在及時的想辦法，可是沒有有效處理。
　　六、咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
　　　　提早考慮到變動狀況，並做出相應的應急計劃。對意外狀況進行防範，並考慮是否添加心計劃。

　　　　#應急狀況會發生，能及時處理纔是最好的。固然能避免，比讓它發生更好。歷史重來一遍，咱們不會讓它發生。
5、設計/實現
　　一、設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？
　　　　是在alpha發佈以前完成的，設計工做是由小組成員一塊兒討論得出的。是合適的時間，合適的人。
　　二、設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？
　　　   有，設計「實現翻頁效果」功能時出現模棱兩可的狀況。在Scrum Master的帶領下，討論出該功能的存在價值，最終決定實現該功能。

　　　　#有，在討論實現支持幾種文件的過程當中就遇到了相似的狀況。能夠完成該項任務的成員決定計劃，其他的成員的意見僅僅做爲參考。
　　三、團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？ 比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

　　　　 沒有用過。

　　　　#本次衝刺階段咱們依舊沒有使用「單元測試」方案。我的認爲是有效的，可是不是全部有效的東西均可以真實的貼合與實際。咱們沒有完成單元測試模塊，的主要緣由在於，咱們將時間花費在了開發的具體項目上，而在課題要求中沒有要求「先使用單元測試再開發」或者「根據上一次過後諸葛亮會議的不足，有哪些改進」這類的任務。因此沒有使用
　　四、什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?
　　 　　「實現翻頁效果」功能Bug最多。由於要涉及到觸屏，因此具體實現起來有不少困難。剛開始單純的認爲，該功能特別簡單。

　　  　　#修改：本次討論中代碼開發人員提到完成「QQ書友羣」時的bug較多。主要是鏈接模塊中的代碼老是出錯，不能及時跳轉到QQ。
　　五、代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
　　 　　沒有進行代碼複審，代碼不規範。

　　　　#本題回答相似於第3題。完成代碼的部分是幾個同窗分別完成的，因此各自完成各自模塊以後，就整合到一塊兒了。完成功能後就沒有針對代碼的維護工做。這是咱們須要改進的地方。
　　六、咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
　　　 考慮好各類Bug出現的狀況，要對程序進行單元測試，要進行代碼複審，要讓代碼規範。

　　　  #設計與實現部分，主要學到了真實的開發經驗。可是對於「測試驅動開發」、「代碼規範」、「合做編程」等方面的任務咱們沒有很好的完成。因此若是歷史重來，咱們會增強這部分的應用。

6、測試/發佈
　　一、團隊是否有一個測試計劃？爲何沒有？
　　　　沒有測試計劃，未考慮到。

　　　　#發佈日期前，每一個功能是不斷完善的，沒有整合到一塊兒。每位同窗手頭都有着本身的任務。只有臨近發佈日期，才遇到了須要測試的需求。可是已經發布了。與其說「未考慮到」更多的是沒時間考慮「測試」這個事情。固然，不能由於「書本上說過，發佈前應該進行大量測試」咱們就真的能在發佈前想到這個問題。真實作完了程序、發佈時遇到了各類問題，才讓咱們意識到「測試的重要性」。
　　二、是否進行了正式的驗收測試？
　　　　沒有進行正式的驗收測試，僅在課堂上演示了一下實現的功能。

　　　　#針對每個功能，咱們都進行了測試，看看是否達到預期的效果。可是不正式，也並非很是完備的「驗收測試」，完成功能就算完成了。
　　三、團隊是否有測試工具來幫助測試？
　　　　虛擬機、手機。

　　　　#用過測試工具完成測試：廢棄的安卓手機、電腦中裝的虛擬手機等。
　　四、團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？
　　　　只在虛擬機和手機上進行了測試，未進行測量並跟蹤軟件。有用，多運用測量和跟蹤軟件，提前找出問題並能及時解決。好比如今就發如今部分版本的安卓手機上存在界面顯示不全的問題。

　　　　#僅僅在手機和電腦上的虛擬機中進行了測試，並無進行多機真實跟蹤測試軟件。測試工做是有必要的，真機實際測試也是有必要的。好比如今就發如今部分版本的安卓手機上存在界面顯示不全的問題。
　　五、在發佈的過程當中發現了哪些意外問題？
　　 　　沒有足夠多的客戶參與互動（發送反饋意見到後臺贏取獎品）。課前準備的安裝連接恰好失效。
　　六、咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
　　　　 測試很重要，要學會用一些有助於優化功能的軟件幫助咱們改進。計劃也很是重要，每一部分的功能最好都分配給一個同窗負責測試。
7、團隊的角色，管理，合做
　　一、團隊的每一個角色是如何肯定的，是否是人盡其才？
　　　　根據每一個人的學習能力和擁有的技術能力，作到人盡其才。

　　　　#在討論任務分配的過程當中，你們一塊兒商討有哪些須要完成的任務，以後才根據任務肯定每一個成員完成什麼工做。因此角色是由任務和本身意願決定的，因此作到了人盡其才。
　　二、團隊成員之間有互相幫助麼？
　　　　團隊成員有相互幫助。

　　　　#互幫互助是固然存在的，當新成員加入羣組後，組內成員就積極的培訓新成員熟悉安卓開發環境。
　　三、當出現項目管理、合做方面的問題時，團隊成員如何解決問題？
　　　　各自表述本身的想法，取利益最大的方案。

　　　　#印象裏並無出現很嚴重的問題，除了各自說各自的想法外，由組長協商、協調也是切實有效的手段。
        四、每一個成員明確公開地表示對成員幫助的感謝 （而且寫在各自的博客裏）：

　　　　李傳康：http://www.cnblogs.com/lick468/p/7922334.html

　　　　楊梓瑞：http://www.cnblogs.com/vector121/p/7922354.html

　　　　翟宇豪：http://www.cnblogs.com/-Rio56/p/7922595.html

　　　　王    航： http://www.cnblogs.com/wangh013/p/7923251.html 

 

　　　四、咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
　　　　作到人盡其能。作到更好的協商統計。作好計劃。

　　　　 #測試發佈階段，咱們沒有及時作好測試，分佈過程也有小瑕疵，但這並不影響咱們團隊的團結與努力。只有經歷過挫折纔會讓你們更緊密。歷史重來一遍，咱們會預留測試的時間。

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

　　　　屬於CMM階段。

　　　　#目前處在第二級~第三級之間：可重複級與已定義級之間。這2個級別的內容展現以下。

　　　　可重複級：基於相似項目中的經驗，創建了基本的項目管理制度，採起了必定的措施控制費用和時間。管理人員可及時發現問題，採起措施。必定程度上可重複相似項目的軟件開發。

　　　　已定義級：已將軟件過程文檔化、標準化，可按須要改進開發過程，採用評審方法保證軟件質量。可藉助CASE工具提升質量和效率。
　　二、你以爲團隊目前處於 萌芽/磨合/規範/創造階段的哪個階段?
　　　　咱們團隊處於規範階段。
　　三、你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?
　　　　知道要用軟件來對程序進行測試，多溝通，人盡其能。

　　　　#團隊更加團結了，分工也更加明確，改進在於，你們知道本身要作什麼，想作什麼，會作什麼。
　　四、你以爲目前最須要改進的一個方面是什麼?
　　　　根據進度及時調整功能，有些過於複雜的功能就暫緩製做，優先核心功能。設計計劃方面，關注用戶需求，根據他們的需求和意見修改計劃。
　　五、對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。
　　　　「以有進取心的人爲項目核心，充分支持信任他們」。咱們都在規定的時間完成任務，互相信任。每一個同窗都有機會選擇本身喜歡的任務去作，在商議後肯定任務分配。

　　　　#最好的構架、需求和設計出自於自組織的團隊。這一點本文做者深有體會。目前衡量某個組是否有「更優秀」的做品的重要標準就是本門課程的成績。據我所知，這2個團隊在軟件工程課程初期就已經有意願結成團隊完成任務了。這就是「自組織」的優點所在。
9、全組討論的照片

 致歉：由於翟宇豪（樓主）我的緣由，致使團隊全部成員的該項做業分數（100分）被倒扣，與其餘同窗分差差值爲200分，深表歉意。錯了就要改正，每一次錯誤都是本身前進路上須要經歷的過程，十分感謝你們的包容。今天花費了約180分鐘從新仔細完成了本次做業，踐行「及時改正是一種態度」的信念。

 

解釋：全部黃色底紋的內容均是與alpha過後諸葛亮會議不相同的表述。