(Alpha)Let's-M1後分析報告

Chronos團隊Let's項目

Postmortem結果

設想和目標

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

　　在最初的用戶需求和市場調研方面，團隊進行了詳盡的調查，也策劃了Alpha階段須要實現的功能，所以在軟件須要解決什麼問題這點上咱們的目標很是明確：開發一款可以融入線下生活，以活動交友的APP。Alpha階段的目標即完成軟件基礎功能，包括註冊登陸，用戶與活動之間的聯繫。關於典型用戶和場景，已在以前的博客中作了清晰描述。

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

有時間，但多數時間都用於盲目地一把抓式開發，缺乏詳細策劃。

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

每一個人的不一樣意見都會獲得尊重，若出現分歧，則會讓各自在天天的scrum meeting時闡明本身的理由，最後由組員共同商討決定團隊最終採用哪一種意見。

 

計劃

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

　　全部功能性工做都已完成，剩餘部分bug以及細節顯示還沒有優化，如：圖片沒法加載的問題，還未實現上拉加載，百度地圖API在部分手機上沒法加載等。其緣由部分是由於時間分配不夠合理，致使部分時間耗費於無關緊要的細節上，而忽視了關乎用戶體驗的細節。另外一方面，和咱們先前未運用好代碼託管機制，以及Android Studio極低的編譯效率都有很大關係(每次pull代碼常常由於配置文件修改出現模塊丟失的狀況；編譯運行一次基本都要3-4分鐘)。

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

　　有，例如首頁界面的搜索框縮放效果。最初看重這個框架的縮放效果，一心想着將其應用於軟件中，卻耽誤了其它實質性功能的開發。

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

　　對於代碼編寫的任務，通常在下達任務以前PM會規定好任務細節，並要求完成基本功能，經過單元測試（如搜索模塊）。但對於UI方面，Alpha階段PM的安排過於籠統，使得任務定義模糊，無形中浪費了不少時間。這點在Beta階段將進行改進，UI任務將由大至小，從統一改善總體風格，到各個組件的設計，將要求提交設計稿等一系列材料。

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

　　常常實際完成時間都要比預約完成時間晚一天。經過反思總結，緣由有如下幾點：全部組員先前都沒有安卓開發經驗，初次開發不免繞許多彎子；開發過程當中效率不夠高，常常以「天」爲時間單位進行規劃，卻沒有精確到「小時」甚至「分鐘」，致使屢犯拖延症；時間分配不合理，致使撿了芝麻丟了西瓜；部分紅員的投入時間難以保證，開發人力有限。

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

　　有緩衝區，在計劃中只給Alpha階段開發留了三週時間，而且在每週的任務中也會預留一至兩天。這樣是爲了必定程度上杜絕拖延現象，另外一方面能夠有更多的時間對開發工做進行審覈修改。

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

　　PM將會明確任務的定義，而且合理分配各個任務的時間和人力，避免沒必要要的浪費，並督促各位組員的任務完成時間，考慮加入懲罰措施；將採用敏捷開發模式，針對每個階段的任務逐個攻破，避免Alpha眉毛鬍子一把抓的方式；改變評估方式，站在用戶的角度考慮開發方向，而不單純依靠開發者本身的喜愛。

 

資源

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

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

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

　　Alpha階段對時間的估計較爲粗略，對難度的預估誤差較大，常常以天來分配Task，致使常常出現一個任務拖延多天的狀況。在Alpha階段經歷了整個流程，瞭解了安卓開發後，Beta階段將會更合理精確地分配任務。

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

　　因爲Alpha階段最後修復bug致使發佈時間拖延，以及最初對Alpha階段的功能設計存在缺陷，致使整個軟件功能漏洞較大，沒法在較大人羣中推廣，測試時間較短。但經過組員的推廣，已經在100+安卓機子上進行了安裝體驗，並受到了許多反饋，咱們將利用這些反饋進行Beta版本的優化。

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

