敏捷开发

敏捷开发相关的理论知识--Scrum，我们的最高目标是通过尽早和持续第交付有价值的软件来满足客户；欢迎对需求提出变更 - 即使在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势；

Scrum

• 12原则
  • 1. 我们的最高目标是通过尽早和持续第交付有价值的软件来满足客户；
  • 2. 欢迎对需求提出变更 - 即使在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势；
  • 3. 要不断交付可用的软件，周期从几周到几个月不等，越短越好
  • 4. 项目过程中，业务人员与开发人员必须在一起
  • 5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务
  • 6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈
  • 7. 可用的软件是衡量进度的主要指标
  • 8. 敏捷过程提倡可持续的开发，项目方，开发人员和用户应该能够保持恒久稳定的进展速度
  • 9. 对技术的精益求精以及对设计的不断完善将提升敏捷性
  • 10. 要做到简洁，尽可能减少不必要的工作，这是一门艺术
  • 11. 最佳的架构，需求和设计出自于自组织的团队
  • 12. 团队要定期反省如何能够做到更有效，并相应调整团队的行为。
• 四大价值观（宣言）
  • 个体和互动 高于 流程和工具
  • 工作的软件 高于 详尽的文档
  • 客户合作 高于 合同谈判
  • 响应变化 高于 遵循计划
  • 总结
    • 敏捷开发（scrum）适用于竞争激烈，快速变化的市场
    • 传统开发模式以文档为驱动，而敏捷开发提倡少写文档
    • 敏捷模式采取迭代式开发，传统模式采用瀑布式开发
    • 敏捷开发更适应变化
• 角色
  • 产品负责人（Product Owner）
    • 主要负责和客户沟通确定产品的功能和达到要求的标准，并指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果，一般是由产品经理担任
  • 流程管理员（Scrum Master）
    • 问题清道夫！主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发
    • 职责
      • 管理Scrum流程
      • 向PO获取合理的工作量
      • 把关质量
      • 跟踪进度
  • 开发团队（Scrum Team）
    • 主要负责软件产品在Scrum规定流程下进行开发工作
• 组成
  • Sprint（迭代）
    • 指的是一次迭代，而一次迭代的周期最好是1-4个星期，也就是我们要把产品需求分布到各个周期完成
  • Story（故事）
    • 用户故事，也可以看做是用户需求点
    • 三要素
      • 角色
        • 谁使用这个功能
      • 活动
        • 需要完成什么样的功能
      • 商业价值
        • 功能能够带来什么价值
      • 作为一个<角色>, 我想要<活动>, 以便于<商业价值>
  • Task（任务）
    • story的进一步细分。为了能够及时，高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task
    • 每个Task 的时间最好不要超过8小时，保证在1个工作日内完成
  • Backlog(列表)
    • 待办工作事项的集合。在开发中需要明确2个Backlog
    • Product Backlog
      • 产品待办事项列表，产品负责人量化用户需求，逐条列出实际需要开发的需求（Story）
    • Sprint Backlog
      • 任务列表，是一次迭代中需要完成的任务，主要是开发团队细化工作的列表
  • 燃尽图（Burn Down Chart）
    • 燃尽图是用来跟踪sprint中未完成工作的情况。每做完一个sprint的用户故事就烧掉，最后烧完sprint也就完成了。用蓝色线表示计划走向，红色线则是实际走向，两条线共同组成了燃尽图。如下图，每一个点代表一个用户故事，或者故事点，或者可度量的工作量。所有点组成sprint
• 4个会议
  • Sprint(迭代)计划会
    • PO 向大家介绍排好序的产品待办事项（Product Backlog），然后大家共同思考决定如何推进计划，梳理出 Sprint Backlog 来完成后续的工作
  • 每日站会
    • 昨天完成了什么
    • 今天计划完成什么
    • 是否有困难需要帮助
  • Sprint 评审会
    • Sprint完成，产品负责人和客户都要参加，每一个开发团队的成员都要演示自己完成的软件产品，然后被判定产品合格、成功、需要修改还是重新做
  • Sprint 总结会
    • 总结会议以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中
• 四大支柱
  • 迭代开发
    • 在Scrum的开发模式下，我们将开发周期分成多个1-4周的迭代，每个迭代都交付一些增量的可工作的功能。迭代的长度是固定的，如果我们选择了1周的迭代，那么保持它的长度不要发生变化，在整个产品开发周期内每个迭代都是1周的长度。这里需要强调的是在每个迭代必须产出可工作的增量功能，而不是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码
  • 增量交付
    • 增量是一个 Sprint 及以前所有 Sprint 中完成的所有产品代办事项列表条目的总和。 在 Sprint 的结尾,新的增量必须“完成”,这意味着它必须可用并且达到了 Scrum 团队 “完成”的定义的标准。无论产品负责人是否决定真正发布它,增量必须可用。增量是从用户的角度来描述的，它意味着从用户的角度可工作
  • 自组织团队
    • Scrum团队是一个自组织的团队，传统的命令与控制式的团队只有执行任务的权利，而自组织团队有权进行设计、计划和执行任务，自组织团队还需要自己监督和管理他们的工程过程和进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作的方式
  • 高优先级的需求驱动
    • 在Scrum中，我们使用Product Backlog来管理需求，Product Backlog是一个需求的清单，Product Backlog中的需求是渐进明细的，Backlog当中的条目必须按照商业价值的高低排序。Scrum团队在开发需求的时候，从Backlog最上层的高优先级的需求开始开发。在Scrum中，只要有足够1-2个Sprint开发的细化了的高优先级的需求，我们就可以启动Sprint了，而不必等到所有的需求都细化之后。我们可以在开发期间通过Backlog的梳理来逐步的细化需求
• 开发步骤
  • 产品负责人使用产品Tab收集产品需求（story）
  • 开发团队根据Product Backlog列表，在Sprint计划会议中做工作量的预估和安排，确定需求提交研发，进入Story看板
  • 确定Sprint周期（1-4周）和本次开发迭代冲刺的开发需求（Stories）。进入Sprint的story出现在Task看板。 在Task看板，研发团队可以拆分Story到任务进行协作
  • 每日立会，团队更新Task看板，和Story看板，保持信息的同步

敏捷开发

• 说明
  • 一种软件开发的流程，强调快速反应、快速迭代、价值驱动
• 特点
  • 大幅提高了开发团队的工作效率，让版本的更新速度变得更快
  • 小步快跑的形式带来的版本变化是比较小的，风险会更小
    • 出现问题可以快速回滚，修复
  • 传统开发模式以文档为驱动，而敏捷开发提倡少写文档
    • 传统开发模式下开发人员按照产品文档进行研发，过程中客户不参与到产品的验收和体验中，这样就会导致最后开发出来的成品并不是客户想要的。 而敏捷开发模式从开始就强调客户协作，分步提供产品模块客户体验
  • 敏捷模式采取迭代式开发，传统模式采用瀑布式开发
    • 敏捷开发采取迭代式开发的形式，即每个阶段有每个阶段需要完成、并且能使用的产品，这一阶段只要开发某几个功能，且这些功能的产品必须是可以使用的，这一阶段产品完成之后与客户进行对接交付，再进行下一阶段的开发
  • 敏捷开发更适应变化
    • 传统开发模式下软件开发过程是执行研发计划，而实际工作中，需求往往在开发过程中会产生巨大变化。敏捷开发更能适应不确定性强的产品和市场
• 实现方式
  • Scrum
  • 极限编程（ExtremeProgramming，简称XP）
  • 水晶方法
  • 动态系统开发方法
  • 精益开发

落地

• 产品
• UI+开发
• 测试+开发