软件开发平台 DevCloud软件开发平台 DevCloud

计算
弹性云服务器 ECS
裸金属服务器 BMS
云手机 CPH
专属主机 DeH
弹性伸缩 AS
镜像服务 IMS
函数工作流 FunctionGraph
云耀云服务器 HECS
VR云渲游平台 CVR
特惠算力专区
存储
对象存储服务 OBS
云硬盘 EVS
云备份 CBR
弹性文件服务 SFS
存储容灾服务 SDRS
云硬盘备份 VBS
云服务器备份 CSBS
数据快递服务 DES
专属企业存储服务
云存储网关 CSG
专属分布式存储服务 DSS
CDN与智能边缘
内容分发网络 CDN
智能边缘云 IEC
智能边缘小站 IES
智能边缘平台 IEF
人工智能
AI开发平台ModelArts
华为HiLens
图引擎服务 GES
图像识别 Image
文字识别 OCR
自然语言处理 NLP
内容审核 Moderation
图像搜索 ImageSearch
医疗智能体 EIHealth
园区智能体 CampusGo
企业级AI应用开发专业套件 ModelArts Pro
人脸识别服务 FRS
对话机器人服务 CBS
视频分析服务 VAS
语音交互服务 SIS
知识图谱 KG
人证核身服务 IVS
IoT物联网
设备接入 IoTDA
设备管理 IoTDM(联通用户专用)
全球SIM联接 GSL
IoT数据分析
路网数字化服务 DRIS
IoT边缘 IoTEdge
设备发放 IoTDP
开发与运维
软件开发平台 DevCloud
项目管理 ProjectMan
代码托管 CodeHub
流水线 CloudPipeline
代码检查 CodeCheck
编译构建 CloudBuild
部署 CloudDeploy
云测 CloudTest
发布 CloudRelease
移动应用测试 MobileAPPTest
CloudIDE
Classroom
开源镜像站 Mirrors
应用魔方 AppCube
云性能测试服务 CPTS
应用管理与运维平台 ServiceStage
云应用引擎 CAE
视频
实时音视频 SparkRTC
视频直播 Live
视频点播 VOD
媒体处理 MPC
视频接入服务 VIS
管理与监管
统一身份认证服务 IAM
消息通知服务 SMN
云监控服务 CES
应用运维管理 AOM
应用性能管理 APM
云日志服务 LTS
云审计服务 CTS
标签管理服务 TMS
资源管理服务 RMS
应用身份管理服务 OneAccess
区块链
区块链服务 BCS
可信跨链服务 TCS
可信分布式身份服务
智能协作
IdeaHub
开发者工具
SDK开发指南
API签名指南
DevStar
HCloud CLI
Terraform
Ansible
云生态
云市场
合作伙伴中心
华为云培训中心
其他
管理控制台
消息中心
产品价格详情
系统权限
我的凭证
客户关联华为云合作伙伴须知
公共问题
宽限期保留期
奖励推广计划
活动
容器
云容器引擎 CCE
云容器实例 CCI
容器镜像服务 SWR
应用编排服务 AOS
多云容器平台 MCP
基因容器 GCS
容器洞察引擎 CIE
云原生服务中心 OSC
容器批量计算 BCE
容器交付流水线 ContainerOps
应用服务网格 ASM
网络
虚拟私有云 VPC
弹性公网IP EIP
弹性负载均衡 ELB
NAT网关 NAT
云专线 DC
虚拟专用网络 VPN
云连接 CC
VPC终端节点 VPCEP
数据库
云数据库 RDS
数据复制服务 DRS
文档数据库服务 DDS
分布式数据库中间件 DDM
云数据库 GaussDB (for openGauss)
云数据库 GaussDB(for MySQL)
云数据库 GaussDB NoSQL
数据管理服务 DAS
数据库和应用迁移 UGO
大数据
MapReduce服务 MRS
数据湖探索 DLI
表格存储服务 CloudTable
可信智能计算服务 TICS
推荐系统 RES
云搜索服务 CSS
数据可视化 DLV
数据湖治理中心 DGC
数据接入服务 DIS
数据仓库服务 GaussDB(DWS)
应用中间件
微服务引擎 CSE
分布式消息服务Kafka版
分布式消息服务RabbitMQ版
API网关 APIG
分布式缓存服务 DCS
分布式消息服务RocketMQ版
企业应用
域名注册服务 Domains
云解析服务 DNS
云速建站 CloudSite
网站备案
商标注册
华为云WeLink
会议
隐私保护通话 PrivateNumber
语音通话 VoiceCall
消息&短信 MSGSMS
云管理网络
SD-WAN 云服务
边缘数据中心管理 EDCM
云桌面 Workspace
应用与数据集成平台 ROMA Connect
ROMA资产中心 ROMAExchange
API全生命周期管理 ROMA API
安全与合规
安全技术与应用
DDoS防护 ADS
Web应用防火墙 WAF
云防火墙 CFW
应用信任中心 ATC
企业主机安全 HSS
容器安全服务 CGS
云堡垒机 CBH
数据库安全服务 DBSS
数据加密服务 DEW
数据安全中心 DSC
云证书管理服务 CCM
SSL证书管理 SCM
漏洞扫描服务 VSS
态势感知 SA
威胁检测服务 MTD
管理检测与响应 MDR
安全治理云图 Compass
认证测试中心 CTC
迁移
主机迁移服务 SMS
对象存储迁移服务 OMS
云数据迁移 CDM
专属云
专属计算集群 DCC
解决方案
高性能计算 HPC
SAP
混合云灾备
华为工业云平台 IMC
价格
成本优化最佳实践
专属云商业逻辑
用户服务
帐号中心
费用中心
成本中心
资源中心
企业管理
工单管理
客户运营能力
国际站常见问题
支持计划
专业服务
合作伙伴支持计划
更新时间:2021-03-18 GMT+08:00
分享