　　這點較很差界定，尤爲體如今先後端的工做上。前端的工做到底是設計和xml界面編寫，仍是包括代碼實現的動效，交互事件？（以下拉刷新時加載動效，箭頭的轉動等）

 

變動管理

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

　　由於任務拖延，不常常Pull最新代碼，部分組員的工程文件常常遠遠落後於最新的版本。但全部push的更新都會在工做組中說起。

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

　　從用戶的角度出發，決定哪些功能是必備的，哪些是附加功能，哪些是無關緊要的，排出優先級。

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

　　Alpha的出口條件簡單粗暴，即沒有致使crash的大bug，預期功能健全完善。

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

　　從Eclipse到Android Studio的一次轉變應該是比較忽然的，實在受限於Eclipse的拓展性，咱們決定利用緩衝區的一兩天時間將總體工程轉移到AS上，並熟悉新的IDE。從結果來看，計劃的制定和緩衝區時間的利用仍是比較成功的。

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

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

 

設計/實現

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

　　Alpha階段對UI設計的任務時間都劃分不當，使得UI的設計較被動，一般由後臺提出請求再轉至UI，其中PM做爲交接人。在Beta階段將爲UI設計作詳細的階段策劃。另外一方面，軟件框架的設計由PM完成。

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

　　較少，多數狀況下PM一人對這些狀況進行決定，但也致使了一些設計缺陷。下一階段將讓更多組員參與討論。

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

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

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

　　頁面加載，佈局錯位的bug最多。最大的緣由仍是安卓機型的繁雜，以及開發者對界面代碼編寫的經驗缺少。

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

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

 

測試/發佈

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

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

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

　　發佈v1.1前進行了最後一輪測試。

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

　　無。

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

　　利用TFS，但在Alpha階段咱們未利用好TFS的bug記錄，且並非全部的Task都記錄在TFS中，其中TFS任務分配沒法同時分配多人這點比較麻煩。

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

　　最終的release版本APK在部分機子上沒法安裝運行，但這些機子的系統已經高於軟件要求的最低版本。以及部分機型上顯示的錯位，空餘等。這些問題都已經記錄，將在Beta階段進一步解決。

 

其餘成員的心得體會

>> 康家華

　　「有沒有一些聲音，呼喚你給本身一點喘息。」

　　連續幾天的熬夜已經嚴重擾亂了個人生物鐘，這種混亂的做息也終於跟着M1答辯的結束一塊兒消弭殆盡。M1結束以後，也抽出一些時間對M1進行一些總結和分析。

　　在整個工程中我負責的主要是UI設計部分，對於歷來沒有開發過安卓應用的我，須要從零開始學習XML語言，而且可以達到脫離所見即所得的UI設計模塊直接在代碼層面上直接進行設計的水平。

　　在開發前期，我一直使用安卓自帶的傳統控件進行設計，作出來的界面基本上是拿不上臺面的，因而咱們在一次會議中討論到了Material Design的設計風格，你們一致決定要按照這樣的設計更改，因此咱們對以前的成品進行了「大翻新」。

　　在向Material Design的設計發展的過程當中，咱們遇到很多的而且有的還嚴重影響到整個工程進展的問題。

　　首先，是框架不兼容的問題。咱們從開源的代碼中找到的合適的界面框架想要移植咱們的程序中，可是因爲後端的代碼已經基本完成，咱們不得不對框架和後端代碼的接口進行修改。在這個過程當中，原本應該屬於測試的時間也都被大量的佔用在耦合調試的過程當中了。

　　其次，因爲時間緊急，來不及設計和Material Design搭配的相關控件，咱們只能用不太搭調的來應急，以致於咱們在展現時的界面仍是多種風格魚龍混雜的場面，根本就不是Material Design，這也是我我的對前端設計的不滿意之處。

　　在接下來的M2中，須要改進的有不少，包括在風格設計上面的統一，在開源代碼的使用方面等等，還須要對實際的用戶體驗進行分析，儘量的讓用戶更舒服、更享受地使用咱們的軟件。另外，團隊之間最須要的就是「溝通」，溝通作得好，隊員之間的距離也就縮小了，咱們的開發就會更有效率。

 

