良工+利器,让软件研发真正敏捷!

写在前面:本文作者是有着多年敏捷开发团队管理和实践经验的郭正元老师。郭正元老师公众号「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。

软件研发项目管理产品各有千秋。但是,笔者深刻的一个体会是,如果一个软件设置复杂,需要有经验的管理员来配置才能顺利使用,而且插件众多,就会让人疲于应付。

如果使用一个工具,它具备了全部功能。就可以让良工真正用上利器,让复杂的事情变得简单。

你可能感兴趣的:(敏捷开发,agile)