敏捷方法Scrum那些事儿

本文中的主要内容是摘抄自网上,出处来源于各处,所以也不知道怎么标记了……

开头的几张图是我阅读《硝烟中的Scrum和XP》的时候做的阅读笔记,放在一起,加深一些印象。

读书笔记

读书笔记一共分为这么几个模块:

  1. 产品Backlog
  2. Sprint计划会议
  3. 如何编写Sprint Backlog
  4. 站立会
  5. Sprint回顾会议
  6. 关于测试

对应的大纲梳理如图:

Scrum中的产物

Product Backlog——Backlog 待开发项,积压的任务
产品 Backlog 包括了所有需要交付的内容,其内容根据业务需求的价值顺序排列,每个 Backlog 的优先级是可以调整的,需求是可以增减的,因此产品 Backlog 将根据不断增长来持续驱动维护。

Sprint Backlog——Sprint 本意为“冲刺”,指迭代周期,长度通常是一至六周
在 Sprint 开始前,定义本次 Sprint 要讨论的“Sprint Backlog”,从中产生本次 Sprint 要完成的 “已定 Product Backlog”。
已定 Product Backlog是 Sprint 计划会议的产物,它定义了团队所接受的工作量,在整个 Sprint 过程中它最好要保持不变。

User Story、Task——用户故事、任务
用 User Story 来描述 Sprint Backlog 里的项目,User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大,可能会导致对它的开发横跨几个 Sprint,此时就应该将这个 User Story 分解。为了能够及时,高效地完成每个Story,Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时,保证在1个工作日内完成,如果 Task 的时间超过了8个小时,就说明Task的划分有问题,需要特别注意。既然拆分成了任务,就要确保拆的够细,以便于燃尽图的维护。

每日立会(Daily Standup Meeting)

会议目的
团队在会议中作计划,协调其每日活动,还可以报告和讨论遇到的障碍。
任务板能够帮助团队聚焦于每日活动之上,要在这个时候更新任务板和燃尽图。

会议输出
团队彼此明确知道各自的工作,最新的工作进度图。
得到最新的“障碍 Backlog”
得到最新的“Sprint Backlog”

会议过程
团队聚在故事板旁边,可以围成环形。
从左边第一个开始,向团队伙伴说明他到现在完成的工作。
然后该成员将任务板上的任务放到正确的列中。
如果可以的话,该成员可以选取新的任务,交将其放入“进行中工作”列。
如果该成员遇到问题或障碍,就要将其报告给 Scrum Master。
每个团队成员重复步骤2到步骤5。

每个人三个问题:
上次会议时的任务哪些已经完成?把任务从“正在处理”状态转为“已完成”状态。——昨天完成了什么?

下次会议之前,你计划完成什么任务?如果任务状态为“待处理”,转为“正在处理”状态。如果任务不在 Sprint
Backlog 上,则添加这个任务。如果任务不能在一天成,把这任务细分成多个任务。如果任务可以在一天内完成,把任务状态设为“正在处理”。如果任务状态已经是“正在 处理”,询问是否存在阻碍任务完成得问题。——今天计划做什么?

有什么问题阻碍了你的开发?如果有阻碍你的开发进度的问题,把该障碍加入到障碍 Backlog中。——昨天遇到了什么问题?

注意事项
不要迟到
不要超出限制时间
不要讨论技术问题
不要转变会议话题
不要在没有准备的情况下参加
如果不能出席会议,需要通知团队,并找一名代表参加。

Sprint计划会议(Planning Meeting)

会议目的
该会议要详细理解最终用户到底要什么,产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束,团队将会决定他们能够交付哪些东西,并且评估出对应的工作时间和故事点大小。

产品负责人在会前准备:条目化的需求(用户故事),优先级排序,最近1~2个迭代最希望看到的功能。会前准备至关重要,可帮助产品负责人理清头绪,不至于在迭代期内频繁提出变更、增加或删除故事。

基本要求
迭代计划会在每个迭代第一天召开,目的是选择和估算本次迭代的工作项。
只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。

会议输出
确认放入Sprint的 Product Backlog 条目。
各个 Backlog 条目的详细需求文档或者解决方案等。
各个 Backlog 条目的验收测试用例。

