关于敏捷开发的网友看法--转载CSDN讨论区

网友一（技术总监）

1. 不管黑猫白猫，能抓住老鼠就是好猫。敏捷不敏捷，没什么意义。从来没有听说哪家IT巨头通过敏捷开发如何如何？
2. 敏捷开发宣言大意这样描述的（我翻译得不好，见凉）：“崇尚个人和交流而不是过程和工具；崇尚软件开发而不是文档；崇尚客户合作而不是合同条款；崇尚随需应变而不是简单计划”。如果我们把敏捷开发定式化成某种过程或者工具集合，实际就呆板了。
3. 这么多年看过来，敏捷开发对人才的要求非常高。高级剑客手中无剑，初级剑客手中也无剑。貌似都无剑，但区别十万八千里。慢慢推进，可能比较好。
4. 文档是不可少的，过程也还是有用的，工具更是必须的。最经典的还是最后一句：随需应变而不是简单计划。

 

 

网友二（技术总监）

总的来说，使用某个模式，很忌讳生搬硬套。使用敏捷，一定要跟自己实际情况结合。我们的很多团队能力都很有限，就向上面的兄弟所说：对架构设计似懂非懂，针对这一的团队，实施敏捷尤其要注意。

在实际应用中，我的解决方式是，成立多个小组，所有的组都会朝一个目标冲刺，其中，具有分析、设计能力的组进行系统分析、架构设计工作，其他只具有编码能力的组只负责开发，高级组与低级组直接的信息传递通过交叉式工作来进行。总的来说，需求分析、架构、设计、编码都做的比较顺利，大部分都按计划进行，或者都会在预料之中。

在推行的过程中，不要去为了敏捷而套模式。在刚开始推行的时候，有些东西可以根据团队的情况省略，减少工作的复杂度，让团队能快速的，并能把握重点的工作。这一点很重要，它往往决定一个团队是否能快速的步入正轨。

想起在高中武术队玩散手，一个师傅教的弟子，同样的招式，姿势一模一样。但打法上，却有较大的区别，有的师兄有章法，节奏感强、风格硬朗，有的灵活多变，潇洒飘逸。但也有的无章法，虽然姿势标准，但整体凌乱。

因此，我们在推行敏捷的同时，除了注意规范，更要注意整体。

 

网友三（副总）

在组建团队试点Scrum方法时，有一些点需要保持较高的关注：
1) 由于是试点新的方法，各种项目干系人对此报有希望，同时也会有怀疑。所以在试点过程中一定要做到项目的透明，包括进度、问题、解决的方案、下一次迭代的改进、本次迭代实现的目标。及时有效的沟通会减少很多干扰，增加很多支持。
2) 在迭代中不要高估自己真正可以交付的能力。因为Scrum中迭代是一个time－boxed的周期，即使完成95%的任务也不会被认为是“Done”的状态。如果团队没有适应这个变化，在最初的几个迭代中不能按时交付，很容易降低信任感。
3) 不要想“一口吃个胖子”。一般有两个切入口：一个是目前遇到的最大问题，以这个问题的解决方案作为最初的切入；另一个是从最容易的开始，例如每日会议、Sprint Planning、回顾会议等