写在前面：本文作者是有着多年敏捷开发团队管理和实践经验的郭正元老师。郭正元老师公众号「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。
软件研发项目管理产品各有千秋。但是，笔者深刻的一个体会是，如果一个软件设置复杂，需要有经验的管理员来配置才能顺利使用，而且插件众多，就会让人疲于应付。
如果使用一个工具，它具备了全部功能。就可以让良工真正用上利器，让复杂的事情变得简单。
————————————————
版权声明：本文为CSDN博主「万事ONES」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ones_ai/article/details/105521646
660
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
