如何理解敏捷开发丨日事清产品经理说

敏捷开发流行了这么多年，到底该怎样理解敏捷？什么是敏捷开发？该如何实践？有哪些风险？敏捷开发是否适用于所有开发团队？

---

文 | 日事清产品经理曹德季

为什么要敏捷开发

“没有人喜欢敏捷，但我们不得不敏捷。就像没有人喜欢工作，但你必须工作。”这是我经常用来调侃敏捷的一句话。

试想一下，拿到一份完整详尽的需求文档，逐个功能Coding，测试部署上线。不需要再次确认需求，不会有人打断思路。没有需求更改，只要自己不犯错，不存在推倒重来这才是大部分开发人员最舒服的工作方式吧，简直太完美了。但它很像瀑布，一点都不敏捷。

既然我们喜欢的工作方式是传统的、瀑布的，为什么要敏捷？这还不都是市场环境逼的。今天的市场向我们提出了三个问题：

01如何做出真正满足用户需求的产品？

我不确定这世上是否有人可以做到，他所做出的全部决定都是对的。但绝大多数人是无法一次性做出真正满足用户需求的产品的。我们无法预测未来，我们必须通过一次次的测试，去寻找用户需要的产品是什么？想要更快地获得好的产品，必须迅速将产品推向市场，快速试验，避免走弯路。

02如何满足不断变化的用户需求？

今天所有的事情的都在快速变化，用户的需求也在变化。毫不夸张地说，我们正在全力开发的一些功能，当它们上线的时候，我们的用户已经不再需要了。我们没有办法让一切不变，我们只能选择去拥抱变化。

03如何同时满足不同层次用户的需求？

过去我们的产品会遵循产品生命周期，早期追求新奇的尝鲜者，中期普通大众，后期落后者。今天，产品的生命周期变化非常地快，我们可能会同时面对尝鲜者、普通大众、落后者，不同的用户类型的需求是不一样的，你如何满足他们？我们必须快速响应，没法快速响应，就没法留住用户，没有用户就没有一切。

迅速将产品推向市场，拥抱变化、快速响应。今天的市场向所有的从业者提出了一个要求：拥有应对快速变化的需求的软件开发能力。而敏捷就是赋予团队应对快速变化的需求的软件开发能力的方法，而这就是敏捷流行的原因。

什么是敏捷开发

敏捷绝非某一种特定的开发方法，它只是一种应对快速变化的需求的一种软件开发能力。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。敏捷相信，只要符合这两份文档的开发方法，就能让开发团队拥有应对快速变化需求的能力，这样的开发方法都叫做敏捷开发方法。

最流行的敏捷开发方式是什么

敏捷开发的方法有很多：ASD、AUP、DSDM、XP、FDD、Kanban、RAD、Scrum。目前国内最流行的应属Scrum。

Scrum本意是指橄榄球运动中的“带球过人”，它可以解决非常复杂的项目，并且能高效并创造性地交付高价值的产品。Scrum包含3个角色、3个工件、5个价值观、5个事件（详情https://www.scrum.org/）。

相比其他敏捷方法，Scrum既不简单又不复杂。它有完善的指南，你可以按照指南，轻易在团队内推广尝试。但想要实践好Scrum，又需要很好的技巧。这种易上手难精通的方法，特别适合培训机构。所以近几年，关于Scrum的培训机构遍地都是。可以说，在Scrum流行这件事上，这些培训机构做了很大的贡献。

如何实施Scrum

在团队中实施敏捷开发是一个很有挑战性的工作，尤其是Scrum这种描述比较详细、有很多规则的方法。

如果你打算把所有人召集到一起，宣布我们要实施敏捷开发Scrum，然后就照着Scrum的描述开发方法直接实施，那么，你离失败不远了。想要实施好Scrum，你必须一步步来，一点一点改变团队的习惯，当一项新制度已经变成本能之后，再推行下一项制度。

>>>>第一步，先把团队的开发任务可视化。

