敏捷开发Scrum

B站视频 敏捷开发介绍

传统瀑布流开发

• 传统的瀑布流开发通常需要很长的时间来进行规划，然后研发，产品测试，最终发布，整体流程例如Plan→Build→Test→Review→Deploy，但是整个周期非常的长，当做好某个部分的时候，产品也许就不在适合当前的市场环境。
• 且瀑布流开发是非常线性的，如果你在Plan中出现了一些问题，或者没有完全理解Plan中的某个部分，而去进行Build，那么在完成Build后，在Test中就会出错，负责Test的人会去拷问Build的人，Build的人找到问题又回去找Plan的人，然后重新进行Plan，在进行Build，在Test。甚至在Deploy中发现问题最终还要回到Plan中，然后重新整个流程。这严重影响开发的时间。

敏捷开发Scrum

• Scrum将整个开发项目分成的一个一个小的Sprint部分，每个部分都有例如以下流程：Plan→Build→Test→Review。我们最初部分是开发一个最小的可行项目，即确保项目的主要功能能够实现，然后在后面的部分里，每次都添加一些功能，直到最后出现可发布的完整的版本。敏捷开发的每个部分大概只会持续1~3周，所以相较于传统瀑布流开发，敏捷开发能减少开发周期，在不同的开发部分能及时适应市场变化，进行特殊调整。

Scrum中主要有三个重要角色

• 产品经理
  • 主要负责确定产品的特性，分析项目的需求，找出项目的亮点，
• 项目经理
  • 是整个项目的主要负责人，负责帮助团队尽可能地完成工作，组织日常会议，和保障其他工作。
• 开发成员
  • 包括但不限开发人员，测试人员以及其他帮助开发的成员，主要负责产品的研发

三种可视化文档

• Product Backlog产品需求列表
  • 产品经理从众多的用户故事中筛选出优先项，并把它们列入产品开发列表中，需求列表会随着每次的Sprint迭代和更改
  • 用户故事：是一种表达产品需求的语言格式 [作为一名___用户，我需要____功能,所以能够____]
  • 产品经理通过用户故事来了解需求的细节，为团队合理的指定任务的优先级
• Sprint Backlog代办事项
  • 最优先的用户故事将进入Sprint代办事项，剩下的继续评估优先级，交到下次的Sprint中
• Burndown Chart燃尽图
  • 用以展示整个Sprint代办列表的进度，当燃尽图曲线接近于0时，也就意味着这次Sprint即将完工

三种不同的会议

• Sprint计划会议
  • 是所有成员都要进行的会议，用于讨论用户故事并估算任务量
• Daily Scrum每日例会
  • 整个团队简述工作进度，并且讨论是否有任务需要搁置或是加派人手
• Sprint Review 回顾会议
  • 当每个Sprint接近尾声时，我们要进行回顾会议，这是整个研发团队会向产品经理演示开发好的功能，然后整个团队讨论是否需要改进的地方

敏捷开发的大致流程

• 产品经理把那些需要上线的产品特性做成产品需求列表。然后由产品经理选出最优项，准备交给整个团队讨论。
• 召开Sprint规划会议，所有成员讨论用户故事优先项，并且决定下次Sprint要研发的需求项
• 根据Sprint规划会议指定Sprint待办事项，会议结束后，所有成员都要对每个用户故事有深刻的理解
• 研发团队要在1~3周的时间内开发完成Sprint中的需求，在Sprint期间，每日例会用来交流他们做完了什么，正在做什么，以及遇到的问题
• 在Sprint结束时会举行Sprint回顾会议，由研发团队会向产品经理演示开发好的功能，然后整个团队讨论是否需要改进的地方

敏捷开发的评论

• 敏捷开发的轻松、高效是建立在优秀的技术实践、正确的敏捷价值观、团队成员非常熟悉项目的基础上才能实现，实际上许多人经常遇到做一半发现需求的部分场景遗漏，代码质量差，实现方式不合理，加上工作量以“人/天”为单位，当天认领的任务又必须当天做完，“敏捷开发”只剩下无休止地加班和几个会议。
• 有明确的规划和目标 把功能定下来不停敏捷迭代没问题 但是有些敏捷就是需求不清楚 也不知道干啥 但每周必须实现东西 美其名曰先做出来看看。
• 敏捷要有与之相配的人，从项目经理 产品经理 开发 测试甚至运维都要是有能力匹配的，有任何一个角色无问题，其他人要么干等加班 要么身兼多职的leader力挽狂澜，否则还不如规规矩矩瀑布式算了。
• 当你一直跟着一个不专业的人的时候，时间久了，你就会不专业

敏捷开发的软件

pingcode