Category: Scrum

避免稳定sprint的12个实际步骤

BY ERIC ISOM 沈义 · 沈潇灵 译 这一切都与质量有关。只有在产品不符合你的质量要求时才需要稳定sprint。 这些是你可以作为项目经理或Scrum主管采取的实际步骤。 其不要求你启动公司范围内自上而下的计划。你可以一次按照这些步骤操作,并查看每个步骤的改进情况。然后其他人会看到你的结果,并问你是如何做到的。 辨认出问题 你创造的质量很差,不得不重做。这就像一个糟糕的制造过程。你构建了一些东西,检查,发现它不符合要求,并重新设计它以满足要求,或者抛弃它。你编写代码,发现它不稳定,现在你正在用稳定sprint重新编写代码。 我们多年前在制造业中吸取了这一教训。不幸的是,我们必须以艰难的方式学习它。戴明和其他质量领导者教授了这些原则。日本人听取了他们的意见,并将他们的制造业变成了世界上最好的。多年之后,我们其他人才会注意到并开始倾听。 现在它在软件开发中再次发生。我们认为稳定sprint(返工)是必要的。我们过分依赖测试(检查)。 我们说,软件是不同的,错误也是不可避免的。无论如何,技术债务都会增长。而且,可以预期稳定sprint。这就像美国的制造行业多年前的借口:缺陷,库存,延迟以及返工是无法避免的。 能不能听到20世纪制造行业的回音? 我们不会问自己我们在编写代码的方式上需要改变什么。很难想象以任何其他方法。 当有人出现并开始向我们展示道路时,我们就会忽视他们。他们提出的建议太具有破坏性,成本太高,只是行不通。我们公司/行业不同。似曾相识。几十年来,人们同样忽略了戴明。  时间已经到了将我们在其他行业中学到的关于质量的艰苦教训应用到优质软件的开发中。 不要让系统不稳定 首先,即使是持怀疑态度的人也不得不承认你不必让生产系统变得不稳定。你有一个选择。 即使你的测试(检查)在发布之前没有发现稳定性问题,你应该在发现稳定性问题时立即回滚。 这个简单的建议引发了一场经典的辩论。 一方面,不成熟的组织认为修复损坏的系统是可行的(有时甚至是不可避免的)。它们允许生产系统在他们争抢和修补时被打破。 他们匆忙并认为最好尽可能快地修复它,而不是花时间回滚。他们觉得承认必须回滚太尴尬了。 另一方面,成熟的组织优先考虑客户服务和系统的稳定性。他们知道,即使需要等待更长时间才能获得这些新功能,客户也可以通过系统运行得到更好的服务。这是事件管理,你的首要任务是尽快让系统再次运行。 如果你的版本破坏了系统,最好要回滚到之前的版本。不要试图将其在现状中固定。并且不要只是忍受它直到下一个版本。你需要训练自己不要容忍不稳定系统的发布。 在接下来的步骤中,你将需要这个规则,使你达到一定的质量水平,以避免稳定sprint。 找到根本原因 回滚后,你自然会专注于查找和修复即时问题,以便可以重新发布。是的,这是返工。 但我们一步一步迈出这一步。如果你遇到稳定性问题,你必须首先扑灭火灾。 找到并解决问题,然后重新发布系统。 现在是重要的部分。从长远来看,要想拥有一个更稳定的系统,并在将来避免这些问题,你就不能止步于此。如果你这样做,他们会堆积起来直到你确实需要稳定sprint。 现在,你必须找到并解决问题的根本原因。允许编写,测试和发布此不稳定代码而没发现潜在问题的来源是什么呢?...

Scrum失败的两个主要原因

