Question

敏捷开发的敏捷开发的原则

Answer 1

1. 快速迭代
相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年仅发布仅2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。
2. 让测试人员和开发者参与需求讨论
需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。 同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。
3. 编写可测试的需求文档
开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。
4. 多沟通，尽量减少文档
任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。
团队要确保日常的交流，面对面沟通比邮件强得多。
5. 做好产品原型
建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。
6. 及早考虑测试
及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。

Answer 2

敏捷型方法发源于20世纪90年代的 IT 软件开发行业。2001年，软件开发业的17位领导者在美国犹他州聚会，发布了《软件开发敏捷宣言》，进而从《敏捷宣言》派生出了12条敏捷原则，他们分别是：
（1) 我们的最高目标是，通过尽早地、持续地交付有价值的软件来使客户满意。
（2) 即使是在项目开发后期，也欢迎对需求提出变更。敏捷过程利用适应变化来帮助客户创造竞争优势。
（3) 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
（4) 项目过程中，业务人员与开发人员必须在一起工作。
（5) 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
（6) 无论是团队内还是团队间，最有效的沟通方法是面对面的交流。
（7) 可用的软件是衡量进度的主要指标。
（8) 敏捷过程提倡可持续的平稳开发。项目方、开发人员和用户应该能够保持恒久稳定的开发速度。
（9) 对技术的精益求精以及对设计的不断完善将提升敏捷性。
（10) 简单——尽最大可能减少不必要的工作。这是一门艺术，是根本。
（11) 最佳的架构、需求和设计出自于自组织的团队。
（12) 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
以上就是敏捷开发的十二原则，希望可以解答您的问题。