0°

你一定要知道的关于Scrum的30个问题(下)


你一定要知道的关于Scrum的30个问题(下)


1
如何应对与团队格格不入的新成员?


有的时候我们把一个人招进来后却发现这个人与团队格格不入,并不是说这个人的能力有什么问题,而是他会给团队带来负面的影响。
比如无法接受敏捷,并且试图让大家放弃敏捷。

有一个概念叫做社会异常,就是违背以确立文化规范的行为做事方式。
敏捷和瀑布没有谁对谁错的问题,只有合适和不合适的问题。
而当一个团队都觉得自己按照一定的节奏前进时,却出现一个不合群的声音,甚至影响到前进的速度和大家的心情,那么就属于社会异常。
对这个概念如果感兴趣的话可以去搜一下。

那怎么办呢?
首先,避免增加与团队不协调的新成员。有一些预判可以帮助你。
如果已经加入团队,那么尝试和行政主管、HR反馈这个问题。
如果实在不行,就只能尝试和他沟通,让他主动退出团队或者做一些边缘性的工作了。


2
Sprint可以取消吗?


当有异味影响到团队实现Sprint目标能力时,可以:
消除障碍
获得帮助
缩小范围
取消Sprint

一般我们不会建议你取消Sprint的,而是尽力去消除障碍或者获得帮助。
如果一切都行不通,才会取消Sprint。
可能的情况是,需求突然变化,有个异常紧急的需求需要处理。
而我们知道Sprint是不能被打断,临时添加任务的。
所以可以采取取消的方式。
但是一定要注意的是,取消的同时要将代码回滚到上一Sprint。


3
Scrum如何看待加班?


Scrum一致强调“可持续”。
而我们知道,一旦加班抢时间,团队在超负荷状态下工作时间越长,就需要更多时间来恢复。
这种“殉道”行为完全无法实现“可持续”。
所以,如果正在经历精疲力尽,首要任务是缩短周期时间。
这样可以提升每次Sprint的专注力。
另外,大家都必须承认,团队的完成量是有极限的。


4
如何保证每次交付可工作的软件?


记得多年前,小婧所在的团队做一个模块,计划半年后交付。
这个模块比较大,于是我们将所有的需求拆分成Story进行开发。
前几个Sprint,我们的主要精力集中在了“业务配置”功能的开发上。
因为我们当时的想法是,不进行业务配置,后面的功能是无法实现的。
后来我们发现,业务配置的部分开发完成都已经过去了三分之一的时间了,而我们的核心功能、业务场景尚未开始。

后来和公司的敏捷教练交流这件事情的时候。
她告诉我,应该先进行的不是业务配置,而是主业务场景和流程涉及的Story。
因为Scrum强调每个版本都可工作,可交付。
但是业务配置功能的发布并不可交付,用户拿着脱离了模块主业务场景的业务配置功能,其实价值为0。

那应该怎么处理呢?
这里有个概念,叫做“核心故事”:最基本的需求。
我们应该鉴别出一个核心故事,固定其他变量,让这个核心故事贯穿于整个系统。

也就是说,之前我们应该一上来就规划开发核心故事,而不支持可配置的功能。
然后逐步的在随后的Sprint中不断的锦上添花。

还有一种方式,可能会适合于互联网软件,就是控制用户数。
限制使用者或访问系统用户数。

无论如何都应该从风险最大的功能开始,避免后续发生风险后失控。


5
如何优化Scrum的效率?


我们都知道在时间管理的话题中有一项非常重要的工作是:时间记录。
也就是你要想省钱,那就必须先知道你钱都花哪里去了。

对于Scrum提升效率也是如此,你需要知道自己每类工作的花费,才能更好的提升效率。
有这样几类工作,大家可以尝试来进行观察和记录。

  • 功能工作:向用户交付商业价值的功能

  • 额外工作:企业服务或强制要求,比如审核或会议

  • Spike穿刺:研究类工作

  • 必要性工作:要达到完成标准需要做的工作


