吐槽Scrum，说说Agile

让我吐槽先

1. 风云突起

现在的工作最开始并不是Scrum模式，计划经济模式，计划到连bug都要老板分配的状态。突然有一天公司开始号召快速适应变化。革自己的命，抢别人的路，让别人无处可走，成为变革的主题。2015号称是自我革命的一年。说到Agile，自然最先想到的是就是Scrum。于是下面就开始炸锅了，高喊着口号向Scrum大跃进。从上到下生生将Scrum搞成了群众运动。各种Scrum分享，内部培训，外部培训，每一个有空地的角落都被白板占据。会议室，角落，位置都是站会的阵地。按理说都已经全员动员了，应该情况scrum越走越顺才对。但是1年下来，似乎没看到团队真正的敏捷起来，会倒是越开越顺，每次会议的内容越来越发散，时间越来越长... ...。

2. 邯郸学步

大老板搭台，小老板指挥唱戏。刚开始有老板连Scrum是什么估计还没弄明白，看着别人每天站会，也开始有样学样，一个4、5个人的团队，就敢每天上午安排一个小时的Scrum meeting（花点时间google一下Agile/Scrum真的很难！你懂的）. 每天把状态过一遍，状态包括但不限于做了什么，结果是什么，怎么做的，怎么想的，打算怎么做... ....。尼玛超过一个小时是常有的事。最奇葩的是有人BBB一个上午，跟你分享他一个问题是怎么分析，怎么解决，怎么验证，怕不明白还拉着大家每一步的demo。一个上午过去，下午你一验证他的方法，发现最简单的case直接fail的时候。当时就感觉一股强大的冲击波迎面而来，恍惚中有种看到了猴王的感觉，敬仰之情难以言表，唯有跟随万千猴子猴孙载歌载舞，在风中摇摆！

3. 自娱自乐

慢慢的，一切开始上了正轨，backlog，planning... 有模有样。4个礼拜一个sprint，虽然经常delay release 但是好歹规律了。但是做着，做着在sprint中间，PO／SM会突然说sprint周期是3个礼拜了是怎么回事。提点一下，JIRA翻出来看一下，嗯，搞错了，原来以前都是4个礼拜。好，过了一个礼拜，又变成3个礼拜了是咋回事！！！

临近release，今天说release时间是下周二，大家开始计划把一些未完成低优先级事情推迟到下一个sprint，并且开始做测试相关工作。过两天突然变成release时间是下周五。到了下周一，再来release时间是再下周...... 这个时刻估计思路最清晰的也只有PO／SM， 深得Agile的精髓——拥抱变化，虽然是大冬天，抱得太紧也难免太热烧包啊！！！

4. 我不入地狱，谁爱去谁去

码农最不喜欢的也许就是改需求。码农第二不喜欢的事情就是每一个feature都有N种方式实现，但总有人要求你用一种最烂的方法去做。但是，码农应该是喜欢敏捷文化的，因为Agile号召将每一个story都拆分得足够小。所以需求改变也会相应的被拆分，分解，将变化无限缩小，所以号称拥抱变化的Agile神奇的将一个Sprint变得相对静止了。另外敏捷文化的一个重要根基是信任，基于信任的基础去除繁杂的规则、流程。让每个码农都可以放手将大部分的精力放在开发上。

实际执行中，当一个团队从计划驱动的方式转换到scrum模式时，中层管理对往服务型的管理团队转变充满了畏惧（当然也有可能是其他原因），不愿放手权力，又不敢承担责任。最中导致Scrum跑得不论不类。程序猿夹缝中求生存，日子过得反不如计划式，戳一下走一步的方式。Scrum的快+传统的乱，这是何等的煎熬！比如：

1），Sprint过程中，PO不能在Sprint开始的时候确定一个sprint中需要完成的需求，随便拉几个backlog。然后在Sprint执行过程中，借拥抱变化之名，随意增加新的backlog，将正在开发的backlog移出当前sprint，随意打乱开发计划。尼玛，马上要release还在换feature，这算什么情况。加feature我能理解，客户需要，开发好的feature移到下一个sprint，我也接受。尼玛费了老大劲设计、实现的代码也得花时间移出去，等需要这个feature再加进来... ...

