敏捷实践笔记
敏捷的关键点： 通过及早和频繁发布的方式小步前进以控制风险，过程中跟客户紧密合作，通过频繁测试来保证质量，高效的沟通，紧凑的自组织团队，注重每个人的参与性
敏捷开发的六个实战经验.
http://www.csdn.net/article/2013-12-09/2817746-6-practical-agile-techniques
简单总结下，六点是：
1. 快速迭代 版本发布周期缩短 可逼迫团队不断优化工作流程，提高效率，避免在无足轻重的地方浪费时间
2. 让测试人员和开发人员参与需求讨论 以讨论组形式讨论更有效率，让这些人参与可以利用成员的互补性，讨论更活跃，参与感更强。同时可轻松定义需求，对其进行分组确定优先级。
3. 编写可测试的需求文档 用用户故事“user story”的方式编写需求文档，该方法可使我们关注于需求上，而不是解决方法和技术上。规划需求可采用3W, who-what-why，一开始不应过分详细。
4. 多沟通 尽量减少文档 好的沟通是敏捷开发的先决条件。团队确保日常交流，鼓励日常的协调会和碰头会，5-7人控制在十分钟。碰头会要过一遍昨天完成了什么，今天要做什么，哪些问题仍待讨论，可用burndown chart（燃尽图）来表示工作进度。
每次迭代要有计划会议和评审会议，以对工作查漏补缺。 开会时，可将分组打破，让整个团队都参与到需求讨论和测试中来，以突出成员个人，让大家更乐意参与。
5. 做好产品原型 建议使用草图和模型来阐明用户界面。
6. 及早考虑测试 及早考虑测试在敏捷开发中很重要。敏捷开发中一个常见问题就是开发者没有对已有的代码库进行充分的回归测试。由于迭代周期很短，可以对迭代的设计、实现和底层测试一块进行回归测试。
一系列迭代之后，可以只针对测试活动再补充一个迭代，将重点放在系统测试、与其他系统的集成度、性能等方面。
开始敏捷开发可以从点滴做起，如经常开碰头会，为项目管理使用更高效的工具等。
敏捷实践：如何让团队迭代交付周期缩短一半
http://www.csdn.net/article/2013-03-25/2814622-cto-club-95
应用敏捷让迭代周期减少一半
应当用敏捷的思想，让一个新组建的团队成为产品的主人和管理创新的驱动者。当团队自发去持续优化产品，不断提升产品质量和研发效率时，他们会树立更高的目标去挑战，当他们持续地“赢”得两次以上高难度时，卓越成为了团队的习惯。
- 集中规划和项目推演。这样做的好处是：研发、测试团队和和项目经理Scrum Master一起深入理解项目要求，测试团队也应此能够更早地开始编写测试脚本，也避免了后期矛盾。
- 站会，每个人都是众星捧月的明星。站着开会带来的紧张感和疲劳感有效地避免了过于冗长的会议。同时，让发言者站在中间的做法更能增强其自信心和责任感。
- 团队自我驱动所做的一系列优化：明确只有可用的功能才算完成；明确项目目标；把目标分配给明确的负责人；严格要求代码提交环节；由敏捷教练管理，明确每个人的观点；优化团队规模等等。同时要避免整体重构，尽可能局部重构。项目经理更需要确定项目能否完成而不是仅是关注项目进度。
- 持续集成和产品演示环境。自动化集成和演示环境，省去了很多重复的工作。
- 别开生面的复盘会。在复盘会上，队员都需要完成自评和他评，绩效与任务难度挂钩的方式也激励员工做有挑战的项目/功能开发。同时，严格的得失分析让队员更好地吸取经验和教训。
- 保证质量可信度。虽然研发速度很重要，但是没有质量保证的快速开发非常危险，质量可信度是一项需要高度重视的标准。
2周，将想法变成开发级需求 成功需要正确的产品方向+正确的构建方法，因此在开发前弄清楚产品方向和构建方法至关重要
敏捷开发之12条敏捷原则
http://www.csdn.net/article/2010-08-05/277860 更多内容：敏捷方法之Scrum.pdf
对《Agile Software Development －Principles,Patterns,and Practices》（中文书名： 《敏捷软件开发——原则、模式与实践》）介绍的12原则进行的加工阐述。
1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。规划迭代故事时必须按照优先级安排，为客户先提供最有价值的功能。通过频繁迭代能与客户形成早期的良好合作，及时反馈提高产品质量。敏捷使用用户故事来罗列需求，用户故事是一种表示需求的轻量级技术，敏捷估算中使用了这个模板：“作为【用户的类型】，我希望可以【能力】以便【业务价值】“。
使用使用基于用户故事的需求分析方法时，仍可能需要原型和编写文档，只是工作重点更多的转移到了口头交流。
3.经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
迭代是受实践框限制的，意味着即使放弃一些功能也必须按时结束迭代。只要我们可以保证交付的软件可以很好的工作，那么交付时间越短，我们和客户协作就越紧密，对产品质量就更有益。
敏捷开发项目中对开发阶段没有什么重要的分割，没有先期的需求阶段，然后是分析阶段，架构设计阶段，编码测试阶段等，在项目真正开始后，每次迭代中都会同时进行所有的上述阶段工作。
4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5.围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。敏捷团队一般不会很多人（大团队实施敏捷时也会分成多个小的敏捷团队），面对面的交谈反而更快速有效。
7.工作的软件是首要进度度量标准。衡量某个功能是否完成的首要标准就是这个功能可以工作了，对用户来说已经可以应用了。
8.敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。敏捷过程希望能够可持续的进行开发，开发速度不会随着迭代的任务不同而不同，不欣赏所谓的拼一拼也能完成的态度，开发工作不应该是突击行为。
9.不断地关注优秀的技能和好的设计会增强敏捷能力。很多原则、模式和实践也可以增强敏捷开发能力。
10.简单——使未完成的工作最大化的艺术——是根本的。敏捷团队不会去构建明天的软件，而把注意力放在如何通过最简单的方法完成现在需要解决的问题。
11.最好的构架、需求和设计出自与自组织的团队。敏捷中有很多种实践，大家都知道，迭代式开发是主要的实践方法，而自组织团队也是主要的实践之一。一支高效的工作团队的形成需要经过几个阶段，大家对工作理念和文化形成共识，相互之间理解并达成默契。
团队中有必要指明一些人承担一定任务的角色。第一个角色是产品所有者（Product Owner）。产品所有者的主要职责包括：确认小组所有成员都在追求一个共同的项目前景，确定功能的优先级以便总是在处理最具有价值的功能，以及作出决定使得对项目的投入可以产生良好的回报。
12.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷软件测试的文化挑战
http://www.infoq.com/cn/news/2010/12/agile-test-culture
软件开发组织采用敏捷开发时，测试团队通常需要花很长时间来完成转变，会遇到难以接受的文化差异。
以如何定义软件质量的可接受水平的角度思考组织的质量哲学。
合适的节奏 传统的测试团队习惯于在项目结束时快速、激烈地测试，这会导致周末和夜间的加班。这与敏捷价值冲突，敏捷价值的中心思想是让大家时刻以最好的状态工作。在敏捷项目中，鼓励人们以一个合适的节奏工作。偶尔需要高强度地工作，但是这是特例，不是一般情况。
客户关系
在传统的软件开发中，开发团队和他们的客户之间的关系更像是买卖关系。敏捷开发依赖于客户或者至少是客户代表的紧密参与。敏捷团队邀请客户协作，如果可能， 在同一地点工作，并且密切地参与开发过程。双方都了解对方的强项和弱点。
沟通挑战 一些敏捷过程提供了便于团队交流的方法。例如，Scrum有Scrum会议，来自多个团队的代表每天交流。如果工作的测试团队或其他部门与编码团队分离，那么需要找到保持不断交流的方式。
先行动后道歉 通常在大的组织中，官僚政治的节奏太慢，团队可能需要找到并执行自己的解决方案。
通常在大的组织中，官僚政治的节奏太慢，团队可能需要找到并执行自己的解决方案。
授权团队 在敏捷项目中，让每个开发团队感觉到有做决定的权力是很重要的。
对软件开发有利的5个敏捷编程方法
http://www.csdn.net/article/2013-09-24/2817034-five-ways-agile-programming-benefits-software-development敏捷编程是一个以客户为导向的方法来管理软件开发团队和项目，它侧重于终端用户的参与、早期发布和增量发布，以及频繁的质量控制测试。这一概念适用于各种规模的公司（尤其适用于小型和中型的IT公司）。下面介绍5种敏捷编程方式，能够帮助开发者在软件开发过程中获得巨大的竞争优势。
1. 快速收益 发布一个有限的、高优先级设计功能的产品可以确保更快的获得投资回报。历史经验表明，大多数市场统治者都是那些最先发布新产品的开发者，一旦发布之后遇到质量问题，则采取断断续续的修补、改善措施。
2. 降低风险 一个带有基本功能的测试版本也是可以发行的，接下来来自潜在客户的反馈将是对产品进行改进的重要依据。
3. 提高效率 消除报告会议的方式，取而 代之的是授权团队成员，让他们自己做出正确决定。除了利用精简实践之外，开发团队可以利用各种技术来提高工作效率，这首先想到的就是云计算。
4. 更好的质量控制 “承诺测试”是与敏捷编程有关的最佳实践项目的核心部分。除此之外，频繁的测试过程能够让质量问题更早的浮出水面。
5. 提高顾客满意度
在敏捷编程环境中，终端用户的参与可以说是一种鼓励行为。这样就无形当中增加了客户满意度，因为客户的积极参与，并用更加灵活的方式改变了软件的特性。
高效敏捷的十大经验法则
http://www.csdn.net/article/2012-12-12/2812720敏捷是一种应对快速变化的需求的一种软件开发能力，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
本文是VersionOne 公司CEO Robert Holler，一家专注于敏捷开发工具和敏捷培训的公司。Robert总结了这十年来的敏捷软件开发经验，缩减成十条经验法则，希望对热爱敏捷的公司、团队和个人有所帮助。
1. 简单至上
成功的敏捷人士需要具备不同的业务能力以适应与他们一起工作的相关人员，包括企业的相关利益者，产品企划人员、开发者，测试人员等等。Holler称很多公司在建立敏捷平台时，每当面对有独特需求的用户时，他们很容易使自己陷入困境。
2. 定义自己的节奏 如开会之前就把问题准备好，以避免低效冗长的会议。
3. 敏捷就是纪律
4. 软件很难Scale，但是敏捷却不
5. Think of the Big Picture 把自己当做统观大局的人 系统思考非常重要，这就需要一个真正成熟、能够深入探究复杂与冲突议题的团队，否则改变系统可能会带来一定的风险。
6. 失去信仰 为了适应不同的节奏，你应该尽可能的与敏捷迭代方面保持密切联系。
7. 持续关注商业价值 团队中的成员需要纵观全局以最大限度地降低项目开发周期。
8. 敏捷不只是为软件部们
9. 持续规划 团队中的成员需要纵观全局以最大限度地降低项目开发周期。
10. 做敏捷但不要做重复的敏捷 行动永远比空谈有效，你无法预见将发生的所有困难与问题，直到你真正开始去做敏捷模式。
一个真实的敏捷开发案例
http://www.csdn.net/article/2010-08-05/277840
拆出一个只关注架构的团队
项目负责人对核心需求很了解，但对安全、日 志、可用性、性能等方面就所知甚少。为此创建了一个独立团队，他们只关注架构方面的内容。他们的工作就是弄清楚非功能性需求，好让我们把它们转换成 backlog中的用户故事。
对于不适合放到Scrum Sprint中的工作（比如寻找关键人员，跟其他客户部门交流），可以让一个单独的团队去做，这样效率更高。特性团队可以集中精力开发软件。有一个专职的技术文案也很好，即便这会增加沟通成本。
[探讨]敏捷开发原则
http://www.csdn.net/article/2012-07-17/2807394
简单至关重要 If I have some complicated work to do, I will give it to the laziest person I have, because they will find the simplest way to do it.如果你只关心和只做客户想要的，而不去添加额外的功能和改进，那么你的工作就会轻松很多，并且会很快达成目标。从根本上说，客户也只关心这个。
其他链接：
http://blog.vsharing.com/agiledo/
敏捷之道Scrum篇 http://www.cnblogs.com/chenkai/archive/2012/04/15/2443164.html
敏捷 RUP：来自实战中的经验 http://www.csdn.net/article/2010-08-05/277857 为在 IBM Rational Unified Process 或者简称为 RUP 团队上面应用敏捷策略提供了被证明为行之有效的建议。
CIO如何帮助IT团队迅速兑现敏捷开发 http://www.csdn.net/article/2009-12-15/274053-215800
敏捷工具：
七个垂手可得的敏捷开发工具
敏捷开发过程剖析及工具推荐