敏捷回顾,只为更好地冲刺

在Scrum中,评审会是说在一个Sprint结束以后,进行Sprint评审,团队在此期间展示他们所完成的工作、可运行的软件。参加评审的应该有Product Owner、开发团队、Scrum Master,加上客户、项目管理者、专家和高层人士等任何对此感兴趣的人。

会议可以是10分钟,也可以持续两个小时。因为会议目的只是对所做工作结果的展示,并听取反馈。

为什么要演示?

演示主要是出于这样几个目的:

演示可以让那些虽然不直接参与Sprint的利益相关者,获得团队工作的最新进展。这里提到了利益相关者,就意味着你可以随意邀请任何没有直接参与Sprint工作的人,只要相关。

演示可以让客户或者Product Owner对你们所做的工作提供最直接的反馈,这样可以让Scrum团队,根据反馈更新产品Backlog,在下一个Sprint中融入新的需求变化,并将这些反馈带到下一个Sprint的计划会议上。

同时,演示是一个很好的机会,可以让团队庆祝他们在过去的Sprint中所取得的成就,鼓舞团队的士气。

团队不需要准备一个非常华丽的演示,只需要展示团队刚刚完成的最新功能即可。不需要额外修饰,只要让人印象深刻,就已经足够了。总之,这不是一个产品发布会,不需要制作一个非常炫目的演示。

不要仅仅从字面上理解“演示”这两个字,范畴可以更广一些。这里的“演示”,还可以是对下列事情的回顾:如一个新建的编辑页面、一个新写的小工具、一份说明文档或其他任何具体的、可以让该团队感觉到有价值的东西、或者是你们工作过程的截图等!

演示要安排在Sprint回顾会议之前。此外,更重要的是要让这个演示会议充满乐趣,不能搞成批斗会。

Sprint回顾会议

