【SCRUM】总结整理

敏捷宣言

我们一直在实践中探寻更换的软件开发方法,身体力行的同时也在帮助他人,由此我们得出了一下价值观:

        个体的互动          重于       流程与工具

        可工作的软件       重于       详尽的文档

        客户合作              重于       合同谈判

        相应变化              重于        遵循计划

敏捷12原则:

1、我们最重要的目标,是通过及早和持续不断地交付有价值的软件使客户满意。        –客户满意 

2、欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。              –掌控变化

3、经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。    –短周期

4、业务人员和开发人员必须相互合作,项目中的每一天都不例外。                          –相互合作

5、激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。                                                                  –激发斗志,辅以信任

6、不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。     –面对面的交谈

7、可工作的软件是进度的首要度量标准。                                                        –可工作的软件

8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。                                                                                            –可持续开发

9、坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。                     –卓越技术和良好设计

10、以简洁为本,它是极力减少不必要工作量的艺术。                                  –简洁为本

11、最好的架构、需求和设计出自自组织团队。                                             –自组织团队

12、团队定期地反思如何能提高成效,并依此调整自身的行为表现                 –定期地反思

1、Scrum概述
Scrum 是用于管理产品开发的单个团队过程框架。该框架包含 Scrum 角色、事件、工件和规则,采用迭代方法来交付工作产品。

2、Scrum色
Scrum团队由5到9个(7±2)团队成员组成。

有三种类型角色:
产品负责人(PO):产品负责人定义项目愿景、需求和优先级,对产品成功负责。
Scrum Master:负责团队,并移除障碍,帮助他们实现产品负责人所设定的目标。
开发团队:自组织、跨职能。他们协同工作,以确定如何最好地满足产品负责人的目标。

团队中有“鸡”和“猪”的角色,“猪”的角色包括scrum master、PO、team;“鸡”的角色是指团队成员以外的管理角色

Scrum角色的关键点

1)产品负责人:
·清晰地表达产品待办列表项

对产品待办列表项进行排序,最好地实现目标和使命·

优化开发团队所执行工作的价值

确保产品待办列表对所有人可见,透明,清晰,并且显示Scrum团队的下一步工作

确保开发团队对产品待办列表项有足够的理解

2)ScrumMaster

       Scrum Master 负责确保所有人都能正确地理解并实施Scrum。因此 Scrum Master要确保Scrum团队遵循Scrum的理论、实践和规则。

       ScrumMaster是Scrum团队中的服务型领导。ScrumMaster帮助 Scrum团队外的人员了解他们如何与Scrum团队交互是有益的,通过改变他们与Scrum 团队的互动方式来最大化Scrum团队所创造的价值。ScrumMaster在期望设定和管理中扮演重要角色,以此去创建高绩效团队。

A)Scrum Master的职责是:

在项目生命周期早期定义基本规则;

确保团队理解干系人期望;

以连贯的单元模式工作;

对愿景给予承诺

扩充:

。起到教练的职责
。领导团队完成Scrum的实践以及体现其价值
。排除团队遇到的困难
。 确保团队的人胜任其工作,并保持高效的生产率
。使得团队紧密合作,使得团队个人具有多方面职能的工作能力
。保护团队不受外来无端影响
。鼓励言论自由
。保证仪式(保证仪式的完整性
。团队有问题,优先内部讨论解决

同团队沟通项目愿景,有利于确保团队认识到他们的目标同项目总目标紧密一致

B)ScrumMaster制定的基本规则包括 
 设定Scrum仪式的开始-结束时间; 
 保持对主题的专注减少分散; 
会议期间杜绝中断; 
允许团队成员特别是初级成员言论自由; 
在制定决策前应广泛搜集所有成员意见。 

3)团队:
有自主权选择如何最好地满足目标,并且为之负责。

>>>>Scrum 三个工件

        Scrum的工件以不同的方式表现工作任务和价值,可以用来提供透明性以及检视和调整的机会。Scrum中的工件就是为了最大化关键信息的透明性,因此每个人都需要有相同的理解。

①产品待办列表(ProductBacklog)

口产品需求列表;

口产品负责人对该列表进行优先级排序;

口待办事项列表中的条目以用户故事的形式呈现:

②Sprint待办列表(SprintBacklog)(迭代代办列表)

口是产品待办列表的子表只记录当前迭代的工作;

