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 进行敏捷项目管理。我们希望帮助团队更好地使用敏捷。
Worktile 官网：worktile.com
原文作者：MAX REHKOPF
译者：Worktile 禹灏波
文章首发于「Worktile官方博客」，转载请注明出处。
来源：oschina
链接：https://my.oschina.net/worktile/blog/3169043