Sprint回顾会议与平常我们经常提到的项目总结会议不同,它不是要对项目进行盖棺定论,而是通过及时回顾,总结上一次冲刺中的得与失,找到改善与提高的办法,从而让下一个Sprint走得更好。第一点是找出在上一个Sprint中做得好的地方,并继续保持。分析那些成功的流程是非常重要的,这样我们才能有意识地保持下去。只有团队中的每一个成员都清楚什么是最佳实践,才能有效地保持这些实践。除了鼓舞士气外,还可以避免把回顾会议变成消极的抱怨会议。第二点是找出上一个Sprint中需要改进的地方,以及对应的改进措施。回顾的目的是持续不断地改进,这也是敏捷开发的主要理念之一。让我们想一想如何才能在下一个Sprint中更加有效率,想一想如何做才能与上一个Sprint不同。收集任何可以量化的数据,以便于做定量分析,推动改善。

  • Sprint回顾会议指导原则

    首先,一定要明确这样一个指导原则。即“无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及现状,我们理解并坚信:每个人对自己的工作都已全力以赴”。

    对团队成员的绩效评估,当然不能采用这样的指导原则。我们现在谈论的是Sprint回顾,回顾的最终目的是学习,而不是审判。如果敏捷回顾没有坚守这样的“指导原则”,倡导团队成员首先要信任自己的伙伴,已经尽了最大努力,就会让回顾会议成为互相攻击、互相推诿的批斗大会,脱离了我们召开回顾会议的初衷。

    “指导原则”就是为回顾会议竖立一个标杆,那就是在项目开发中没有破坏者,没有替罪羊,没有关键人物,只有整个团队的利益。虽然某个人或许在上一次迭代中出现了错误,但我们会善意地相信此人之所以犯下错误,并非有意为之或者消极怠工,而是囿于当时之识见、经验、技能。我们的回顾会议必须指明这些错误,并试图寻找到最佳实践以避免在下一次迭代中犯同样的错误,而“指导原则”则能够消除因为指出他人错误时给成员带来的负疚感,消除同事之间可能因此出现的隔阂与误解。换句话说,回顾会议提出的所有批评都应该“对事不对人”。

  • 组织Sprint回顾的方法

    组织Sprint回顾最简单的方法是找个白板纸,在上面注明“哪些项工作顺利”“哪些项工作不成功”或者“哪些项工作可以做得更好”,让与会者在每一类别下增加一些条目。当条目重复时,可以在该项旁边画正字累计,这样普遍出现的条目就一目了然了。最后团队成员共同讨论,找寻这些条目出现的根本原因,就如何在下一个Sprint中改进达成一致意见。

    其实,敏捷回顾的主要目的就是明确目标、持续改进和处理问题。敏捷开发之所以采用迭代的方式,实际上是利用蚕食方式逐步完成开发任务。将一个宏伟的目标切割为一个个小目标,会给予团队成员更大的信心,并且能够更加清晰地明确目标。而每次迭代后的回顾,使得团队成员可以更加清晰地明确我们在这个征途中,已经走到了哪里,未来还有多远的路程。当然,也可以用ORID(Objective Reflective Interpretive Decisional,焦点呈现法,一种沟通引导方式),结合“心情曲线”、4F、4R等玩法,要让你的回顾会多样化,避免形式上的千篇一律。另外,地点的选择也可以多样化,不一定总是在公司会议室开,可以去咖啡厅、水吧,甚至是公园的草坪,团队建设的饭桌上。关键就是要灵活多变。

敏捷回顾的要点

  1. Sprint评审会议不是让开发团队做成果“演讲”:会议上不一定要有PPT,最好是直接做产品演示。会议通常不需要超过30分钟的准备时间,只是简单地展示工作结果,所有与会人员可以提出问题和建议。
  2. 在Sprint评审之后,开发团队会进行Sprint回顾。有些开发团队会跳过此过程,这是不对的,因为它是Scrum成功的重要途径之一。这是提供给开发团队的非常好的机会,来讨论什么方法能起作用,而什么不起作用,就改进的方法达成一致。
  3. Scrum开发团队,Product Owner和Scrum Master都将参加会议,会议可以由外部中立者主持;一个很好的方法是由Scrum Master互相主持对方的回顾会议,可以起到各团队间信息传播的作用。
  4. 敏捷回顾不能是一场没有主题的讨论会,这样的形式对于项目进展没有任何帮助。
  5. Scrum回顾会议的参考议程。
    • 在白板上写上主要指导原则。
    • 在白板上画上一个至少三页纸连在一起长的时间轴。
    • 在第一页上写上“我们的成功经验是什么”。
    • 在第二页上写上“有什么能够改进”。
    • 在第三页上写上“谁负责”,然后分成两个区域,分别是“团队”和“公司”。
  6. Scrum回顾会议的指导原则。即“无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及现状,我们理解并坚信:每个人对自己的工作都已全力以赴”。
  7. 在项目过程中,问题处理得越早,那么付出的代价与成本就越小。通过回顾会议,利用团队成员互相善意地“敲击”,或者反复“锤炼”开发过程与方法,就能够让每一位成员练就“火眼金睛”。
  8. 进行Scrum回顾时,发现问题仅仅是第一步,我们还要在回顾会议中合理分析这些问题出现的原因、所属类别,并因此划定问题的“责任田”。我们要明确这些问题是团队内部的,还是由于外在因素导致的,也就是说要明确“责任田”的归属,指定责任人和处理时间,一定要SMART。
  9. 在每个Sprint开始的时候,我们都要明确,当Sprint结束的时候需要演示的是哪些东西。很多时候,如果一个Scrum开展得不是很顺利,在Sprint演示的时候我们常常会听到这样的理由,“因为某些原因,这个功能我没有办法展示给你,但是这个功能是有的,我只需要改动小小一点东西就可以了”,或者是“这个部分与另一个系统相关,我代码已经写好了,但我要一起改好了你才可以看到”。如果放任的话,这些理由到后期会泛滥成灾。我们所能做的,除拒绝通过这些相关的需求之外,在每个Sprint开始的时候还应该帮助团队了解到我们需要在Sprint演示会议上看到什么东西。强调我们重视的是可交付的软件版本,而不是一个口头上的功能实现。
  10. 回顾会议要灵活多变,可以采用ORID技术,结合心情曲线、4F和4R等玩法, 一定要让你的回顾会多样化 !

