[知識路書]項目展現

項目相關地址彙總

線上地址：http://47.94.141.56/

前端倉庫：https://github.com/MinJieDev/Roadmap-Frontend

後端倉庫：https://github.com/MinJieDev/Roadmap-Backend

日會彙總：https://www.cnblogs.com/minjiekaifa/p/Scrum_Meetings.html

功能規格：http://www.javashuo.com/article/p-wqsswgyj-nh.html

技術規格：http://www.javashuo.com/article/p-fwhgjhii-nh.html

團隊成員簡介

請參考團隊介紹博客 http://www.javashuo.com/article/p-hzzarakr-nm.html

PM：hdl

前端：zwx yzn ljy ym

後端：zzy zxz

Alpha發佈與新增功能

Realease Alpha v0.1.0: 發佈聲明

Realease Alpha v0.1.1 20200507:

[問題修復]

• 修復外鏈分享時關聯article權限問題
• 修復編輯器頁面自動縮放邏輯異常

[新增功能]

• 編輯器強化
  • 添加結點選擇與基於其的操做，簡化結點、鏈接刪增改邏輯
  • 添加快捷鍵
  • 添加使用幫助
  • 添加文獻筆記的渲染顯示
  • 顯示外觀優化
• 文獻管理
  • 添加bibtxt批量導入文獻
  • 表格顯示優化，支持行內信息摺疊
  • 文獻筆記強化，添加markdown編輯器

部署形式與發佈流程

部署形式：nginx+uwsgi，雙環境

• nginx負責靜態資源分發，並把全部數據請求根據wsgi協議轉發給後端服務
• uwsgi開啓多個後端實例，接收請求並分配後端服務實例響應
• django服務實例響應請求，並經由uwsgi、nginx逐層返回

數據庫開放了測試環境與生產環境，經過替換服務器配置文件實現對不一樣環境的鏈接（默認開發時使用測試環境，線上使用生產環境）

發佈流程：

前端：打包dist並推至服務器，nginx分發容許了熱更新

後端：服務器上拉取生產分支prod，（遷移數據庫後）uwsgi --reload roadmap.pid實現熱更新

目標/用戶/功能描述/預期用戶數量

Alpha階段預期用戶數量：超過100人

實際註冊用戶數量：78人（截至5月8日）

分析：

咱們的推廣思路起初不夠開放，起初只是像其餘團隊同樣在學生大羣中進行廣告投放。考慮到羣內本科生（多爲2017及2018級的大2、大三學生）大多還對文獻閱讀沒有需求，這樣的推廣收效甚微。

5.6及5.7完成alpha階段主體開發更新後，咱們調整思路，進行定向投放，向認識的同窗中已經參與科研的同窗進行說明推廣，用戶量快速增長了一倍。

有理由相信在完成了後續開發完善並使得產品更易用後，咱們延續該思路推廣能更快速地斬獲用戶。

如何知足需求

咱們在頁面中設置了反饋入口，Alpha期間收到39條反饋：

濾除無效信息，列舉有參考意義的反饋以下:

6: 從bibtex導入這個功能作的很好啊，很方便就能導入不少文章
38: 導入Bibtex這個功能不錯，不用一條一條往裏面加

這是對咱們在alpha期間實現的「bibtex批量文獻導入」功能的正向反饋。實際上這個需求是在alpha版本發佈前的課上討論上就被老師提出的，可見其極大補充了文獻管理功能。相應的，有用戶提出了進一步的需求：

20: 有批量導出bibtex麼
17: 贊啊 看paper就靠它了 能不能導出馮如杯格式的文獻引用啊，這幾天快被他搞瘋掉了

這是一個很是合理的需求。若是把咱們的產品歸入學術工做流考慮，寫論文時若是能夠批量導出先前逐條添加的文獻將很是便捷。咱們已經計劃在beta階段實現該需求，前置需求：[爲文獻table view添加複選框和全選按鈕]正在開發

10: 前端很好看，要是有個help頁面就更好了
12: 是花花讓我隨便罵的！並且他說我是目標用戶我就姑且是了！可是我沒用過相似的文獻管理app，不知道怎麼用！因此推薦大家添加一個About頁面！目前就是這樣！

這些反饋實際上說明咱們對產品的使用說明與用戶引導作的還不夠好。在看到該需求後咱們已經第一時間爲路書編輯器添加了操做幫助，同時正在調研更好的引導方法與相應代碼工具。或許寫一篇路書教用戶如何使用路書是一個不錯的主意？

8：中間的body有點小寬了
14: 能夠作一下手機端自適應，手機點開比較混亂哈！其餘都挺好的

這些是用戶提出的對界面佈局及設備適配的需求。實際上咱們初期受限於開發精力，並無對此做出太多考慮。可是考慮到如今移動端設備高度普及，一些基本的適配仍是必要的。咱們會在beta階段視開發進度安排決定是否進一步解決這個問題

