(Beta)Let's-M2後分析報告

設想和目標

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

　　在M1階段咱們對用戶需求進行了調研，同時M1階段咱們的開發目標就是爲了解決用戶發起、參與、查看、搜索活動等一系列需求；而M2階段咱們要解決的問題是，用戶與用戶之間的聯繫，以及增強各類功能的完整性（如活動管理、活動評分、活動評論等）。對於典型用戶與典型場景在以前的博客中已有詳細描述，或者也能夠參看咱們的發佈博客。

　　2. 是否有充足的時間來作計劃?

　　Beta階段最惋惜的地方就是時間不足，因爲Beta階段中後期與考期、編譯考覈、數據庫大做業、數模等諸多任務對撞，致使咱們主要的開發精力只能限制在Beta剛開始的衝刺階段內。這也致使咱們部分預約的功能沒法正常上線，如推送和IM通信。二者均有雛形，但因爲存在一些bug未解決，所以沒法發佈上線。

　　3. 團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？

　　Beta階段出現分歧時，主要仍是參考這個部分開發人員的意見。但願能把決定權放在最瞭解問題的人手上，其餘人起輔助做用。這點也是和Alpha階段不一樣的地方，由於在Alpha階段有時PM可能不瞭解前臺的一些工做（好比對MD的設計理念不夠了解），致使在出現分歧時作的決定不合理（對界面設計的要求不符合MD規則）。所以Beta階段當出現分歧的時候，其餘人出意見，但主要決定權仍是在負責此事的開發人員手上。

計劃

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

　　未徹底完成。未完成的部分有：消息中心、消息推送、IM模塊。其中IM模塊和消息中心已經有雛形，但還存在必定問題未解決。有關消息這塊沒作完主要是到後期開發時間太少，並且總體難度比較大，由於沒有現成的模塊，須要從零開始搭建，開發難度較大。另外一方面，仍是因爲Android Studio的編譯效率比較低，致使開發效率較低。

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

　　沒有。在Beta階段咱們吸收了Alpha階段的教訓，採起敏捷開發的模式，將用戶需求中比較重要的部分放在首位，集中精力開發，所以完成的都是比較重要的功能欠缺。

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

　　有。Beta階段總體任務分爲幾類：團隊博客攥寫、後臺開發、前端設計。其中對於團隊博客攥寫這部分，由PM分配任務肯定好Deadline後，成員必須將文檔在既定時間前存放至堅果雲；對於後臺開發，每次修改的代碼都須要push到遠程倉庫，而且有對應的comment，除此以外，後臺還須要攥寫需求文檔（即後臺功能須要前端設計出什麼樣的界面，要實現什麼功能，須要有什麼控件，有什麼限制之類的），這些需求文檔也要統一放至堅果雲下；對於前端設計，咱們統一在堅果雲中存放了每個界面的設計稿，因爲有修改，各類設計稿也有迭代版本，統一進行管理。

　　4. 是否項目的整個過程都按照計劃進行?

　　大部分功能都按着計劃走。但因爲IM模塊牽涉到的機制太多，所以IM模塊的完成在任務列表上一拖再拖，後來因爲時間問題也沒辦法繼續優化。

　　5. 在計劃中有沒有留下緩衝區，緩衝區有做用麼?

　　有緩衝區。爲了預留緩衝區，計劃中的發佈時間是在12月底，但後來由於期末各類大做業的緣由，拖到了一月才發佈，但此時緩衝區也發揮了做用。

　　6. 未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

　　若可以繼續，在接下來的開發中將會更平均合理地安排任務。在早期開發過程當中，因爲PM（兼開發人員）接手完成了大部分後臺功能，致使其餘開發人員沒有過多機會接觸一些開發流程，對部分知識比較生疏。而在Beta的開發過程當中，PM不得不繼續完善以前開發過的功能，沒法將精力和經驗放在更難攻克的IM模塊上，這也致使IM的開發效率比較低。所以，任務的均配是一個待修改的方面。

