图(三)经验性的开发过程 a) 周期性的检验和调整
Scrum框架中包含多个检验和调整的反馈循环。每日Scrum会议上团队检验工作进展,和sprint目标进行比较,调整接下来的工作以更好地达成目标;Sprint评审会议上,团队演示软件,获取业务人员和客户的反馈,及时调整产品的方向以及开发计划。通过不断的检验和调整,团队和客户持续修正产品开发方向和计划,更好的实现商务目标。 b) 业务人员更紧密的参与开发过程
不管业务人员还是用户,都不可能在项目一开始就准确无误地把握产品方向和定义完整的需求,它们需要在开发过程中不断的被修订、调整和完善。如果,业务人员不参与到开发过程当中去,在项目结束时就可能会出现“团队开发的产品和业务人员的定义不符”,或者“团队开发的与当初业务人员所定义相符,但却不是业务人员和市场需要的产品了”。
业务人员参与开发过程,一方面团队能够及时获得对产品目标和需求的澄清和确认,确保双方的理解一致;另一方面,通过参与开发过程,业务人员更准确地理解客户需、把握产品目标,并做出及时的调整。
针对开发过程的不良症状分析
图(四)Scrum中的两个调整与检验循环
影响过程能力的要素很多,如团队协作方式、开发流程、技术实践、基础设施等。每个sprint的回顾会议都应对以上要素进行反思和调整,为保证sprint回顾及其后续活动的有效,团队要做到: a) 让团队成员,积极参与改进的过程
“retrospective prime directive”是回顾会议的基本指导原则,它明确的指出,回顾是为了改进开发过程,而不是针对任何个人。一个被少数人主导的回顾会议,很难达到期望的效果,创造一个安全开放的氛围,让每一个人都积极参与改进过程,是确保其有效的前提。尝试不同的形式来组织回顾会议的进程,也有助于提高成员参与的积极性,Agile Retrospective一书提供了丰富的回顾会议的组织形式。 b) 每次聚焦有限的改进项目
一次改变太多的东西是不现实的,会导致分析不够深入彻底,执行的效果打折。每次聚焦一到两点,集中力量,积累小的改进成果。 c) 找到深层次的原因
就问题解决问题是不够的,多问几个为什么,挖掘问题背后的本质原因,这样的改进才是彻底和长久的。 d) 产生具体可执行的行动方案
光发现和分析问题还不行,要制定切实可行的方案。方案必须是具体和可执行的,可以落实到人,而不是仅停留在口头或纸面。 e) 检验改进效果
改进计划落实执行后,需要检查其效果,形成改进环。每次回顾会议的开头检查上次改进方案的执行结果,是一个比较好的做法。 f) 永远不要放弃改进的努力
Scrum的改进过程没有终结,持续改进是Scrum的一部分。
在Scrum实施中暴露并解决问题Ken Schwaber曾经对Scrum做出一个非常好的类比,他说:“Scrum象丈母娘,她希望自己的女儿好,总是对女婿不满意,不断挑他的毛病,却从来不提供改正方案”。相似之处在于,Scrum暴露问题,却不提供解决方案,因为那是团队的责任。
Scrum没有告诉你怎么开发软件,甚至也不告诉你怎么协作,这些由团队自主决定,《敏捷开发艺术》的作者James Shore评论“Scrum是一个有意为之的半成品”。这恰恰是Scrum的生命力所在,维持了Scrum的简洁和包容性;这也是Scrum的陷阱所在,它可能误导使用者低估Scrum实施的难度,而事实上它却对组织和团队提出了很高的要求。通过Scrum实施暴露问题,然后解决它们,这是Scrum引领团队成功的不二法门,这需要团队的勇气和智慧。 a) 尽可能暴露问题,并解决这些问题
Scrum通过透明和检验使问题更易被发现。每个迭代产生潜在可交付的产品增量,暴露了过去深藏于长开发周期中的问题;团队的直接沟通,暴露了隐藏于复杂组织结构下的问题;更少并行开始的用户需求,暴露了隐藏于大量的半成品里的问题。因此选择更短的开发周期,更直接沟通,同一时间更少的并行需求开发,都有助于问题的暴露。
没有重大的改变,就不可能有重大的不同。问题暴露了,就要去解决,不管是组织的问题、团队合作的问题、工程实践的问题、还是研发基础设施的问题,都要去解决。在解决问题的过程中,团队完善自己、提高交付能力并从Scrum实施中真正获益。 b) 技术实践必须跟上
Scrum框架中并不包含任何技术实践,当然也不排除任何技术实践。问题是在实际操作中,技术实践很容易被忽略。James Shore在“The Decline and Fall of Agile”中表达了对许多Scrum团队忽略技术实践的深深担忧,言辞激烈,但发人深思。Robert C. Martin 在 “The Land that Scrum Forgot”中也旗帜鲜明的指出离开技术实践的Scrum是无法长久的,他提出如果没有技术实践的支持,更快的交付软件就意味着更快的积累技术债务,这篇文章还列举了最应该被重视的技术实践,很有参考意义。
尽管,在Scrum的框架中,由团队自主决定技术实践的采用,团队在检验和调整过程中决定是否需要技术上的改变和怎样改变。但理论和实践都已经证明Scrum的成功离不开敏捷技术实践的支持,很多团队都因技术实践未跟上而走向失败。既然这是一个必然且十分重要的选择,那么,在操作上单独去强调技术实践就十分必要。
针对持续改进的常见不良症状分析