23: 驗證碼太難了（哭\n試了3次都不對
20: 登陸的驗證碼太難了！！！

這是feature。咱們認爲對大多數天天看內存模型或者變分推斷相關文獻的用戶來講，口算百之內加法並不算太難。（yzn：已經調整爲30之內加法）

9: 加油呀！沒有域名的大哥哥！

缺錢。騰訊雲域名備案導入阿里雲有點困難。此外咱們原計劃beta之後的最終的發佈形式將是相似overleaf同樣的可自部署的私有云服務，所以這個地址也能夠視做一個非正式的live demo

10: 用戶名不支持中文編碼 但願有空能夠改進哦

已知問題。不支持中文是數據庫對用戶名域設置了latin編碼，這個扔將維持，可是前端註冊時須要提供更易於理解的錯誤反饋。將在beta加強

27: 好使啊。但願有相似博客的交流系統
37: 有沒有交友功能啊
28: 但願能有大佬分享一波本身的路書

社交與學術社區其實是Mendely等產品的殺手功能，但考慮實現難度咱們暫時不予考慮。做爲折衷方案，咱們在alpha版本提供了路書的分享外鏈功能，用戶能夠生成一條路書的分享連接並經過其餘社交媒體傳播，站外用戶藉助這個外鏈能夠無需登錄就看到別人分享的路書。

34: 挺好的工具，能搞個微信小程序麼

暫時不予考慮。但先後端分離確實容許咱們這樣作，或許能夠做爲之後的軟工課程迭代方向。

總結：用戶們對咱們的評價是十分中肯而友善的，咱們也藉助這些反饋發現了不少不足，完善了不少以前沒有考慮的細節，肯定了後續開發的方向。

Q: 對於項目的目標用戶是通常學生的項目， 大家如何找到學生作需求分析？他們給你什麼樣的反饋？

A: 羣發vs逐個推銷，後者數量少但反饋質量通常更高

網狀協做

咱們的開發協做是網狀的：每次同步會你們肯定接下來一個小階段的開發目標與各自負責方向，而後採用分散開發的形式各自完成開發工做。若是遇到問題須要協做解決，由PM組織小規模會議迅速聚焦問題。在兩至三天的迭代後再此進行全體同步會繼續推動。期間穿插結對編程與互動式review，實現項目的異步-同步推動。

即，咱們的整體流程是：同步會 - 小規模會與分散開發 - pr與review - 小規模會與分散開發 - ... - 同步會

在關鍵開發節點（如衝刺末尾、發佈前），根據進度須要安排集中開發，共同解決最後餘留的問題，並集體review發佈前的代碼，完成衝刺

• 與集體日會制度相比，引入分散的小規模會議能夠把每次會議須要解決的問題高度聚焦，提高會議效率
• 參考okr管理，每次同步會爲每一個成員制定階段大目標與小任務，成員就能夠自行評估小任務的完成質量，自主補充小任務改善大目標的實現。這種總-分的管理更加節能。

項目管理與工做流

全部的代碼首先要從主分支（dev分支）遷出，修改後提交到一個新分支（或本身的fork），再發起pull request合入dev分支。要求合併至dev前必須被至少一名其餘開發者複審

發佈時將dev分支的代碼併入prod分支，要求必須至少2人蔘加複審

這樣的雙主分支工做流，容許在發佈前擁有一個彙總分支（dev），全部測試工做在其上完成無誤後再實際併入發佈分支（prod），爲生成環境創造一個錯誤緩衝區，也方便以後引入CICD

時間與效率管理

Q: 團隊如何平衡 時間/質量/資源 爭取如期完成任務的

在不可替代性與可替代性中取得平衡

咱們的分工安排，每一個人主要專精一個小方向的開發，使他/她能夠大幅節約開發時的學習成本，這是開發者的不可替代性。同時同步會又要求全部人必須理解、熟悉其餘人的代碼，使得每一個人都具有可替代性。

這樣，開發能夠高度並行化展開，每一個人總主要負責推動本身所負責的小方向；當某個方向的開發遇到阻力時，即可以抽調其餘方向的開發人員進行協助。

這能夠自適應地最大化時間利用效率。

同時，咱們頻繁引入、穿插結對編程，以此進一步優化開發效率。

測試用例數量與覆蓋率

測試方法論：後端狠，前端穩

前端隨發佈隨測，團隊成員的開發環境覆蓋了windows、ubuntu1604/1804和mac xos，瀏覽器覆蓋ff、chrome。beta時可能考慮引入e2e測試

單元測試主要針對後端展開，前端主要以表格枚舉測試爲主（參考測試報告）

後端目前爲全部模型接口的CURD行爲與權限添加了單元測試，共11個case