資源

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

　　機器的限制仍是蠻大的。尤爲Google強推Android Studio後，大部分紅員的電腦跑這個吞內存的傢伙都很是吃力，且編譯時間浪費挺多。

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

　　因爲經歷了Alpha階段的開發，PM對總體成員的開發能力，各類功能的實現難度都有了更深的瞭解。所以從經驗上能更準確地判斷某個任務須要耗費的時間。除了IM模塊以外的其它任務估計時間都是比較精確的。

　　3. 用戶測試的時間，人力和軟件/硬件資源是否足夠?

　　因爲發佈較急，沒有花太多功夫用於宣傳上，所以沒有過多的用戶測試。大部分仍是靠開發人員本身測試，機型也較有限，只能用身邊人們的手機和平板。但Beta階段咱們在軟件中加入了反饋功能，容許用戶提供Bug反饋。咱們會經過這些反饋來進一步維護軟件。

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

　　這點在IM模塊的開發上體現比較明顯。因爲PM在以前的開發過程當中積累了較多的經驗，所以可以更快速地定位出問題。然而由於其餘緣由，最後IM模塊的開發並非PM負責，也從必定程度上拖延了時間。

變動管理

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

　　每次有更新都會push到遠程倉庫，而且在堅果雲或羣組中發佈更新的消息，確保全部成員的代碼是最新同步的。

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

　　Beta階段採用敏捷開發的模式，從用戶需求量最大的部分出發，而且以「最後可發佈的版本」須要哪些功能來界定哪些功能必須實現，哪些是能夠推遲的。

　　3. 項目的出口條件（Exit Criteria）是否獲得清晰的定義?

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

　　因爲計劃制定初期預留了緩衝區，所以若是遭遇緊急變動能有時間給團隊制定方案，同時任務通常都由兩人共同承擔，不會存在如有緊急狀況先前的任務就沒法進行的狀況，一人能夠調配來處理緊急狀況，另外一人能夠繼續原來的工做。

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

　　這些任務一般分配給較爲積極的組員，從完成狀況來看這些組員可以有效地完成這些意外請求。

設計/實現

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

　　Beta階段的設計分爲對早期界面的改進，以及新界面的設計。早期界面的改進由PM提出修改要求，前端設計人員來完成；對於新界面的設計，須要由後臺開發人員提出需求，並攥寫需求文檔，需求文檔中須要包括：該界面的功能，該界面的控件，你預想中界面的雛形以及界面的限制等。需求文檔是先後臺進行交互的窗口，而且要求需求文檔在預計開發時間前2-3天攥寫完成，提交給前端人員。前端人員根據需求文檔再去完成設計稿。經過實踐證實，總體設計的流程，時間和任務分配都是比較合適的。

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

　　吸收了Alpha階段的經驗，在設計工做上統一按照設計稿進行。考慮到PM對設計方面的瞭解不夠，所以不進行過多幹預。

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

　　單元測試要求在提交代碼前要完成，沒有藉助其它工具，由於多數模塊與安卓機的交互有關，直接在機子上運行測試。

　　4. 什麼功能產生的Bug最多，爲何？

　　活動的交互部分產生的bug最多，由於此處邏輯比較複雜。在代碼實現中甚至嵌套了好幾層監聽器用於實現此部分功能，多線程加上覆雜的邏輯使得這部分的bug比較難處理。

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

　　團隊開發中沒有專門進行代碼複審，代碼複審基本上都在各自調他人bug的過程當中完成了。。

測試/發佈

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

　　咱們制定了測試項，從界面顯示，交互功能到後臺狀況都有涉及，而且針對多種機型測試，編寫了測試矩陣。

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

　　發佈Beta前進行了最後一輪測試。

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

　　無。

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

　　利用TFS記錄Bug List，利用OSC的代碼質量分析工具對代碼質量進行檢查，加上最後的測試。這些測試從必定程度上減小了許多細節bug，但不足的是機型較少。

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

