良工+利器，讓軟件研發真正敏捷！

寫在前面：本文做者是有着多年敏捷開發團隊管理和實踐經驗的郭正元老師。郭正元老師公衆號「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。

軟件研發項目管理產品各有千秋。可是，筆者深入的一個體會是，若是一個軟件設置複雜，須要有經驗的管理員來配置才能順利使用，並且插件衆多，就會讓人疲於應付。

若是使用一個工具，它具有了所有功能。就可讓良工真正用上利器，讓複雜的事情變得簡單。