藉助coverage實現後端測試覆蓋率分析：

Name                                                Stmts   Miss  Cover
-----------------------------------------------------------------------
roadmapBackend\__init__.py                              0      0   100%
roadmapBackend\settings.py                             22      0   100%
roadmapBackend\urls.py                                  3      0   100%
roadmapData\__init__.py                                 0      0   100%
roadmapData\admin.py                                    5      0   100%
roadmapData\apps.py                                     3      0   100%
roadmapData\migrations\0001_initial.py                  9      0   100%
roadmapData\migrations\0002_feedback.py                 4      0   100%
roadmapData\migrations\0003_auto_20200430_0001.py       6      0   100%
roadmapData\migrations\0004_roadmapshareid.py           5      0   100%
roadmapData\migrations\0005_auto_20200501_1357.py       4      0   100%
roadmapData\migrations\0006_tags.py                     6      0   100%
roadmapData\migrations\0007_auto_20200504_0914.py       6      0   100%
roadmapData\migrations\0008_auto_20200504_0925.py       4      0   100%
roadmapData\migrations\0009_auto_20200504_0928.py       6      0   100%
roadmapData\migrations\__init__.py                      0      0   100%
roadmapData\models.py                                  41      0   100%
roadmapData\serializers.py                             36      0   100%
roadmapData\tests.py                                  197      0   100%
roadmapData\urls.py                                    15      0   100%
roadmapData\utils.py                                   56      5    91%
roadmapData\views.py                                   90      9    90%
-----------------------------------------------------------------------
TOTAL                                                 518     14    97%

代碼規範

對於前端代碼，咱們使用eslint進行自動化的代碼質量檢查

對於後端代碼，咱們要求全部提交的代碼必須經過ide自帶的格式化（基於pep8）

此外在review時會進行必定程度的代碼質量複審，如命名等。原則上，不影響理解的代碼都能經過，咱們只追求自注釋的清晰代碼，不但願把大部分時間花費在維護commit與註釋上。

文檔

不齊全，但夠用。咱們的宗旨是避免一切低效的文檔工做

兩個代碼倉庫分別有基本的部署文檔，同時，

前端：頁面即文檔/註釋即文檔。api調用封裝爲一個總的函數入口，藉助restful api設計使得全局的數據請求邏輯類似。每一個view拆分紅一個vue組件，使得頁面邏輯內聚，可讀易懂

後端：自動化文檔。藉助django restful framework與coreapi生成的自動api文檔，便利先後端協做的同時解放後端同窗雙手

燃盡圖與功能發佈

角色與貢獻

貢獻量化表

姓名	任務	按時(-5~1)	質量(-2~2)	任務量(1~5)x10
hdl	初始化CI/CD	-1	1	3	30
hdl	路書編輯中自動添加引用關係	0	1	3	31
hdl	將author和note綁定在表單中	1	2	1	13
hdl	hdl: fix bugs: editor; reader; router; package.json	0	1	3	31
hdl	Hdl add markdown preview and style	0	1	3	31
hdl	博客撰寫/PM工做/彙報展現	0	0	50	500
					636
ljy	錯誤處理模態框封裝	1	1	1	12
ljy	爲文獻管理列表添加按鈕欄	0	1	1	11
ljy	添加文獻CU表單面板	0	2	4	42
ljy	添加路書管理table view	0	1	5	51
ljy	文獻CU抽屜綁定form data	1	0	4	41
ljy	文獻表單數據項中增長[引用關係]	0	1	2	21
ljy	用戶反饋收集	0	2	4	42
ljy	退出按鈕	0	1	3	31
ljy	BibTex import in article table	0	1	4	41
ljy	添加文獻筆記markdown編輯器	0	1	3	31
ljy	Change the description in README	0	1	1	11
					334
ym	引入table view組件	0	2	4	42
ym	MindTable組件添加data屬性並接入	0	2	2	22
ym	文獻管理頁接入數據加載api	0	2	1.5	17
ym	文獻管理頁增刪查對接後端數據api	0	1	3	31
					112
yzn	配置並封裝axios	1	1	2	22
yzn	爲axios配置攔截器	0	1	3	31
yzn	合併req函數的param與data參數	-1	1	1	10
yzn	文獻管理頁接入數據加載api	0	1	1.5	16
yzn	登錄界面與緩存	0	1	4	41
yzn	具備權限認證的Request接口	1	1	3	32
yzn	註冊界面	0	1	5	51
yzn	增長卡片式的登陸歡迎界面	1	1	5	52
					255
