敏捷过程（小规模团队敏捷开发）
记录一些优秀的敏捷开发案例或经验：
敏捷开发：项目管理的一些思考
w_fsovereign：三个月（敏捷）项目收获
RobinsonZhang：敏捷开发入门
一、敏捷过程
敏捷开发是一种以人为核心，以迭代方式循序渐进开发的方法，其软件开发的过程称为“敏捷过程”。
在这一过程中，软件项目的构建被切分成多个子项目，各个子项目的成功都经过测试，具备集成和可运行的特征。
在2001年年初，一些业界专家成立了敏捷联盟，起草了敏捷软件开发宣言。该宣言针对一些企业的现状，提出了让软件开发团队具有快速工作、快速应变能力的若干价值观和原则，其中包括4个简单的价值观以及敏捷开发方法应遵循的12条原则。
1.1 敏捷开发的价值观
- 个人和交互胜过过程和工具。
- 可以运行的软件胜过面面俱到的文档。
- 客户合作胜过合同谈判。
- 响应变化胜过遵循计划。
1.2 敏捷开发应遵循的12条原则
- 通过尽早的、不断地提交有价值的软件来使客户满意。
- 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
- 以从几个星期到几个月为周期，尽快、不断地提交可运行的软件。
- 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
- 以积极向上的员工为中心，建立项目组，给他们提供所需的环境和支持，并对他们的工作予以充分的信任。
- 在团队内部，最有效、效率最高的传递信息的方法，就是面对面的交流。
- 测量项目进展的首要依据是可运行软件。
- 敏捷过程提倡可持续的开发，责任人、开发者和用户应该为能够保持一个长期的、恒定的开发速度而努力。
- 时刻关注技术上的精益求精和好的设计，以增强敏捷能力。
- 简单是最根本的。
- 最好的构架、需求和设计出于自组织的团队。
- 每隔一定时间，团队要反省如何才能更有效地工作，然后相应地调整自己的行为。
敏捷组织提出的敏捷开发模型的整体框架主要有三个：
Scrum、XP（eXtreme Programming）、OpenUP 这3个敏捷实践。
二、敏捷开发的原则
- 凝聚人的力量，紧密协（合）作。包括业务负责人、开发团队、客户、管理者之间的关系，所有这些关系在以前都是造成项目危机的原因之一，那么，在敏捷时代，我们需要这些角色 紧密合作，最大限度的发挥各个角色的力量.
- 聚焦客户价值，消除浪费（如何聚焦用户价值，即频繁的交付用户可工作的软件，快速收到用户反馈）
2.1 敏捷团队运作机制
- 一个团队有自己的代办事项，对代办事项进行拆小。
- 按客户价值进行优先级排序，产品经理负责价值排序。
- 小而稳定，跨职能团队。
- 多个团队松耦合（依赖性比较低），对齐迭代时间和战略目标。
2.2 关键的团队角色
- 产品负责人
- Scrum主管（流程主管）
- 开发团队
2.3 产品负责人（Product Owner）
- 负责管理产品backlog（代办事项）的唯一负责人
- 代表客户/项目如责任人
- 定义产品的所有特性
- 负责产品的投入产出
- 负责最大化产品和开发团队工作的价值
2.4 Scrum Master（流程主管）
- 起到教练的职责，领导团队完成Scrum的实践以及体现其价值。
- 排除团队遇到的困难，使得团队紧密合作，使得团队个人具有多方面职能的工作能力。
- 确保团队能胜任其工作，并保持高效的生产率。
- 保护团队不受到外来无端影响
2.5 关键的团队活动
- 每日例会：每日5分钟左右的一个简单例会，尽可能多的开发人员参与进来对紧要问题的讨论。
- 评审会：需要在迭代周期的最后一天召开，1个小时左右就可以了，需要客户出席，如果客户不能出席，则需要产品经理出席
- 迭代回顾会：迭代回顾会是在每个迭代结束时进行，总结工作中的经验和教训，时间维持在30-60分钟内，整个团队都需要参加（Scrum Master、Product Owner、开发团队以及客户）。迭代回顾会包括两部分，第一部分是定量分析，第二部分是定性分析。其中定量分析又包含团队是否完成了迭代目标，收集并评审迭代度量指标（包括速率、迭代燃尽图、迭代计划故事和实际完成故事、计划发布日期与实际发布日期、客户满意度、团队满意度、生产环境Bug数、生产Bug解决时间、用户故事等）。定性分析包含哪些工作良好（应该继续保持），哪些做的不好（应该停止）？哪些可以改进（团队选出１－２条在下一个迭代实现）？
敏捷开发
作者：木可大大
三、敏捷团队的五个约定
3.1 约定1. 业务分析师们，我们其实是同一个角色的两种面孔，请叫上我们参加客户需求会议
我们的团队需要让客户频繁的得到可用的软件，客户的不断反馈会给软件的未来做出最正确的方向指引。
如果我们交付的软件有很多质量的问题，存在大量的缺陷，客户会被这些缺陷的奇怪行为干扰，没有办法把注意力放在软件本身的价值是否符合他们的真正需求上，
不能给出最有价值的反馈。所以，我们只有频繁的做测试，在每次交付之前都把质量问题找出来告诉我们的团队，问题才能及时的得到改正。而我坚信“prevention is better than
cure”（预防胜于治疗），我会要把工作的重点放在预防缺陷上，这样可以节省Dev们很多修复缺陷的时间与精力。为了达到这个目的，我需要跟你一起参加客户需求会议，尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候，我也基本完成了测试用例的准备。
我们可以赶在开发人员们写代码之前就告诉他们我要测什么，让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况，减少缺陷的发生。这是我测试的一项重要任务。
如果你们在大部分需求都整理好了再交给我们，我会浪费掉等待的时间。更重要的是，开发好的软件里面已经有很多本来可以不存在的缺陷在里面了，开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。
所以，请让我尽早了解需求，请不要让我到项目后期才能开始测试。
3.2 约定5. 测试人员们，那些敏捷实践对于我们也是有用的。
如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们，design for testability（提高你们设计的可测性）。
如果你发现业务分析师写的需求无法验证，定义的客户行为不够具体，一个用户故事中包含太多了功能点，等等，那么也请大声地告诉他，INVEST（独立，可协商，价值，可估算，短小，可测）。
也请你们多跟开发人员结对写自动化测试，既可以帮助你们学习怎样更好的编写自动化测试，也能帮助开发人员们结对更多的了解用户行为。
四、敏捷开发的前置条件
4.1 比较固定的流程，文档，需求
- 需求是控制稳定性的根本，对于需求一定是整体可控的，并且是可以由迭代内进行调整的，而不是定死的
- 流程是指什么时间什么人该做什么事是高效的，明确的
- 文档是指每个流程阶段具有可交付或者可查阅参考文档，不是口头或者个人评定。
4.2 可灵活调整，允许试错
- 检查
检查是指在每天的站会中检查每个人的工作状态，是否能完成自己的任务，存在什么问题，完成效果如何。另外就是保证整体在每天的进度，是否有有整体效果，如果没有完成今天的整体效果，需要检查是否符合整体迭代。
- 调整
调整是指检查发现迭代的进度或者外界环境发生变化时，及时调整当前迭代的开发任务，保证迭代最终产物的准确及时性变动。当然，这种变动是不允许太多的，一般情况下在需求没有做详细分析时，不接受；在当前有风险的情况下，撤销某些需求；其他情况不做描述。
- 试错
正是由于检查以及调整的策略，保证了迭代的灵活性，我们可以在敏捷团队中尝试一些较革新、新的功能点或者技术点，如果实验成功则可以对外拓展；如果不行，可以快速切换方案。
4.3 问题场景&&错误认识
- 一个团队闭关开发一个项目就是敏捷
正确理解：敏捷不等于闭关，只是可能坐一起效率更高，其倡导的是何时都可以发生沟通，并准备一白板可以随时讨论方案；敏捷团队质量以及效率高于一般团队；敏捷团队开发的是以迭代为单位，不是项目；
- 有了任务细分，开发白板，站会就是敏捷
正确理解：任务细分、白板、站会都是其形式，关键还是其将迭代的内容进行细化，可执行化，用高频的沟通反馈提高开发、沟通、理解的效率。
- 敏捷团队没有特殊前置条件
正确理解：前面有讲到敏捷对团队，需求，文档，流程，调整等都有比较完整的规定。
- 敏捷团队做的事情没有差别性
正确理解：敏捷完成的任务具有明细化，分阶段性，可调整性。所以在开发相关任务时，也具有类似的特点。
- 敏捷团队会完整完美的交付产物
正确理解：敏捷在迭代结束只交付该阶段的可交付产物，很可能不完整不完美，对于可交付也有不同的理解。