转自：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. 要给员工充分的自主，建立一个互相信任的团队。
380
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
