敏捷是一种文化，不是一个流程

原文：http://www.iteye.com/topic/1120906

敏捷这个东西挺奇怪的，在有些公司相当好用，在有些公司简直就是一滩屎。我看过不少推崇敏捷的人的部落格，不少书，参加过不少敏捷的大小会议，大家对这个东西褒贬不一。 我想说说我在两个不同的公司的亲身体会。

公司1, 敏捷搞的很好，implementation(落实)是scrum。我们当时的软件随时都是可以release的状态，团队精神很好，每个人都很满足。整个团队15个人，每个人都参与设计，开发，测试的过程。

公司2, 也是scrum，我靠，每天standup meeting时候就是个和领导汇报工作，整个软件的设计过程是流水线，每一个环节的人都不是很相信上一个环节人的工作，这个团队精神很差，跳槽的人很多。

我现在目前还是在公司2奋斗着，想改变这个公司的文化，我觉得以下几点造成了公司2目前的失败。

文化方面：
1. 最重要的一点：敏捷不是一个流程，照猫画虎的去干一些敏捷的事儿纯粹是浪费时间，适得其反。

2. 公司要把员工当成财富，而不是把产品当财富。

3. 一些公司甚至把流程当成财富，整个一个流水线，这些公司的目的就是弄一套完美的流程，然后雇一些猴来都能出产品。这个理念做点儿衣服，鞋一类的东西还行，软件肯定不行。

4. 杜绝流水线，很多公司的软件开发流程是这样的：分析师见客户，写一个用户要求文件给设计师，设计师设计一个软件构架给工头儿，工头儿和设计师商量商量把这个设计分成几个小部分给程序员，程序员压根搞不明白自己写的这玩意儿有啥用，反正瞎写一顿，写完的东西给测试人员，测试人员发现bug 若干，这个时候时间已经不够用了，还有一个星期就要交活儿了，程序员没日没夜的一顿修理，睁一只眼闭一只眼把一滩粑粑交给客户，客户很不满意。敏捷是需要沟通的，任何时候一个团队的每一个人都知道这个project的情况是如何，不是说把自己的事儿干完就闪了。

5. 团队要有一个共同的认知：没有什么东西是完美的，所有的东西都可以改。我每次听到领导说这句话都想抽他：“这个功能在第一个sprint已经做完了，怎么还要改？” 这个认知很重要，因为做到真正的敏捷，一个团队不能瞻前顾后，不能怕把东西弄坏。

操作方面：
1. Sprint的作用不是把一个设计分成N个部分去完成。Sprint和Sprint应该做到互相不影响。在每一个Sprint结束后应该都能够给客户展示一些东西，解决一些客户的问题。如果客户说：我觉得这个挺好的了，剩下的东西我不要了。你应该可以立刻把现有的东西在一两天的时间里面包装一下交给客户。我在公司2看到的最常见的一个问题就是第一个sprint做UI，第二个sprint做backend services....

2. 大部分测试都必须是自动的，而且是每次commit代码的时候都要去运行的。不能等着一切都做完了以后再测试。

3. 要给员工充分的自主，建立一个互相信任的团队。

引用

同意第二和第三条 很多公司都不注重培养员工，导致员工翅膀硬了就飞走

引用

没错，一个公司的文化是从高层一直传下来的，如果CEO注重的就是钱，员工们注重的也只是自己的工资。

引用

我也希望找到一个团结友爱的开发团队，不怕吃苦、不推卸责任。只有员工都是这样的人，何愁不怕做不好项目？一个好的氛围可以造就一个天才，一个坏的氛围可以毁了一个天才

引用

我也觉得 敏捷 要起到该有的作用还是挺难的，真的要看Team氛围。
想以前 实行的激情澎湃
看如今 做的是名存实亡

敏捷是否能够实施成功的关键点在于：
1、项目经理对敏捷的理解程度
    这个是最重要的,无可置疑
2、项目经理是否有耐性按照敏捷(Scrum)指导的步骤走下去。
    有很多的项目经理虽然口里面整天喊着敏捷，但做的事情和敏捷没有关系
3、项目成员对敏捷的理解程度
    项目成员对敏捷的理解是敏捷成功的另外一个重要原因，不理解敏捷就谈不上如何入支持敏捷.在这个方面，项目经理要多花心思给他们培训

引用

总之，IT界是一个浮躁的世界，大家都静下心来或许能干出一番事业，只可惜牵绊太多了

引用

能遇到这样的团队是个宝，但是往往事与愿违啊。。。。所以不怕神一样的对手，就怕猪一样的队友。