scrum_Scrum的性质

最新推荐文章于 2023-06-13 00:35:27 发布

weixin_26752759

最新推荐文章于 2023-06-13 00:35:27 发布

阅读量254

点赞数

文章标签： python java

原文链接：https://productcoalition.com/scrums-nature-tool-love-hate-6353c514d3f3

版权

scrum

TL; DR：Scrum的本质：它是一种工具；这与爱或恨无关 (TL; DR: Scrum’s Nature: It Is a Tool; It Is Not About Love or Hate)

Regularly, we find articles from developers detailing why ‘Agile’ in general and Scrum’s nature, in particular, deserve our collective disdain.

通常，我们会从开发人员那里找到文章，详细介绍为什么总体上讲“敏捷”，尤其是Scrum的本质，应该受到我们的集体鄙视。

What has always struck me in this discussion is the fact that Scrum is a tool useful to accomplish one primary task: delivering value to customers of emergent products in complex environments while mitigating an organization’s exposure to risk at the same time. So, if Scrum is not working in an organization, maybe it is because Scrum is applied to the wrong cause in the first place. Or, that its application has been mechanical, driven by folks who don’t know what they are doing. (Seriously, how hard can Scrum be if the manual comprises of 18 pages, right?)

在本次讨论中，令我印象最深的是，Scrum是完成一项主要任务的有用工具：在复杂环境中为新兴产品的客户创造价值，同时减轻组织面临的风险。因此，如果Scrum在组织中不起作用，那可能是因为Scrum首先被应用于错误的原因。或者，它的应用是机械的，由不知道自己在做什么的人驱动。 (严重的是，如果手册包含18页，Scrum会有多困难，对吗？)

The question then is: Why would I “hate” a tool unsuited for the intended purpose or applied incompetently? Would I hate a hammer for not being capable of accurately driving a screw into a wooden beam? Probably not, as the hammer wasn’t designed for that purpose, and neither sheer will-power nor stamping with your feet will change the fact.

那么问题是：为什么我会“讨厌”一种不适合预期目的或使用不当的工具？我会因为无法将螺丝准确地钉入木梁而讨厌锤子吗？可能不是因为锤子不是为此目的而设计的，而且纯粹的意志力或踩脚不会改变事实。

Do you want to get this article in your inbox? You can sign up here and join 26k other subscribers.

您是否要在收件箱中获得此文章？ 您可以 在这里注册并加入26k其他订户 。

📅 Join the 25th Hands-on Agile meetup on August 20, 2020, to explore the virtual Ecocycle Planning.

📅加入2020年8月20日举行的第25届动手敏捷聚会，探索虚拟的Ecocycle Planning 。

黑客新闻或DZone得分高 (Scoring Big on Hacker News or DZone)

Have you ever dreamt of scoring big, as an author, on Hacker News or DZone?

您是否曾梦想过在Hacker News或DZone上以作家的身份获得高分？

That’s simple; let me help you: Write something about how awful “Agile” and Scrum are. These rigid methodologies inevitably turn developers into mindless cogs in a corporate machinery — churning out more and more code — while ignoring the true potential of these knowledge workers. Then find a catchy headline like “Why I [Hate, Despise…] [Agile, Scrum, …],” and the response will be liking shooting fish in a barrel.

很简单；让我来帮助您：写一些有关“敏捷”和Scrum多么糟糕的东西。这些僵化的方法不可避免地将开发人员变成公司机构中毫无头脑的齿轮-编写越来越多的代码-而忽略了这些知识工作者的真正潜力。然后找到一个吸引人的标题，例如“为什么我[讨厌，鄙视...] [敏捷，Scrum，...]”，这样的响应就像是在桶中射鱼。

In a recent article on Scrum’s nature, the author describes his experience with “Scrum” in detail. Let’s have a look at some of the author’s issues:

在有关Scrum性质的最新文章中，作者详细描述了他对“ Scrum”的体验。让我们看一下作者的一些问题：