你可以用一块白板，让团队成员把所有的开发任务都用便签写好放上去，也可以找一个专业的看板工具。硬广，我推荐日事清，因为这是我做的产品（www.rishiqing.com）。当所有任务都在看板上，尽收眼底，那种感觉还是很棒的。团队中每个人的工作都会被所有人看到，会形成一种无形的监督。

>>>>第二步，引入站会制度。

当团队所有人的任务都在看板后，这些任务的状态是需要有人更新的。无论是专人更新，还是每个人自己更新，都会出现忘记更新，更新不及时的情况。这时，就可以顺势引入站会制度了。每天上班的时候，或者每天下班的时候，所有人站到一起，花15分钟，说一下自己做了什么，准备做什么，所有人一起把看板更新了。

>>>>第三步，引入回顾会议

当站会制度成熟后，就可以挑一个版本发布的日子。等版本发布后，把团队成员叫到一起，开一个回顾会。让团队成员对这个版本开发的情况做个总结，同时可以让大家用便签把这个开发版本遇到的问题、不满写下来。针对这些问题不满，大家一起讨论一些改进方案。

>>>>第四步，引入计划会议

如果再开回顾会的时候，有人提出需求不清，拆解不够细致，工时估算不准之类的问题，那你真是太幸运了。碰到这种情况，你顺势提出这个制度：每个版本开发前，产品经理要和团队人员开个会，一起逐条对需求。产品经理要向团队解释每个需求，并且对团队提出的疑问进行解释和澄清。开发团队要将需求分解成任务，估算工时，最终形成一个开发清单。

>>>>第五步，引入评审会议

当计划会成功开过几次之后，就可以考虑引入评审会了。你可以在某个重大功能发布的时候，把所有项目相关的人员召集起来，向大家展示团队做了哪些了不起的功能，也可以和大家讨论讨论还可以做哪些优化。

>>>>第六步，宣布引入Scrum

当整个流程都跑顺以后，就可以在某次全体会议上，提出我们要实施Scrum了。你需要任命PO、SM，对团队培训Scrum知识，讲解Scrum的价值观。

实施敏捷开发会面临怎样的挑战

1.团队成员对变化的恐惧

实施Scrum最大的挑战来自内部，来自团队对变化的恐惧。每个团队在运营一段时间后都会形成固有的默契和习惯，引入Scrum必然会打破这种习惯。这会让团队很不舒服，团队也会抵制，甚至是反抗。

而且实施敏捷的过程，一定不是一帆风顺的，尤其是实施敏捷的早期阶段，不仅不会对团队产生太大的价值，反而会引起混乱。所以，在实施敏捷的过程中，千万要小心，每次只改变一点点，敏捷地完成敏捷。

2.组织人员的专业化水平

敏捷并不会直接提高团队的专业化水平，反而对团队专业化水平有一定的要求。必要的专业分工、合适的专业能力是必须的。敏捷会让开发整个流程持续运转，当某一个环节专业化能力出现问题的时候，会极大地导致整个流程运转停滞。

平时团队中的问题会在敏捷中快速暴露。一旦出现专业水平问题，要及时解决，补充人员，或者帮助其提高能力。即使问题并不严重，也要在最短的时间解决，否则会影响团队对敏捷的信心。

3.产品经理这个组织Bug

国内在实施Scrum的时候经常会碰到的问题就是团队中会有产品经理这个角色。

一般的处理方法是产品经理当PO，但PO是需要领导开发团队的。国内的产品经理往往不是技术出身，领导开发团队会出很多问题，所以产品经理并不适合当PO。

另一种做法是产品经理做利益相关者，这种做法更不靠谱，利益相关者离团队太远，会出现无法及时响应的问题，时间长了也会导致产品和开发之间关系冷漠，出现隔阂。

我们目前的做法是尝试是引入一个非官方版本的Scrum（Scrum 3.0），他将PO拆分成了业务拥有者（BO）和团队队长（TC）。产品经理担任BO，开发经理担任TC，目前看效果还不错