zwx	接入vue-mindmap	0	1	1	11
zwx	配置vuex	0	1	1	11
zwx	添加「新建結點」與「新建鏈接」按鈕控件	0	1	4	41
zwx	mindmap編輯器加強	0	1	4	41
zwx	路書編輯接入api：獲取文獻列表	1	1	3	32
zwx	路書編輯：接入路書加載api	0	1	3	31
zwx	路書編輯：接入路書上傳API	0	2	3	32
zwx	路書管理頁面接入API	0	0	3	30
zwx	路書添加title CUR	0	1	3	31
zwx	建立reader view	0	1	3	31
zwx	路書接入描述	0	0	2	20
zwx	路書添加結點id-title映射	0	1	4	41
zwx	路書樣式：文獻節點顏色；線形加箭頭；拖拽節點去抖動	0	1	4	41
zwx	add share button in editor and reader; fix share cannot get article bug	0	1	1	11
zwx	login-error-modal-fix	0	1	3	31
zwx	路書編輯器加強：點擊事件編輯路書	0	1	5	51
zwx	爲編輯器添加快捷鍵	0	2	4	42
zwx	添加Icon 添加幫助	0	1	2	21
zwx	路書閱覽和編輯界面展現note	0	1	3	31
					580
zxz	添加requirements.txt	0	1	1	11
zxz	添加素材實體序列化器	0	1	3	31
zxz	完善API接口	0	1	2	21
zxz	增長路書名稱字段	1	1	3	32
zxz	文獻雙向引用	0	1	3	31
zxz	fix bug: modify article_references symmetrical from true to false	0	1	3	31
zxz	容許空的URL	0	1	1	11
zxz	添加JWT登陸認證	0	1	4	41
zxz	添加用戶反饋接口	1	1	2	22
zxz	remove feedback permission	0	1	3	31
zxz	change user-article relationship to 'one2one'	0	1	2	21
zxz	添加Permission測試和Auth測試	0	1	4	41
總					324
zzy	根據ER圖添加Models	0	2	1	12
zzy	添加用戶與路書實體序列化器	1	1	2	22
zzy	生成簡易接口文檔	0	2	2	22
zzy	添加單元測試	0	1	3	31
zzy	完善API接口	0	1	1	11
zzy	ignore venv; setting allow all host	0	2	1	12
zzy	fix bug: add id for roadmaplist	0	1	1	11
zzy	Add jwt	0	1	2	21
zzy	後端支持tags	0	2	3	32
zzy	隨筆curd	0	1	3	31
zzy	添加models的CURD測試	1	1	4	42
總					247

最終分配

根據[知識路書]團隊貢獻分數分配方案獲得最終分配：

總分	636	334	112	255	580	324	247	2488
比例	0.25562701	0.13424437	0.04501608	0.10249196	0.23311897	0.13022508	0.09927653	1
實際量化分	8.94694534	4.69855305	1.5755627	3.58721865	8.15916399	4.55787781	3.47467846	35
去重量化分	8	6	2	4	7	5	3	35
總分	53	51	47	49	52	50	48	——

特點功能總結

• 文獻管理
  • 批量bibtxt導入
  • 支持markdown的文獻筆記編輯
  • 能夠自定義的文獻引用關係
• 路書編輯
  • 定製的路書編輯器，支持快捷鍵、符合思惟直覺的高效編輯方式
  • 自動鏈接文獻引用關係，一次定義，處處鏈接，直觀呈現文獻發展脈絡
• 路書閱覽
  • 支持生成站外分享連接，分享給親朋好友，無需登錄便可一覽你精心編輯的知識路書

beta開發計劃

• 外觀與顯示
  • 增長用戶引導
  • 優化文案，消除中英文混雜與歧義
  • 整理通知與模態框提示
• 文獻管理
  • 引入條件搜索與分頁，更快更精準定位知識
  • 引入自定義標籤，讓文獻找到組織
  • 複選與文獻批量導出
• 路書編輯
  • 容許連接添加弧度，編輯出更有人情味的路書
• 路書閱讀與分享
  • 爲分享頁面添加筆記查看

收穫與啓示

hdl：PM初體驗。感受本身不少地方作的不是很好，好比開完會後老是不能即便完成博客記錄、給你們分配的任務常常亂七八糟。好在隊友各個都很能打，你們一塊兒寫出本身（和用戶）須要的、喜歡的產品，一點一點打磨，這個過程很開心。軟工的敏捷開發實踐帶給我良多收穫，好比如何向其餘人清楚表述個人想法，如何向他人請教問題更能節省雙方時間，如何更快讓別人理解個人思路云云。以前一直對PM這個崗位有一些偏見與誤解，實際上手幹起來發現PM這個崗位是軟件團隊中的掌舵者，責任重大，一點也沒必要開發輕鬆，不只要對項目、對技術、對功能需求足夠熟悉，還要學習一些管理技巧，確保團隊的開發進度與方向正常。這再一次啓發我，軟件工程是一門十分深奧的管理哲學。