寫在前面：本文作者是有著多年敏捷開發團隊管理和實踐經驗的郭正元老師。郭正元老師公眾號「IT老船長」，會不定期分享一些技術乾貨內容供粉絲學習與交流，歡迎各位技術研發愛好者們前往關注。今天來看看郭正元老師如何用ONES進行敏捷的最佳實踐。
眾所周知，敏捷開發是以用戶需求為導向，需求進化為核心，採用迭代、逐步完善的方式進行軟件開發；其中的核心是“用戶需求進化”與“迭代、逐步完善”！前者保證我們所做的工作於用戶（包含終端用戶、產品、領導、實施、研發等所有提出合理需求的人）而言是有意義的（或者說有商業價值的），後者保證需求開發的有序性、並在一定週期內的研發工作不會被打斷。
想要真正落地敏捷開發整套流程，必須實際貫徹敏捷的“三三五”原則，即：3個角色、3個工件、5個過程，並且配合上好用的管理工具 ，才能相得益彰，真正將敏捷開發貫徹實施起來。
能夠清晰理解、貫徹敏捷“三三五”原則的，是優良工程師，而能夠理解研發、順利推進軟件項目管理的的優秀工具才是真正的利器。
良工與利器兩者的結合，讓產品經理輕鬆、工程師順心、客戶滿意，也使得軟件研發達到真正的敏捷。總結起來一句話就是：
「把複雜的事情變簡單——貢獻！」
筆者從事軟件研發十餘年，目前推進所帶團隊研發進度的工具是ONES。今天就跟大家討論一下ONES是如何是踐行敏捷開發的“三三五”原則的。
三個角色，完成三個工件
敏捷開發中，以Scrum為例，三個角色分別是：
l 產品負責人（Product Owner），通常是產品經理；
l 開發團隊（Development Team），就是研發工程師團隊；
l Scrum Master，通常是研發經理，筆者目前就是團隊Scrum Master
三個角色，通力配合，溝通成本可以降低，項目有跡可循。
在最通用的Scrum中，三個工件分別是：
l 產品待辦列表（Product Backlog）
l 衝刺待辦列表（Sprint Backlog）
l 增量
一個理想的流程，看起來是這樣的：
產品負責人，整理需求，錄入系統，明確“想要什麼”，完成Scrum敏捷開發的第一個工件——“產品待辦列表”。
之後，產品負責人溝通Scrum團隊，明確確認任務優先級。
Scrum Master和團隊拆解需求，形成一個一個任務。
再根據優先級，確認當前研發衝刺（Sprint）需要做什麼，完成Scrum敏捷開發第二個工件——“衝刺待辦列表”。
研發工程師，認領任務，明確需求內容，構思實現思路。
研發工程師在開發過程中，更新任務狀態。更新中完成了Scrum敏捷開發的第三個工件——“增量”。
Scrum Master作為團隊領導和對外接口人，實時查看研發進度。
ONES提供了最能代表Scrum敏捷開發的“燃盡圖”。
為了更貼閤中國特色的敏捷開發，常見的報表，也一應俱全。
五個事件，是指Sprint研發衝刺的階段拆解，分別是：
l Sprint計劃
l 每日站會
l Sprint執行
l Sprint評審
l Sprint回顧
五個事件，除了“每日站會”，均在ONES軟件中，已經在上文提到的“三個角色”完成“三個工件”中一一落實。
而實際上，筆者在帶著團隊開展“每日站會”的時候，也是投影出ONES的敏捷管理泳道，一個一個任務確認的。
Scrum敏捷開發的“每日站會”，只明確問題，不做具體討論，所以一個ONES的電子展板，讓團隊工作一目瞭然。
由中國特色的Scrum敏捷開發，怎麼能少了缺陷管理和報告流程？
不管對外匯報質量管理總體結果：
還是全員大會上，給出趨勢分析：
ONES的產品設計理念總結起來其實就是「一個工具，全部功能。」
筆者想起之前帶領軟件研發團隊工作時，也用過國內外的其它工具，其中不乏大名鼎鼎的Jira。
軟件研發項目管理產品各有千秋。但是，筆者深刻的一個體會是，如果一個軟件設置複雜，需要有經驗的管理員來配置才能順利使用，而且插件眾多，就會讓人疲於應付。
如果使用一個工具，它具備了全部功能。就可以讓良工真正用上利器，讓複雜的事情變得簡單。
