一個極簡的敏捷項目管理系統。
一個PMP和ACP的結合的產物，以敏捷為核心卻有那么一丁點的傳統。
只適合小團隊，而且負責人可能身兼數職。
GeeTask不是完整的敏捷思想的實現，主要是根據自己的工作環境做了妥協。 我現在的團隊是只有4個人團隊包括我自己，如果完全按照敏捷過程的實施就會很繁瑣， 特別是在關鍵角色上不能分離，比如PO和PM都是同一個人。 另外，公司的項目的壓力以及人員的水平和思想還很難完全按照敏捷的思想去做。像自愿領取任務等這樣的工作就很難。
妥協是為了簡化
- 系統使用必須簡單，沒有繁瑣的各種設置。在項目中分別使用過redmine,禪道，在小團隊中很難推，因為添加一個任務或者修改一個任務要設置很多不明覺厲的各種參數，暈！
- 增加了會議記錄的功能。會議很重要，我們的需要溝通，我們會花跟多的時間溝通，溝通到每個人都理解對方的需求，甚至寫代碼的邏輯都會確定清楚。
- 增加了變更記錄的功能。系統發布的時候，需要清楚，生產環境會有哪些變更，比如SQL等
- 增加了IM機器人的功能。這個功能是增值功能，目的是讓團隊時刻收到任務變更的通知，在通知中會指名道姓（表揚）。從心理學上來說，每個人都希望看到自己的名字在一些場合出現會。這種暗示會提高積極性。
系統特點
- 基于Yii2框架
- 使用了Yii的RBAC權限框架，在使用的過程中限制了原生的靈活（放棄了可以給某個人分配具體的權限，以及分配多角色多權限），只個一個用戶安排一個角色。個人認為這樣的系統沒有必要把權限分配弄的過于復雜。本身Yii的RBAC權限對一般的初學者還有點難度，而且也很難圖形化表達角色權限規則等等的關系。本人前端技術有限，之前在其他的項目嘗試過，盡管表達了，但是還是很難簡化。如果有興趣可以留言。
- 本系統盡量保證了RBAC的功能，比如規則的擴展，系統自實現了項目更新規則（更新自己創建的項目），其他地方暫時沒有（只是覺得這樣的需求不強烈）。有興趣的可以自己研究。
- 在Yii的事件中增加了自定義的簡單事件模型（不是對原生事件的擴展，只是可以通過原生的事件觸發），通過后臺管理，靈活擴展
- 消息機器人，默認實現了釘釘機器。只是在添加或修改故事的時候觸發消息。基于自定義事件實現，抽象出各種事件處理句柄。通過后臺管理，靈活擴展自己需要的機器人。支持自定義消息模板
- 項目管理獨立化，用戶時刻只能在一個項目的會話下工作，通過切換控制臺的功能在用戶參與的多個項目中切換工作環境。
- 支持故事狀態自定義。本系統默認定義的狀態的出發點是類似敏捷的完成定義
- 每個項目可以獨立配置阿里云的日志服務只讀模塊，方便開發者查看線上日志
- 產品Backlog
- 會議記錄
- 變更記錄
- 增加了emoji表情，讓工作的表達也有充滿表情
是如何使用的
- 項目應該化80%的時間理解需求確定需求，所有開會討論是必要的。
- 核心是計劃（迭代），負責人必須積極主動的推動團隊的積極參與，一定要保持每個人都能參與到，建議每日站立會議，形成開會討論的習慣，引導團隊逐步導向團隊自治
- 項目的主持者是推動的主要動力，也是主要的使用者。負責主持會議，協調和分配任務，主持所有的會議并將結果更新到系統中，也人員可以輪崗記錄會議。
- 我們項目約定的迭代周期是1周，一般周5安排下周的開發任務，盡量保證一周完成。
- 如果本周沒完成的，大家一起開會討論，分析原因，是否安排到下周或者放到產品backlog中
機器人如何使用
可以參考釘釘的機器人文檔：https://open-doc.dingtalk.com/docs/doc.htm?treeId=257&articleId=105735&docType=1
效果圖
項目地址
https://gitee.com/dungang/gee-task
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
