文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

Image title

当大多数人想到敏捷时,他们会想到“Scrum”。Scrum是运用广泛,可以说是被滥用的敏捷框架。Scrum在概念上很简单,但要实际运用好却很难。这边叙述了10个常见的Scrum错误以及怎么避免他们:

1. 其他转化成Agile和Scrum很容易

通常一个人拿起一本关于敏捷或者Scrum的书,开始把需求变成用户故事,开始每天的站会,在两到三个Sprint里开发软件,然后他们自称敏捷。很容易,是吗?他们可能在一段时间里会看到应对软件改变能力的改善,但这不会持续太长时间。当敏捷的变化不是那么明显,团队很难跟上进度,软件总是不能匹配用户期望,这时候敏捷被认为失败了。敏捷改变需要花费时间,并且总是在一开始的时候很糟糕。真正的转变暴露现有的企业文化问题,如缺乏沟通、问责、不信任等,这些问题必须要解决。有效的敏捷转变往往是企业文化的变化。需要给予时间,准备经历变化的痛苦以及文化改变的阻力。

第 1 段(可获 2.64 积分)

2. 不按准则实践

做那些容易的事情比如开展Scrum会议,选用合适的Scrum工具是好,但这只是一班。敏捷的准则使得能很好的开展实践,并且从长远来看保持可持续。准则比实践更难,这就是为什么许多企业缺乏的,他们不按准则实践。用敏捷的技术,却没有思考为什么要这样使用他们会导致挫折。敏捷是与人、相互作用、文化相关的,而不是流程、实践、工具。

第 2 段(可获 1.25 积分)

3. 将敏捷/Scrum开始复杂化

做任何你可以做的使得敏捷开始简单化。敏捷项目没有最新最酷的协助或生命周期工具也可以成功。墙上的标记物,表格中写的任务以及手动生产的燃尽图将标志工作完成了。花费宝贵的时间获取并运行工具,而不是让开发人员聚在一块工作是敏捷错误的关注点。敏捷宣言认为个人和相互作用比起流程和工具有更高的价值。

第 3 段(可获 1.04 积分)

4. 像项目经理一样带领Scrum团队

"命令和控制“的心态存在于敏捷框架中。领导分配任务并估算时间是反敏捷模式的。优秀的敏捷团队是自我组织的,Scrum Master是一服务型的领导,团队成员通过定期检查和相互适应能更好的工作在一起,并更有效率的提交成果。通常来说,通过经验(好的坏的)比被告知怎么做会更有效的获取经验教训。需要允许Scrum团队自己做出判断,犯错误,从自身获得学习,获得成为高效团队的自我满足感。Scrum Master和敏捷教练给团队的指引超过了他们的驱动力。

第 4 段(可获 1.54 积分)

5. 一份没有准备的产品待办事项

一份没有准备的产品待办事项是导致sprint失败和团队无动力的最常见原因之一。这也是低效率以及无高产出的根本原因。大多数产品负责人靠自己是没有成效的。他们需要指导,培训以及在开始几个Sprint的时候手把手的指导,直到他们学会开发维护产品待办事项,能以宏观水平评估有足够价值的功能,并以商业价值将这些功能优先排序。在下一个Sprint开始之前,准备好待办事项是必须的工作。你不会希望团队做无关紧要的工作,团队的工作必须在那个时间点上是有最高价值的(由产品负责人评判)。要成为团队负责人是很费时的。设置正确的期望,提供所有的培训,帮助产品负责人保持价值流通。

第 5 段(可获 2.01 积分)

6. 通过ScrumMaster进行交流

在新成立的Scrum团队中我经常看到的一件事情是,开发人员通过Scrum Master向其他成员传递信息。举个例子,一个开发人员对于软件需求有疑问,他不直接去问产品负责人,而是给Scrum Master发邮件来获得信息。一条核心的敏捷准则是在任何可能的时候,面对面的进行沟通。写邮件花费的时间可以从产品利益相关者中直接得到所有问题的答案。然而,对于很多技术人员来说,面对面的交流是一件可怕的事情。他们习惯于坐在自己的格子间,不和任何人交流。这是程序员文化问题或者是个人特质问题,必须要克服。因为这浪费了时间,更重要的是这增加了沟通不畅的风险性。

第 6 段(可获 1.73 积分)

7. 产品负责人没有融入团队

产品负责人这个角色是非常耗费时间的。许多新手产品负责人对所要承担的责任还没有准备好,或者他们不知道要包含在团队中。在敏捷的世界里,合作是至关重要的。业务人员和开发人员需要共同工作生产出业务人员期望的软件。他们通过不断的沟通,合作,短小的反馈周期来验证或修复。我所期望看到的敏捷实践是,产品负责人参与每天的敏捷项目活动,敏捷回顾会议纯碎是形式。因为他已经在整个sprint中看到几轮迭代的功能,并且已经引导整个团队开发业务人员所期望的软件。这是一件非常美妙的事情。

第 7 段(可获 1.76 积分)

8. 每日站会松懈化

每日的站会从以下几个方面来说非常重要。会议使得开发团队人员每天要面对面15分钟,促使交流合作,提供了项目的可视化和透明图。对于如此关键的会议来说,在此之前要设定正确的期望值,这样团队成员会认真对待。这可能听起来很激进,但是每日站会的出席是必须的。准时开始,准时结束。坚持三个问题(昨天我完成了项目的哪些任务,今天我会做什么任务,有什么阻碍了我准时完成工作)。不允许其他交谈、讨论或者在站会上解决问题。这些都可以在站会结束后再进行。这使得团队成员尊重团队各成员的时间,通过坚持会议目标以及语言简洁化,他们能学会更好的沟通。

第 8 段(可获 1.95 积分)

9. 没有尽早提出遇到的问题

每日站会提供了一个机会,可以交流工作中遇到的阻碍,以保证我们的工作得以完成。Scrum Master主要功能之一是清除障碍,使得团队人员能将注意力集中在开发软件,但如果不提出所遇到的问题, Scrum Master不能帮助解决它们。太晚提出以至不能恢复是不可接受的。除非团队成员已经习惯于及时交流阻碍,否则Scrum Master需要在站会一开始就提醒成员提出遇到的阻碍,甚至是潜在的阻碍。如果不这样的话,有可能会阻碍他们的工作或者导致他们没有赶上sprint的任务。

第 9 段(可获 1.54 积分)

10. 在每个Sprint后没有开展回顾性会议

敏捷宣言的十二条准则之一是“在固定的时间间隔,团队成员需要反省怎样变得更有效率,然后相应的调整其行为。” 不幸的是,Sprint回顾会议总是被认为是附加品或奢侈品,只在有足够时间的时候才开展。事实上,敏捷随处都关于调整以及应对改变。如果我们不停下来想想哪些需要调整,我们很难做出好的改变。维持现状不是敏捷,持续的改善才是敏捷。

第 10 段(可获 1.3 积分)

文章评论