灵活的替代
“ Scrum”一词至少指两个实体：哲学和框架。
杰夫·萨瑟兰（Jeff Sutherland）在书中描述了这种工作哲学或工作方法。
框架，即 一种称为Scrum指南的文档中描述的动作算法。
哲学之所以成为一个框架，是因为哲学的作者想以此来赚钱（用自己的话说）。
与哲学相比，该框架大大简化了。 最主要的是目标已被简化，或者被抛弃了。
哲学的宗旨：加速成果的实现。 而且，有时。 书中有8倍加速示例。
该框架的目标是拥有Scrum。 它说的是：按照说明进行操作-您有Scrum，违反说明-您没有Scrum。
通常，该框架并不意味着加速实现结果。
教或实施Scrum的人会使用该框架。 他们讨论并实现了一种算法，除了“我们现在有了Scrum”之外，该算法不会导致任何其他结果。
重点很明确。 哲学很难推销。 该框架更简单。
框架是一种产品。 正如他所料，他通过了“包装”。 它简单易懂，有支持和许多专家。 看起来不一样吗？
一切都很好，除了结果-事实并非如此。
如果客户不熟悉Scrum理念，那么框架的实施将非常适合他。
如果客户熟悉Scrum的理念，那么他将对该框架的实施感到失望-不会加速获得结果。
它将很酷，时尚，现代，但不会实现任何业务目标（除了“新事物”预算的制定外）。
如何成为 了解Scrum的哲学。 它基于日本的质量管理理念，其本质是：测量和无止境的改进。
不幸的是，您必须在这里进行思考，实验，观察，并且很努力。 如果这不适合您，请使用框架。
habr.com/en/post/345540可变环境
为了提高程序员团队的效率，您需要一个可变的环境。 团队中已经存在某种环境-我们需要使其变得多变。
可变的环境是缺少正式的，经过批准的工作算法。
程序员喜欢从事算法工作，因为他们自己从事算法的创建。
可变环境是一种调试类型，不是程序算法在调试，而是团队的工作。
只是同意团队的观点，变革时代已经开始。 今天，有些规则，明天-不同。 不是因为the绳落在后面，而是因为团队需要调试。
调试是一种算法的启动，跟踪其操作并在出现预期或期望错误时进行调整。
大多数变更项目由于缺少可更改的环境而失败。 零散地进行更改很可怕，每天引入新规则也很可怕。 在不做任何更改的情况下，开发一个大型文档（其中规定了一切）并提供执行即可，这要简单得多。
粗略地讲，这是无需立即开始就立即编写程序代码的方法。 不，有时候可能会很有趣，但是在体面的任务上，这种方法不起作用-您必须太聪明。 在可变环境中进行调试要容易得多。
habr.com/en/post/345830Scrum大师
正确使用书中描述的干净的Scrum可以使团队的效率提高2倍。 这是经过实践检验的。
但是其他人的实践表明，根本没有加速发生。 因为本书中描述的方法已简化为出售。 是她使用过的-简化了。
Book Scrum涉及三个级别：
- 秀（“服从”）的状态是第一阶段，训练，重复，不背离规则。
- 状态Ha（“突破”）-我们开始更改规则，即兴创作；
- Ri（“独立”）的状态-我们摆脱了规则的束缚，开始建设。
通常，第一级是销售-指令，及其执行的执行。 要真正提高效率，您需要进入第二级和第三级。 用自己的头脑思考，寻找优化，实施和监控结果的方法。
Scrum主管应该处理加速问题-这是他的责任。 因此，它写在书中，我引用：Scrum管理员的主要关注点是带领团队不断进步，并定期寻找“我们如何才能更好地完成已经做好的事情？”这一问题的答案。
但这是第二和第三级。 第一个被出售和引入。
在第一级，Scrum主管的职责完全不同。 在Internet上检查，列表将如下所示：
喔喔
- 组织并举行集会；
- 监视对Scrum原则的遵守情况；
- 营造合作气氛；
- 解决冲突并保护团队。
一言不发关于提高效率。 只需按照说明进行操作即可。
如果您从逻辑上考虑，那么如果团队不断按照相同的规则工作，效率如何提高？ 要更改某些内容，您需要更改某些内容。 但是您不能执行此操作-根据说明，该操作是不允许的。 因此，第一级的效率不会提高。
Scrum主管应该是对提高效率感兴趣的人。 如果这项工作没有意思，则无法学习。 您必须进行很多思考，建立实验，检验假设，不断犯错并填补难题。
发布指令和监视其执行要容易得多。 好吧，有时候会方便（无论意味着什么）。
我试图让不同的人担任Scrum-master，但很少有人对此感兴趣。 这很正常。
如果您熟悉Belbin测试，则最适合使用Ideas Generator，Analyst和Diplomat（资源调查员）。
Scrum Master的角色与优化应用程序性能的程序员的角色非常相似。 只有在这里，这个系统才能在人们中生存。
habr.com/en/post/346158系统提交
大多数组织变更的结果：失败。
副产品：该技术是胡扯。
更改所依据的方法。 特别是Scrum。
原因很简单：系统性从属。
嗯，解决方案非常简单：系统提交。
不是系统的，而是系统的。 提交作为系统，作为原则。
在我们国家，由于我们国家已有数百年的历史，因此人们对邪教的服从程度越来越高。
系统性的不服从会导致奇怪的反馈：考虑到没有人遵守这些规则和法律，因此创建了新的规则和法律。
对于组织变革尤其如此。 他们的作者甚至没有考虑人们按照提议的规则工作的选择。 因此，它不会影响规则的可执行性和适当性。
但是，有一些成功实施更改的示例。 在十字路口拍摄相同的摄像机。
正式地，驾驶到交通拥堵排队的十字路口的惩罚早就存在。 但是实际上没有遵守该规则。
现在可以在单独的交叉点完美观察到它。 在安装了摄像机的摄像机上。
相机刚刚提供系统提交。 人们一开始遵守该规则，就很明显，该规则本身就是一个有效的规则。 曾经在一起的同一条规则被认为是一种废话。
另外，任何其他规则，更改，算法，技术或案例。 任何技术都是有用的。
如果您有不同的看法，如果您说“ Scrum不起作用”，“ TOS不起作用”或“精益是胡扯”，那么您就是个好人。 只是您没有实施此技术，因为您没有提供系统提交功能。 而他无法提供该信息的原因在于该方法的不可操作性。
提供系统提交非常简单。 您必须从自己开始。 这将是系统的自我提交。
向您的团队介绍Scrum？ 遵守所有声明的规则，没有例外。 每一天，没有通行证。
您将立即看到该方法的优缺点-这种方法以及其他任何方法。
如果成功，那你就是原因。 如果出现故障，则将是原因。
habr.com/en/post/346712