2），当前架构不能适应新的需求变化，需要对原有架构进行改变才能适应新的需求时。PO／SM居然第一反应不是怎么样才能保证满足需求的持续迭代，而是需要做这么大的改变，作为“猪”的你怎么说服更大的老板同意花efforts去这个改变。思想，思想要跟上啊，亲，需求是客户说了算啊！觉悟，觉悟要有啊，小弟，升职，加薪都还得靠老板！

3），PO将计划经济的流程带入scrum，每一个细节都不放过，每一个feature的设计原则，实现都要确保自己能明白，最终才能开始实现。尼玛一个feature我写代码才只要一个礼拜，让PO明白居然要花两个礼拜。文档写了两轮，讲要好几遍，讲的时候听明白了，过几天又不明白了，又得重新来一遍，这算是啥情况！

Agile

Agile与其说是一系列软件开发的方法论，不如说是一种观念，一种思想。有很多流程框架用于敏捷文化。Scrum是其中最出名，应用最广的一种。但是不管是哪一种都仅仅是一种参考，并不是一个绝对的方法。要实现敏捷，最关键的依然是团队，而不是方法。只有方法跟团队完美结合才能真正将敏捷的效果发挥出来。所以没有一成不变的Scrum流程，流程应该根据团队成员配置，团队文化，在敏捷过程中不断改进，流程与团队互相磨合、改进，最后确定一个适合团队的敏捷迭代方式。

鉴于个人经验，资历，我没法在这里讨论正确的Scrum流程应该是怎么样，只是讨论什么是我觉得不对的方法。不断意识到错误，在错误中不停修正，震荡中趋向稳定，也是一种不错的方法。照着教科书照搬Scrum流程，都是对产品和团队不负责的行为。

1. 职责

1） Project Owner。 PO是团队与外部的接口，与客户合作确定产品需求。负责拟定每一个Sprint需要交付的需求，向团队输出待办事项，并确定优先级。在Sprint中要确保待办事项及其进度对所有项目成员可见。PO还需要确定开发团队下一步做什么，delay什么来权衡范围、进度以确保有最好的产品交付。

2）Scrum Master。SM是团队的教练，帮助团队遵守流程，协助PO创建维护待办事项列表。和开发团队一起发现并实施技术实践，为团队清除外部障碍。

3）开发团队（“猪”）。项目具体实施者，负责对产品的增量实现。开发团队采用自组织的方式完成工作，对于项目而言，开发团队应该是全职的，具有完成每个产品增量所需的所有技能。开发团队成语与产品负责人共同预测在一个Sprint里面能完成的工作，并决定如何实现。

在传统的计划式开发中，命令自顶向下，一级一级传达，每一层都有相应的责任人。为了明确责任，做任何事情前都需要详尽的文档，提供足够充分的理由，证据，一级级申请，批准，然后立项才能开始实施。创新和敏捷就在这个冗长的过程中被扼杀了。

在Scrum中，所有的执行都是基于客户需求，每一个Sprint持续迭代，交互。开发成员直接作用于backlog，并承诺每个sprint都完成相应待办事项，目标明确，责任清晰。

但是在实际实施过程，Manager引入Scrum，又对传统的方式依依不舍，管理层不想放权，不想向服务型管理转变就会是什么一种情况呢。PO依然用瀑布式方式管理，在Sprint过程中随意更改待办事项，打乱开发计划，最终导致开发效率低下。按照Scrum的方式对一个Sprint能完成的工作做plan，但是执行过程中，每一个实现方法都需要PO或者团队外的Manager审阅，批准，导致项目进展缓慢，临近期限，为了赶进度又不得不作出妥协，delay交互或提交一些低质量代码。最终导致Scrum流离于形式，相比于传统的计划是模式，又增加了更多的流程，会议。这种混杂模式更加的混乱，低效。

2. 文化