BY ERIC ISOM 沈义 · 沈潇灵 Scrum太常失败。为什么呢?主要有两个原因: 因为它的应用不正确 因为只有Scrum不够 Scrum适合每个项目 你认为我是反Scrum还是反敏捷? 我崇拜Scrum! 这是世界上最好的敏捷方法。  每个行业的每个项目都应该是一个Scrum项目。即使是固定价格,数百万美元的土木工程项目也应该作为Scrum项目运行。  我是不是太爱Srcum,对你来说? Scrum是一套简单但功能强大的原则和实践,可帮助团队在短周期内交付产品,实现快速反馈,持续改进和快速适应变化。 Scrum结盟  #1 :Scrum失败,因为它的应用不正确 许多人试图使用Scrum的一些部分,并且不了解潜在的敏捷和Scrum原则。 保持Scrum板的简单性 很多人都有Scrum板,但不明白其目的。他们通过构建团队详细的工作流程来使其过于复杂。如果没有专门的工具,就变得太复杂了。然后,你就失去了Scrum板的主要好处,即将是简单的方式传达给技术和非技术人员。 Scrum董事会需要成为任何利益相关者可以走过的东西,一目了然地看到正在发生的事情。 它不应该要求利益相关者学习复杂的工作流程,或者为不同的项目学习不同的列。Scrum板需要成为任何相关方可以一目了然地看到正在发生的事情。它不应该要求相关方学习复杂的工作流程,或者为不同的项目学习不同的列。 Scrum板应该只有3列:To Do,Doing和Done。 我知道,为了清晰起见,添加其他列是很诱人的,例如Testing / QA专栏。不要这样做。你是一个团队。在测试时将其保留在“执行”列中。更改分配给谁,但将其保留在“执行”列中。 发布专栏怎么样? 这属于发布计划,而不是Scrum板。让Scrum板专注于当前的Sprint。 如果每个sprint以发布结束,那么你不需要该列 – 或发布计划。如果每个sprint没有以发布结束,则使用发布计划。...

计划扑克的问题

BY ERIC ISOM 沈义 · 沈潇灵 译 计划扑克的麻烦是斐波那契数字系列。这是一个令人着迷的系列,有惊人的应用程序,但计划扑克不是其中之一。 在计算产品待办事项中的任务时以及进行sprint计划时,会使用计划扑克。 整个开发团队收集并使用基于Fibonacci数字系列的规划扑克牌。每个人通过选择具有他们认为最能代表相对努力程度的数字的卡来估计完成用户故事的努力。 每个人独立完成,然后每个人同时分享他们的估计值,以便他们的初始估计不受其他团队成员的影响。 然后,团队讨论异常值,经常发现问题 – 有时甚至是简化。 什么是斐波纳契数? 斐波纳契数是一系列数字,其中每个数字是它前面两个数字的总和。 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144,… 这一系列的数字已被采用和修改,用于计划扑克。 卡片组通常包括: 0, ½, 1,...

固定价格可以使用Scrum吗?可以!

固定价格项目可以使用Scrum吗? 当然可以!以下就是秘诀:   从固定价格的项目来开始。其有已经明确的范围、时限和预算。 组织范围为工作分解结构(WBS)的可交付成果与工作包,就像为瀑布式项目。  重组工作包为拥护故事。(每事项都要添加角色与原因)。 与客户合作,将工作包排序在未完工里,最高优先级项目位于顶部。 让团队估计积压中每个项目的工作量。 使用计划扑克,斐波那契数字,T恤尺码或您最喜欢的相对尺寸技术。 开始迭代,包括迭代规划会议、每日站会、迭代评审会/证明以及迭代回顾。 通过这方法你就会有使用Scrum所带来的效益,包括: 每迭代都交付价值 先完成最重要的事情 通过每日站会更好地协调 使用迭代评审会/证明更加提早识别问题 通过迭代回顾不断地提高产生里 需要变更呢? 假设你发现需要改变的东西呢? 使用Scrum,你会很快发现这种需求,这会让你有更多的选择和能力做出改变。 变更费用太高怎么办? 大多数固定价格合同都有一些变更请求和额外资金。照常,使用此合同条款。 预算固定了怎么办?在这种情况下,你可以让客户在新事项的待办事项中交换优先级较低的项目,以便整体预算保持不变。将项目工作分类为未完工,并先处理最高优先级事项,使你可以灵活地在项目期间进行这种交换。 在固定价格的项目中使用Scrum会增加你从瀑布式方法中不能获得的效益。 问题不在于你是否可以在固定价格项目中使用Scrum。 问题则是,“你为什么不会在固定价格项目中使用Scrum?”。附: 不相信我吗?没关系。有关Scrum如何成功应用于价值数百万美元的固定价格项目的示例,请阅读Jeff Sutherland的书:《Scrum: The Art of Doing Twice the Work in...