>> 劉彥熙

　　軟件工程阿爾法階段的工做告一段落了，在這一階段的工做中，我感受我的收穫不少，也有一些體會想要談談。

　　首先，本身以前沒有過團隊開發的項目經歷，經過此次的開發，瞭解到了團隊合做進行項目開發的常規模式，而且對於團隊合做有了全新的的認識。一方面是一些版本管理工具的使用，另外一方面是學到了不少如何與隊友溝通協做的知識。

　　另外就是學會了一些基本的安卓開發知識，由於以前一直想要學習一些有關APP開發的知識，可是感受專門去學比較費勁並且效率不高，結合項目進行學習更有針對性一些。而且在開發過程當中可以看到本身本身所作的東西變成實際可以看到的東西，因此比較有成就感，也就能更加促進開發的熱情。

　　以上是一些此次開發過程當中的收穫，接下來談談體會。

　　越是龐大的任務就越須要妥善的規劃，所謂規劃包括如下幾點：

　　首先，須要制定一些列階段性的任務：由於開發的過程很是漫長，任務很是的繁重，面對着如此龐大的工程，不免會很打怵。因此要將任務分紅若干個階段。

　　在每一個階段咱們須要對項目的總體面貌有一個統一的認識：諸如一些相似界面的佈局圖以及接口的書面材料，雖然在定義的過程會耗費一些時間，可是可以大大提升開發的效率。而且可以在之後的開發中提供依據與參考。

　　另外體會在於：當你真心想作好一件事的時候，你就會積極主動地去完成任務，而且在乎你所作的工做的質量。既然是團隊開發，團隊中的每一個人就都有責任和義務爲團隊作出貢獻。

　　但願咱們團隊可以在下一階段的開發中排除編譯帶來的困難，越作越好吧。

 

>> 馬瑤華

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

　　首先，這門課以及這種團隊合做形式讓我對於軟件工程有了全新的認識。之前咱們編程頂可能是本身作個小做業，或者是幾我的弄個小程序，而像這樣大規模的持續的團隊合做之前並無經歷過。兩個月的時間，和小夥伴們一塊兒作個應用，同時還要兼顧學業，不是個很容易的事，至少沒有看上去那麼簡單。

　　在M1階段，咱們主要是在進行將一個軟件從無到有的生產過程，也就是相似於原型的軟件。可想而知，這個東西不會那麼完善。在界面方面，一開始的工做作的不細緻，固然也是由於第一次接觸到緣由：咱們能作到什麼樣子，能作多少，內心都沒有底。一開始的xml佈局結構徹底是邊看邊學邊寫。巴不得就是一半屏幕放着IE網頁教程，一半屏幕是eclipse。在最初的原型有了之後，確定最早想到就是這個效果很差，想要本身從新設計界面。然而本身設計也並無想象中的容易，如何造成統一的風格而非拼湊？如何選用規範的標準？伴隨而來的都是問題。而客觀上時間不夠，主觀上付出不夠，咱們的UI仍是沒有達到目標效果。雖然這是必然的，但在接下來的開發中卻又必然是會改進的。

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

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

　　在接下來的階段中，我認爲我須要更加主動的和其餘組員的溝通而且時刻跟進咱們的項目，在UI方面造成一個總體的設計而且花更多的時間在咱們的項目上。學業很忙，但如何統籌安排，別老把事情拖來拖去，這絕對是我最須要思考以及改進的地方。

 

>> 張啓東

　　通過這兩個多月以來的軟件工程的學習，還有團隊項目的經歷，總結反思以下：

　　首先，一個月的軟件工程團隊項目的進行讓我對軟件開發有了比較實際的認識，之前咱們的編程可能是我的編程，兩人編程，程序難度低，代碼量少，也很容易配合。此次團隊做業，咱們6我的一塊作一款app。咱們組實力還算能夠，雖然沒有可以獨自承擔起所有任務的大神，但你們在編程方面基礎都還不錯，還有兩人有過些項目經驗。同時咱們每一個人都是認真對待此次做業的，不僅是爲了期末的分數，更是珍惜這個可以一塊參與編程的機會，同時還有這咱們對這款活動平臺app的共同希冀。

