敏捷开发的特点：
以用户的需求进化为核心，主张简单，拥抱变化，可持续性，有足够的鲁棒性，递增开发。迭代、循序渐进，实时可使用，轻文档测试驱动开发，有针对性的设计但不需要面面俱到的设计。
一般敏捷开发的周期为5-10个工作日，一次story的代码量不超过2000行代码，若超过2000行代码建议进行story拆分，功能迭代的最小时间单位精确到半天（不能精确到1小时，因为一个功能开发完要有足够的时间），若开发的一个功能低于一天需要进行开发功能合并。
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发被称为轻文档的测试驱动开发，它不是没有设计和和文档。而是设计要有，但是不需要面面俱到的详细设计，是有针对需求的设计。文档可以很简单，甚至开始没有，但是完成一个开发周期要补充文档，认为敏捷开发没有文档和设计是错误，若真是那样，那是裸奔开发，裸奔开发不是敏捷开发。
以前我们采用瀑布模型进行开发，把需求写的很详细，写的像ppt一样，近一个需求就整一到两周，评审两次次，结果做时各种问题都出来了，产生很多新需求，原来写的需求设计书与接口文档和实际实现相差十万八千里，并且开发完成他们一般也更新。需求设计书最终变得像对付开发流程和应付领导，把实际的开发时间大大缩减，导致后期不断加班来弥补。这就造成等需求和设计需求是很清闲，软件开发时很忙。这违反了软件是我们的主要目标基本思想。瀑布模型开发很容易产生设计过度问题，设计过度问题和没有设计开发同样影响开发进度。开发模式和头脑风暴，盲目反对都是软件开发中常遇到的问题。在整个项目组都处于畏惧项目时，头脑风暴也很有必要，但是过度的头脑风暴会造成严重错估时间错估项目复杂度问题，有的老程序猿经常犯一个通病是畏惧困难盲目反对。其实很多项目只要做都能做出来的，只是时间问题，有很多问题都有变通的方法。要在战略上蔑视敌人，战术上重视敌人。
◆软件是你的主要目标
软件开发的主要目标是以有效的方式，制造出满足投资者需要的软件，而不是制造无关的文档，无关的用于管理的工件，甚至无关的模型。任何一项活动（activity ），如果不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。
◆轻装前进
你建立一个工件，然后决定要保留它，随着时间的流逝，这些工件都需要维护。如果你决定保留7个模型，不论何时，一旦有变化发生（新需求的提出，原需求的更新，团队接受了一种新方法，采纳了一项新技术…），你就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果你想要保留的仅是3个模型，很明显，你实现同样的改变要花费的功夫就少多了，你的灵活性就增强了，因为你是在轻装前进。类似的，你的模型越复杂，越详细，发生的改变极可能就越难实现（每个模型都更“沉重”了些，因此维护的负担也就大了）。每次你要决定保留一个模型时，你就要权衡模型载有的信息对团队有多大的好处（所以才需要加强团队之间，团队和项目投资者之间的沟通）。千万不要小看权衡的严重性。一个人要想过沙漠，他一定会携带地图，帽子，质地优良的鞋子，水壶。如果他带了几百加仑的水，能够想象的到的所有求生工具，一大堆有关沙漠的书籍，他还能过得去沙漠吗？同样的道理，一个开发团队决定要开发并维护一份详细的需求文档，一组详细的分析模型，再加上一组详细的架构模型，以及一组详细的设计模型，那他们很快就会发现，他们大部分的时间不是花在写源代码上，而是花在了更新文档上。
在敏捷开发模式下，让我们把注意力集中到写代码的主要目标上，减少了过度设计的问题，因此我们开发功能很快，很健壮，再也不用为了发一个版本晚上加班熬夜了，开发和需求达到同步。
以前我在南京做的一个华为项目，赢得了2010年全球华为十大敏捷开发最佳开发团队第四名。