　　最終的release版本APK在部分機子上沒法安裝運行，但這些機子的系統已經高於軟件要求的最低版本。以及部分機型上顯示的錯位，空餘等。

咱們的感想

　　康家華

　　本學期的課程默不作聲卻十分有默契地擠在一塊兒，如今也終於擠在一塊兒結束了。趕在明天的答辯以前，對M2作一個總結。

　　用一個字來形容M2——「趕」。幾乎全部的事情都是趕出來的，我本身的時間徹底不能由我本身來安排。天天的任務從早上開始，一直覆蓋到晚上甚至明天凌晨。咱們在衝刺階段中有幾天是把daily scrum擱置了，由於遇到了編譯和數據庫兩門課程設計的夾擊，因此咱們不得不暫時放下工程。衝刺階段結束以後，咱們又不得不把工程放下，依舊是由於編譯和數據庫的關係，就連數學建模也在臨近期末的時候插了一腳，致使咱們有連着十天左右的沒有繼續工程。不要問我課程孰輕孰重。

　　爲何？咱們的項目是作一個APP，並且仍是安卓的。作APP不像作網頁那樣，有不少已經很完善的框架，即搜即用。作安卓的APP要考慮系統的版本，設備的適配，若是想要更高級的UI效果，還須要根據版本的限制來作兼容等等。使用Android Studio最新版在Windows 10的操做系統下編譯一次時間極限最快1m30s，有時AS抽風給你拖到10m+你還死活關閉不了，和網頁對比效率簡直天差地別。因此咱們的時間就是這樣一點一滴眼淚通常從臉上滑走，可是實際上每一個人都欲哭無淚。

　　不過好在咱們趕在編譯課設催命以前把整體的功能所有實現了，而且完成了發佈。在整個M2中，我無數次翻閱Material Design的設計文檔，從總體的設計風格，細節到字體的大小和邊距，在個人竭盡腦力之下終於把以前的設計所有推翻重改。如今，除了一個界面由於當時設計的關係沒有實現MD，整體上咱們的APP能夠稱得上是一個Material Design風格的APP了。不過還有一些動畫、頁面切換這些UI由於時間不夠沒有來得及設計，也是挺遺憾的。

　　M2答辯就在明天，仁者見仁，智者見智，咱們的APP實力不容小覷！

 

　　仇棟民

　　在M2階段，我主要參與了活動評分功能、手機位置與活動地點的距離計算、刪除與退出活動等功能的開發。整個M2階段我在作的工做都直接與用戶對於咱們這款軟件的主要功能相配套的其餘需求相關。這一點認識我在開發過程當中，逐漸加深，咱們的軟件設計是爲了解決用戶的一個或多個主要需求——尋找同好活動或朋友，可是在知足這個需求的同時，做爲用戶必定會同時產生其它許多附帶需求，一個比較好的軟件應該對此類需求有一個界限界定，究竟哪些配套需求是須要本身的軟件解決的，而哪些又是冗餘的。就咱們的軟件而言，在首頁給用戶提供按不一樣方式的活動排序顯示，顯然可以有助於用戶更快更好的發現本身適合參加的活動，這可以很大程度的提高軟件的用戶體驗。

　　另外在進一步的功能開發中，我還發現軟甲的新舊版本兼容也是一個很難處理的問題。由於新功能的開發，會涉及到數據庫版本的修訂，新舊不一樣的數據庫數據定義在同一份代碼的運行中，會帶來許多空值、空指針等查詢問題。咱們在快速開發過程當中，爲了保證原來的用戶可以不從新註冊也可使用咱們的新功能，只能採起在代碼邏輯中人工判斷的方法來解決。

 

　　劉彥熙

　　在阿爾法階段中，咱們團隊精誠合做，盡心盡力，取得了不錯的結果，我我的而言也頗有收穫，在貝塔階段中，咱們面臨的困難更爲嚴峻。