　　在團隊編程中，任務量是很繁重的，若是隻是一我的來承擔，天然是十分困難的，這就須要凝結團隊中的每一個人的力量。團隊中的每一個人應該按時完成pm分配的任務。同時多溝通，彼此知作別人在作什麼，這在一個不超過10人的小組，並非困難的。並且多溝通可以節省不少本身研究代碼的時間，符合敏捷開發的思想。

　　因爲是團隊開發，每一個人都須要修改版本的代碼，因此必定要學會用好倉庫管理，這樣可讓多我的共同開發，同時容易知道代碼變更，避免了繁重的不一樣的代碼的合併。

　　固然，團隊編程有時候也會存在一些問題。好比說咱們每每把任務細化到每一個人的身上。但一般會有各類各樣的緣由致使不一樣的任務進度不一樣，這就會形成有的進度會出現延期現象，給整個項目的進度形成影響，這就須要在分配任務時作到合理化，使得彼此之間能夠有效的銜接上，這樣團隊項目的實現就會變得迅捷許多。最好團隊編程中也存在結對編程，這樣能夠保證若是一我的有事情，另外一我的能夠補上這個缺口，咱們組就是這樣作的，我和另外兩我的都結對編程過。

　　同時還在必要的時候承分擔某一慢進度的開發工做。除了PM的協調，固然還須要各個模塊負責人之間的溝通和交流，作好模塊間的通信工做，方便一方出現變化時另外一方可以迅速作出調整。

　　咱們組的pm統籌能力比較強，他可以合理給每一個人分配任務，力求作到進度之間彼此銜接。

　　關於我的的建議，其實我不太建議選學長代碼的完善，我更傾向於選一個新的問題從頭作起，這樣我可以從頭至尾經歷一次比較完整的開發過程，才能真正體會到團隊項目的特色和交流，整合以及優化測試的重要性，這樣也讓我認識到了大工程不只僅要重視算法，更要重視架構上和變化上對軟件目標實現的綜合整合。

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

 

>> 仇棟民

　　連續幾天的熬夜的工做，已經徹底打亂了個人生物鐘，最後一點精力已經被消磨殆盡。如今就這兩個月來的軟件工程的團隊項目的M1階段作總結與反思。

　　在M1階段中，我主要負責的是後臺功能的開發與測試。對於歷來沒有學過android開發相關知識的我，這實際上是挺有挑戰的。

　　遇到的第一個困難是對android機制的理解與應用。安卓的Activity、Intent、Handler、Bundle等類都比較特殊，我都是在用到以前在網上簡單學習一下，就開始寫，這致使了個人初次代碼質量很低。學習的太粗略，太粗淺了，下一階段學習新技術的時候應該注意理解透徹技術的機制再使用，避免後期調試爲開始的粗心埋單。

　　第二個大困難是JAVA多線程機制的使用，在這裏就不贅述了。

　　另外因爲是第一次開發安卓應用，在開發過程當中，咱們寫到必定程度後，結構框架不是很是合適，意圖對咱們的工程進行一次重構，然而緊張的時間進度不容許咱們進行重構。因此只能先改了一些方法內部的代碼結構進行了調整。

　　這種狀況在真實的軟件開發過程當中應該是很常見的，咱們團隊既然遇到了這樣的問題，必定程度上說明了咱們體驗到了一種真實的軟件開發過程，這是很是寶貴的經歷。

　　同時，時間節點的限制，也使得咱們整個過程都在「試用」敏捷開發的方法，說「試用」是由於咱們有的地方還用的不到位，可是整體原則和大方向沒有偏。

　　最後，我在M1階段中遇到的困難與問題，會在M2階段中努力克服與解決。

 

OUR TEAM