敏捷开发相关

敏捷开发

什么是敏捷开发

• 敏捷开发是一种以人为核心、迭代、循序渐进的开发方式，它并不是一门技术，而是一种开发方式。它会指导我们用规定的环节去一步一步完成项目的开发。
• 特点： 积极响应客户需求，快速高质量的持续交付软件。

相比于传统的开发模式，敏捷开发的效率更快，开发成本更低（由于迭代反馈的不断进行，避免了大量的返工），能够快速抢占市场，缩短快发周期

1.敏捷宣言

• 个体和互动 高于 流程和工具；
• 工作的软件 高于 详细的文档；
• 客户合作 高于 合同谈判； 相比于只有客户表明需求，双方共同做出需求更合理
• 响应变化 高于 遵循计划； 计划赶不上变化，及时对计划之外的事情做出响应

2.敏捷开发的12条原则

1. 我们最重要的目标，是通过不断的及早交付有价值的软件使客户满意
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌握变化
3. 经常的交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外
5. 激发个体斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好和效率最高的方式是面对面交谈
7. 可工作的软件是进度的首要标准
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续
9. 坚持不懈地追求技术卓越和良好的设计，敏捷能力由此增强
10. 以简洁为本，它是激励减少不必要工作量的艺术
11. 最好的架构、需求和设计出自组织团队
12. 团队定期地反思如何能够提高绩效，并以此调整自身的举止表现

敏捷开发中的角色

• Product Owner——产品负责人
  产品经理确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，是维护产品需求清单的人。

  1. 确定产品的功能，必须证明要做的功能是合理的，是值得尝试的；
  2. 决定发布的日期和发布的内容；
  3. 每个迭代中，根据需要调整功能和优先级（每个迭代开始前调整）
  4. 接受或者拒绝开发团队的工作成果；
  5. 参与迭代计划会议，demoday（评审会）和回顾会

• Scrum Mster——团队负责人
  敏捷教练是团队的导师和组织者，及时为团队成员提供帮助。促使团队按照迭代的方式运行，屏蔽外界对开发团队的干扰，为迭代过程负责的人，是公约的执行者。

  1. 保证团队资源合理运用；
  2. 保证各个角色及职责良好的协作；
  3. 解决团队开发中的障碍；
  4. 作为团队和团队外部的接口，协调解决沟通中的问题；
  5. 保证开发过程按计划进行，组织迭代计划会议，每日站立会议，评审会和回顾会；

• Scrum Team ——开发团队（包括设计师、开发人员、测试人员等）
  开发主要负责在迭代中的研发工作，每个成员可能负责不同的技术方面，但要求每个成员必须要有很强的自我管理能力以及表发能力，即使主动做好代码编辑前的需求确认，编写中的协作，进度把控，编写后的测试等工作，确保开发的结果和需求是一致的。

  1. 参与任务分解，确保自己理解的需求是明确无误的，是清晰且可执行的；
  2. 做好项目的进度控制，风险控制；
  3. 确认自己写出来的代码是可以维护的；
  4. 配合QA（测试）人员进行测试；
  5. 需求交付给开发后，那么就应该主动为这件事负责；

  质量保证人员，将迭代的目标烂熟于心，将质量控制贯彻开发全过程。

  1. 意识需要从发现BUG换变为预防Bug出现，尽早给出质量反馈，做到风险前移；
  2. QA人员从迭代计划会就要参与进来，注重质量，达到零缺陷的软件开发过程；
  3. QA人员需要站在客户的角度去思考，辅助开发人员完成设计和软件的实现，并对软件的整体进行掌握，及时提出架构上的问题；
  4. 测试用例，Bug优先级判断；
  5. QA人员还需要对客户反馈的信息进行统计，以便团队更好的改进问题。此外也需要于开发人员紧密合作，双方形成互补，避免敏捷测试对软件开发无用以及测试不完整的问题出现。

敏捷开发中四个会议

一、迭代计划会（计划评审会）

• 约2—4小时；
• 产品/用户需求（User Story）
• 本轮迭代的需求
  • 任务分解
  • 任务分配及估算
  • 测试方案
  • 获得共识的“完成”标准

二、每日站立会

• 约15分钟
• 当天的工作内容，遇到的那些问题
• 第二天要做什么，需要什么帮助
• 结果：最新的工作进度图

三、评审会

• 约1-2小时
• 测试质量报告
• 演示demo（团队中的任何一个人均可以演示）
• PO进行评审（意见及建议）
• 结果：对当前迭代的结果和整个产品的开发状态达成共识

四、回顾会

• 约1-2小时；
• 总结本轮迭代成功经验和所遇到的障碍并找出改进方法；
• 团队中每个成员需回答：
  • 我们的成功经验是什么？
  • 有什么地方可以改进？
  • 哪些方面需要在下个迭代中改进？
• 结果：会议纪要含相关改进及负责人名单

结合看板使用敏捷

PO关注的看板

• 用户故事地图
  • 拆分用户故事
• 产品Backlog
  • 把拆分的用户故事分类
• Sprint看板
  • 把要迭代的故事放入看板讲解

用户故事地图

• 用户故事：作为一个<角色>，我想要<活动>，以便于<商业价值>
• 地图：寻找路径=>了解全貌