Alpha階段項目展示

1、團隊成員介紹

• bsh

  負責工作：前端開發及測試，前端負責人。

  bsh的個人博客

• byw

  負責工作：PM，各類文檔、博客的撰寫，總體計劃及督促完成進度。

  byw的個人博客

• lqh

  負責工作：後端開發及測試。

  lqh的個人博客

• lw

  負責工作：後端開發，後端負責人。

  lw的個人博客

• szy

  負責工作：暫定後端開發及測試。

  szy的個人博客

• wb

  負責的工作：前端開發。

  wb的個人博客

• ycd

  負責的工作：頁面的優化與改進

  ycd的個人博客

2、工程相關信息

（1）我們的用戶

• 需求

  ? 我們團隊之所以會想到做出這樣一個項目，就是因為註意到了平時許多同學們的需求。進入本科高年級，大家的註意力越來越多的從學習，轉向了實踐。在系裏的通知版、吐槽版中，也出現了越來越多的組隊招募、項目招募信息。但是，由於吐槽版是大家閑聊的場所，每天的消息量十分龐大，這類重要的信息往往會被埋沒在大量的聊天消息中。，需要長時間翻閱才能找到這一類信息。並且，在接收到有意者的申請時，也分散在各類社交平臺。

? 因此，我們希望能為這類招募信息提供一個統一的，清晰的平臺，集中發布這類招募信息，讓同學們能方便、快捷的查閱所有招募，找到自己最心儀，最滿意的項目加入。同時，也為發布招募的同學們，提供羅列清楚的申請者列表，以供其查閱申請者的簡歷，挑選最合適的隊友。

• 典型用戶

  ? 我們預期的典型用戶，主要是北航或其他學校的本科生，尤其是想要參加各類比賽，或想要加入各類項目豐富自身經驗，但又不知去除的同學。

• 預期功能及用戶數量

  ? 通過產品進行招募的發布以及申請。能清晰明了的查看所有招募，並記錄自己相關的所有招募以及申請。

  ? 由於alpha版本的功能仍較為有限，且限於時間因素，未能爬取學校中的各類招募信息，所以預期用戶量較少，註冊量預計50左右。

（2）產品表現

• 功能實現

  ? Alpha版本我們實現了組隊招募與申請有關的基本功能。其中，包含了重點的招募信息的發布、具體招募的申請，以及接受他人的申請。除此之外，我們還是實現了一些配套功能，如註冊登錄、自動登錄、簡歷模板等，最低限度滿足了用戶的需求。

• 用戶量

  ? 因當前版本的功能仍然有較多限制，因此用戶量較低，基本限於我們身邊的各位同學。

（3）團隊分工

• 如何分工

  ? 由於微信小程序的前後端完全分開工作，因此在確定好前後端開發人員後，分開進行工作，前後端各有一名成員，負責前後端的接口對接。在PM確定每日的任務後，開發部分的任務由前後端負責人與PM一起將任務進一步細化並分配給相應人員。出現不在計劃中的臨時任務時，優先分配給完成工作較少的團隊成員。

• 經驗教訓

  由於大三同學們各有各的安排，復習考研、參加比賽爭取保研、為畢業工作進行實習準備等等等等，平時都比較繁忙，因此不可避免的工作主動積極性較低，需要分配工作的人員將任務盡量具體，只有詳細、具體、具有明確DDL的任務，才能合格完成。

（4）項目管理

• github

  ? 項目使用github進行管理，主分支主要進行文檔的管理，分支front_end與分支back_end分別是前、後端的代碼倉庫，其他分支用於不同團隊成員自己開發所使用。

  ? 在開發過程中，在完成一個小模塊後都進行相應commit，以確保成果安全並便於統計沒人完成的任務。截至4月20日晚，除去個人開發的各個分支，僅master、front_end、back_end三個主要分支，commit量就達到了200。

• 任務管理

  ? 每日任務都會新建相應的"issues"，每晚由PM統計各成員完成的任務，並關閉相應的issues。

  ? 在時間上，我們不要求各成員工作的具體時間，只要能在規定的DDL前，合格的完成任務即可。我們希望每個成員都能找到最適合自己的節奏，盡量達到個人最高的效率。

  ? 所謂萬事開頭難，Alpha階段作為“從無到有”的階段，如何利用有限的人力、時間資源，做出合格的產品是一大難題。因此，我們討論後決定在第一階段中，將主要精力放在功能的實現上，畢竟這些功能本身才是我們想要提供給用戶的東西。並且，頁面的具體設計本身就是一大難題，經過實踐我們發現，從零開始設計一個好看的界面，其難度與花費其實遠大於在實現一個原型，確定頁面中各個元素所占的比例、重要程度後，再進行優化。