口将用户故事拆分成任务,团队成员主动领取任务;

团队成员可以添加删减或者更改迭代中的任务

③产品增量(PSPI:Potentially Shippable Product Increment)????

口团队在迭代内完成交付成果,集成到以往的迭代成果中,形成增量式的交付。

口每次交付的用户故事必须符合验收条件。

>>>>Scrum 会议(5 个仪式)

冲刺计划会、每日站会、冲刺评审会、冲刺回顾会、冲刺

1冲刺计划会议(规划会议): 选故事、领任务、拆任务
Scrum团队的所有成员出席,在此次会议中开发团队识别当前冲刺开发交付的产品待办事项中的故事
这个会议时间箱为:一个月的冲刺,会议时间8小时,4个小时用于选择故事和4个小时估算分配。

②每日站立会议:  15分钟   轮流开   不解决问题
由ScrumMaster和开发团队参加产品负责人可以自行选择是否参加。每日站立会议是快速专注的会议,用来分享迭代或迭代进展
每个团队成员就他们将要完成的任务对其他人做口头承诺。每个团队成员回答以下问题:

“昨天做什么

“今天将做什么

“遇到了什么问题
每日立会只有猪的角色可以发言,鸡的角色不可以发言这次会议时间箱15分钟每天发生在同一时间和地点。

③冲刺评审会议:(review)     演示   评审   反馈
这次会议是由Scrum团队的所有成员参加
开发团队将可能移交的可交付物开发特性演示给干系人和项目发起人
Sprint评审会议的结果是一份修订的产品待办列表,确定很可能进入下个Sprint的产品待办列表项。
这个会议时间箱为一个月的迭代,4个小时,比冲刺计划会议的持续时间更短

1、冲刺评审是在迭代末期进行的时间盒(有指定时间限制)会议,此时不断变化的解决方案展示给利益相关者,他们的反馈得到收集。该会议是:
口针对冲刺末期召开;
口被时间盒定义到四个小时,按月冲刺和较短的时间段口冲刺评审会议由包括开发团队,产品负责人,ScrumMaster,和企业的利益相关者的整个团队出席;
口这些冲刺评审会议被团队通过录音、快照来展示产品。
 

2、冲刺评审的益处
        进行常规冲刺评审会议有助于:
口产品根据利益相关者的需要在变化;

口任何反馈或升级在即将到来的冲刺或发布中被记录和强调;

口优先级排序的待办事项将被展示给利益相关者去评估是够满足他们的期望;

口逐步完善未来的项目计划。

3、冲刺评审的重要性
        在一个2周冲刺的项目中,没有组织冲刺会议将导致项目进度落后于整整一个月。这是因为:
口开发的需求没有满足利益相关者的期望;
口为即将到来的冲刺所选择的需求,没有同利益相关者的需求保持一致。

4冲刺回顾会议:(retrospective)   总结   改进  计划
        是由Scrum团队的所有成员参加。这次会议的焦点是对整个迭代进行回顾。细节包括:什么进行顺利,缺少什么,需要改变什么等等。团队就未来的迭代改进计划达成一致。这个会议时间框为一个月的迭代,3个小时,比迭代评审时间短。如上图所示,所有的会议都会在每次迭代中重复。

冲刺回顾是针对迭代末期进行的时间盒(有指定时间限制)会议,目的是认识团队可以如何提高他们的工作方式,就未来的迭代改进计划达成一致,该会议:

口针对冲刺末期召开;

口被时间盒定义到三~四个小时按月冲刺和较短的时间段;

口由包括开发团队,产品负责人,ScrumMaster,和企业的利益相关者的整个团队出席;

口在冲刺回顾中,团队将认识到他们做的好的领域以及有待改进的领域。

口来自于回顾会议的反馈对实施持续改进策略和最大化团队交付价值非常关键。

口细节包括:什么进行顺利,缺少什么,需要改变什么等等…..…
 

待办事项梳理(Grooming)
        Scrum团队在冲刺中经常会面进行待办事项的梳理
梳理或细分是一种逐步完善待办事项的方法,所以它会保留现有信息同时反映利益相关者的需要。

该会议有助于:

口增加新用户故事;

口丢弃不相关的用户故事;

口估算新增加的用户故事;

口重新估算用户故事;

口对用户故事进行优先级重排序;

