根據用戶反饋,是否發現以前的需求分析有誤差?爲何會出現這種誤差?beta階段大家是否能真的分析清楚用戶需求?如何作到?html
根據alpha階段的推廣狀況以及用戶反饋,咱們吸收了經驗教訓。本項目的真正用戶是有實際科研需求的研究生、老師等科研人員。咱們對這些典型用戶進行了定向推廣,收集到了不少寶貴的評價和改進意見。經過對這些反饋信息的分析,咱們從新思考了咱們的需求,制定了在beta階段的計劃。前端
知識路書的產品定位是——圖形化文獻管理工具,主要的核心需求有如下兩點vue
這二者須要有機緊密結合,才能最大限度地發揮知識路書的產品效力。git
在alpha階段,咱們已經完成了文獻管理工具和圖形化的路書編輯器、閱覽器,咱們在beta階段要着重作好此兩者的有機結合,使用戶更方便地使用圖形化的方式管理文獻、梳理文獻。github
如何才能更好地結合上述兩大主要功能呢?後端
本階段要新增什麼功能?是否須要新的原型設計?是否有新增典型用戶?新增的功能有什麼驗收標準?api
根據上述需求,咱們總結出如下需求,原型設計、典型用戶與alpha階段相同。驗收標準:後端作到覆蓋測試,前端作到無顯式錯誤。markdown
路書和文獻管理框架
路書編輯器編輯器
技術上相對前一階段須要做何改進?好比:增長對代碼規範的要求、針對新的功能點所須要掌握的新技術、對代碼流程管理上的一些規範
咱們開發團隊在alpha階段的代碼管理作的很好,使用eslint進行代碼風格管理,使用github平臺的看板管理、issue、Pull request等功能,實現了十分高效的開發管理。
在本階段,咱們要繼續堅持上一階段的管理模式,幫助新進成員更快熟悉、適應咱們的管理模式。
上面這些要作的事情,如何具體分配到我的?請注意計劃的粒度。
分組 | 姓名 | 任務 | 參考難度 | 預計時長 |
---|---|---|---|---|
前端 | ljy | 引入tag標籤 | 3 | 6h |
- | 批量導出bibtex | 1 | 2h | |
- | 文獻閱讀計劃:已讀 未讀 | 2 | 4h | |
- | markdown 優化 | 2 | 4h | |
- | 隨筆編輯器 | 4 | 8h | |
- | yzn | 麪包屑改進crumb+動態路由 | 2 | 4h |
- | help文檔或新手引導、爲新用戶提供模板路書 | 2 | 4h | |
- | 路書管理的卡片佈局 | 3 | 6h | |
- | zwx | 拖拽方式添加節點 | 4 | 8h |
- | 路書的編輯撤銷 | 4 | 8h | |
- | 過長的文獻名如何顯示在路書中(alias?) | 2 | 4h | |
- | 隨筆與路書的結合 | 3 | 6h | |
- | ym | 批量導出bibtex | 1 | 2h |
- | 多選與刪除 | 3 | 6h | |
- | 引入filter | 4 | 8h | |
- | cc | 熟悉項目管理工做流 | 2 | 4h |
- | 曲線鏈接 | 4 | 8h | |
- | 用戶自定義結點顏色、字體等 | 3 | 6h | |
- | 文獻筆記在路書中的顯示形式 | 3 | 6h | |
後端 | zzy | 引入filter | 4 | 8h |
- | 分頁功能 | 3 | 6h | |
- | 隨筆、文獻計劃的相關api | 4 | 8h | |
- | zxz | 引入filter | 4 | 8h |
- | 分頁功能 | 3 | 6h | |
- | 隨筆、文獻計劃的相關api | 4 | 8h |
本階段是否會嘗試新的分工?新人入會如何進行培訓?
cc同窗在原項目軟工管理平臺的開發中,有過前端的vue開發經驗,咱們的項目也是使用vue框架搭建的前端,因此比較適合cc同窗的技術棧。通過協商,cc同窗與zwx一同進行路書編輯器相關功能的開發。
因爲本項目原PM奆佬因某種奇特的方式不幸離開,咱們以一樣的奇特方式,推選出新的PM菜🐔zwx同窗。其在alpha階段負責路書編輯器相關功能的開發,在beta階段將負責PM的相關工做以及與cc同窗共同開發路書編輯器功能。
咱們對新人進行了項目培訓,主要分爲三個部分
cc同窗十分努力,已經成功掌握了咱們的項目開發工做流,並且已經成功提交了一個修復bug的PR,審覈已經過。
預祝敏傑開發團隊beta階段開發順利。