谈敏捷开发

这年头不做敏捷开发都不好意思说自己是做软件开发的。很多人都知道敏捷开发或者项目就在敏捷开发中，但是越来越多的人对敏捷开发表示不理解了。我经常听身边的人问：敏捷是什么？究竟什么才是敏捷开发？难道敏捷开发就是这样吗？

这就跟早上正常点上个班，周末加个班就喊“狼性”是一个道理：很多人认为早上开站立会就是敏捷了！

我不是科班出身，对敏捷开发了解是工作时候了解的，很早工作的时候有个雅虎来的牛人加入公司，他本来就是做流程软件的，天天给我们将如何敏捷，如何走开发流程，第一次听说还有敏捷开发这种东西。之后在腾讯工作，团队有个业内Scrum大师，参与了很多大型项目，包括腾讯搜搜项目整个的研发流程制订之类，那段时间给我们团队做流程优化，也给我们分享，经他推荐，也算读了几本Scrum的书籍。下面简单谈下自己的认识。

敏捷开发和每日站会的关系

如果要问：敏捷开发和站会是什么关系？我想说：的确有关系，但要知道不是你把敏捷的流程都走一遍就真的敏捷了。

scrum会议可以分为：sprint计划会，每日站会，评审会和回顾会。

个人认为：敏捷提到的站会只是一天固定时间沟通的会议，主要目的还是跟进进度、暴漏问题，PO（product owner）和SM（Scrum Master）意图通过站会来完成自己的职责：

• 协调资源，解决项目的障碍

• 保证项目进度

• 保证团队内角色之间的协作

• 团队跟其他团队的接口人，协调沟通

而现实中的站会可能是下面的样子：

• PM忙着改需求

• RD讨论解决方案

• UE忙着改图

• QA在报bug

• 无关紧要的人在打哈欠

敏捷开发究竟是怎样的

敏捷开发是一套经过多年实践而总结出来的一套方法论。所以不要神化，更不要跟风，适合自己的team就好（本人一直实用主义，从不盲从）。

敏捷总结了一些项目中常常遇见的问题，并且想通过敏捷的流程来避免这些问题。而现在很多公司很多项目用了敏捷（或者敏捷扩展版），实际参加敏捷的童鞋并没有「敏捷」，而是在抱怨：为什么这么多流程？为什么这么多会议？

究竟错在哪里？？！

往往大公司一个项目需要牵扯太多人，一次发布会可以开5个小时，涉及到的人都参加，前面的人七嘴八舌各抒己见，后面的人各干个事。可能某些人只知道自己负责的部分，绝大多数都不知道自己想要的是怎样的一个产品，产品的roadmap是什么，该坚持的不坚持，最多的情况是在听取了意见后做了妥协。

团队太大，还会出现一些鸡同鸭讲的会议，比如每日站会：先是UE，然后RD，后是QA，再。。。

这样前面讲的事情，根本自己都不知道干啥，听不懂，那为啥还要非拉在一起开会呢？

team太大

最大的错误是team太大，忽略了个体。敏捷有个说法：2个披萨。也就说团队人数要控制在两个披萨够吃内。

敏捷提倡对团队人的信任，充分调动团队中每个人的积极性，发挥最大的效率。

当一个项目team太大的时候，可以考虑拆成几个敏捷团队来执行，团队之间共享角色，来实现沟通。比如：UE开UE的会，而参加RD的会就会昏昏欲睡；何必呢~当涉及到其他团队角色的时候可以叫上一起啊。

其实这在scrum里面有个专业术语：scrum of scrums。我的想得到，大佬想不到吗？当然我相信他们也想得到，不过没有什么比成功更具有说服力。所以也许坚持经验更重要。

太看重流程和工具

比如说燃起图（燃尽图）这件事，就是为了大家看到每天的进度，而老一些“敏捷er”往往对新“敏捷er”说：task要拆的够细，每天都有事情做，每天都有事情完成，要燃起图好看。

你是知道的中国人都是很聪明的，于是会想尽办法「造」task，因为我要保证第二天我的燃起图正常，不然会被点名批评的，被批评了KPI怎么办？

对于流程来说，当流程太复杂的时候，我们应该勇于提出来，去精简。当一个新的SM（搞错意思的面壁三分钟）接棒的时候，应该审视之前的流程，是否合理，是否需要调整。

现在往往是大家觉得项目做成了，leader升级了，留下的就是宝贵的经验，下一个leader就会按照这个流程来做，尽快他也深受其害，但是这是「宝贵经验」，之前的leader就是这样成功的，为什么我们要颠覆呢？

并行还是串行

也许好几个项目并行，一个角色穿梭于多个项目中，这样貌似在并行，其实人还是那个人，他不可能同时做两件事情，这不是一种提高效率的事情。人只有在专注一件事情上，才能发挥最大的效率。多个事情并行会分散精力。这就像番茄钟要25分钟专注一件事情的道理一样的。

穷则变，变则通

为啥大家都怨声载道还要摸黑走下去呢？该变就变！

SM需要做的是：要每个角色效率都最大化利用，为角色提供更舒适的工作环境（包括流程）。

1. 个体和互动高于流程和工具

2. 工作的软件 高于详尽的文档

3. 客户合作 高于合同谈判

4. 响应变化 高于遵循计划