敏捷开发

敏捷原则比敏捷框架更重要


2018年5月10日,敏捷宣言的发起人之一Ron Jeffries公开宣称“开发人员应放弃使用敏捷框架”。Ron Jeffries提到,诸如Scrum和看板之类的敏捷框架,与敏捷原则相差甚远,并不能为开发人员提供好的服务。他希望开发人员重新关注敏捷原则,并放弃使用这些敏捷框架。

我们询问了一些团队在实际工作中如何进行敏捷实践,希望大家在公开场合(互联网或社交媒体上)讲述他们的敏捷实践,以此进行一个大规模的敏捷回顾。我们将这次活动称为“Retro On Agile”。

我们想知道敏捷软件开发这种方式在哪些方面表现得比较好,又在哪些方面可以得到提升,希望大家可以分享他们在实践过程中遇到的困难,付出的努力以及收获的成功。 作为敏捷工具的开发者,我们需要收集这些反馈,以便更好地升级产品,为客户提供更好的服务。

实施敏捷后的反馈

在这次活动之中,大多数参与者都反应“敏捷”并未让他们的团队变得更好。

“虽然敏捷被定义为具体的方法论,但并未真正提高工作的效率。”

“希望人们能更多的注重敏捷的原则和价值观,而不是专注于流程和方法论。”

“能不能不将敏捷当做一个具体的执行方法?”

“如果人们都能意识到敏捷中比站立会议更重要的是 敏捷原则 就好了…”

以上都是他们真是的反馈。与此同时,我们也收到了很多积极的反馈。例如:

“我们团队的敏捷过程涉及了假设,实验,测试和执行,而不仅仅只是交付了。”

“软件开发的重点已从交付软件转变为交付价值。”

“工作更加智能,解决问题的方式也在通过协作不断发展。”

“我喜欢在敏捷过程中的交流,可以帮助我们搞清楚推理中的假设和差距。”

还有一些其他观点,可以看出研发团队对敏捷的应用有各种各样的想象。

“能否在学校早期教一些敏捷技术,使孩子们可以从中受益,比如学习如何有效地计划功课?”

“如果我们可以将看板制作成三维的会怎么样?另一个会是什么维度?会有什么效果?”

“如果整个公司都实践敏捷,那该怎么操作?我们的团队会是什么样?”

“如果 Scrum和看板不是敏捷的唯一方法,那会怎么样?”

关于敏捷,人们抱怨的主要内容之一就是: 敏捷框架 。这也是Ron Jeffries所提出的问题。众所周知,Scrum 就是目前大多数团队参考的敏捷操作指南。其实这一类敏捷框架在实施过程中都会带来一些负担。例如要利用 Scrum,你必须雇用Scrum敏捷教练。而看板思想有些单一,仅能作为一个任务拖动系统。这些结构和流程虽然有用,但并非适用于所有团队。 敏捷不仅仅是具体的执行方法,还需要关注其它的事。

更好的使用敏捷

我们为团队提供了一个简单而灵活的工作板,每个成员都可以参与进来。从进入项目的那一刻起,团队成员可以自行调整使用方式,让工作更加得心应手。随着团队对工作板的适应程度提高,成员自行添加、删除结构,甚至修改流程都变得非常简单。与具有大量内置流程的Scrum项目模板相比,这种方式更加简洁流畅。

敏捷团队将特性和用户故事引入项目并快速地配置使用,可以节省很多时间。团队成员可以自行调整展示页面,减少在项目模板中统一设置所花费的时间,从而集中在手头的工作上。

除了深刻理解敏捷原则并在团队中进行尝试之外,我们也可以使用优秀的工具来帮助我们进行协作。好的协作工具会让团队的工作效率快速提升。在Worktile Agile 当中,可以轻松规划产品路线图、版本以及迭代,快速安排待办事项,并通过燃尽图、成员工作量图等跟踪迭代进度;同时使用Worktile Testhub 进行测试管理,无缝连接用户故事和测试用例,快速规划测试用例,组织测试计划,有效保证迭代质量。

现在,我们正在为产品提供更多灵活的配置。客户使用Worktile 研发产品的频率开始提升,并且一些新用户可以更快地掌握敏捷基础知识。我们相信这种灵活的方式更加接近敏捷的价值观。我们不再让客户去适应Scrum框架,而是在帮助他们真正地进行敏捷。

我们想要为敏捷团队消除不必要的开销或任何复杂的规则。不管是经验丰富的敏捷从业人员,还是初次接触敏捷的团队,都可以在Worktile Agile 进行敏捷项目管理。我们希望帮助团队更好地使用敏捷。

原文作者:MAX REHKOPF
译者:Worktile 禹灏波
文章首发于Worktile官方博客,转载请注明来源。

智齿客服