重新理解敏捷开发（下）
敏捷开发的实现方法
组织文化必须支持谈判
人员彼此信任
人少但是精干
开发人员所作决定得到认可
环境设施满足成员间快速沟通之需要
软件开发之韵，Software Development Rhythms
敏捷数据库技术，AD/Agile Database Techniques
敏捷建模，AM/Agile Modeling
自适应软件开发，ASD/Adaptive Software Development
水晶方法，Crystal
特性驱动开发，FDD/Feature Driven Development
动态系统开发方法，DSDM/Dynamic Systems Development Method
精益软件开发，Lean Software Development
AUP（Agile Unified Process）
Scrum
XBreed
极限编程，（Extreme Programming）
探索性测试
ATDD
测试驱动开发，TDD/Test-Driven Development
行为驱动开发，BDD/Behavior-Driven Development
Scrum
极限编程
计划游戏：先快速地制定一份概要的计划，然后随着项目细节的不断清晰，再逐步完善这份计划。一般在大公司基本是这样的流程：<1>初始计划 – 确定重要的需求，进行快速响应，工时评估。<2>发布计划 – 了解开发进度后，客户就知道需求的实现成本（包括人力、时间等资源）、商业价值、优先级别（预估可能不准确，随开发不断调整），然后就回对需求根据优先级进行替换。<3>迭代计划 – 一般迭代周期为1到2周，周期内需求的实现顺序根据技术来进行排序，可以串行也可以并行开发，开发中的需求不应被更改，未开发的需求可以看情况调整。<4>任务计划 – 每次迭代更新，开发人员对要开发的需求任务进行拆解，客户进行优先级调整， 计划的方式可以采用任务列表、便笺、白板标示等方式，每完成一项，则应对其进行标注，对任务进度随时更新；
小型发布：更多的发布测试版本，中间版本，让客户或者PM审核，确认功能开发没有错误，需要引入代码管理工具，版本控制工具 ；
隐喻：创造心照不宣的词汇和列子，更形象有趣的沟通。比喻有时候更能让人更快更好的理解你的意思，而不是一堆晦涩专业术语；
简单设计：没有重复代码，尽量少的类和方法，使用迪米特法则等 ，尽可能考虑当下需求，不要为了扩展性过度设计，多考虑不同的方案，然后选择一种最实际、简单的解决方案，只有在确定真的需要引入某些基础结构（比如数据库、通信服务框架）性价比更高时，再去引入它们；
测试先行／测试驱动开发：编写单元测试是一种验证行为，更是一种设计行为。测试驱动开发（TDD），需要借助一些自动化测试工具，可以帮助开发人员做到有目的的开发。验收测试（ UAT ）可以用来验证系统功能是否完善；
重构：在Martin Fowler大神的名著《重构》一书中，他把重构定义为：在不改变代码外在行为的前提下对代码进行修改，以改进代码内部结构的过程。重构的目的是降低变化引发的风险，使得代码优化更加容易。重构有时并不是需要做很大的修改，XP倡导开发人员经常进行重构；
结对编程：鼓励团队进行结对编程，而且认为结对编程的组合应该动态地搭配，根据任务的不同、专业技能的不同进行最优组合。在XP中，结对编程指的是由2个开发人员公用一台电脑，一个人进行编码，另一个进行观察并寻找代码中的错误和可以改进的地方，两个人进行频繁的角色互换。结对关系每天至少进行一次，且团队中每个成员都应和其他成员一起工作参与。研究表明这样不但不会降低开发效率，还会大大减少缺陷率。简单理解就是一个人身兼开发和测试开发2个岗位职责，这种方式已经很少看到 ；
集体代码所有制：团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。同时，XP强调代码是谁破坏的（也就是修改后发生问题），就应该由谁来修复；
持续集成：团队每天尽可能多次的进行代码集成（多次的check in和check out并进行merge，使用非阻塞的源代码控制工具；每天进行多次系统构建），保证团队获取的代码都是近期统一过的代码，避免太多不一致造成冲突 ；
每周工作40小时／可持续的速度：简单来说，就是反对加班，将进度控制在合理的范围，让开发人员保持一个健康高效的状态。做到让开发人员享受开发，而不是让他们感受到了煎熬；
现场客户：XP方法论认为最重要的需要将客户（不仅仅指为我们产品付费或使用产品的外部客户，它还包括公司内部的业务部门，有合作关系的甲方、第三方等，一般在公司中你面对的是产品、业务分析师、项目经理等）请到开发现场，要面对面沟通 ；
编码标准：除了这种文字规范以外，还可以采用一些如自动格式化代码工具之类的方法进行代码规范，大公司一般对各种语言都有相应的编码规范 ；
Scrum
Scrum中的三种角色
产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（Scrum Team）
由开发人员、测试人员、文案和其他帮助研发的成员组成，主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力，团队成员常常扮演多种角色；成员可以采用任何工作方式，只要能达到Sprint（指在Scrum项目管理方法中的一个常规、可重复的较短工作周期）的目标。
Scrum中的三种常用可视化文档
产品需求列表（Product Backlog）
这里的Backlog是指待开发项，积压的任务。产品 Backlog 包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的，需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护。产品经理会从众多用户故事中筛选出优先级，并把他们列入产品开发列表中，需求列表会随着每次的Sprint迭代和更改。
Sprint代办列表（Sprint Backlog）
Sprint 本意为“冲刺”，指迭代周期，长度通常是一至六周。每次Sprint迭代前，团队要进行讨论，最优项的用户故事将进入Sprint代办列表，剩下的继续评估优先级，交到下次Sprint中。
燃尽图（Burndown Chart）
燃尽图是用来展示整个Sprint代办列表的进度，横轴表示整个Sprint的总时间，单位可以是小时或天等，纵轴表示Sprint中的所有任务，当燃尽图曲线接近于0时，也就意味着这次Sprint即将完工。燃尽图的跟踪进度应该由团队整体每天更新，如果曲线下降太快，说明本次Sprint中的任务太少，可以添加一些任务进来，反之则去除一些任务，这个跟团队开发评估经验有关。燃尽图要便于更新，不用追求酷炫的效果，也不要太过复杂，难以维护。
公司中燃尽图常常搭配看板使用，参考下图：
Scrum中三种形式的会议
Sprint计划会议（Sprint Planning）
Sprint计划会议是产品经理、Scrum Master和开发团队碰头的会议，用于讨论用户故事并估算任务量。
每日例会（Daily Scrum）
每日例会，即你学习Scrum必定会遇到、大公司平时也常见到的站立会，整个团队会简述工作进度，并讨论是否有任务需要搁置或加派人手。
Sprint回顾会议（Sprint review）
在Sprint临近尾声时，团队会进行Sprint回顾会议，这时研发团队会向产品经理展示开发好的功能，然后整个团队讨论是否有需要改进的地方。
Scrum整体流程
了解完了Scrum中的重要组成部分，我们可以来谈一下Scrum的整体流程了。
产品经理把需要上线的产品特性做成产品需求列表（Backlog），然后由产品经理甄选出最优项，准备交给整个团队讨论。
召开Sprint规划会议，研发团队、产品经理和Scrum Master讨论用户故事优先项，并且决定下次Sprint要研发的需求项。
根据Sprint规划会议制定Sprint需求列表，这个列表就是经过团队讨论后的用户故事，用于下次的Sprint，会议结束后，整个研发团队和产品经理必须要对每个用户故事有深刻的理解。
研发团队要在一到三周的时间里开发完成Sprint列表中的需求。在Sprint期间，每日站会用于团队来交流他们做完了什么、正在做什么以及遇到的问题。Sprint的产出是一个可以发布的产品版本，是否可发布由产品经理来决定，也可以在发布前增加新功能。
在Sprint结束时会举行Sprint回顾会议，由研发团队向产品经理做案例演示，同时团队一起反思工作中可以改进的地方，每次的Sprint结束后都要进行这种回顾。
敏捷开发在互联网公司的落地应用
需求规划和分期；
需求评审；
需求讲解；
方案评审；
每日晨会；
性能测试；
CodeReview；
Demo；
测试阶段；
线上Bug修改流程 ；
敏捷开发之“ 理想和现实的差距 ”
结对开发：
开发人员水平太差，典型的“哟写bug呢？
”，结对开发成了开发人员直接搭配测试妹子一对一联调，
代码评审：
人和人之间的善意往往低的可怜，代码谁写的谁负责，除了问题锅是跑不了；
弹性工作：
国内加班文化不说了，符合当下国情，毕竟你的bug这么多还好意思下班？
Scrum会议：
没想到吧，人和人的沟通成本是很高很高的，还有早上的立会就安排9点，你不可以迟到；
去文档、去流程：
相对的对团队的耦合度要求更高了，人员变动频繁、团队规模较大的情况下，非常不现实，所以重要的文档如产品文档、概要设计、接口文档还是要有的，从长久来看，文档依然是提升效率的一大利器，所以敏捷落地的过程中往往会搭配文档管理工具，如confluence；
Sprint周期推进：
很多开发尤其是大型软件的开发，并不是每个Sprint都能有demo的进展，所以release总是要推迟；
用户故事：
很多需求是无法通过口头沟通建立起晚上的需求文档和需求模型；
现场客户：
如果是面向外部客户，很难让甲方全程参与开发过程；
敏捷开发：
老板尝尝以为是使用了可以降低开发时间。
当下互联网公司的敏捷开发
参考文献
软件的几种开发模式；
敏捷开发指导思想；
实施敏捷开发，看这一篇就够了；
瀑布式开发、迭代开发、敏捷开发、XP与SCRUM的区别；
敏捷开发，英文是Agile，我所理解的敏捷；
【敏捷】什么是极限编程；
极简XP极限编程图解；
[读书笔记]Scrum 总结；
图解常用的8款Scrum敏捷开发工具；
如何实现敏捷开发；
敏捷开发，在互联网公司项目中的各个环节；
你大概走了假敏捷：认真说说敏捷的实现和问题；
基于JIRA的敏捷开发管理过程；
敏捷开发培训(Agile_Development)；
SCRUM敏捷开发教程；
欢迎转载，转载请注明出处。
点击“阅读原文”，查看更多精彩！
北凉柿子的博客：http://www.beiliangshizi.com/