Agile以及Scrum的一点个人理解

这个暂时算凑字数,后面会根据实际内容更新-->好的我来更新了。

看这里:

1
2
3
title: "Scrum"
date: 2020-07-26T18:02:22+08:00
draft: false

这是文档的元数据,如果 draft 是 true 的话,表示是草稿, Hugo不会生成页面到production级别,所以这种情况下发布后是看不到这个页面的。

刚开始的时候忘了改了,掉坑里半天没爬出来,汗一个~


开始

从第一次接触Agile理念到现在,已经有很多年头了,对Agile理念,Scrum框架,以及Scrum中角色的理解也比刚刚开始时更深刻了些。后期随着DevOps,微服务,云计算等等的不断发展,这些技术与框架理念的结合,也发挥出了比以前更大的影响力。

让我们从头开始。

敏捷和Scrum

敏捷是一种思维方式,它是基于敏捷宣言中的一系列原则和价值观的方法和实践的总和。

如果说一个团队或者一个组织敏捷了,那么应该是正确的理解了敏捷的理念,在价值观和原则的指导下,实践了敏捷倡导的方法,并且取得了预期的结果。最后一点显得尤为重要,虽然说这有点结果导向,但其他的部分根本不太容易检验,只有团队及其成员获得了成长,团队取得可喜产出的情况下,一个团队才可以算是真的敏捷了。

实施敏捷可以采用很多种方法或者框架,Scrum算是其中一种,其他还有精益(Lean),极限编程(XP), SAFE等等。有人说Kanban也是一种框架,我觉得这种情况下是把Kanban当作一种管理的方式,基于Kanban board对大家的工作进行跟踪。而在实施敏捷的过程中,确实不需要太拘泥于框架的限制,我们采用过的方式,就是在Scrum的基础上,增加了Kanban board,另外还有Scrum board,这两者的维度不同,在不同的场合或者会议中使用是没有问题的。任何符合Agile理念的工具/想法,都是可以拿来主义一下的,最终求的只是团队和个人的成长以及产品和项目的高质量和高速交付。

3355记法

Scrum的核心要点"3355"记法还是很不错的,这个是照抄了,不是我的理解:

3个核心角色

  • Scrum Master

  • Product Owner(产品负责人)

  • Scrum Team(团队)

3个工件

  • Product Backlog(产品待办事项)
  • Sprint Backlog (Sprint 待办事项)
  • Increment(可交付产品增量)

5个事件

​ Sprint(冲刺,迭代)、Sprint计划会、每日站会、Sprint评审会和回顾会

5大价值观

​ 承诺/专注/开放/尊重/勇气

价值观这些基本属于与Agile理念类似的,团队了解即可,需要平时慢慢培养而不适合经常拿出来说来说去,否则就跟唐僧差不多了。

Scrum大致流程

按照几个大的部分来说吧。

需求理解拆分

首先从PO说起。PO是产品负责人,在这里不是产品运营,而是负责首先对产品需求进行分析的一个角色,而且这不是个title,这个角色负责将从客户那里来的需求理解透彻,然后按照需求大小分成Epic/Feature/Story,当然最终给团队开发的都是Story,这是最小的单位,实际中不一定使用三级结构,也许Epic/Story或者Feature/Story就足够了。拆分完成后,PO需要对各个Stroy的验收条件了如执掌,或者说最终做成什么样子了然于心。要注意的是,并不是所有的需求都是做处理的,PO应该具有拒绝某些不合理需求的能力,而且也应该做到。这里是考验PO沟通能力的地方之一。再然后,每个story都应该有自己的优先级,然后把他们按优先级从高到低全部放到产品的backlog里面。总体来讲,PO是要对产品负责的。

计划

接下来是Sprint,中文翻译为迭代或者冲刺。这两个词都比较形象,而且接近实际,毕竟大家在一个小的开发周期结束之后(冲刺完成)也需要休息调整和总结,而迭代则是说明了开发循序渐进逐步提升的过程。

每个Sprint中的backlog是三个角色一起在计划会中完成的,在会上,团队成员各自按照优先级从高到低的顺序挑选产品backlog中的story,然后大家一起对每个story打分,估计时间,常用的方式是poke game。此时可能有需求不清晰的情况,PO负责解释澄清;如果在这之后时间估计太多,那么PO需要对这个story进行再拆分,然后重新估计。

此时可以使用Scrum board。

Scrum master应该清楚团队的整体开发水平,知道一个sprint大家能够完成的工作量大致多少,然后在大家挑选了足够的story之后,结束整个计划过程。 在团队创建初期的时候,需要有几次试错的过程,此时需要跟着感觉走,在几个Sprint之后大家就可以找到自己的节奏了。