口史诗分解成更小的用户故事。

需要记住的点:
口梳理会议提供了调整估算范围的最佳时机;
口利益相关者的期望通过对产品待办事项进行与时俱进的更新来管理;
口已经完成优先级排序和更新的产品待办事项应该作为冲刺评审会议的一部分由利益相关者来评审;
口来自于运营和维护问题的反馈需要被考虑,新需求必须添加到产品待办事项中;
口识别出的现有缺陷经过分析后,需要确保他们在梳理会议上被讨论。

会议名称 与会人员 时间箱 会议时间 会议的目的
冲刺
计划会议
团队所有成员参加 一个月的冲刺 8小时(4小时选择故事,4小时估算分配) 开发团队识别当前冲刺开发交
付的产品待办事项中的故事
每日
站会
SM和开发团队参加
产品负责人可以自
行选择是否参加
15分钟 用来分享迭代或迭代进展;团队
成员对要完成的任务做口头承诺;
回答以下问题“昨天做什么
“今天将做什么“遇到了什么问题
冲刺
评审会
团队所有成员参加 一个月的迭代 4个小时 开发团队将可能移交的可交付物
开发特性演示给干系人和项目发
起人;修订的产品待办列表,确
认进入下一个冲刺的产品待办列表项
冲刺
回顾会
团队所有成员参加 一个月的迭代 3个小时 认识团队可以如何提高他们的工
作方式,就未来的迭代改进计划达成一致

其他常考知识点

 
                                               敏捷教练
        它是指掌握了敏捷知识和经验的人员其在组织和团队转型中能够发挥培训、辅导和指导的作用。
        敏捷教练可以是内部教练或外部教练,教练需要:
1)跟不同团队共事时具备平衡视角;每个团队具备不同的进展节奏,可能会面临制约,需要帮助去克服;

2)忠于团队成员价值;

3)认识 会心理及团队复杂性;

4)运用有效方法解决团队面临的问题;

5)开发方法进行非侵入型干预从而改变团队动力;

6)学习真正需要什么才能让人们作为一个团队去工作。

                                        优先级技术-MoSCoW
MoSCow技术是进行需求优先级排序的敏捷方法。在这种技术下,需求基于以下方面排序:
1)Must必须有-这些需求是强制性的
2)Should应该有-这些需求不是强制性的,但是高度渴望的3)Could可以有-这些需求如果满足会很好
4)Won’t不会有-当下可以不去满足,但是将来可以加入。
在开始新一轮时间箱前,会有一个新的MUSTs加入。这些可能是新的需求,或者现有需求被调整优先级进而转移成MUSTS

                                        仆人式领导
        仆人式领导是一种为团队赋权的方法。仆人式领导是通过对团队服务来领导团队的实践,它注重理解和关注团队成员的需要和发展,旨在使团队尽可能达到最高绩效。仆人式领导的作用是促进团队发现和定义敏捷。仆人式领导实践并传播敏捷。

仆人式领导按照以下顺序从事项目工作:

1)目的
        与团队一起定义“为什么”或目的,以便他们能围绕项目目标进行合作互动。整个团队在项目层面而不是在人员层面优化。

2)人员
目标确立后,鼓励团队创造一个人人都能成功的环境。要求每个团队成员在项目工作中做出贡献

3)过程
不要计划遵循“完美”的敏捷过程,而是要注重结果。如果跨职能团队能够常常交付完成的价值并反思产品和过程,团队就是敏捷的。团队将其过程称作什么并不重要。

4)特征
以下仆人式领导的特征让项目领导变得更加敏捷,促进团队的成功:

A.提升自我意识;

B.倾听;

c.为团队服务;帮助他人成长;

E.引导与控制;

F.促进安全、尊重与信任;

G.促进他人精力和才智提升;

                                        Kanban 看板
    看板在项目实施期间作为信息发射源运用,它有助于相关干系人去了解冲刺或迭代的当下状态

1)看板是一个跟精益和及时制生产相关的概念

        任务板被细分成段来反映关键活动。

        故事是由索引卡或代表的便利贴来表示。

        卡的状态由它在任务板上的位置来表示,并随着项目进展从开始到结束变化。

        看板帮助团队意识到他们是如何工作以及下一步要做什么。让团队形成自我指挥。

