0°

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


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



1

敏捷Scrum如何开始?



为了成功实施Scrum,团队必须坚持Scrum的基本要素。

  • 团队必须理解Scrum的规则

  • 团队成员必须学习Scrum的基本机制

  • 给予足够的时间

  • 不要在项目中途实施Scrum

  • 保证为持续学习分配时间

要知道Scrum是一个框架,提供的是一整套规则,而不是一个指南。
小婧以前觉得我可以把Scrum中的一部分拿来实施,其他的比如结对编程、重构等不纳入也就不纳入了。
近些年发现自己错了。
因为Scrum框架的各个部分是相互支撑的,如果你进行裁剪,不是倒塌就是变成了另外一个东西,不是Scrum了。
所以在实施Scrum的时候一定要先明确和学习Scrum的规则和机制。


2

如何自下而上实施?


  • 取得大家的支持

  • 耐心:让其他人领悟你已经理解的东西,找到其他人的动机

  • 提供信息


大部分的Scrum都是自下而上实施的,也就是领导没有特别强硬的推行,而是团队内部觉得这种框架很合适,于是在自己团队内做尝试。
这个时候你就要特别注意,一定要及时的向外部,特别是领导层汇报项目的进展情况,使得信息透明。



3

资源冲突如何解决?



有的公司项目多,人力不足,特别是资深的经验丰富的人比较缺乏。
当一个项目出现问题时,大家都想要协调多的资源,特别是那种能够以一敌三的。
但是资源毕竟是有限的。
搞到最后就像是救火一般,哪里紧急就把资源派到哪里。
这样不仅打乱了项目团队的节奏(团队不稳定),而且也让这些资源疲于应对。
针对这样的情况,Scrum提议使用团队顾问。
也就是让员工自愿是否愿意作为顾问,服务所有团队。


这样的解决方案在实施时要特别注意:

  • 依赖于管理层的支持

  • 长时间在小范围内做尝试

  • 选择核心团队,并决定需要哪些专家

  • 小心团队顾问过度承诺

  • 计划可能的空闲时间

  • 顾问团队不应该替代专职团队,应该是一个核心的团队,辅以顾问团队。



4

如何确定团队的速率?


确定团队的速率一般有三种方法:历史数据、走着瞧、猜测。

  • 对于组建的团队,熟悉的技术:优先选择历史数据,其次选择走着瞧,最后选择猜测

  • 对于已组建的团队,不熟悉的技术:优先选择走着瞧,其次选择历史数据,最后选择猜测

  • 对于新成立的团队,熟悉的技术;以及新成立的团队,不熟悉的技术:优先选择猜测,其次选择历史数据,最后选择走着瞧。其中历史数据可以,依赖于其他团队的历史数据。




5

Scrum的三大角色如何平衡?


Scrum的三大角色,包括关于Scrum Master,Product Owner以及团队成员。
很多公司会让一人身兼两职,甚至三职。
相较于让一个团队成员身兼数职,有一个专职的Scrum Master要好很多。
这样可以更好的保持三个角色所固有的检查与平衡。


虽然有人不赞成Scrum轮值,认为不够专注,但是我尝试过。
我个人觉得轮值可以提升团队成员的责任心。



6

如何确定Spring长度?


一般建议是1~4周。而长还是短是与项目、团队等多种因素决定的,各有利弊。
短周期的Sprint能使你更快地发现潜在的风险。
但其代价是团队得花更多的时间与客户互动,受到的干扰也更多一些。
可以尝试一周的sprint强制用户故事更小,让团队有更多机会来反映和纠正问题。


长周期的Spring,意味着需要更长的时间才能发现风险,但好处是互动干扰会少一些。



7

Sprint完成的标准?



制定并发布一个DoD。
这里面包括团队一致同意的内容清单。
比如:所有的Story都已经接受;对应的帮助文档已经更新……


这样一份DoD:

  • 有助于团队成员建立密切联系

  • 为项目干系人提供清楚的交流方式,间接降低了把技术债务推迟到项目后期的风险

  • 使团队保持正确的方向,保持专注



8

Scrum Master到底做什么?


Scrum Master主要职责有:

  • 消除障碍,解决问题

  • 结束争论当团队的保姆

  • 报告团队的行为表现

  • 引导并在必要时提供帮助

  • 教育组织并驱动组织变革


也许这也是为什么大部分人都建议Scrum Master要专职的原因吧。

别以为Scrum Master看着很轻松,其实一点儿也不。
要不你试试看?



9

真正的Scrum应该包含的实践有哪些?


我觉得如果下面这几点缺少了一个,就不能称之为Scrum了。

  • 测试驱动开发TDD
    首先写一个新的单元测试用例,但不写通过这个测试所需的代码;
    然后写新的代码,使之刚好能够通过这个用例;
    最后重构:重构在不改变,而是在已有意图和行为的情况下加强或改善其设计。外部行为保持不变,内部行为更流畅

  • 持续集成:团队成员频繁地集成他们的工作,通常每个人每天至少集成一次,这样每天就有多次机场。每次集成都通过一个自动化构建,包括测试来尽快检测错误。团队可在任何时间构建发布。

  • 结对编程:一人驾驶一人导航,一起工作,共同完成一个任务。

  • 自动化集成与验收测试:集成测试是用来测试系统中各种集成点,验收测试用来模拟用户行为的测试





10

团队成员工作时间不一致,如何处理?


现在很多公司为了提倡人性化,对于员工上班时间不做强制规定,也就是所谓的弹性制。
只要你每天工作满8个小时即可。
而这样对于Scrum却是个挑战。
如果团队没有办法保证一定的时间在一起办公,如何进行结对编程?如何开站会?如何进行有效沟通?
所以我们需要确保团队核心时间。
核心时间就是大家对各自喜欢的工作时间和工作习惯所取得的共识。
比如有的人喜欢一大早7点到公司,下午4点左右就下班回家。而有的人喜欢快到中午11点才来上班,然后工作到晚上7、8点回家。这个时候的核心时间就是除去午休时间的共同时间。
在每个项目开始的时候,以及整个项目过程中需要的时候确定核心时间。
鼓励团队保持一定的灵活性。



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


写在最后:

今天先就这10个问题进行说明哦,希望对大家了解和学习Scrum提供一些参考。


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

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





「点点赞赏,手留余香」

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