Scrum master需要确保每个team成员各自都有足够的工作量,而且都有足够的时间来完成各自名下的story,尽量不要出现某个人特别多,某个人特别少的情况,也不可以超出整个团队承诺的工作量的值。另外,Scrum master还需要确保每个人有足够的能力来完成各自的story,否则就应该引入新技术培训等等来提高大家的水平,最终提升整个团队的水平。所以说,Scrum master着眼在整个团队

另外要注意,所有几个会议都是Scrum master来主持的,所以要求Scrum master有会议控制的能力。

研发日常

接下来是每日站会,三条目:昨天做什么,今天准备做什么,有没有什么问题需要帮忙解决。时间尽量控制在15分钟。这个时候可以使用Kanban board。障碍或者问题只需要提出来,不要进行太过深入的讨论,否则容易超时,此时仅仅需要记录下来并指定人员在协商好的时间处理即可。每日的站会保证了Sprint的透明性,而且对前一日的工作可以有个小的回顾的作用。会上问题的及时提出解决,则更进一步的保证了质量和速度。

此时可以看出,过大的团队规模是不合适的,否则单单站会的沟通时间都会远超15分钟了,这必然导致沟通成本大幅上升,毕竟除了站会还有其他的会议以及日常的交流。还有个问题,过大的团队规模对Scrum master也是个挑战,对普通的管理者来讲,能够直线管理的人数是有个上限的,所以才会有管理的层级结构出现。以经验而言,10个左右的团队成员已经OK了。

Scrum master在日常会议以及平时的开发中,注意维护整个流程的流畅通顺,理清障碍并教练大家遵循流程中的注意事项,比如注意设置各sotry的状态,完成的标记为完成,这样最终的燃尽图才有统计意义。此时,PO如果有紧急事件或者其他问题,需要提出来与scrum master一起讨论解决方案,在保证团队尽量少受影响,按时按质完成交付件的前提下解决问题。

开发过程中,Scrum master的需要处理的事情越少,越是说明团队已经走上了正轨。

演示评审

在全部开发结束后,全体成员会同用户一起要进行Demo和评审,注意只针对当前sprint的工作内容。演示时间也不应该过长,半小时即可,并记录评审中的问题。

此时PO是有权利拒绝接受sprint的某个交付件的,当然此时应该是研发团队确实没有达到PO的验收条件,但是又将story标记为完成了。

总结回顾

没有完成的story其实已经属于异常情况了,此时多是团队磨合还不足,对各自能力估计不够导致,当然还有对需求理解的问题。在回顾会上,可以对这种类似的事情做总结。在团队建立初期,磨合不足导致的异常情况会有出现,此时必须对工作总量以及个人的工作量做出调整。需求理解的问题说明沟通不足,后期要加强。而如果是因为中途需求变更导致的异常情况,说明在研发日常中需求变更没有得到合理解决,或者PO与Scrum master没有达成一致意见,属于沟通失效了,这种情况应该尽量避免出现。

另外一些问题,也许并没有影响到当前增量交付的发布,但是有其他方面的不足或者损失,只要让大家不太爽的问题都可以提。回顾会上的问题解决应该尽量提出切实有效的方案,并指定责任人,给定合理的解决时间。如果问题太多,则选择可以解决的,比较有代表性的2-3个,在下个Sprint优先处理。其他的如果将来再次出现,则说明问题严重性高了,到时候再看是否可以处理即可。

当然,回顾会上也应该对做的比较成功的事情提出来进行表扬,而且这应该是排在问题分析的前面,因为后面这是在找不足了。

说下SAFE

既然前面提到了SAFE,那也说一下。SAFE是号称大型团队Large scale的敏捷,即是规模化的敏捷,它为那些需要很多团队配合的大型软件开发的团队和组织提供了一套类似Scrum的流程规范和逻辑。可能类似4G/5G设备软件的这种开发可以采用,因为涉及到的模块实在太多,彼此之间的又有若干的耦合,使用一套比较标准的开发规范是有些好处的。但是这种情况下,流程中的沟通成本非常巨大,所以实际中我们公司在尝试了一段时间之后就沉默下来了。个人以为,每个公司对项目管理的概念和流程的理解可能都有点相似但又不完全相同,SAFE难以推进除了沟通的成本外,恐怕与原有流程的某些冲突也有些关系。


以上皆是工作所得,也算是对自己这段时间工作的一个小结吧,很多说的都还不够全面,希望有时间的话再来调整或者补充些细节。

就这样。

updatedupdated2020-08-052020-08-05