　　首先，隨着學期將盡，愈來愈多課程須要提交一些大做業，記得最爲艱難的一週中，咱們前後提交了編譯的階段測試、數學建模課論文、數據庫課程設計等做業，在這樣的壓力之下騰出時間寫軟工確實是殊爲不易。

　　另外，在阿爾法階段咱們實現的功能都相對基礎簡單一些，貝塔階段的工做任務較之以前不管從任務難度以及任務量上都應該說有了極大的提高，而且隨着程序規模的提高，往往作出改動可能會對以前的程序產生的影響都要考慮在內。

　　即使如此，在如此的不利條件下，咱們的組員仍是排除萬難，交出了一份較爲滿意的答卷。

　　可是在這個過程當中，很遺憾，我我的沒能作出什麼貢獻，在貝塔階段，我和張啓東主要負責IM模塊的工做，通過權衡咱們選擇了使用bmob的即時通信的SDK，因爲提供的案例程序代碼量較大，在前期的工做中我兩出現了分歧，我想要去摘取碎片式的信息，在須要用到什麼功能的時候再從代碼中去找相關的實現方式，而他以爲直接將咱們須要的全部功能從源程序中找一個閉包出來，添加到咱們本身的項目中，而後將一些UI風格進行修改較爲方便，由於工做模式不太統一因此前期進展緩慢，我在採用本身的方法執行的時候也遇到了諸多問題，無力解決的狀況下無奈也採起了他的工做模式，以後的工做中，我倆經過對案例的分析與調試，一點一點的將問題細化，從推送收發，到實時更新，從消息接收處理到頭像顯示，一點一點地將問題細化，在這過程當中遇到了不少困難，幾天時間不間斷地對着電腦一點一點調試，雖然說自認爲付出了努力，可是因爲對相關原理的不熟悉，只是經過閱讀源碼仍是有不少問題沒辦法解決，加之消息中心的實現無暇顧及，而若是沒有消息中心，即時通信的功能也顯得很雞肋，在發佈以前咱們仍是沒有來得及將這部分功能妥善完成，因此最終的發佈版本中，只能無奈放棄了這部分的功能。

　　儘管結果不盡人意，可是過程當中我仍是收穫到了不少啓示，最重要的一點在於在之後的工做中要作到在理解要完成的功能的實現原理以後再開始工做。理論永遠是指導實踐的不二法門，認識到這一點才能將工做進行妥善的規劃與執行，才能統籌全局，走在正確的前進道路上。

 

　　馬瑤華

　　持續幾周的BETA階段結束了，下面來總結一下個人收穫以及感想。

　　首先BETA階段有別於ALPHA階段，其中最大的問題就是時間問題。雖然在一開始的設想有許多要改進的地方，然而計劃趕不上變化。在期末階段許多事情趕在了一塊兒，給軟件工程所分配的時間也就天然地減小了。由於有編譯這門高難度課，時間的安排頗顯得捉襟見肘。好在小夥伴們都是熟悉的夥伴，項目也是原來的那個不用從新適應了。

　　在BETA階段，咱們的主要任務是基於ALPHA版本的軟件作進一步的更新和完善。其中我所參與的UI部分要進行一個大的改進。須要將沒有風格可言的界面修改成相似於material design的風格。在我研究了material design的官方文檔後初步有了一個計劃，而且按照PM的要求，接寫來用ps作了幾個頁面的設計圖。從設計圖來講，整體的效果仍是不錯的，須要注意的部分包括MD風格，美觀性和一致性都有了改進。在設計的過程當中我也參考了許多現有APP的樣式，我本人的收穫也是很大的。

　　BETA階段給個人還有一個感覺就是，咱們的應用是要上架在真實市場的，而非學校裏本身小打小鬧的產物。一切都要向市場上的成熟應用看齊。如何有競爭力，如何從一個安卓菜鳥一下就向最酷炫最前沿的理念看齊，真的是個不小的挑戰。以業內的標準，而非一個學生的課堂做業的標準來衡量做業，這是第一次。