6
利用Scrum如何进行项目成本估算?


一般来说我们估算一个项目的成本有几种方式:人天、功能数。
而Scrum会提供给你一个更准确的评估方式。

  • 生成用户故事:列出带评估项目的所有用户故事。

  • 确定用户故事的优先级:按照优先级由高到低,逐一排列。

  • 估算用户故事的大小:主要是为了是确定速率。计算所有用户故事的总点数。以以往的速率计算需要多少人在规定时间内能完成。

  • 确定团队的成本:上一步得到的人数,乘以团队平均工资等成本。

  • 计算项目的成本

  • 承诺是否能做


7
Scrum后就不用写文档了吗?


有好多人说,我们是Scrum,我们不需要写文档,只有你们瀑布才会要写那么多文档。
对不起,我没听清。
谁告诉你Scrum可以不写文档的?
Scrum只是说,不写没用的文档。

也就是说,首先我们需要决定,项目需要什么什么文档以及什么时候做文档最有意义。
然后,按计划交付承诺的文档及及时汇报项目状态和白板照片。
并且,最好是投入自动化,部分文档可以通过自动化工具来生成。
比如我们以前写Online Help文档,后来就自动化转成操作手册进行交付。


8
外包与离岸开发要注意什么?


不管相距多远都要营造出一种氛围,让大家觉得是在同一个地方,工作的同一个团队。
以下几点要特别注意:

  • 选择合适的离岸团队:雇佣敏捷团队,并且时差小于三个小时

  • 以痛苦最小的方式分配工作:
    让团队按工作包交付
    让多个团队在同一代码机上工作
    把特定的开发功能外包,如,测试、UI

  • 坚持Scrum框架

  • 建立团队文化

  • 持续集成

  • 准备差旅

  • 配合一个项目或团队协调人

以下情况建议绝不考虑离岸:

  • 高度复杂技术高风险的第一个发布

  • 本地团队还在挣扎于开发实践如TDD等,或缺乏纪律

  • 公司没有成功必备的差旅预算和远程沟通技术的预算


9
大型列表如何进行优先级评定和估算?


像一般开发周期在3个月以上,涉及三类以上干系人的项目,其Story的数量和复杂度是非常可观的。
我们不可能逐一评判优先级,这个工作量太大了,需要协调的干洗人也会非常多。
这里有一个办法,可以快速的(一天内)完成Story列表的优先级评定和估算。
首先,你需要将所有的Story都准备好。
然后,让团队先大致将所有的Story按照大小排序:小的、中等的、大的、超大的。
这种排序是模糊的,不精确的。
接着组织所有干系人对同一区域内的Story进行优先级高低调整。
最后,Scrum Master一定要记录干系人讨论的内容及有争议的地方,以便后续进行进一步的跟踪。


10
你见过这样的合同吗?


一般来说,软件合同分成:固定总价合同和人天合同。
固定总价合同很好理解,就一笔钱,做多做少都这么多钱。
一般对需求比较明确的项目建议使用固定总价合同。
人天合同更多见于软件咨询类的合同。
顾问来多少天就给多少钱。
当然还有一些合同的变形,我这里就不展开讲了。

而Scrum给了我们另外一种合同的可能。
主要是两部分组成:调研合同和项目合同。
首先,签订的是调研合同。
由团队业务人员进行业务调研,并进行分析后给出Story清单和评估。
如果甲方觉得满意可以继续签项目合同,如果觉得不满意可以找别人来进行开发。
这个合同基本上会以“人天”合同为主。

接下来如果签“项目合同”,则是分Sprint签订、给钱。
如果甲方对这个Sprint的交付不满意,可以拒付。
也可以在几个Sprint后随时喊停。只需要提前通知即可。

但是我觉得要做到这点,真的是需要使用Scrum框架的每个实践,保证每次交付都是可用的软件。




小婧是一名行走在产品路上的资深业务分析师(BA),如果想与我同行,就请关注我吧!

你一定要知道的关于Scrum的30个问题(下)


「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论