（5）測試

• 前端

  微信小程序的前端，由類似html的wxml，類似css的wxss與js代碼組成。由於大部分都是頁面的繪制，“所見即所得”，因此沒有代碼覆蓋率一說，而測試也只能通過觀察每個頁面、每個功能在不同環境下的工作情況來進行。因此，我們在多種不同的環境下進行了相應的測試，也發現了許多bug，關於bug的解決情況等詳情請見Alpha版本測試報告。

• 後端

  我們的產品後端采用django實現。

（6）文檔

? 所有的文檔都上傳在github項目，主分支的docs文件夾下。

? 其中，頁面相關的前端信息更新在功能規格說明.md中，主要包含頁面的大致布局，頁面中含有的主要元素，以及頁面主要搭載了何種功能。是前端開發時的依據。在初期階段，例會中大家在討論時為了讓其他成員理解自己的想法，也進行了一些粗糙的手繪示意圖。

? 之後，在進行文檔的撰寫時，將當時的想法重新繪制成了原型圖，進行了整理與重置。作為前端開發的參考。在下一階段，我們將會再次重新設計我們的頁面，大幅改善整體的審美表現。

? 後端數據庫的主要信息包含在數據庫設計.md中，包含了各個數據庫現在含有的內容。是後端開發的主要依據之一。

? 最重要的是接口設計信息，前後端都需要嚴格按照設計好的接口進行編程，才能確保對接後，最後的小程序能完成計劃中的功能。這一部分設計包含在技術規格說明.md中。這一部分的設計盡量詳細，避免開發人員造成任何誤解，導致可能的潛在BUG。

（7）用戶調研

? 我們的目標用戶主要是學校的學生，據我們團隊成員對周圍同學的調研，對於招募發布的統一集成平臺的需求是十分迫切的。在這一基礎上，我們也制定了電子問卷對北航的部分同學們進行了調研。就結果而言，顯然，一個招募信息的集中平臺是同學們迫切需要的。

3、項目信息

（1）實際進展

? 在前期，團隊成員們花費了較多的時間在學習微信小程序的開發上，後端的django，前端的html、css、js都需要一定的時間進行學習。在度過學習階段後，我們在實際代碼開發階段的進展較為迅速，完成了alpha階段的預期功能。燃盡圖如下。

? 燃盡圖中可以看到，項目前期的進展較快，成員們的工作積極性較高，在alpha階段後期，尤其是知道實際展示時間比我們預期的晚一周這個消息後，大家的工作節奏緩了下來。這是燃盡圖直觀展現出的一大現象。燃盡圖這一現象的另一原因是，這幅燃盡圖直接根據issues數目生成，忽略了不同issues的權重。前期學習、準備工作相關issues數量較多，但是比重較小，而後期的issues往往都是占比較大的“重活”。這一特點也造成了燃盡圖後期進度放緩的現象。

? 燃盡圖最後所剩余的一小部分，是一些長期任務，比如重新，詳細設計各頁面，盡量加入更多圖片元素等。這些任務alpha階段無法徹底完成，因此等待接下來的開發中完成後再關閉。

（2）產品功能

Alpha階段的功能如下：

其中功能的詳細介紹參見Alpha階段發布說明。

（3）產品發布

? 我們的產品已經正式發布在了微信小程序平臺上，打開微信點擊右上角的“放大鏡”，單擊“小程序”，在搜索框搜索“小小易校園“，即可使用我們的產品。

4、團隊成員貢獻

5、反饋及BUG

根據發布後一些同學使用後的反饋，我們的小程序主要存在以下問題：

• 在ios端較為不穩定

  ? 這一點是我們沒有想到的問題。由於微信小程序的開發與具體的手機操作系統無關，開發過程完全相同，因此我們沒有想到在不同手機環境下的差異會如此之大。在ios端下，部分功能如下拉刷新等無法使用，簡歷修改頁面的排版也與正常情況有一定區別。在下一階段我們將會仔細研究為何個別頁面會出現問題，尋找這些頁面使用的組件、設置與其他頁面有何不同，以定位ios端出現問題的原因。

