误解
人人都在谈敏捷开发。但真正成功的案例其实不多，百度上搜“敏捷开发”，除掉推广，第一条是“为什么我不推荐敏捷开发”。令人无语。
对敏捷开发存在误解太多，就以那篇头条来说，作者其实只试了皮毛，或者说只看到了粗浅尝试带来的恶果，而没有领会Agile Development的本质。
最大的误解，就是把敏捷当做了便捷，以为有一条捷径。
首先来自老板，听说有“敏捷开发”这样的好东西，就可以肆无忌惮地压团队时间。
“啊，这个要这么久才能完成？！为什么你们不采用敏捷开发呢？”
在这种思维主导下，开发团队不管应该不应该，只能把文档、性能、安全、交互体验等一时半会不爆发的问题搁置一边再说。
对老板来说，敏捷开发最好的操作手段是daily meeting。因为老板喜欢开会嘛，每天固定一个时间，让所有团队成员汇报进度。Daily meeting变成了daily report。
其次来自程序员。
现在的程序员应该70%以上不是计算机专业出身吧。或许对开发语言很熟，但是缺少系统逻辑思维训练。更重要的是，严重缺乏项目管理/文档管理的历练。他们既不知道流程的重要性，也不知道死于流程的局限。对于敏捷开发，他们只是抱着一种学语言的态度去学习敏捷开发的具体方法，以及避开文档、流程的小确幸。
所以对程序员来说，敏捷开发的“最大好处”是不用写文档。（因为程序员最讨厌写文档了，仅次于看别人的代码而没有文档。）
在我有限的接触中发现，所谓敏捷开发培训师往往是一些专业的培训师，而不是产品经理或项目经理。他们培训敏捷开发，就像培训OFFICE办公软件一样。对他们而言，敏捷开发当然是包治百病的灵丹妙药。他们就是“捷径”的推销员，而不是经历过爬坑的真正开发者。
本质
05年我第一次接触SCRUM。培训老师第一堂课便说，SCRUM is not a silver bullet!敏捷开发并非万能。
同期培训的同学，有很多来自微软和雅虎，个个都是IT精英。和他们聊天时听得出来，这些大公司不缺人才，但依然严重困扰于决策流程长，项目周期严重超标等问题。
那么敏捷究竟能解决什么问题？
或者反过来看，如果不用敏捷，那么可以采用什么方法呢？那就是传统的软件工程啊。其实这个问题也经常被提到，敏捷开发VSCMMI。
敏捷和软件工程都是好东西，适用不同场景。问题的实质是，时代变了。
在PC时代，所谓软件开发基本是2B。那个时候也没有产品经理，而是需求分析师和项目经理。软件收入是靠做项目，或者卖拷贝。这就决定了软件项目的成功取决于两点：
正确理解客户需求（或者说服客户接受现有方案）；~需求分析师
用最小的人力成本完成客户需求；~项目经理
CMMI在做的努力，就是想对某个领域的知识进行模式化，然后对这个领域的不同客户复制项目。可复制性和可配置性越好，边际利润就越高。在这个方向上，软件开发的高峰是SAP，IBM，Oracle的超级ERP软件。在他们所服务的领域内，企业模式是固定的，至少是相对固定的。
而这种软件服务领域的试错成本非常高，一个企业不可能因为软件因素而模拟运行或者停运。
但是在敏捷开发时代，环境变了。其实是由于环境先变了，才使得敏捷开发有了需要。互联网带来了两个变化：
首先世界是平的了。软件的复制和扩散大大加强，信息以前所未有的速度传播到个人。以前必须通过企业再传递到个人的服务，可以直接为个人服务。以前是为出租公司写调度系统，现在是为UBER、滴滴写算法。
其次，世界是个人的。每个人都有自己独特的需求要求被满足，每个人的声音也可以通过互联网传播。过去只要版本号一定，你打开WORLD、EXCEL后的界面肯定是一样的。但今天每个人每个时刻看到的FACEBOOK、微信都是不一样的。
这两个变化导致软件的高度多样性和高速演化。过去我们在盗版市场可以用一张光盘收罗一年的新软件和新游戏，而现在APPSTORE一天发布的新应用我们都看不过来。张小龙过去也许一年只需要更新Foxmail一次，但微信一个月就得升级。
因此，发现用户想要什么，比工程师能做什么成为更重要的话题。这也是为什么沃茨尼克虽然在极客心目中仍然地位尊崇，但在商业社会上重要性远远不如乔布斯。
乔布斯因为对产品定位的准确，成为神一般的存在。也使得产品经理这个岗位得以神话。
而对一般人来说，如果没有乔布斯的灵感，那么发现需求或解决方案的最好办法就是试错。当然，也有很多自诩乔布斯直接下注的。那是在敏捷之外的另外一种误会了。
为什么不要文档而要看可用的软件？因为可能有误读，可能现有文档规范限制了表达，甚至可能在写文档的过程中，环境已经变化了；
为什么互动重于流程和工具？因为所有现存的流程和工具都是为解决过去已经存在的问题而设计的，而不是为正在发生的问题设计的；
为什么和客户协商重于合约？因为客户也不知道他/她要什么，甚至我们都还没找到严格意义上的“客户”呢？一个新产品，即便是“好”的，往往也需要一批潜在客户去尝试去体验，发现最适合的一个子类人群；
拔高地说，做敏捷开发要有向死而生的勇气。如果没打算重构，那么就得好好计划。如果要做敏捷开发，就得做好下一轮重新来过的准备。
因此对老板来说，敏捷开发不见得就会节省时间；但是能更准确地知道项目成本，或者更早知道产品的问题。
对程序员来说，敏捷开发是通过小改来避免大改。用前期的的失败（试错）来保证最终结果；而不是顺风顺水地冲到一个大坑里。（当然，有的程序员不这么想。因为小改是个人麻烦。而大改是整个项目组甚至公司的事情）
最后说下培训机构。回想起来，我当年的授课老师也是收费上课，但他们的商业模式却大不相同。授课只是普及概念，他们真正的收入来自亲自入驻企业带队做项目，或者驻场培训SCRUMMSTER。因此无论是是从实际出发，还是要给自己留条后路，他们都会强调敏捷开发并非万能，必须结合产品/项目/企业实际情况而定。
实践
前面说的都是虚的，现在来谈实践。在国内国外尝试过敏捷开发十多年，每一次尝试都带来新的体会。
作为SCRUM MASTER，面临三种考验。
第一，当然是老板了。
非技术出身的老板基本上没有真正了解敏捷开发的。这没关系。接上文，老板关心的是否能更快交付。我的策略是拿敏捷开发作为筹码，和老板谈价还价。敏捷需要保持开发团队的完整，需要跨部门抽调人员，或者扩大产品经理/项目经理的职权；敏捷需要保证开发团队的专注，至少一个sprint周期内的无干扰；需要让猪走开，需要和客户（用户）直接接触。这都需要管理层的支持。所以我会拿更精准（同时也必须是更短）的交付计划与老板做交换。
然而坦白地说，如果能够得到完整的团队和专注的时间，不采用敏捷也能有更高效的产出。^_^
第二重考验来自团队。
作为SCRUMMASTER，认清自己的团队成员也许比做需求分析更重要。
团队成员中有的可能并不能完全胜任自己工作，按照标准SCURM模型这是不能接受的！但现实往往如此，不管大公司小公司都会遇到人员短缺的问题。
团队成员有的来自其他部门，他只是想做猪而不是鸡。
团队成员有的曾经听说过敏捷开发，因此非常急切地想尝鲜，甚至主动推荐某种协同工具。
团队成员有的曾经经历过“敏捷开发”并且有着糟糕的体验，比如上文提到的作者。他对这一套有着非常强烈的抵触情绪。
但最危险的不是他们，而是团队中的技术大牛。
对的，就是技术强责任心重勤勤恳恳还特别愿意帮助新同事的大牛同学。
在项目KICKOFF会议上，大牛同学想好了项目实施方案，准备尝试新的技术框架；大牛同学愿意教小白兔怎么使用；小猪同学来不及做的部分，大牛同学也准备接过去；其他同学也因为大牛的存在，而对项目增添了信心。
然后在第一个SPRINT周期的末尾，大牛同学通宵加班，并建议将这轮迭代延长两周，这会保证新框架可以稳定上线并且提供十倍的灵活性和二十倍的稳定性。
如果你同意了，苦逼之旅就开始了。大牛同学最终花了三周时间完成了新框架，但是除了底层模块，前端功能什么也没有。老板在等了一个月之后急着要看DEMO，如果这个项目有问题，那么小猪同学就回他自己部门了。而大牛和小白兔已经几天没合眼了…
敏捷就是面向试错，所以敏捷开发要竭力避免开发过程中的完美主义，而要保证稳定持续的结果输出，从结果反馈寻求答案。团队中的技术大牛是最容易走入技术导向误区的人，同时他也最容易影响他人。
那么要不要尝试新技术新框架呢？当然可以。但是程序员必须具备有限优化的能力，在一个迭代周期内进行小范围的尝试。项目本身不应该是新技术的试验田。
对于其他同学的问题，很多时候我并没有告知他们这是一个敏捷开发过程。只是通知他们按阶段交付结果，结果最重要，文档、会议、协同工具都是手段而已。如果他们喜欢DailyMeeting，那么就开；如果他们喜欢用Worktile，那么就用。SCRUMMASTER可以推荐工具，但不强制实行。只有当团队自身发现这个工具有利于他们更好地交付结果，他们才会真正地去使用这些工具。
另外一些最基本的经验：
尽可能保持人员稳定；
尽快排除情绪不稳定的成员；
在一起办公；
不超过十个人；
最大的考验，嗯，来自于…SCRUMMASTER自己。
换句话说，在这个项目团队中，SCRUMMASTER究竟是怎么样的一种存在呢？
对一个没接触过敏捷开发的团队成员来说，经典的SCRUMMASTER是一个完全不参与实际项目开发，只是做做思想工作的精神鼓励师啊。
但其实对老板，对团队来说，你才是那个OWNER。
如果每个项目成员都很牛逼地胜任本职工作，并且充分理解敏捷开发的精神，SCRUM MASTER的确可以抽象化了，或者就由某个软件替代了。但其实这个角色才是最无法抽象或者被替代的。
在我的实践经验中，我的角色就是产品经理+项目经理，也就是这个项目的OWNER。只有这样，才能有话语权向老板争取资源，才能有权威克制大牛的技术冲动，对抗外部干扰。
但这样又很容易走向一言堂，破坏敏捷开发所提倡的主动性和平等性。用来平衡的手段，是让团队更多接触用户，通过用户反馈让团队意识到“我的工作对用户的影响”，而不是为了取悦项目OWNER。
对于像我这样研发出身的SCRUM MASTER，还有一重风险：技术的诅咒。
虽然技术背景对于项目开发周期和BUG风险有更好的理解和判断，但是技术背景会使得SCRUM MASTER忍不住参与到技术实现中去。
个人最失败的一个案例：当时有三个并行的项目需要管理，偏偏是我参与最多的项目进展最不顺利。项目瓶颈在于后台数据库设计进度太慢，导致前端无法开始联调。由于我熟悉数据库设计，因此有时直接上阵开发。
直到某天我在敲代码的时候，忽然看到本该做此工作的DBA眼神呆滞，茫然地坐在一边；才突然醒悟自己的越俎代庖。其实数据库设计慢的原因，是作为前开发人员的我，认为设计不够“美”，而作为OWNER的我，应该把开发的权力还给DBA，而只从实际输出结果评估是否可以交付。
SCRUM MASTER必须时刻考虑大局，放下自己的技术偏好。SCRUM MASTER需要根据实际任务情况和成员情况，尽可能地组织出一只团队不断交付。前面说到每个项目都有新体验，就是说项目本身可能相似，但总会遇到不同背景不同性格的程序员们，看他们是怎么理解怎么执行敏捷开发的。
SCRUM MASTER不写代码，但通过调动程序员完成一个产品，从某种意义上说，这是另一种形态的编程呢。
