来自HP敏捷论坛
1. 敏捷是“一个”过程
敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷价值观，遵循敏捷的原则。
敏捷的价值观如下：
l 个体和交互 胜过 过程和工具
l 可以工作的软件 胜过 面面俱到的文档
l 客户合作 胜过 合同谈判
l 响应变化 胜过 遵循计划
由价值观引出的12条敏捷原则：
l 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
l 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
l 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
l 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
l 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
l 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
l 工作的软件是首要的进度度量标准。
l 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
l 不断地关注优秀的技能和好的设计会增强敏捷能力。
l 简单——使未完成的工作最大化的艺术——是根本的。
l 最好的构架、需求和设计出自于自组织的团队。
l 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
建立敏捷联盟的17位大师所创立的敏捷方法包括：极限编程，Scrum，特征驱动开发，动态系统开发方法，自适应软件开发，水晶方法，实用编程方法。这些方法统称为敏捷方法。
其实每个人都可以从敏捷宣言和原则出发，明确问题，找出一些解决方法，形成自己的过程。我觉得国内的软件环境这么复杂，程序员的自主精神又这么强，敏捷方法应该是在中国首先提出才对，只是国人都有唯标准唯规范至上的心理定式，即使找出好办法，也觉得不规范，没有深入形成理论，无法提升高度，始终是跟着鬼子屁股后面走，我想这也是国外软件行业不成熟的表现之一吧。
2. 敏捷仅仅是一个软件过程
如果仅仅从软件过程的角度去认识敏捷实施敏捷，效果不会太好。敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上，正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。
涉及到人的问题，就已经不再是过程所能覆盖的了，就到了企业管理的层面上了，包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍：
l 把客户当作合作伙伴而不是对手，从客户角度出发去想问题，充分的跟客户沟通，而不是出了问题推诿责任。目标是让软件实现客户的价值，而不是收钱就完事儿。
l 把人的能动性调动起来，给动力而不是给压力。
l 要实用而不是要规范。让开发人员理解并实施，体验到敏捷的好处，而不是盲目机械地实施规范。
l 没有绝对的权威，每个人都有可取之处。
3. 迭代就是敏捷，UP属于敏捷。
看到这么多人都把UP归入敏捷，我都开始怀疑是不是自己搞错了。但是在我的印象中：
UP是重型的过程，虽然引入了迭代，但是其原则和价值观与敏捷是不同的。敏捷注重的是反馈，迭代周期尽量的短，重在客户的参与，通过客户的参与，获取持续的反馈，不断调整使整个项目走在正确的方向上。同时也给客户一个感受和思考的机会，因为对于大多数客户而言，目标是明确的（不排除有些客户目标也不明确），但是具体怎么做，开始时是没有想法的，只有看到具体的东西的时候，才知道“噢，原来可以这样，那我想把这里调整一下”。
4. 敏捷是彻底革命的。
敏捷，特别是XP，让人有耳目一新的感觉，觉得以前的所有软件工程理论，设计方法都可以抛弃掉了，推翻一切，从头再来。抱着这种想法实施敏捷，那就错了，敏捷不是“石头里蹦出个孙大圣”，以前的软件过程中也有敏捷的影子，只是没有像敏捷一样上升到价值观和原则的高度，比如快速原型法。敏捷是在对已有的软件过程方法的改进，抛弃的是传统软件工程低效的外表，以往的软件过程中很多技巧都是很实用的。实施敏捷应该以现有的软件过程为基础，从敏捷宣言和原则出发，利用敏捷的方法来改善过程。
5. 敏捷是反文档的。
文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，怎样解决沟通的问题？难道你想每次沟通都完全用手比划，用嘴说，跟不同的人重复表述同样的想法，那样更是低效的。
应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价（特别是更新同步文档的代价）。
因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。
文档不是目的，有效沟通才是目的。
6. 为了敏捷而敏捷
“嗯，敏捷这么好，我们也敏捷吧”，可能很多人会有这种想法。忘了以前是在哪儿看的大师采访录：
Q：“我们现有的过程很好，不知道怎么用敏捷改进？”
A：“既然很好，那就不要用敏捷”。
做什么事情都要有明确目标的，敏捷虽好，得看你需不需要，能不能解决你现在头疼的问题，如果不是，那就不要给自己找麻烦了。
7. 敏捷是CMM的反义词
在桂林会议的讨论中，很多人把CMM作为敏捷的反义词，我觉得这不是很合适。CMM只是一种衡量软件成熟度的标准，并非过程，和敏捷不是一类概念。如果要给敏捷找一个反义词，我觉得传统的瀑布式开发应该更合适一些。
并且，我认为，如果CMM还能继续流行下去的话，应该会有公司可以用敏捷改善的过程通过CMM认证。
8. 敏捷是自由的，无约束的。
敏捷强调的是自组织团队，发挥人的能动性，以动力代替压力，让人有绝对自由的错觉。但是应该清楚，凡是都是要讲究一个平衡，人也是两面的，消极的一面和积极的一面同时并存，绝对的自由会放纵人消极的一面。敏捷并非是绝对自由，无约束的。作为管理者，有一个职责，就是引导团队成员用自己积极的一面去压制消极的一面，不能放任团队中出现搭便车的现象，否则将打击整个团队的士气。如果实在无效，那就只能将其排除出团队了，这个惩罚够有约束力吧？
9. 重做就是重构
重做不等于重构，很多场合这两个概念是混淆的。但是在敏捷中，重构的一个特征是必须可控的。当对系统结构进行大的调整时，如果没有测试驱动辅助的话，那么可控性就会很差，这不能叫做重构。
HP敏捷论坛地址：http://h50237.www5.hp.com/partnerportal/forum/default.aspx?cod=asd
分享到：
相关推荐
总之，敏捷开发强调灵活性、客户参与和快速反馈，但其实施必须根据项目特性灵活应用，避免陷入常见的误区。理解并正确运用敏捷原则和实践，才能充分发挥敏捷的优势，提高软件开发效率和客户满意度。
然而，UML建模实践中存在一些常见的误区，这些误区可能导致建模效率低下或者误解建模的本质。 误区一：建模等于写文档。这种观念将建模等同于传统的文档编写，认为建模是繁琐且无用的。实际上，建模的核心价值在于...
本文将基于给定的文件内容，提炼并深入探讨敏捷开发中常见的十大错误及其应对策略。 #### 1. **缺乏有效的引荐** - **错误描述**：当敏捷教练加入团队时，如果缺乏来自管理层或团队内部权威人士的有效引荐，可能会...
- **敏捷的定义**：明确敏捷开发的核心价值观和原则。 - **成为自适应型组织**：介绍如何构建一个能够快速响应变化的组织结构。 - **明日行动指南**：指导团队和个人如何采取具体步骤迈向更敏捷的工作方式。 #### ...
采用敏捷开发模式，持续集成和持续测试可以尽早发现问题。 6. **测试是孤立的阶段**：软件测试不应被视为独立于开发的阶段，而应与之并行进行。贯穿整个开发过程的集成测试和回归测试可以提高效率，减少返工。 7. ...
敏捷开发强调快速迭代、频繁交付以及应对变化，这与TDD中通过持续测试来保证软件质量的做法不谋而合。敏捷开发中的许多其他实践，如持续集成、持续部署和代码复审，都与TDD紧密相连，共同构成了一个有机的整体。 ...
在实施SOA的过程中，存在一些常见的误区： 1. **误区一：SOA成本过高**。这种误解往往源于缺乏整体规划和预算控制。SOA确实需要初始投入，但它的核心价值在于服务的复用，长期来看，可以降低IT成本并提高效率。规划...
文章特别提到了敏捷开发的重要性，敏捷并非一套固定的规则，而是一种平衡“混乱”和“死板”的艺术。它强调适应性和灵活性，以应对软件开发中的不确定性。作者建议，每个团队应根据自身特点定制适合的敏捷过程，以...
在敏捷开发模式下，测试和开发是并行进行的，测试人员和开发人员需要共同参与测试活动。测试驱动开发（TDD）和行为驱动开发（BDD）强调了测试的重要性，提倡先写测试用例再编写代码，这有助于提升代码质量。 最后，...
小强老师的“软件测试基础课程3-测试用例误区”深入探讨了在设计和执行测试用例时常见的误解和错误，帮助我们更好地理解和优化测试过程。以下是对这个主题的详细解析。 首先，我们需要明确测试用例的定义。测试用例...
在《测试驱动开发的三项修炼——走出TDD丛林》中，作者深入探讨了TDD的核心理念、实践技巧以及常见误区，帮助开发者更好地理解和应用TDD。 一、TDD的基本原则 1. **红灯原则**：首先编写一个不能通过的测试用例...
- **常见误区**：在需求收集过程中，往往会收集到大量需求，但这并不意味着每一个需求都应该被同等对待。 - **改进策略**： - **需求筛选**：建立一套有效的筛选机制，确保优先处理高质量的需求。 - **需求质量...
误区九：设计模式无法适应敏捷开发。敏捷开发强调快速迭代和适应变化，而设计模式恰好提供了一种灵活应对变化的方法，如适配器模式、装饰者模式等。 误区十：不使用设计模式就是落伍。虽然设计模式不是强制性的，但...
2. 管理模式分析：IPD（集成产品开发）、DT（设计思维）、AD（敏捷开发）等是当前产品开发管理中常见的模式。 通过这些知识点的阐述，我们可以更全面地理解物流支付行业的市场现状、发展趋势和产品开发策略。这些...
这本书可能会介绍Scrum的角色、事件、工件及其在实际项目中的应用，帮助读者理解敏捷开发的核心理念。 7. **《人月神话 40周年中文纪念版_8593309.pdf》**：弗雷德里克·布鲁克斯的经典著作，揭示了软件项目管理中...