Definition of Done: “I entirely agree that every task should have a definition of done. But the definition should be task related […] Figuring out ‘Done’ is also difficult because the client may not have a good idea of what done looks like.” The Definition of Done in Scrum serves a higher purpose than merely checking off tasks as in quality control. The Definition of Done is the quality standard that applies to all Product Increments. It is well-understood by everyone who is inspecting Product Increments, thus providing the basis for empiricism to work. It comprises of everything necessary to ship the Product Increment to our customers, including but not limited to engineering standards, governance, and legal requirements. Considering these attributes, no one expects the customers to have a complete understanding of what ‘Done’ means. That is why we pay the Development Team to accept the responsibility to deliver a ‘done’ Product Increment.
完成的定义 ：“我完全同意，每个任务都应该有完成的定义。但是定义应该与任务相关[…]找出“完成”也很困难，因为客户可能对所完成的工作不太了解。” Scrum中的“完成定义”具有更高的目的，而不仅仅是在质量控制中检查任务。完成的定义是适用于所有产品增量的质量标准。检查产品增量的每个人都很好地理解了这一点，从而为经验主义的工作提供了基础。它包括将产品增量交付给客户所需的一切，包括但不限于工程标准，管理和法律要求。考虑到这些属性，没有人期望客户对“完成”的含义有完整的了解。因此，我们付钱给开发团队来承担交付“完成的”产品增量的责任。
Timeboxing and delivery: “When things are done, they are done. And you should be able to ship with the done feature at any time. Waiting for the end of a sprint and a sprint review means waiting to ship a done project.” The statement is plain wrong. The decision of whether to ship a Product Increment is the prerogative of the Product Owner. An Increment might be shipped at the end of the Sprint, or its shipment is delayed. Or the Development Team is continuously delivering Increments during the Sprint. At no point is the delivery of a Product Increment depending on the Sprint Review as this event is not a Stage-Gate®-like approval instance.
定时装箱和交付 ：“当事情完成时，它们就完成了。而且您应该可以随时随便附带完成功能。等待冲刺结束和冲刺审查意味着等待运送完成的项目。” 该声明是完全错误的。是否交付产品增量的决定是产品所有者的特权。增量可能会在Sprint结束时寄出，或者会延迟寄出。或者开发团队在Sprint期间不断交付增量。绝对不会根据Sprint审核来交付产品增量，因为此事件不是类似于Stage-Gate®的批准实例。
Scrum Master: “What the Scrum Master really is is the project manager stripped of the ability to manage the project. […] But there are times when something needs to be done and a project manager can make the changes and get it done.” Scrum relies on self-organizing and cross-functional teams that decide on how to create valuable Product Increments. The job of the Scrum Master is hence to support the Scrum team by removing impediments — problems the team members cannot solve by themselves-thus supporting this decentralized leadership approach. Moreover, those impediments are mostly situated at an organizational level. Here, change is not happening by simply “getting things done,” but by working with other stakeholders and their plans, agendas, objectives, etc. This need is also the reason that being a Scrum Master is a full-time job. Scrum Masters are not getting paid to facilitate a few Scrum events, order stickies, and book meeting rooms. Their primary role is that of an organizational change agent.
Scrum Master ：“ Scrum Master真正是使项目经理失去了管理项目的能力。 […]但是有时候，有些事情需要做，项目经理可以进行更改并将其完成。” Scrum依靠自组织和跨职能的团队来决定如何创建有价值的产品增量。因此，Scrum Master的工作是通过消除障碍(团队成员无法自行解决的问题)来支持Scrum团队，从而支持这种分散式领导方法。此外，这些障碍大部分位于组织级别。在这里，改变不是通过简单地“完成工作”而发生的，而是通过与其他利益相关者及其计划，议程，目标等一起工作来实现的。这也是成为Scrum Master成为全职工作的原因。 Scrum Master并没有获得酬劳来促进一些Scrum活动，订购便笺和预定会议室。他们的主要角色是组织变革推动者。
Scrum events: “While I like the basic concepts, I don’t like the huge time sync associated with these events. I don’t like meetings and I like non-productive meeting even less.” If you don’t know where you are going — we are working on an emergent product — , any road will get you there. Hence it probably makes sense to regularly allocate some time to figure out whether we are heading in the right direction. All events are time-boxed to reduce the risk of wasting everyone’s time without creating value for our customers. No one expects that your events will be effective, starting with Sprint 1. It will take some time to get them right. Fortunately, we also have a formal event to support the team’s strive for continuous improvement, which also means that we do not have to wait for the Sprint Retrospective to start changing things for the better. Just do it.
Scrum事件 ：“虽然我喜欢基本概念，但我不喜欢与这些事件相关的大量时间同步。我不喜欢开会，甚至更不喜欢非生产性会议。” 如果您不知道要去哪里(我们正在开发一种新兴产品)，那么任何一条路都将带您到达那里。因此，定期分配一些时间来确定我们是否朝着正确的方向前进可能是有意义的。所有活动都有时间限制，以减少浪费每个人的时间而不为我们的客户创造价值的风险。从Sprint 1开始，没有人期望您的活动会奏效。幸运的是，我们还举行了一次正式活动来支持团队为不断改进而做出的努力，这也意味着我们不必等待Sprint回顾展开始使事情变得更好。去做就对了。
Team: “I believe in individual effort and that individuals should get credit for their efforts. […] I also reject the concept that every team member should have an equal vote on everything.” Spoiler alert: Scrum is not for everyone; heroes and rockstars — self-proclaimed or otherwise — will be probably disappointed. Scrum stresses the importance of ‘true’ teams, as the team needs to assume responsibility for creating a valuable Product Increment with the regularity of a Swiss clockwork. A diversity of experience, background, and opinion will support the required self-organization and deliver superior results in that respect. Finally, remember the adage: If you reward firefighters, you create a culture of arsonists. Guess, where toxic engineering department cultures come from?
团队：“我相信个人的努力，个人应该因自己的努力而获得荣誉。 […]我也反对这样的概念，即每个团队成员都应该对所有事情进行平等投票。” 剧透警报：Scrum并不适合所有人；英雄和摇滚明星，无论自称还是其他，都可能会失望。 Scrum强调了“真正”团队的重要性，因为团队需要承担起以瑞士发条的规律性创造有价值的产品增量的责任。丰富的经验，背景和意见将支持所需的自我组织，并在这方面取得卓越的成果。最后，记住一句谚语：如果奖励消防员，您会创造纵火犯的文化。猜猜，有毒工程部门的文化来自哪里？
Scrum is Not a Team Player: “In the Scaled Agile Framework (SAFe), you get to the time boxed scrum teams by having an ‘Architectural Runway’ filled with ‘enablers.’ Scrum is Scrum; SAFe® is SAFe®. Please, do not confuse the two as Scrum does not have anything to do with SAFe®. As far as a successful collaboration between several Scrum teams is concerned, both NEXUS and LeSS offer the appropriate framework extensions to the Scrum Guide. Of course, it is possible to create new products with more than one Scrum team working on them, unless you remove critical collaboration and self-organization components. As Ron Jeffries so eloquently put it: “We Tried Baseball and It Didn’t Work.”
Scrum不是团队合作者：“在可伸缩敏捷框架(SAFe)中，通过将'enabler'填充到'Architectural Runway'中，您可以进入时间限制的Scrum团队。 Scrum是Scrum； SAFe®是SAFe®。请不要混淆两者，因为Scrum与SAFe®没有任何关系。就几个Scrum团队之间的成功合作而言，NEXUS和LeSS都为Scrum指南提供了适当的框架扩展。当然，除非删除关键的协作和自组织组件，否则可以由多个Scrum团队来开发新产品。正如罗恩·杰弗里斯(Ron Jeffries)雄辩地说：“ 我们试过棒球，但没有成功。 ”
User Stories: “I’m not even going there. Here is a smattering of why user stories aren’t the be-all and end-all.” If nothing helps, read the manual. Please point me to where the Scrum Guide is mentioning User Stories. If you like to apply them, and it works out, good for you. However, there are other ways of dealing with Product Backlog items, for example, job stories. Employ whatever helps your ProductBacklog become actionable to create value for the customers.
用户故事 ：“我什至不去那里。这是为什么用户故事并非一无是处的一切。” 如果没有帮助，请阅读手册。请指出Scrum指南提到用户故事的地方。如果您想应用它们，并且效果很好，那么对您有好处。但是，还有其他处理Product Backlog项目的方法，例如，工作故事。采取任何有助于您的ProductBacklog变为可操作的方式来为客户创造价值的方法。
Working Software: “Scrum is based around dropping working software every two weeks. […] But the real problem I have with the working software model is that it gives short-shrift to planning and documentation. […] o you have two weeks to do planning then you can forget about that drudgery. And after that two weeks, don’t plan or document, just code, code, code.” The author argues that Scrum’s focus on working software leads to poor design decisions, inferior code quality, and a lack of documentation. In my experience, this only happens in environments with poor engineering standards and probably would happen anyway regardless of the development framework employed. Scrum’s success depends on strong engineering culture and teams that strive for craftsmanship, which is the reason that Scrum and Extreme Programming, for example, work together so well. When TDD, refactoring, and emergent architecture meet a continuous Product Backlog refinement process, none of the issues mentioned before will materialize.
工作软件 ：“ Scrum的基础是每两周发布一次工作软件。 […]但是，我在使用的软件模型中真正遇到的问题是，它使计划和文档编制工作变得步履蹒跚。 […] o您有两个星期要做计划，那么您就可以省去那些繁琐的工作。在那两个星期之后，不要计划或记录文档，而只是编写代码，编写代码，编写代码。” 作者认为，Scrum对工作软件的关注导致了糟糕的设计决策，劣质的代码质量以及缺乏文档。以我的经验，这只会在工程标准较差的环境中发生，并且无论采用何种开发框架，都可能会发生。 Scrum的成功取决于强大的工程文化和追求Craft.io的团队，这就是例如Scrum和Extreme Programming如此出色地合作的原因。当TDD，重构和紧急体系结构满足产品Backlog持续改进的过程时，前面提到的所有问题都不会实现。

