当“敏捷”日益成为整个软件业的热门词汇，作为优秀的开发者、成功的项目经理，我们是否有足够的理由不去关心敏捷？我们帮你列出了6个“不必关心敏捷”的理由，以及对这些理由的深入解释。
如果这些理由仍然不能打消你对敏捷的兴趣，首届“敏捷中国”开发者大会即将来到你的身边。你现在就可以报名参加本次大会，与Martin Fowler和众多敏捷专家面对面交流。
我们的需求来自对客户目标的仔细分析和准确理解， 并严格的将其付之实现，通过签订合同的方式，可以在一开始的时候就明确项目范围，这样也避免了不必要的责任，鉴于我们对待客户要求的严肃态度， 这将是我们不关心敏捷的第1个理由。
通常，软件开发者需要的是精确理解客户需求，并且以合同的方式明晰这些需求，而敏捷项目使用QuickStart来进行这一过程， QuickStart是一个建立对于业务目标共同理解的过程， 其不仅仅是让需求制定者明白客户需求， 也是让客户明白什么是自身需求的过程。 即使是客户，对现有业务过程的理解也并不完全一致，从而带来不同的需求。 然而非常普遍的一种情况是，由于各种因素的制约(文化，理解度， 时间)用户的需求并未完全展露， QuickStart正是一个利用一种行之有效的方法发掘客户需求，将客户利益最大化的过程，而非简单的遵循客户要求。
客户制定了项目期限，我们需要的只是按期交付，我们的客户总是会耐心等待最后的交付时刻。鉴于我们的客户深谙没有钱不搞信息化的道理，这将是我们不关心敏捷的第2个理由。
敏捷项目的初始需求是投资回报的基线，通过开发过程中频繁的客户反馈，敏捷使客户来掌舵项目，利用对项目新的认识，对外部环境变化的及时响应来构建更好的系统，以改善投资回报。并且通过尽可能早的交付，敏捷项目使早期部署和早期投资回报变成可能。
总而言之，我们是开发者，我们的客户在需求完成的时候就从人变成了具有法律效力的合同，不管市场怎样，合同确保了我们一方的收益。客户应当为自己的失误决策买单。这将是我们不关心敏捷的第3个理由。
通常，项目80%的工作会按计划完成，在这种情况下，项目的负责人面临着一个艰难的决策，如果在花费了80%的预算后，环境发生变化，项目进入一 个进退两难的境地，我们是否要抱着最后一丝希望来继续开发？ 敏捷项目通过渐进开发方式和使用交付情况估算项目进度的方法避免了这样的情况，这些方式提供了真实可靠的反馈而非字面上的进度，过度乐观的商业计划在敏捷 项目中将变得十分明显，这样项目负责人可以有机会更早的重新审视项目的成本和收益，尽早在未陷入投资泥潭的时候抽身而退。
我 们需要面对的是客户制定的最终期限，以及在此期限内需要完成的功能，这才是最头疼的根源。通常我们和客户会因为缺少的功能而产生纠纷，对于某些质量问题我 们和客户都认为可以通过fix bug的形式消除，鉴于项目质量并非我们亟待解决的问题，这将是我们不关心敏捷的第4个理由。
软件开发之中需要控制的4个变数是成本，时间，范围和质量， 大多数的敏捷项目选择控制范围。 所有的敏捷项目都强调交付高质量的软件，而敏捷项目使用的极限编程确保了这一点地实现。
我们有严密制定的计划，并且项目经理会监督并确保计划中的每一项可以按时完成，而且我们也同时认为公司的知识产权就存在于设计文档和代码中，定当控制能接 触到这信息的人群，避免无形资产的流失。 鉴于我们同样能够很好的控制项目以及对无形资产的良好控制，这将是我们不关心敏捷的第5个理由。
敏捷项目从不制造表面假象，通过进行短小的迭代以及时刻面对迭代完成后运行中的软件来开展工作，敏捷项目给予项目负责人和客户持续增加的项目能见 度和控制度。 紧密合作以及训练有素的团队更加强了这一点。在敏捷的团队中，增加信息的透明度，共享这些信息是例行公事一般的行为。 即使为此付出额外的努力，敏捷团队也认为是值得的。
我们有很好的开发者，项目也已经经过仔细划分，每一部分的设计者、开发者都是这个位置最佳人选，我们希望用正确的人做正确的事，否则就是浪费资源，这些开 发者的工作合同也确保了他们在项目结束前不会离开，鉴于我们项目小组经过了仔细组织，这将是我们不关心敏捷的第6个理由。
敏捷项目强调信息共享，并且依赖以团队方式进行的分析，设计和编码而非某个设计者，这将预防开发过于依赖于某个人，这也意味着预防开发瓶颈的出 现，在一个敏捷项目中，任何一个人在任何一个领域工作都是可能的，每个人工作领域的变化取决于业务上的优先级，而不是他所熟练掌握的部分。
如果这些理由仍然不能打消你对敏捷的兴趣，首届“敏捷中国”开发者大会即将来到你的身边。你现在就可以报名参加本次大会，与Martin Fowler和众多敏捷专家面对面交流。发表于 @ 2006年05月16日 10:18:00|评论(loading...)|编辑