2) kanban卡片
        Kanban任务板上的每一张卡片就是kanban卡片。

        Kanban卡片用来显示迭代过程

        Kanban任务板上的卡片呈现在开发周期的不同环节中移动的工作部件。

        Kanban卡片反映所有需要被跟踪的事物。例如:用户故事,缺陷,任务。

        日在用户故事定义完整前,相关于系人需要对用户故事必须经历的部分进行评估。

3)简化的看板面板简化的看板面板有3列:

口待完成

口进展中

口已完成

任务用卡片表示,卡片状态展示在其中一列的下方。
 

五问法(五个为什么5whys)
        五问法是一种通过不断重复询问为什么来识别问题根本原因的技术。每个为什么的答案成为了识别下一个为什么的驱动力。
确切地说,不是强制的使用五个“为什么”来深入到问题的根源,“五”只是一个指示性的数字。这种技术同鱼骨图结合起来使用提供了一个问题解决可视化过程。。

DoD完成的定义
        它是团队需要满足的所有标准的核对单,只有可交付成果满足该核对单才能视为准备就绪可供客户使用。

电梯演讲
产品愿景–电梯演讲(Elevator Pitch)

for [target customer]

who [statement of the need or opportunity]

the [product name is a [product category]
that key benefit.compelling reason to use

unlike [primarycompetitive alternative]

our product [statement of primary differentiation

为了[目标客户],

他们的[需要和机会!,

这个[产品名称],

它可以关键优点和使用理由),

而不像 同类竞争者!.

我们产品的[差异化声明)

信息发射源
        信息发射源概念由Alistair Cockburn发明。根据他的理解,信息发射源的定义是:一个信息发射源在任何人都可见的地方显示信息。有了信息发射源,大家不需要问任何问题。

信息发射源的特征有:
        让团队成员可以看见项目和项目进展的当前状态;

        大部分敏捷团队在过程中不同程度使用它。

最受欢迎的信息发射源有:
        任务板;大型可视化表格,包括燃尽图;

        持续集成构建健康指标,包括街灯等。信息发射源有助于对于成功验收、交付物的共识。

        信息发射源用来促进干系人期望管理,对当下进行的工作可见、透明他们提供团队日常进展、工作质量、障碍和风险的视图

敏捷项目中运用的一些信息发射源有:
        燃起图;燃尽图;看板或任务板;障碍日志

点燃尽图&燃起图
燃起图

        燃起图根据工作范围展示已完成工作量。在特征驱动开发中又被称为“特征完工图

燃尽图
        燃尽图显示在一次迭代或发布中的剩余工作量。这些图可以用来追踪实际速度和预期速度的对比,评估项目绩效

 
燃起图和燃尽图用来预测团队最可能的速度,团队按照这个速度去开发即将到来的冲刺或迭代交付物,从而促进有效计划。

WIP(在制品)
        在敏捷开发中,WIP限制决定了每种情况下的工作流中可以存续的最大工作量。限制进行中的工作数量可以更容易辨识团队工作流中的无效工作。在情况变得更糟前,一个团队在持续交付通道中的瓶颈是非常容易辨别的。

        WIP限制通过强制让团队聚焦在更小的一套任务中来改善吞吐量和减少“将要完成”的工作量。从根本上来讲, WIP限制鼓励的是“完成”的文化。更重要的是,WIP 限制可以让阻碍和瓶颈显而易见。当有明确指示现有工作遇到瓶颈时,团队可以聚焦在阻塞问题上尽快的理解、实施和解决。一旦消除阻塞,团队中的工作将再次开始流动。这些优势可以确保在最短的时间内向用户交付有价值的增量,从而使得WIP限制成为敏捷开发中一个非常有价值的工具。

用户故事

***********************************************************************待更新*************

3355  三种角色  三种工件 五个仪式 五种精神

3种工件:

产品待办事项列表: 排序的需求池

   产品需求列表

包含业务需求 、技术需求 、NFR等         

  理想的情况下,每个待完成的工作豆浆对客户产生价值             

PO对该列表进行优先级排序

每个迭代开始前,优先级排序还需要再度修正

迭代待办事项列表:迭代完成的需求列表

产品增量  :交付物

文章知识点与官方知识档案匹配,可进一步学习相关知识Java技能树使用JDBC操作数据库数据库操作92165 人正在系统学习中

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2022年7月21日
下一篇 2022年7月21日

相关推荐