评审会议与回顾会议

评审会议的目的是获取相关人员的反馈,是迭代进度展示,同时给业务方,以及高层领导以信心(这点很重要,要想清楚谁是团队的投资人),是团队进行阶段成果展示以及进行庆祝的机会,“鸡类”角色与“猪类”角色都要参与。评审的目的是获取反馈,回顾的目的是学习改进。

演示并不是评审会议中最重要的一环,更重要的则是审视,调整计划以适应当前的情况。

两个会议都是仪式感的体现,是每个Sprint不可或缺的。两个会议纪要都应该有专人记录,并通过邮件公开发出,如果有可能,通过工具记录在本Sprint的信息中。

两个会议都是必要的,如果两者一定要比较,我认为回顾会议会更重要一些。评审会是针对业务层面的,面向结果的;回顾会是针对团队层面的,是面向过程的;磨刀不误砍柴工,从长期来讲,持续的学习和改进,最终对业务输出会产生根源的影响。科恩(Mike Cohn)说:“有时,我以为衡量一个团队敏捷实施质量的最好标准是看他们对待回顾会议有多认真。”

另外的一个例证是,关于回顾会议,有专门的一本《敏捷回顾》来讲如何开回顾会议, 而评审会议则没有专门的图书。

安全度检查

回顾会议中,最重要的是要能听到真话,要为团队成员创造一个敢于畅所欲言的氛围, 即安全感。

安全度检查,是回顾会议中很容易被忽视的一个环节。安全度检查,是将安全性从“愿意畅所欲言”到“想保持低调”分成几个不同的等级。会议开始时,所有团队成员将其自身感觉所处的等级,匿名写在一张纸片上,折好交给会议组织者。由组织者统计安全度。如果等级都比较高,回顾会议可以继续开;如果有较低等级出现,哪怕是个别人,会议组织者需要考虑是否取消本次会议,或者采取一些措施,让大家放松下来, 直到安全等级都比较高以后,再进行会议。

如同Blameless Post Mortem(无指责的事后分析会议),关键是营造安全的氛围和文化。每个人都不用担心自己会承担风险,可以自由地表达意见,并提出不会被评判的问题。需要提供一种保护文化,使团队成员可以畅所欲言,大胆尝试。在这里,管理者起到至关重要的作用。

安全文化的营造,也与学习型组织和个人成长型思维等密不可分。

持续改进

回顾会议是Scrum中进行检视与调整的一个重要的环节。

会议应该面向未来,而不是简单的对过去进行回顾,回顾主要的目的还是为了改进。

改进不宜太过贪心,建议每个人针对每个方面,不超过三条,但不能一条不写。如果安全度较低,也可以尝试不记名的方式。针对提出的问题,可以用计点投票法,得票高的三个问题进入讨论环节。可以进行头脑风暴,进行五指表决法等;对回顾会议输出的改进点,可以统一维护到产品Backlog,作为特殊类型的需求,与技术故事对应的技术债务一样,流程也存在债务,需要定期偿还;团队可以决定每个迭代固定做多少比例的流程改进故事,多少比例的技术故事。回顾与改进,应该变成团队承诺,每个迭代,都必须有所改进,积少成多,聚沙成塔。

此外,回顾会应该尽量保证会议聚焦,并且高效;但偶尔举行大团队的回顾会也是有益的,可以保证在更大范围内获取改进建议和经验分享;这类会议开销较大,通常以季度为周期即可。

回顾会议也有一些小的游戏环节,例如心情卡片,用一个词形容你现在的感受;或是感谢环节,每个人通过写卡片的形式感谢他人对自己的帮助,或是对团队做出的贡献。

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)。

分享:

    相关文档

    相关产品

关闭导读