也谈敏捷软件开发

目录

1.敏捷简介

      1.1 敏捷宣言

      1.2 XP实践洋葱图

      1.3 SCRUM的过程图

2.实施和管理敏捷项目

      2.1 组建敏捷项目团队

      2.2 项目启动—搭建项目环境

      2.3 项目启动－准备及制订Product Backlog

      2.4 用户故事 User Story

      2.5 划分迭代和开工会议

      2.6 敏捷中的迭代实施过程

      2.7 敏捷项目中程序员的一天

      2.8 每日晨会（站立式会议）

      2.9 迭代评估和回顾会议

      2.10 测试和测试如何参与敏捷项目

3.小结

1.敏捷简介

1.1 敏捷宣言

• 个体和交互 胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档
• 客户合作 胜过 合同谈判
• 响应变化 胜过 遵循计划

1.2 XP实践洋葱图

1.3 SCRUM的过程图

2.实施和管理敏捷项目

2.1 组建敏捷项目团队

敏捷项目团队由三种角色组成
1、Product Owner—由系统分析人员担任。负责收集和描述待开发产品的信息，并转换成待开发列表。解释和描述每一项任务的要求,项目开发过程中关注每个Story是否实现，解释其要求细节。
2、开发团队成员－由来自开发、测试、资料共同组成的多功能团队，负责构建产品。
3、Scrum Master－由熟悉敏捷的成员，负责帮助和指导团队按照敏捷方式操作。

除此之外，还有一个项目经理，负责整个团队的管理。

2.2 项目启动—搭建项目环境
1、搭建持续集成环境
      敏捷项目需要维护一套唯一的持续集成环境，能够实现自动的从配置库获取代码、编译、静态检查和测试。
持续集成环境搭建，可采用IC持续集成系统，联系软件工程部进行技术支持。
持续集成至少做到每天固定执行一次，也可根据配置库代码变化触发执行。
2、搭建开发环境
      包含项目的编译等环境的配置等
3、搭建测试环境
      尤其是自动化测试的环境，能够为持续集成系统调用执行

2.3 项目启动－准备及制订Product Backlog

• Product Owner分析待开发需求任务列表，形成产品Product Backlog，并按照商业价值排序。
• Product Backlog是产品唯一的待开发任务列表（如示例），是对开发任务的初步简要描述，并附带工作量的初步估计。Backlog既可以包含新增需求、功能，也可以包含待解决的问题等（有点类似传统的AR列表）
• Product Backlog随项目进行，根据外部环境的变化，可能会不断调整，但是已经在迭代内实施的任务项将不受影响。
• Product Backlog通常使用User Story形式分析描述。

2.4 用户故事 User Story

• User Story- User Story是站在外部的用户角度来描述系统所具有的功能/特性，并且此功能/特性能为客户感知。
• User和Story的识别：
  用户Users-使用到待开发系统的任何角色（包含人、也包含其他软件或程序），一般可以采用头脑风暴形式识别所有的Users.
• Story识别及描述：
  As a <Role>,I want <function>,so that<reason>
  做为一个<XXX角色>,我希望<YYY功能>，以便<解决什么问题/原因>
  User Story通常是最小的用户感知粒度。
  注意：
  1、项目所有成员都可参与分析制作User Story（含开发、测试人员,资料人员也从使用资料的对象分析，形成资料User Story)，这时候并不需要太多的系统实现内部细节。
  2、User Story分析结果记录在《User Story模板》中，虽然敏捷可以记录在白板、卡片等形式上，但在公司内部实施的特定环境下，用文档记录还是比较好的。

2.5 划分迭代和开工会议

敏捷计划和开工会议包含：
1、Product Owner向开发团队介绍待开发任务Product Backlog,讨论各项需求任务的目标和背景，提供所有成员深入理解需求的机会。
2、开发团队集体从Product Backlog根据优先级，选择任务，初步划分迭代，设定迭代周期（迭代周期通常是固定周期，比如1-4周都是常见的迭代周期）。划分迭代时，通常从Backlog的优先级开始，结合需要的工作量进行划分。
3、完成迭代划分后，启动第一次迭代的分析工作,分解成任务，形成本迭代的Sprint Backlog. Backlog列举任务的大小不同，可能分解为一到多个任务项Task.各Task也可以用User Story形式进行描述。这时候会涉及到部分的实现细节。

2.6 敏捷中的迭代实施过程

2.7 敏捷项目中程序员的一天

2.8 每日晨会（站立式会议）

• 15分钟的站立式会议，通常在早上进行。
• 每个成员介绍三个事情：
  从上次会议结束后，完成了哪些工作？
  到下次会议前，将准备完成哪些工作？
  工作中还存在哪些障碍？
• Product Owner和所有项目成员必须参与会议。
• 每日晨会后，项目经理负责更新每项任务的进展情况。

2.9 迭代评估和回顾会议

• 在每次迭代结束时，进行迭代评估，团队展示他们所构造出的产品。
• 参加人员：所有项目成员，以及项目的客户。
• 不需要准备PPT胶片材料，只需要如实的展示工作进展即可。
• 同时回顾当前做得好的和不足的，以便在下一个迭代中改进。
• 通常，迭代评估紧接召开下一个迭代的计划会议。

2.10 测试和测试如何参与敏捷项目

3.小结

    本文简单介绍了敏捷开发的基本概念，详细介绍了在敏捷开发中使用的优秀实践，这些实践在实际开发中对提高开发效率保障项目质量有明显的效果。此外本人使用敏捷约2年时间，在实施敏捷的时候遇到各种各样的问题，这些困难有：项目情况特殊，客户不配合；团队技术、积极性层次差异；成员工作习惯不接受敏捷；工作压力变大，让人抵触。这些困难在各个公司相信都有或多或少出现，但敏捷其实是一种思路，并不是一种规范，不是所有的实践都用上才叫敏捷，所以可以根据公司的实际情况来制定符合公司情况的敏捷流程，最终目的还是提高工作效率，并更好的适应需求变化，提高项目质量。