团队成员应该有足够的自信，以“我能做到”的心态去迎接，支撑敏捷。敏捷中强调的更多的是实践，通过实践去发现问题，解决问题，论证问题。但是传统的方式中，由于流程的限制，责任的明确划分。没有人拍板，所有人都不敢做决定，总是强掉问题，但是少有主动提出解决问题。

敏捷中，团队成员之间是相互信任的，相信别人能完成工作。所有团队成员的工作进度是透明的，但是完成方式并不需要每一个人都明了。所有团队成员都相信别人会在规定时间内用最好的方式完成并交付任务。团队成员也被赋予足够的信任和自由，可以自主的设计、解决问题，而不用得到实现许可。

团队成员被赋予了足够的决定权可以独立完成自己的工作，又与团队其他成员相互紧密协助，共同解决完成相关的工作，确保不会因为自己的工作阻塞别人的工作。

实际执行中，如果团队成员之间没有足够信任，往往会造成过多的干涉别人工作，剥夺别人开发工作中的自主权，导致别人进展缓慢，同时自己也因为精力分散，而效率低下。比如PO不信任团队，觉得只有自己参与其中才能把控产品质量，进度，但是其实对每一块的具体细节PO都是了解的最少的一个人，参与其中，只会占用开发成员过多的时间去帮助PO理解细节。同样，如果两个开发成员的工作相互依赖，一人怀疑另一个人的开发不能很好契合自己的部分，不是通过两个人很好的沟通，协商解决问题，而是以为自己能力更高一筹，直接指手画脚，干涉别人的工作，结果往往适得其反，久久不能达成一致，相互block。

3. 产品交付

敏捷中产品以增量的形式的交付，每一个Sprint结束都向客户交付功能增加的产品。即使收集客户反馈，根据客户反馈信息，实时改变后面的产品开发策略，需求。敏捷中的变化应该是根据客户需求，调整产品功能，待办事项优先级。保证每一次都向客户交互拥有最重要增量的产品。

传统开发模型中，产品在一个预定的期限完成几乎所有的功能后再交付给用户。交互后除进行bug修复外，基本不在进行大的改动。如果客户有其它的需求需要引入，则需要以release升级包的形式在原来产品基础上进行升级。甚至在原来产品基础上，进行大的重构，再经过一个漫长的开发周期后向客户交付升级换代的产品。

敏捷中，需求的变化频率远高于传统开发模型。敏捷开发中，有些需求在开发的早期不明了，甚至根本不存在。所以在敏捷开发中，开发早期可能并不能确定一个能适用于整个项目生命周期的开发模型，架构。在开发过程中，需要实时的，快速的根据需求变化在不影响持续迭代进度的基础上对design进行改进。所以在敏捷中变化的是需求，随之而变的是适应需求变化的设计。

传统开发模型中，由于在项目早期立项时就已经确定的项目的走向，目标。所以在项目立项是，架构，模型就已经确认。在执行过程中，更多的变化来自于PM的安排，PM可以指定每次release需要包含的feature，fix哪些bugs。甚至PM可以在一个release周期中，更改需要release的事项，只要确保项目能在最后的期限完成所有的预期就可以。

在Scrum的执行过程中，如果PO／SM打着拥抱变化的旗号把传统开发模式的release方式带入了Scrum中，会是什么情况呢。就是可能在Sprint做到一半的时候，PO／SM出于某种不严谨的原因打断当前开发进程，把正开发的story挪出当前sprint，新加入一些其他待办事项，造成开发效率低下。

当然在Scrum模型中，开发过程中完全有可能客户出现新的优先级更高需求，也有可能客户不在需要某个正在开发的需求。这样的话，就对PO／SM提出了更高的要求，要求PO／SM有更高的责任感，严格评估新的需求的优先级，确定只把特别重要的需求插入正在开发的待办事项中。PO／SM在开始筛选Sprint待办事项时，也确定只筛选backlog中最重要，优先级最高的事项。以确保尽可能少的影响开发中的待办事项，打乱开发进度。杜绝传统开发模式中权利在手，任我胡来的不负责任的方式。

小结

鉴于个人经验有限，暂时能想到的就是这几点。希望能抛砖引玉，收集更多的不正确的方式，正确的方式。