敏捷！敏捷？

iamredeye

了解你说的developer自己的“psp”。这个对开发人员的maturity要求不低。敏捷成功实施的基础实际上也是成员的maturity（当然也对项目特点有要求）。如果能达到这种自管理自组织的水平，当然很好。现在很多公司也都引入了一些bottom up的方式。

你说的对，一般所谓的SEPG是个单独的组织，脱离了项目，这种方式我也觉得有点问题。我说的“所谓的SEPG”只是一个名字而已，可以有多种实施方式，可能比较好的一种是各种相关开发人员组成的virtual team，实际上他们主要工作就在项目里，了解真正的需要。也许还需要少数人专门来做一些协调或总体工作，比如你举的例子。当然如果整个公司或项目的成员不够成熟，也没办法实行这种方式。不同公司的情况不同，没有最好的和唯一的，只有对他们最合适的方式。

oceanchip

最主要的还是要根据自身项目以及PM来考虑问题会比较合适，不要XP与XP

lee_huo

先敏捷再规范，先做到再写到，先短期利益再长远利益，先实效再完备。

这个策略源于实践。因为一步到位直接采用规范的方法，阻力比较大，效果难以持久，很可能事倍功半，敏捷方法以其短期内可以见效、对已有的开发过程调整幅度小等特点易于开发人员接受，所以可以先敏捷再规范，将敏捷作为通向规范的一个阶段。

芸芸众生，大都是凡人。凡人都是注重短期利益的。只有那些领袖、那些思想家才是目光如炬，站的高看的远。过程改进要从凡人做起，凡人是体系的执行者，所以首先要满足凡人的需求，让凡人看到好处，否则，群众的力量是无穷的，这力量可以建设的力量也可以破坏的力量。

敏捷的方法是适应变化的一种方法，因时、因势、因事调整计划，它可以处理近期内即将发生或已经发生的变化，它不赞成去为未来的变化太多花费时间，变化会导致近期计划的调整，也使长期的计划难以预期。

采用敏捷的方法并不意味着没有规矩，没有文档、没有计划、没有跟踪与控制并不意味着就是敏捷。敏捷方法在落实其规矩时和重量级的方法有所不同：

1 敏捷方法减少了中间结果的记录、减少了管理与支持类的文档；

敏捷方法中最常见的是3种角色：教练、客户、程序员。教练起到了项目经理和过程指导者的作用，客户实时执行确认与验证的动作，程序员去实现产品。敏捷方法减少了管理与支持文档的工作量，但并不意味着没有做管理，只是做的少、文档也少。比如敏捷方法也要做计划、也要估算项目的工作量、也要和项目组的成员沟通计划的可能性、也要获得项目组成员的承诺，只是这些管理活动可能只有最终的计划书，而没有中间结果的记录。在敏捷方法中很少看到关于质量保证活动、度量分析活动的系统要求。

2 敏捷方法强调通过面对面的口头交流减少书面的文字交流；

文档是沟通的一种方式，口头交流也是一种沟通的方式。在重量级的管理方法中强调了文档的重要性，而敏捷方法并非没有文档，只是它认为口头交流更重要，口头交流效率更高，因此可以编写简单的设计文档，设计的思想可以通过口头交流进行评审，用口头交流弥补文档简化的不足，因为文档简单，将来的变化也就少，维护的工作量也相应减少。

3 敏捷方法强调最终的交付物而忽略了中间产物。

关注最终交付物的质量而不是中间结果的质量，采用诸如单元测试、结对编程、代码重构、持续集成、代码规范等手段确保源程序的质量，采用迭代的方法尽早进入编程，在过程中通过沟通进行设计的实时评审、代码的实时评审，以便于尽早发现交付代码的缺陷，尽早修复缺陷。作为开发过程的中间产物需求与设计等文档则进行了简化。代码是必须交付的，所以要采用一切手段规范之，既然要交付，就要保证其质量。而需求与设计文档并非是必须交付的，而需求和设计也是经常变化的，既然不交付，既然始终变化，干脆就不去花时间去写。

4 高效的人比规范的过程更重要。

