敏捷开发必须注意的12项原则
刚好今天有点时间，整理了一哈资料。share 给大家。
1.我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意。
有一篇文章分析了对于公司构建高质量产品方面有帮助的软件开发实践，其中一个实践表明尽早的交付具有部分功能的系统和系统质量之间具有很强的相关性。文中说，初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。从该文中还发现，以逐渐增加功能的方式经常性的交付系统和最终质量之间有非常强的相关性。交付得越平凡，最终产品的质量就越高。敏捷实践会尽早的，经常的进行交付，我们努力在项目刚开始的几周内就交付一个具有基本功能的系统，然后我们努力坚持每2周就交付一个功能渐增的系统，如果客户认为目前的功能已经足够了，客户可以选择把这些系统加入产品中，或者他们可以简单的选择在检查一偏已有的功能，并指出他们想要的改变。
2。即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势：
这是一个关于态度的申明。敏捷过程的参与者不惧怕变化，他们认为改变需求是好的事情，因为那些改变意味桌团队已经学习到了很多如何满足市场需要的知识。敏捷团队会非常努力的保持软件结构的灵活性，这样当需求变化时，对于系统造成的影响是最小的。
3。经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好：
我们交付可以工作的软件，并且尽早的，经常性的交付他，不赞成交付大量的文档或设计计划
4。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
为了能够一敏锐的方式进行项目开发，客户，开发人员以及涉众之间就必须要进行有意义的，频繁的交互
5。围绕被激励起来的个人构件项目，给他们提供所需要的环境和支持，并且信任他们能够完成工作。
在敏捷项目中，人被认为是取得项目最成功最重要的因数，所有其他因数--过程、环境、管理等等都被认为是次要的。
6。在团队内部，最有效果的信息传递方式是面对面的交流
7。工作的软件是首要的进度度量标准、
敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度，他们不是根据所处的开发阶段、已经编写的文档的多少或这已经常见的基础结构代码的数量来度量开发进度的，只有当30%的必须功能可以工作时，才可以确定进度完成了30%
8。敏捷过程提倡可持续的开发速度。责任人、开发者和用户应能够保持一个长期的、恒定的开发速度
敏捷项目不是50米短跑，而是马拉松长跑，团队不是以全速启动并试图在项目开发期间维持那个速度；相反，他们以快速但是可持续的速度行进。
9。不断的关注优秀的技能和好的设计会增强敏捷能力
高的产品质量是获取高的开发速度的关键，保持软件尽可能的简洁、健壮是快速开发软件的途径。因而，所有的敏捷团队成员都致力于只编写他们能够编写的高质量代码。他们不会制造混乱然后告诉自己等自己有更多的时间在来清理。
10。简单
敏捷团队不会试图去构建那些华而不实的系统。
11。最好的架构、需求和设计出自于自组织的团队
敏捷团队是自组织的团队，任务不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。
12。每隔一段时间，团队会在如何才能更有效地更有效的工作方面进行反省，然后相应地对自己的行为进行调整。
Just a little time today, collate some information. Shares to you.
1. Our highest priority is to be done through early, continuous delivery of valuable software to enable customer satisfaction:.
An article analyzed companies have built high-quality products to help software development practice, a practice which has shown early part of the delivery system and quality of functional systems between highly relevant. The article said that the initial delivery system contains functions less, the ultimate delivery system for the higher quality. From the text also found that the way to gradually increase the regular functions of the delivery system and quality of the final between the very strong relevance. They treat ordinary delivery, the higher the quality of the final product. Practice will rise early, often referred to the conduct of our efforts in the beginning of the project within a few weeks to a basic function of the system, and then we try to uphold every two weeks on increasing delivery of a functional system, if customers believe that the current function is sufficient, customers can choose to join these systems products, or they can choose to check goes a simple function and that they want change.
2. Even the development of late, and also welcomes change demand. Quick changes to the process used to create competitive advantages for customers :
This is the attitude that one on. The participants were not afraid of hard process changes, changes in demand that they are good things, because those changes mean table team has learned a lot of knowledge of how to meet the needs of the market. The team will be very strong efforts to maintain flexibility in the structure of the software, such as changes in demand, the impact of the system is the smallest.
3. Regular delivery to the software delivery intervals from weeks to months, the shorter the better delivery intervals :
We can work to the software, and the early, regular delivery he did not favour large files or design plan to
4. Throughout the project development, business development officers and staff must work together daily
In order to be able to project development of a sensitive manner, customers, the development of trade between the staff and must be meaningful, frequent world
5. Focusing on the individual components of the project was to inspire, to provide them with necessary environment and support, and trust them to complete their work. In quick projects, were considered to be the most successful project achieved the most important factor, all other factors -- process, the environment, management, etc. are considered to be minor.
6. In the internal team, the most effective way is face-to-face exchange of information transmission
7. Working software is the primary measure of the progress standards, Nimble project through measurement of current software to meet customer needs to measure the amount of progress that they are not on the basis of the development phase, has been prepared by the number of files that have common or infrastructure code number to the measurement of progress, only when 30% of the work must be functional, it can progress to complete the 30%
8. Quick process to promote sustainable development speed. Responsible persons, developers and users should be able to maintain a long-term, constant speed development 50-meter dash was not quick projects, but marathon relay, the team not to start at full speed and trying to maintain that speed in the project development period; Instead, they began to fast but sustainable rate.
9. Constant concern of outstanding skills and good design will enhance the ability of quick High-quality products is the development of high-speed access to the key, and maintain the software as simple, healthy development of software is rapid way. Thus, the ability of all team members are committed to only prepare them to prepare high-quality code. They will not create chaos, and then tell their own in more time to clean up.
10. Simple Ability to build a team would not try to utilize those systems.
11. The best structure, and demand from organizations in the design from the team Since the team was quickly organized team, the task is not allocated to individual team members from the outside, but allocated to the entire team, and then complete the task by the team to determine the best method.
12. Periodically, the team will be more effective in how to work more effectively reflect, and then act accordingly to adjust its own.