免费下载“ Scrum反模式指南”

Scrum的性质：它是一种工具—结论 (Scrum’s Nature: It Is a Tool — Conclusion)

Agile software development is not about solving (code) puzzles all day long. As a part of creating new products in complex environments, it is first-of-all about identifying which problems are worth solving from a customer perspective. Once that is established, and Scrum’s empirical approach has proven to be supportive in that respect, we strive to solve these puzzles with as little code as possible. As the Manifesto of Agile Software Development puts it clearly: “Simplicity — the art of maximizing the amount of work not done — is essential.”

敏捷软件开发并不是一整天都在解决(代码)难题。作为在复杂环境中创建新产品的一部分，首先要从客户的角度确定哪些问题值得解决。一旦确定了这一点，并且事实证明Scrum的经验方法在这方面是有帮助的，我们将努力以尽可能少的代码来解决这些难题。正如敏捷软件开发宣言中明确指出的那样：“ 简单-最大化未完成工作量的艺术-是必不可少的。”

To better understand Scrum’s nature, let me rephrase Churchill’s quote on democracy: ‘Many forms of Government software development have been tried, and will be tried in this world of sin and woe. No one pretends that democracy Scrum is perfect or all-wise. Indeed it has been said that democracy Scrum is the worst form of Government software development except for all those other forms that have been tried from time to time.’

为了更好地理解Scrum的本质，让我重新解释丘吉尔关于民主的名言：“许多形式的政府软件开发都已经过尝试，并且将在这个充满祸患的世界中受到尝试。没有人假装民主Scrum是完美的或明智的。确实，有人说民主Scrum是政府软件开发中最糟糕的形式，除了不时尝试的所有其他形式。

What is your experience with Scrum’s nature? Please share it with us in the comments.

您对Scrum的天性有何经验？请在评论中与我们分享。

🎓您想阅读更多类似的文章吗？ (🎓 Do You Want to Read more like this?)

Well, then:

好吧：

📰 Join 26,781 peers and sign-up for my weekly newsletter
📰 加入26,781个同龄人并 注册我的每周时事通讯
🐦 Follow me on Twitter and subscribe to my blog Age of Product
on 在 Twitter上 关注我 并订阅我的博客 产品时代
💬 Alternatively, join 7,850-plus peers of the Slack team “Hands-on Agile” for free.
💬 或者，免费加入Slack团队“动手敏捷”的 7850 多名同行。