一群精英如果能配合默契的合作，则不需要去监督他们是否按照标准规范去执行了，这个团队是自我管理的，大家有着共同的价值观，彼此能快速协同，互补合作，最终走向成功。是英雄创造了历史，还是人民群众创造了历史？结论不言而喻，但是如果没有英雄呢？如果各位都是英雄呢？

以上种种思想，反应了敏捷方法的实用主义哲学。如果一家企业的项目大都在10人一下的开发团队完全可以从敏捷方法开始着手进行过程改进。但是，软件开发是一种非规模经济的现象，随着团队规模的增加，上述的手段可能很快就失效，还要回到重量级方法上来。

iamredeye

"先敏捷再规范", 我觉得这个说法值得商榷,敏捷和没文档并不划等号,不规范.规范也不意味着就是山一般的文档.这些不是敏捷或"规范"的本质特征.

同样,我也不认为CMM就是重视文档.这些都是咨询机构的误导.

sungubbi

两年过去了，，，，哈哈。。。。。

2009年的过程改进年会的辩论主题是“敏捷 VS CMMI”，结果是CMMI队大获全胜，当然这个结论不代表敏捷不行，只不过CMMI队的辩手们者们都是咨询师出身，而敏捷队的辩手们基本是企业选手，嘴上功夫可见分晓。这一点也不阻挡敏捷在中国持续热潮。

忘了是在2010年的过程改进年会上，还是某次与某咨询师的沟通中，再次提到了CMMI与敏捷的关系。CMMI是一个集大成者，里面即搬出PMP的东东，也搬了ISO的东东，还搬了敏捷的东东，还有以前的软件工程等等。

CMMI其实约定了一系列企业需要达到的目标，但并没有要求一定要执行什么样的实践或按什么样的生命周期模型来生产产品。CMMI提供了方向，而敏捷是达到目标的方法或实践之一，除了敏捷你还可以用六西格玛或者别的什么自创的优秀实践来达到CMMI所定义的目标。

所以CMMI与敏捷应该也不是冲突吧，两个层面的东西。

楼上两位针对拿来主义的讨论，不知道两年过去有没有什么新的体会与收获。有时候真有种朽木不可雕、孺子不可教的郁闷。期待让每一个人（包括高层）都能够自优化，在中国的企业文化大环境下，让那些闷声不吭、没有反抗力、按部就班、埋头苦做的人，让他们想做、愿意做、敢做、主动地做可真是件难事。

nini

呵呵，我今天有感悟，打个不恰当的比方，CMM象一部资治通鉴或史记的话，敏捷就像战国策。
目前的情况是，产品生命周期越来越短，但上市时间要求越快越好，而用户粘度很低，等产品做精做深，搞不好黄花菜都凉了。
当然，如果涉及安全、金融、军工、航天等重型、机要型产品，精密程度就不是这么回事情，严格的CMM甚至ISO就是一种很好的保证。

换个角度看问题，以前我推广CMM的时候，我知道CMM带来的好处主要是组织的，工程师是间接的帮助，而敏捷，带来的好处直接是工程师的，而组织是间接的，所以，从学习热情而言，无意敏捷开发更有趣。

舞俪姑娘

回复 step365he 的帖子

    “ 敏捷中的极限——极限编程创始人谈论敏捷开发”中 最后部分的对话能否帮忙解释一下啊？实施敏捷与关系数据库是什么关系？（不好意思，发布这么久才问这个问题。。。嘿嘿，谢谢哈～）

*****************

记者：那么像AJAX、Ruby和PHP等脚本语言呢？它们适合敏捷编程吗？

Ken Beck：当然。举个例子说，Ruby来自于以人为中心的语言。你可以通过一种非常具有可维护性的风格编写Ruby代码，在很长时间内可以非常轻松的修改。我担心的是当你使用数据库的时候，这种修改可能会突然变得非常困难。

记者：和Ruby语言有关吗？

Ken Beck：一般来说是和关系数据库有关。但是敏捷社区正在推出解决这个问题的技术。厂商也正在让数据库接受增量修改。

*****************

端木若希

不错，有收获，支持

玫瑰

很有见地的探讨，先收藏着~

抚涟i

看起来好像不错的样子

说话算话。

其实，很多情况下都是这样的，习惯就好。

十年约

顶不错 支持下

古董小姐

路过 帮顶 嘿嘿

独眠共梦

不错 支持一个了

命呓

看起来不错