敏捷项目管理基础及失败案例分析-（丁仿）
Scrum 敏捷开发 基础及失败成功案例分析
什么是敏捷开发方法？何谓Scrum？
看到敏捷，想到的是什么？
有人说是动作敏捷、反映灵敏，速度快；
有人说是多快好省；
有人说是没有制度，松散的工作方式；
有人说敏捷就是只要写代码就行，没文档；
有人说只要把最终交付物提高就行……
90实际中期，有一些所谓的激进人士，他们反对重量级的开发方法（瀑布模型站着中枪），So,在2001年，17位不安分的老鸟，跑到犹他州的雪鸟滑雪场，一边玩鸟，一边讨论轻量级的开发方法，这群“身手敏捷”的骚年，给这个轻量级的起了个名字：敏捷，并发布了入伙规则，简称12条敏捷宣言。
敏捷方法强调以人为本，Focus在有价值的软件。在自组织的环境中，使用迭代式的方式进行增量式开发。
经常使用PDCA的思想来进行反馈、思考、反省和总结，不停的进行自我检视、调整和完善。敏捷，是这些轻量级方法的总称，后宫佳丽很多，比如：极限编程（XP）、特征驱动软件开发（FDD）、DSDM、Scrum等。但现在Scrum最养眼，受宠度远高于其他爱妃。Scrum词来自于橄榄球运动的术语，由Jeff Sutherland在1993年创立。
讲真，Scrum是一种框架，不是技术也不是方法。那么Scrum如何于万千佳丽中受宠一身？简单说，它由三个角色、4种会议（仪式）、三项工件（Artifact）组成。
三个角色：
产品负责人（Procuct Owner）：排序产品功能优先级
ScrumMaster：帮助团队遵守Scrum流程，仆人，为团队移除障碍；
开发团队成员（Dev Team）：跨职能，自组织，干活。
四种会议（仪式）：
Sprint Planning Meeting 迭代计划会议：确定迭代周期内做什么及如何做
Sprint Review Meeting 迭代评审会议：展示成果，获得反馈及调整
Sprint Retrospective Meeting迭代回顾会议：三省吾身，争做最好
Daily Scrum Meeting每日站会：承诺，检视，反馈
三种工件：
产品功能列表（Product Backlog）：来自客户，PO做了初步的排序
待开发任务列表（Sprint Backlog）：迭代周期要干的活
进度图、燃尽图（Burn-Down Chart）：评估团队速率
在敏捷刚出现的时候，极限编程（XP）一直是主流。但是，在敏捷在全球流行的今天，为什么最火的却是Scrum？这是因为它更够敏捷，易普及和推广。当然，Scrum也没有完全抛弃XP，里面也有一些XP的理念和方法，比如User Story，结对编程等
先说清楚，我们很难定义成功和失败，在这里借用Scrum调查中的定义：
失败：使用Scrum不当，没有到达预先的期望，团队撕逼，最后抛弃Scrum；
成功：按照Scrum流程及框架做事，基本达到预期
我在做咨询的时候，遇到一个大型的互联网公司是这个情况：
有些高层或者PM错误理解了敏捷，使得太形式化，他们在尝试使用敏捷中的一个实践：每日站会，下面是他们如何实践的过程：PMO的一个经理听了一节敏捷的课，发现这个东西太niubility，就单独把Daily Scrum搬到项目团队来推广。结果是，这个经理并不理解什么是敏捷，把Daily Scrum变成了Report会议：每个员工早上9：00在一个固定的区域开Daily会议，然后把当天的任务告诉PM，PM决定员工工作是否饱和，而其它敏捷的精华部分都没有推广。后来PMO部门说，敏捷很潮，然并卵……
了解敏捷开发的人，这家公司应用的只是皮毛而已，很多公司也都开站会，但人家也没说是用了敏捷。其实除了公司文化的问题外，还有就是：PM根本就不知道什么是Scrum，更有甚者，自己生病自己开药方，结果治成了残废……
就以每日站会为例，每人只说3件事：
1. 昨天完成了什么
2. 今天准备做什么
3. 在工作中遇到了什么障碍
每日站会，目的有如下几点：
加强团队的信息交流和共享，互相了解大家都在干嘛，做了什么。每日的信息交互，可以让每个人了解整个项目业务和技术状况。而且，如果在每天的工作中有什么问题，提出来，大家可以相互帮助。特别是在技术方面，我相信你遇到的问题，团队其他成员很有可能也遇到过，相互探讨，总会有解决方案。
促使每个团队成员早上规划好一天的工作。这样，大家就会有明确的任务和目标，提高效率，也不会每天像个无头苍蝇一样，不知道干嘛，浑浑噩噩一天过去了。
所以，上面的这个项目的失败，压根就跟敏捷没关系，连基本的敏捷框架都没整明白，更不用说精神层面的了。
一个创业型公司，有海外团队。突然有一天，部门老大看到介绍敏捷的，看的热血沸腾，觉得很好，然后在网上download了一些文档，让大家一起学习，然后开始了Stand-up Meeting。和案例一相比，这个团队是在真正的推行敏捷，表面看，大家都是按照敏捷的框架来做事：有角色的划分，任务的分解，有各种会议，也有sprint。
每日晨会：
双方有7个小时的时差，对方上班，我们这边就基本下班走人了，这样还要介绍3个问题，其实真的是然并卵，so, Stand-up Meeting就成了一种形式化的东西了。
再后来，他们又间歇式的组织Stand-up Meeting，但是还是流于形式，不得不放弃。
但还是失败了，为什么呢？究其原因，他们照搬了敏捷的框架，两个跨地区跨时区的团队，因为各种差异，很容易导致沟通不畅， 显然，他们是在照搬照套了Scrum的框架。他们是两个离岸的开发团队，因为地点、时区和语言的差异，很容易就会导致沟通和交流不畅，这时候再生硬的引入Scrum，无异是火上浇油。
在第一次使用敏捷的时候，PO设置了优先级，团队估算时间，最终确定哪些故事放到下一恶搞Sprint里做。随着工作的开展，项目的忙碌，到后来无论是谁都可以往Backlog里扔任务了，也不知道哪些是高优先级的，哪些是最有价值的，都是开发人员自己看着办。
显然，这个迭代过程是随意、松散的、没有任何约束的。
谁可以往Backlog里扔任务？很显然是PO的职责，就算你团队的大拿想扔任务进去，也得经过PO的评审和团队的讨论，明确任务和优先级，再放。这是最基本的要求，也是所有Team都需要遵守的原则。
明确了短期目标
如果让team做半的详细工作计划，一定非常困难。但若是做未来2周的，那完全不同了。假设，客户有200个东西要做，但团队在一个迭代 （2周左右），只能完成40个东西。那就明确的告诉客户，一个迭代的周期内，我们只能搞定40个东西，那么我们就先做200个里面最有价值的前20个
便于进度控制及风险预测
怎么知道团队在一个迭代周期能完成多少工作？迭代只有2周的时间，相对的计划也会比较准确，而且前一个迭代完成的故事点数，会是这个迭代很好的参照。根据团队的经验做好一个合理的2周计划应该不难。
检视与调整，逐步完善的过程
迭代结束之后，产生可交付的成果，给客户演示，及早获得反馈，这个时候有可能需求要有变动或调整，没事，咱欢迎探讨。同时团队在一个迭代结束后，也会对整个过程进行反省，开一次回顾回忆，讨论这个迭代周期内哪些做的好，不好，改善。敏捷的团队正是用这种迭代的方式，小步前进，不停思考、反省和总结，不停的进行自我检视、调整和完善，一步步走向卓越。
总之，如果只是学了SCRUM的形，却没有敏捷的意，没有掌握敏捷的思想和精神，那么再怎么使用SCRUM，仍然只是在东施效颦。