• 服務器連接常常出現問題

  ? 由於微信小程序後端使用的域名需要經過長時間，大概半個多月時間的審核，因此在alpha階段我們來不及使用華為雲服務的服務器，只能使用之前已經通過了審核的，團隊成員自己的服務器。服務器的性能有限，盡管在校園網環境下還較為穩定，但是移動4G常常會出現連接不上服務器的問題。

• 缺乏操作反饋

  ? 許多用戶反應“點了一個按鈕後毫無反應，也不知道是自己沒點上還是小程序出了問題“。這一重要問題的原因是，我們在開發時更多的考慮了用戶操作成功、用戶非法操作時的提示，忽略了部分操作等待連接服務器的問題。所以在連接服務器時缺乏相應的提示，導致用戶的迷惑。

6、alpha階段小結

? alpha階段中，經過了3個星期的開發，踩了許多坑，繞了許多彎路，也從中吸取了許多經驗。

• 前端設計的難度不亞於實現的難度

  ? 作為6個沒有任何美術基礎的理科生，開始實際開發後才發現，設計出好看頁面的難度，對於我們來說不亞於實現這一頁面的難度。作為零基礎的設計者，尋找現有的、相近的模板進行參考，可行性遠大於自己設計。

• 一個明確的整體規劃，是項目按時、合格完成的必要條件

  ? 通過這一階段的開發，我們發現，在多人合作的實際工程中，需要明確的，具體的分工，來保證每個人清楚自己在團隊中的位置；同時，也需要詳細的，清晰的分配每日任務，來保證每個人認識到自己肩上的責任。

• 在溝通時，只有把每個細節都闡述清楚，才能確保想法的傳達

  每個人的思想都各有不同，在討論時，不能指望他人通過一個粗略的比喻，就完全理解自己心中的某個想法。在討論過程中常常出現因為語言表達的不具體，而導致兩人以為互相達成了共識，等到工作做完才意識到在細節上雙方的想法仍截然不同。借助紙筆，或者電子文檔、畫圖來傳達自己的想法，遠比單純的口頭交流有效。

在下一階段的任務

經過討論，在下一階段我們的主要任務如下：

• 增加操作反饋，確保用戶的每一下點擊後都有相應的事件觸發

  ? 根據alpha階段的反饋，我們意識到，必須為用戶的每一下點擊，都做出相應的反饋：若操作成功，則應跳轉到相應的頁面、實現相應的功能；若操作失敗，則必須明確的提示用戶為何操作失敗，如何解決；若需要向後端索要或發送數據，則必須要提示用戶正在鏈接服務器，並在超時後給出提示。如此才能避免用戶在使用中出現“到底是我沒點上還是卡了”的疑惑。

• 添加亮點功能，將目前的功能做精、做專

  ? 我們意識到，貪心的實現多個不同類型的功能，最後做成一鍋什麽都涉及一些，什麽都做的不好的大雜燴是絕對需要避免的。因此，我們團隊經討論決定，將當前的招募發布、申請功能做到極致，添加讓人眼前一亮的獨特功能，如在查看申請界面，根據用戶的需求，將符合要求的簡歷排在最上方；在發布列表頁面，根據用戶的專業，推薦符合其專業技能的招募等等。

• 重新設計頁面，大幅提升審美體驗

  優秀，好看的頁面既能吸引新用戶的增長，也能提升用戶的使用體驗。經過對比其他成熟的，使用人數極多的成功小程序，我們發現我們的UI主要有兩大問題：

  • 顏色單一，控件樣式單一，界面重復感強
  • 缺少圖片，頁面較為單調

  在下一階段，我們會參考一些好看的設計模板，爭取大幅提升我們的界面質量。

課程建議

經過alpha階段的實際動手開發，我們發現管理這門大學問的難度與重要性都超乎我們的想象。軟件開發的效率不僅僅取決於每個成員的個人能力，也取決於是否有好的管理制度和總體規劃。而可惜的是課上由於老師要為每個組提供寶貴的建議，實際能夠講課的時間並不多。希望課上能留出更多的時間用於講授軟件工程中，關於管理與合作內容。

[Alpha階段]項目展示博客