会议过程
从第一个 Product Backlog 条目(故事)开始。
讨论该 Product Backlog 条目,以深入理解。
分析、明确用户验收测试。
找到非功能性需求(性能、稳定性…)
找到验收条件。
弄清楚需要“完成”到何种水平。
获得 Backlog 条目各个方面的清晰了解。
绘制出所需交付物的相关图表,包括流程图、UML图、手绘草图、屏幕 UI 设计等。
回到步骤1,选取下一个 Backlog 条目。

流程检查:询问团队能否快速回答下列问题,只需要简要回答即可:“我们能在这个 Sprint 中完成第一个 Backlog 条目吗?”如果能得到肯定的回答,那么继续询问下一个 Backlog 条目,一直到已经分析完的最后一个 Backlog 条目。接下来,休息一下。在休息后,对下一个 Backlog 条目展开上述流程。

补充

需要尽可能的让团队估算出对应的用户故事的故事点,如果当场不能完成,可以用下一个会议进行;

需要确认最终用户故事的完结的状态是开发完还是测试完,还是其他;

需要将故事拆分成任务,确保估算时间的准确,同时也方便更新燃尽图;

估算会议

会议目的
要做好战略规划,你需要知道 Backlog 中各项的大小,这是版本规划的必要输入;如果想知道团队在一个 Sprint 中能够完成多少工作,这个数据也是必须的。
团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。
只有团队才能作估算,Product Owner(产品负责人)需要在场,以帮助判定某些用户故事能否拆分为更小的故事。

会议过程
Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。
团队使用规划扑克来估算 Backlog 条目。
如果某个 Backlog 条目过大,需要放到下一个或是后续的 Sprint 中,团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目,并对新的 Backlog 条目使用规划扑克进行估算。
重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。

会议输出
经过估算的 Product Backlog。
更小的 Backlog 条目。

Sprint评审会议(Review Meeting)

会议目的
Scrum 团队在会议中向最终用户或者需求方展示工作成果,团队成员希望得到反馈,并以之创建或变更 Backlog 条目。

Sprint评审会议也是审查演示会议,通过完成的Demo进行演示,从实际运行的过程中去检查是否遗漏,是否满足用户的需求,是否可以通过验收。

会议过程
Product Owner 欢迎大家来参加 Sprint 复审会议。
Product Owner 提醒大家关于本次 Sprint 的目的:Sprint 目标、Scrum 团队在本次 Sprint 中选定要开发的故事。
产品开发团队展示新功能,并让最终用户尝试新功能。
Scrum Master 推进会议进程。
最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。

注意事项
不要展示不可能发布的产品增量。
Scrum Master 不要负责展示结果。
团队不要针对 Product Owner 展示。

Sprint反思会议(Retrospective Meeting)

会议目的
该会议的对应隐喻:医疗诊断!其目的不是为了找到治愈方案,而是要发现哪些方面需要改进。

基本要求
从过去中学习,指导将来。
改进团队的生产力。

会议内容
准备一个写着“过去哪些做的不错?”的挂图。
准备一个写着“哪些应该改进?”的挂图。
绘制一条带有开始和结束日期的时间线。
给每个团队成员发放一叠即时贴。
开始回顾。

注意事项

发现问题比解决问题更重要,需要鼓励大家提出已发现的问题;

改进当前迭代的一些模式,找到让大家都舒服且满意的合作方式;

不针对人进行批判和指责,而是针对发生的事情来做对应的问题发掘;

总结

Scrum的知识其实不算多,网上一找会有一大把的资料和相关的案例等,但是真正实施起来却没有那么简单,因为我比较认同一个观点:敏捷的核心点是人与变化

任何团队,任何方法论的落地最后都会落在人身上,而敏捷更加强调的就是人的沟通和协作,以一种高效的,有节奏的合作方式来应对变化,尤其是软件开发网页,需求瞬息万变,技术方案也千奇百怪。所以对于Scrum来说,仅仅了解它的一些表层知识是不够的,更关键的应该是怎么 以一种方法论作为指导,然后灵活地、科学地、高效地去调度团队进行相关的工作。

当前我对Scrum的理解和认识可能只是一个浅层次的方法论,但是我相信只需要慢慢地落地并实践它,在实践的同时去调整和优化,时间长了,肯定会有不同阶段的感悟和成长,而敏捷不正是鼓励拥抱变化么!

--本文到此结束感谢您的阅读--
随缘打赏,佛系产品
0%