我与IBM敏捷培训中心的一次交流后的问答，关注的敏捷的可以看看交流.

XXX:

你的这些问题都是很好的问题，有些问题，我们自己也在思考, 我就这些问题发表一下我自己的看法，见下面的蓝字部分：

邮件正文：

您好：那天的培训我提了几个，还有几个请帮忙解答一下，可能有些问题比较幼稚：）

1、敏捷合适什么样的项目类型？ 因为IBM的项目大部分是产品研发类型的项目，可以很好的做一个比较长期的规划，明确发布计划和迭代周期，但对于那种需求不是非常明确或者经常变来变去的项目，感觉是不是不太合适？？

敏捷思想和实践能适应的项目类型非常广泛，但不等于适合所有的项目，我去年参加了中国敏捷开发者大会、中国软件过程改进年会，从交流的内容来看，进行敏捷实施的项目类型很多，涵盖产品和项目，而且项目类型分散在各个行业领域，项目周期有长的也有短的，但是很难用简单的语言来概括哪些项目适合敏捷，哪些不适合。关键是在敏捷实施过程中灵活、准确的采用合适的敏捷流程和实践。敏捷不能包治百病，有时候我们的药方需要综合一些，结合敏捷已经其他的开发模型。


2、对于敏捷开发，这个干系人是非常重要的，对于客户来说，很多时候能参与到项目的人基本上是客户的项目经理，但这个人应该不是关键用户，对于一个比较复杂的项目，关键用户是很多的，但这些人是不是都要参与进来？？ 实际情况下，很难做到让他们都参与进来的，仅仅这个PM肯定是不够的，这种情况下如何处理？

干系人的范围比较大，在项目中我们要抓住关键干系人。如果关键干系人有很多，我们很难让他们同时参与每次的计划、演示会议，我可以安排在不同的milestone给不同类型的干系人演示，过多的演示和反馈不但消耗大量的时间，而且容易造成干系人反馈意见难以统一。


3、敏捷开发与现在常用的分阶段开发的区别，你那天也提了一下，我想有没有更好的优劣对比？我个人认为分阶段开发可能更合适些，这个阶段周期可以根据需求情况可长可短，不受敏捷的固定迭代周期限制。

敏捷和其他的开发模型，我认为没有好坏之分，关键是针对项目的具体情况，选择适合的开发模型，敏捷的很多思想就来源于其他的开发模型例如Scrum、OpenUP，RUP，XP等。

4、敏捷的一个优点的是叫快速反馈，但很多项目，有时候在一个迭代内可能做的都是后端的基础研发，在前端UI上根本没有什么东西给客户看，这种情况下会不会存在一定的风险？

这样的阶段不能持续时间太久，即使是后端的开发也需要有验收的标准，比如自动化测试，或者是测试驱动开发。没有验收标准，如何保证质量，如何保证开发的成果能满足客户的需要，这种情况下的开发风险显而易见很大。

5、对于敏捷类型的项目，如何给客户报工作量？？常规项目，一般都是在项目开始时把全部需求整理出来，然后整体评估工作量并给出一个合理的报价，但按照敏捷的思路，它不需要这样，只需要在每次迭代之前明确这次迭代的需求即可，它号称的是快速响应用户的变化，也就说通常是边做边确定后续的迭代需求，但这种方式貌似在开始的时候不好评估整体工作量？

我一直也在思考这个问题，敏捷的开发模式对估算整个项目的整体工作量是没有好的办法的，只能借助其他的手段来实现，比如，企业的组织过程资产库，或者其他的项目流程等，IBM就是采用IPD和敏捷开发相结合的方法来实现的。


6、无论是否敏捷，其实最关键的都是：人的自我能动性，如果开发人员的自我素质很好，对自己的开发东西非常认真负责，而且团队内部的沟通也非常好，那么是否敏捷是否还有必要？？

你会发现，敏捷是没有一个固定的定义的，只有敏捷宣言和12条准则，敏捷重在方法，来确保这些目标的实现，如果你有很好的方法来实现团结成员有很好的能动性，那这本身也可以说是一种敏捷实践，虽然这不是典型的常见的敏捷实践。敏捷最佳实践就是收集并分享这些好的方法。


7、敏捷转型涉及到HR、财务等其他部门，对于IT这个对企业来说并不是很重视的部门，如何去推动整个组织的变化？？

这个问题好像在会上回答过了，我想只能循序渐进了，纯的自上而下或者自下而上的去推动都是非常困难的，我们需要领导的支持和信任，同时开发团队也愿意去实践来解决他们的头疼的事情，在这种情况下进行敏捷转型是比较合适的。对于IT部门在整个公司的组织结构中地位偏低的情况，我想先把开发的事情做好，让敏捷能真正地解决我们的问题，同时带给我们受益，改善我们的业务目标，在这个基础上再逐渐对其他部门产生影响，这个时间会更长一些。

8、敏捷的核心是什么？？ 或者说带来的最大的变化是什么？？ 是迭代吗（分阶段类似）？是需求管理方式的改变（这个的优劣目前不明显）？是单元及自动化测试（这个无论是否敏捷，都是必须的）？还是TDD（这个感觉推动起来非常困难）？？

我认为敏捷的核心就是我提到的那四点：准、快、优、稳，以及确保这些目标得以实现的敏捷实践。