康家華：http://www.cnblogs.com/AmazingMax/
馬阿姨：http://www.cnblogs.com/oushihuahua/
劉彥熙：http://www.cnblogs.com/xixibaba/
張啟東：http://www.cnblogs.com/jirufeng/
林珣玙：http://www.cnblogs.com/kanelim/
仇棟民：http://www.cnblogs.com/nightcool/
效果示範
Before——項目選擇與前期準備
創意來源：
我們的創意來源主要源于我們自己的切身體驗，日常生活中，我們理工科學生的交際圈相對較為狹窄，當我們想要結識一些具有相似興趣愛好的夥伴時，缺乏一個管道或者平台來滿足自己的需求。另外，現代人更多地喜歡線上交流，滋生了諸如低頭族，宅文化這樣的社會現象，我們希望有一個能夠發起線下活動的平台，讓人們更多地與身邊人進行實際交流。
軟體定位及使用者調研：
同好活動交流平台
· 彌補生活中缺少同伴一起參與想去的活動的遺憾、為交際圈小的人提供與興趣相投的人結伴的途徑
· Let's能夠提供他們一個途徑或者選擇
· 适用使用者是所有人群
· 主要客戶群是的年輕人，比如大學生、年輕白領等。這些人群會有比較強烈的好奇心和活動積極性
http://www.sojump.com/jq/5981768.aspx
平台與開發環境：Android Studio 1.5
堅果雲的使用：堅果雲可以友善地在本地建立一個團隊共享檔案夾，我們用堅果雲服務管理日常的通知、任務送出、工程資源檔案、個人進展彙報等。(我們在Beta階段仍然貫徹使用了堅果雲的管理模式，實作了文檔的高效管理)
團隊的分工： 在阿爾法階段初期我們先對項目的幾個主要子產品進行了劃分，這樣能夠對項目的整體規劃有一個較為清楚的認識，并且友善進行分工，另外我們還确定了各個子產品之間的關聯結構，以利于各個成員之間的協作溝通。
（下圖為Alpha結束後進行的第一次會議中決定的Beta階段的開發計劃）
APP示範
Doing——版本變動與開發曆程
Git的使用：
兩項工程，80+100次送出記錄
TFS的使用：由于在阿爾法階段我們沒有正确使用燃盡功能，是以最後的燃盡圖效果很不理想，在事後分析的總結中我們一緻肯定了TFS對于團隊開發效率的提升功效顯著，在貝塔階段的開發過程中始終貫徹着靈活開發的模式，在開發初期将所有的任務配置設定項提前配置設定給每位團隊成員，之後堅持每日對開發進度進行實時的更新維護。
每日的daily scrum中都會對當日的燃盡情況進行記錄。
DailyScrum ：
此外我們堅持着DailyScrum的開展，為此還特地買了一塊白闆在宿舍内，将每人的今日任務以百分比的形式展示在闆面上，這樣既可以更友善地了解到開發的進度情況，還可以起到一定的督促作用。
Daily Scrum 12.20: http://www.cnblogs.com/Chronos/p/5061023.html
Daily Scrum 12.19: http://www.cnblogs.com/Chronos/p/5058527.html
Daily Scrum 12.18: http://www.cnblogs.com/Chronos/p/5056258.html
Daily Scrum 12.17: http://www.cnblogs.com/Chronos/p/5055111.html
Daily Scrum 12.16: http://www.cnblogs.com/Chronos/p/5050441.html
Daily Scrum 12.15: http://www.cnblogs.com/Chronos/p/5047240.html
Daily Scrum 12.14: http://www.cnblogs.com/Chronos/p/5046940.html
Daily Scrum 12.13: http://www.cnblogs.com/Chronos/p/5043890.html
Daily Scrum 12.12: http://www.cnblogs.com/Chronos/p/5041423.html
Daily Scrum 12.11: http://www.cnblogs.com/Chronos/p/5040858.html
Daily Scrum 12.8: http://www.cnblogs.com/Chronos/p/5030912.html
項目的整體變動：
三個版本、兩次重構：我們的項目先後有三個版本，期間經曆了兩次徹徹底底的外觀重構。第一次重構是必然的，由于所有成員先前都沒有安卓開發的經驗，我們隻能在嘗試中摸索，從我們熟悉的Eclipse到完全陌生的Android Studio、從一個個預設的系統控件到經過精心設計實作的UI元素，但因為全體組員的盡職盡責，我們第一次的轉型十分成功，不僅在UI上給人眼前一亮的感覺，在功能上也實作了既定關于活動的各種基本操作。
第二次的重構是我們精益求精的偏執，我們希望Lets的設計能夠更遵從原汁原味的Material Design風格，同時我們更希望它的功能能夠提供一個完整的使用者體驗，于是第二次的重構我們不僅在UI上下足了工夫，更是在整個開發模式，對軟體功能的定義取舍做了全新的改變。
前後端互動的管理：
在阿爾法階段協調上存在一些問題是以貝塔階段之初就決定采取這樣的工作模式。我們要求：任何一個背景功能在進行開發前需要提前2-3天送出需求文檔，該需求文檔的内容包括以下四個方面：需求功能的整體介紹、頁面需要使用的控件類型、開發者預想中的頁面雛形、對功能的一些限制和補充說明。送出完需求文檔後，前端設計和實作人員需要根據實作難度和背景人員進行協商，在最終确定一個雙方都同意的可行方案後，即可開始設計實作。2-3天内，設計人員能夠将基本的xml架構，設計思路理清。後端人員同時可以利用這段時間進行基礎功能的開發，這時的開發可以不注重任何界面效果，它甚至可以隻是一堆預設控件的堆疊，但它必須要和需求文檔一緻。這樣在得到設計人員的設計後，即可一同開始設計界面的實作，此時的背景功能應已完成。“需求文檔”就像一把同步鎖，引入了它之後，我們的前後端協調互動變得有條不紊，工作效率也大大提升。
設計需求文檔的展示：
前端的概念設計圖以及手稿：
靈活開發模式與出口條件：
在Beta的開發過程中，我們吸取上次的教訓，始終保持靈活開發的模式。對于不必要，成本效益不高的功能，我們給予其較低的開發優先級。始終将主力用于必要功能的實作。那麼什麼樣的功能才是必要不多餘的呢？首先必須從使用者的角度出發，按照測試場景代入，如果我們是使用者，我們希望它能有什麼樣的功能來滿足我的需求？另一方面，我們需要考慮到有限的時間和龐大的工作量，是以，通過出口條件也可以協助我們确定什麼樣的功能是必要的。
如果說在阿爾法階段我們以“木桶效應”來拟喻應用的出口條件，在這一階段，“齊頭并進”才是我們所想要達到的效果。是以，任何會造成使用者功能完整性不一緻的地方，都是我們開發的重點。
具體的某些功能實作過程中遇到了哪些困難：
IM通訊的發送與接收（廣播機制、多線程操作、UI的實時更新等）
活動管理和關注功能（關聯多個資料表，操作邏輯複雜）
整體界面Material Design化（各種細節的追求，小到邊距、字型，達到控件的風格，頁面配色等）
After——釋出情況與總結反思
釋出到了哪些平台:
騰訊應用寶：http://op.open.qq.com/index.php?mod=appinfo&act=main&appid=1104889725#mobile|center
百度手機助手：http://shouji.baidu.com/software/item?docid=8103349&from=as
安卓市場：http://apk.hiapk.com/appinfo/com.example.lets/1
91應用市場：http://apk.91.com/Soft/Android/com.example.lets-1-1.0.html
預期下載下傳量：200次
收集使用者回報的方式：我們一直十分注重使用者的回報，為此專門在應用中一個顯眼的位置添加了擷取使用者回報的管道：
下面就是在近期我們收到的一些使用者回報
Bug修複：
下拉崩潰
不能更改個人頭像（已修複）
不顯示頭像
百度地圖（已修複）
活動資訊修改加載圖檔（已修複）
在某些機型上軟體裝不上
圖檔加載有時不加載，有時會有殘缺。
未知錯誤，偶爾點選活動會崩。
連擊兩次活動卡片會打開兩次該活動的界面。
參與活動過程中背景資料記錄的Bug(已修複)
測試：
Beta階段我們将測試矩陣細化，并增添了對多種新功能的測試。
參考測試部落格：http://www.cnblogs.com/Chronos/p/5093717.html
反思感想：
仇老闆
整個M2階段我在做的工作都直接與使用者對于我們這款軟體的主要功能相配套的其他需求相關。這一點認識我在開發過程中，逐漸加深，我們的軟體設計是為了解決使用者的一個或多個主要需求——尋找同好活動或朋友，但是在滿足這個需求的同時，作為使用者一定會同時産生其它許多附帶需求，一個比較好的軟體應該對此類需求有一個界限界定，究竟哪些配套需求是需要自己的軟體解決的，而哪些又是備援的。就我們的軟體而言，在首頁給使用者提供按不同方式的活動排序顯示，顯然能夠有助于使用者更快更好的發現自己适合參加的活動，這能夠很大程度的提升軟體的使用者體驗。
康家華
在整個M2中，我無數次翻閱Material Design的設計文檔，從整體的設計風格，細節到字型的大小和邊距，在我的竭盡腦力之下終于把之前的設計全部推翻重改。現在，除了一個界面因為當時設計的關系沒有實作MD，總體上我們的APP可以稱得上是一個Material Design風格的APP了。不過還有一些動畫、頁面切換這些UI因為時間不夠沒有來得及設計，也是挺遺憾的。
劉彥熙
在M2階段我收獲到了很多啟示，最重要的一點在于在以後的工作中要做到在了解要完成的功能的實作原理之後再開始工作。理論永遠是指導實踐的不二法門，認識到這一點才能将工作進行妥善的規劃與執行，才能統籌全局，走在正确的前進道路上。
馬瑤華
BETA階段給我的還有一個感受就是，我們的應用是要上架在真實市場的，而非學校裡自己小打小鬧的産物。一切都要向市場上的成熟應用看齊。如何有競争力，如何從一個安卓菜鳥一下就向最酷炫最前沿的理念看齊，真的是個不小的挑戰。以業内的标準，而非一個學生的課堂作業的标準來衡量作業，這是第一次。
在BETA階段中，大家需要在一個團隊中共同做事，頗像一個開發小組。如何互相溝通、磨合，如何互相銜接，都是需要自己在實踐中去學習的。好在組員們非常給力，給了我很大幫助，PM以及其他人非常負責，非常感謝他們，他們身上有許多我需要學習的品質。
張啟東
總的來說，還是認為這樣的軟體工程課是很棒的嘗試。從這門課中，确實學到了很多知識，收獲了很多前大班所沒有收獲的。技術上學習到了安卓的很多知識，讓我比較輕松地通過了本學期的安卓課程；團隊合作上，增加了一定的經曆，有了很多感受；項目管理上也積累了一定的經驗，比如對git、對文檔有了更深的認識。
付出越多，收獲越多，這門課程很難得，需要珍惜。
總結：
一個學期的開發過程中，我們經曆過技術上的迷茫，經曆過設計上的偏執，經曆過組内成員的分歧與争吵。但我很開心，無論如何，我們的組員在小組需要他們的時候從來沒有說過不，包括今天展示時，我們仍是全體出勤，我能夠站在這裡自豪地向大家展示我們的APP，這都是我們共同團結努力的成果。
無論是Alpha階段沒日沒夜地趕工，還是Beta階段縱然在編譯、資料庫、數模和考期等多重因素的施壓下，我們仍然沒有停止開發的步伐。我相信其他組的成員也有目共睹，我們的付出從git的送出記錄也可見一斑。
最後，陪伴了我們半個學期的白闆，之上的任務也終于都清空了。
THE END