1.1 BXERP產品簡介-集成微信小程序的多商家開源收銀系統
1.1.1 BXERP是什么
BXERP是幫助零售門店商家經營的ERP軟件，在門店的顧客、員工、商品3者的數量達到一定程度后應用開源BXERP系統，能有效減輕商家經營負擔、提升顧客滿意度。目前BXERP已開發出滿足單一門店經營需求的產品，我們把該產品稱為“博銷寶”。
1.1.2 BXERP可以帶給你什么
- 對於Java web開發者，可以快速照抄BXERP的Java后端框架。
- 對於Android開發者，可以快速照抄一套網絡請求框架。
- 對於教師和學生，本項目將是你迅速提高教學質量、投身真實戰場的不二選擇。
- 對於項目經理和企業管理者，可以快速組建一個具備先進開發流程的團隊。
- 對於零售企業，應用開源的BXERP可以低成本、快速、0試錯搭建一個新的商業軟件系統，尤其是N平台客戶端1服務器的軟件系統，BXERP可以為你節省大量成本（資金和時間）。
- 對於收銀設備廠商，應用開源的BXERP可創建自有品牌的收銀系統，結合收銀機等硬件設備銷售從而來帶更多收益（硬件+軟件+微信支付商戶平台分潤）。
1.1.3 BXERP所能滿足的用戶需求
以小型單店為例，通常有如下類型的用戶：顧客、老板、店長、收銀員。其中顧客是核心用戶類型，老板、店長和收銀員均圍繞顧客的購物需求開展經營活動。以下為各類型用戶的基本需求：
根據用戶需求分析，BX研發團隊定義了如下系統角色：
| 角色 | 角色說明 |
| 會員 | 即顧客群體當中認可商家，願意提供手機號碼進行注冊為會員的顧客。 |
| 老板 | 即門店所有權人。 |
| 店長 | 即負責門店日常運作、處理的各類事項的管理人員。 |
| 收銀員 | 即負責商品過機及收款的人員。 |
| 系統操作員（系統OP） | 即BX公司內部負責為商家開通及配置BXERP的人員，通常由客戶經理擔任。 |
1.1.1 BXERP子系統結構及模塊簡介
BXERP子系統結構：
BXERP包含了nbr服務器端和客戶端。
nbr服務器包含商家ERP子系統和客戶管理子系統（CMS），它們的模塊組成如圖：
用戶客戶端：POS機客戶端（包含安卓應用軟件和電腦桌面應用軟件）、微信小程序、微信公眾號：
1.2 BXERP產品研發理念
1.2.1 研發團隊做好事情的原則
2019年3月27日，一個名為“996ICU”的項目在GitHub上傳開，迅速火遍了全網。這一事件揭露出了國內程序員的加班現狀，反應出了程序員們對這種加班狀況的抗拒心理。2021年下半年，騰訊等互聯網公司相繼宣布取消996工作制，國內程序員是否迎來了不用加班的福音？短時間內恐怕還不行，不過這無疑是人心所向，是一種趨勢。那么之前通過加班才能完成的工作，取消996工作制，還能按時按量的完成工作嗎？答案是肯定的，不過需要找出一個科學有效的方法。
我們都知道，程序員加班很多時候並非開發一些新功能，而是陷入了修bug改bug的泥潭中。如果能避免或減少這種情況，那么程序員就能高效率的完成工作。BX研發團隊開發BXERP時，始終沒有忘記尋找科學有效的方法，讓研發人員輕松地把事情做好。做好事情是許多團隊的基本要求，但是輕松地做好，幾乎是奢求。我們通過嚴格執行以下團隊組織原則達成“輕松地做好事情”的目標：
- 第一、重復。其精華體現在以下幾個方面：
- 通過重復使事情逼近一個完美的狀態，此重復即迭代。我們認為這是敏捷開發最大的精華。
- 令重復的事情不重復。使用機器來代替人類的重復勞動，使得人類有精力完成更多的事情。譬如自動化測試可以解放大量的生產力。
- 不能重復做的事情，想方設法重復做（針對事情本身或拆分后的局部，進行多次重復的仿真），以使真正第一次做時就成功。
- 人類不是禽獸，通過重復做一件事，必定可以獲得進步。
軟件工程充滿各種重復。據說Windows 2000大約有2000萬行代碼，由大約1000位軟件工程師完成。假設他們事先得到了上帝的指引，編碼完全不需要修改而且沒有bug，那么，按照每人一天1000行代碼的速度，這些工程師20天就可以開發一個Windows 2000。但是事實上並非如此，Windows 2000開發周期是三年左右。可見這些工程師花費了大量的時間做了重復的事情。如果我們在軟件工程里面很好地控制重復的勞動，那么一定可以輕松地將事情做好。BXERP代碼量大約100萬行，測試用例大概是15000個（大部分是自動化測試），研發團隊人數11人（絕大部分是實習生），開發周期是18個月左右，由於很好地遵循了重復的原則，加上以下第二點的流程，程序員幾乎不加班，經常處於一種精神抖擻、斗志昂揚、活潑有趣的工作氛圍中，工作效率比較高。
- 第二、流程。結合業界的先進流程，探索以及不斷優化一些適合BX研發團隊的敏捷開發流程。一個產品從0到1，和從1到2，其流程是不同的。我們采用的軟件工程流程如下：
| 階段 | 主要活動 | 軟件產出 | 服務器要求 | 作用 |
| 立項 | 主要論證市場需求和政策需求，即產品研發的原因。 | 立項書 | ||
| 需求分析 | BA（商業洞察者）制作需求規格說明書。 | 需求規格說明書 | 商業角度看需求 | |
| RD（研發團隊）將業務轉化為BA和RD都可以理解的文檔。 | 功能需求說明書 | BA和RD對需求達成一致的理解 | ||
| 設計 | RD將功能需求說明書細化成概要設計說明書甚至詳細設計說明書，使得RD在開發、修改bug、迭代新功能時有據可依。如果沒有這些文檔，后面的溝通費時費力。 在產品的維護期，一旦有問題出現，幾乎無法輕松解決。故一般來說，缺乏本階段的文檔，產品沒有很強的生命力，難以可持續發展。維護成本巨大，所有人都很頭痛。 |
概要設計說明書、詳細設計說明書、 測試用例設計文檔 |
RD內部對需求達成一致的理解 | |
| 編碼和測試 | 如之前所言，編碼期，會進行手動測試和編寫自動化測試。 敏捷開發擁抱需求變化，所以在需求變化發生后，有些功能會回到設計階段甚至需求階段進行討論。 |
代碼、測試用例設計文檔、測試腳本 | 1人1台開發機器 | |
| DEV | 開發測試階段。測試單項功能、手動單元測試，每天運行全部自動化測試並發送問題報告。版本更新非常頻繁。 | 兼有運行測試、運行產品的服務器 | 1台服務器 | 確保單項功能沒有問題 |
| SIT | 集成測試階段。測試N項功能同時運行有沒有問題。在DEV階段開發得到穩定的版本后，再部署到本階段的服務器。 | 運行產品的集成測試服務器 | 1台服務器 | 確保集成測試沒有問題 |
| UAT | 用戶驗收階段。用戶驗收功能是否正確。 | 運行產品的用戶驗收服務器 | 1台服務器 | 確保用戶滿意 |
| Prod | 生產環境階段。用戶使用。 | 運行產品的線上服務器，即生產環境 | 1台服務器或以上 | 產出用戶價值 |
| 維護期 | 功能迭代。 |
1.2.1 敏捷開發方式
針對用戶需求不是所有都明確的、可能發生改變的，敏捷開發可以很好地應對這種情況。敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。敏捷開發屬於增量式開發，在開發軟件過程中，將軟件分為一個個小的模塊。先開發主要的模塊，再開發次要模塊，逐步完善，最終開發出符合需求的軟件產品。它的最大特點是迭代，能更好的應對用戶需求變更較多的情況。
我們特別重視“重復和流程”，這是我們在開發過程中總結出來的，認為做某一類事情的科學方法和步驟。然后不斷的重復按照這個流程去做類似的事情，結果我們會越來越熟練，完成事情效率也會越高。開發人員應該也必須按照“重復和流程”做事情，我們也會不斷的迭代已有的流程，讓團隊受益於新的更有效的做事方法，輕松做好事情。
1.2.2 項目管理工具
JIRA是Atlassian公司出品的項目與事務跟蹤工具，被廣泛應用於敏捷管理、需求收集、任務跟蹤、缺陷跟蹤等工作領域。我們使用它來進行BXERP研發管理。BX團隊研發人員經過討論，制定出一個Sprint沖刺（未來一個短時間段要完成的目標），項目管理人員根據目標細分任務，在上面創建、分配、追蹤任務。將項目分為一個一個的Sprint沖刺去完成，能更好的應對用戶需求的變化。程序員在分配的任務上編寫工作計划、工作總結。工作計划就像茫茫大海中的指南針，讓我們不會失去方向，或避免做了撿芝麻丟西瓜的事情。不管遇到好的壞的，我們都應該善於做工作總結，好的可以分享給其它隊友，壞的可以提醒自己和他人注意，當下一次做類似事情的時候，勢必會胸有成竹、馬到成功。
1.2.3 軟件工程流程細節
前面表格介紹了我們采用的軟件工程流程包含了以下階段：立項、需求分析、設計、編碼和測試、DEV、SIT、UAT、Prod、維護期。在每一個階段，我們都會產出一些文檔。用文檔記錄思考或討論好的事情，讓我們智慧的結晶得以保存，也有利於后期的迭代完善。沒有文檔，我們就無章可循，像一只無頭蒼蠅亂撞，程序員與產品經理打架的悲劇也將不斷重演。
我們認為，需求分析在整個軟件的開發周期中占比是最大的，在開發前期、開發期和開發后期都可能不斷的做着需求分析的工作。所以在前期做需求分析的工作越充足，后面改動越少，額外花費的時間也會越少。產品經理根據市場調研編寫出需求規格說明書，然后與開發人員根據需求規格說明書，編寫出功能需求文檔，開發人員最后根據功能需求說明書編寫出數據庫設計說明書和詳細設計說明書。
各個開發人員的代碼體系不應各成一派，不利於后期的維護。在不斷的迭代中，我們也有了自己的一套代碼架構。該有的代碼結構不能少，不該有的也不能畫蛇添足。這樣統一代碼架構讓隊友間討論彼此代碼的時候能更迅速的了解對方的思路，甚至能指引新員工如何去寫代碼。在編碼階段，我們還會總結出很多好的做事方法，如怎樣解決bug、如何進行代碼的重構等，並記錄到開發文檔當中。
螞蟻金服擁有30多萬的測試用例，說明他們對測試用例是非常重視的。我們開發這個產品也是很注重測試的，認為測試用例越豐富、越全面，開發出來的軟件越穩定、越符合需求。開發人員編寫自動化測試代碼代替重復的手動測試工作。開發人員對自己開發的功能編寫測試用例，測試驅動開發，編寫功能代碼。寫好功能代碼后，根據測試用例編寫自動化測試代碼，確保測試通過，保證功能的穩定。以上的單元測試我們稱為元粒度測試，除此之外，在不斷地迭代過程我們還會產出以下粒度的測試：
（1）細粒度測試：子系統級測試；
（2）中粒度測試：跨子系統級測試；
（3）大粒度測試：用戶接受度測試；
（4）在上述階段會產出功能代碼、測試代碼、測試用例文檔。
在一次次的部署中我們發現，將代碼部署到服務器是一個步驟比較多、比較復雜的過程，人工去完成這些操作會出現遺忘某些步驟、在某些步驟容易出錯的情況。我們就思考能不能把這些操作交給機器去完成，避免這樣的情況發生。於是我們應用了Jenkins，它是一個持續集成工具，結合SVN、MAVEN、python腳本完成自動化部署，可以提高效率和避免手動部署的出錯。Jenkins還可以很好地結合TestNG，使用它運行自動化測試代碼、生成測試報告並發送給開發人員。Jenkins相關用例圖如圖所示：
備注：
“皇后”Windows服務和“小王子”是我們自行開發的工具。“皇后”Windows服務用來創建數據庫，她在接到nbr服務器創建數據庫的請求后開始執行任務。
“小王子”是用來刷新數據庫或配合Jenkins任務啟動tomcat的。
BX開源ERP代碼及開發文檔托管在GitHub：https://github.com/Boxin-ChinaGD/BXERP