亲身体会，敏捷是一种文化，不是一个流程

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

公司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. 要给员工充分的自主，建立一个互相信任的团队。

i欢迎大家拍砖讨论

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

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

我就在一个屎一样的外企挣扎着，第一次接触敏捷没想到就这么烂。╮(╯▽╰)╭

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

"如果CEO注重的就是钱，员工们注重的也只是自己的工资" good

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

“敏捷是需要沟通的，任何时候一个团队的每一个人都知道这个project的情况是如何，不是说把自己的事儿干完就闪了。 ” 不知道在这点上面lz有没有什么操作的经验介绍一下，尤其是在一个较为大的团队里面，比如50人以上的开发团队，这样做是否可行？对project的了解是只是在大的框架层面的了解就足够还是需要非常深入的了解呢？

“想改变这个公司的文化”，如果不是很有决策权的话，最好把这种努力转化为对老板和公司的期许，否则白费劲。
我的看法，推行敏捷成功的话：
1、一定要是真正有推动力的人（比如老板）对敏捷的理解深刻，且不变味；
2、同意linxux的看法，“真的要看Team氛围”，是否需要和能够实施敏捷，是要考量的；
3、敏捷强调的是团队自管理，这背后的含义其实是有一些自上而下的管理模式的改变，这点才是重中之重，需要有魄力的团队和有魄力且开明的领导。

暂时想到这些，初入scrum，正在实践，欢迎讨论。

50人以上的话，可以分成多个团队，再如果项目必须投入50人以上的人员的话，多个团队可以组成联合项目组，另外推选评审委员会等等。敏捷团队人数最好控制在5-9人，对信息的透明做到团队内即可。