　　在BETA階段中，你們須要在一個團隊中共同作事，頗像一個開發小組。如何互相溝通、磨合，如何互相銜接，都是須要本身在實踐中去學習的。好在組員們很是給力，給了我很大幫助，PM以及其餘人很是負責，很是感謝他們，他們身上有許多我須要學習的品質。

 

　　張啓東

　　M2階段主要是對咱們作的LETS的升級。咱們主要在關注、評論、IM和界面幾個方面進行的升級。咱們按照功能進行了分工，平均是兩我的作一個功能。M2階段和M1階段就有了很大地不一樣。由於M1階段，幾乎是咱們一塊作的開發，因此工程中每一個部分都很熟悉，對總體有較好的瞭解，而M2階段，徹底是新作一個功能，而後融合到原來的工程裏面，這就使我對總體工程的把握變少了。應該說這樣更符合軟件工程的思想，好比到了大公司，我確定只是作軟件的一部分。另外一個不一樣點就是咱們M2階段是以功能爲主導，經過實現一個功能來學習一系列的技術，而M1階段是以技術爲主導的，最初功能爲空，每學會一個技術，就把它能實現的功能加進去。這使得M2階段的難度增加了不少，由於新增一個功能要學習太多的功能，並且因爲時間有限，不可能從零開始一點點的作新的功能。這就只能找一個現有的工程，進行抽取和融合。這個過程當中出現了不少難以解決的問題首。先是xml類的問題，好比manifest.xml中的activity的說明，layout中的佈局，使用的圖片等等。這些從一個項目轉移到另外一個項目時，不少須要更改。下一個問題是Bmob的消息發送機制，它把發送的函數實現寫在一個sdk中，咱們沒法查看，因此並不知道它的實現原理，而後仿照它的消息發送寫，就是不成功，這裏浪累了很長的時間。並且要是徹底使用被引入的項目的數據結構，須要改變數據庫的結構。這個咱們最初竭力避免的，可是最後經過android studio的反彙編，努力讀出了必須是用一個新的類，必須改變數據庫的結構。

　　以上是關於技術方面的感悟。另外仍是感受到一個團隊不該該全都是搞技術的人。張炯老師說過，一個團隊裏若是有人只是負責想法或者管理，一點代碼也不寫，這也是合理的。從公司的角度看，這確實是正確的，我感受在公司並非程序員就是最NB的。可是在咱們的課程中，咱們沒法模擬到公司的環境，仍是作得以技術、代碼量爲重。有點感受咱們全部的隊伍都缺乏系統的測試、缺乏按期進行規劃。缺乏系統的測試是說，每一個隊伍都認爲能夠一邊寫一邊測試，甚至認爲測試是浪費開發時間。編譯課程的學習讓我認識到了測試真的是一門藝術，有的同窗的測試就十分完善，測試數據覆蓋面很全，測試思路十分清晰，測試結果顯示也十分清晰。還有缺乏按期規劃，大多數隊伍都是開始定了計劃，本次迭代要開發哪些功能（固然可能也有隊伍沒有規劃，就是有空就寫點，寫多少算多少）。可是，隨着學業壓力的增大，你們都先去寫哪些最着急的做業了，好比編譯、數據庫、數學建模，致使軟件工程開發時間不夠了。這時應該對任務進行從新規劃，以期仍然可以按時發佈，而大多人都仍然開發着原來計劃的任務，致使到截止時間時，項目並非一個完整的總體，最後是截止時間的一次次的推遲。

　　總的來講，仍是認爲這樣的軟件工程課是很棒的嘗試。從這門課中，確實學到了不少知識，收穫了不少前大班所沒有收穫的。技術上學習到了安卓的不少知識，讓我比較輕鬆地經過了本學期的安卓課程；團隊合做上，增長了必定的經歷，有了不少感覺；項目管理上也積累了必定的經驗，好比對git、對文檔有了更深的認識。

　　付出越多，收穫越多，這門課程很可貴，須要珍惜。

 

Yes! We Are And Always Are Chronos!