我们的世界很奇怪。 而且你走的越远，它变得越奇怪。 然后您会明白什么。
世界上有工程师和程序员。 有时所有的东西都合而为一。 了解算法是什么的人。 而且，创建这些算法的人。 他们很清楚所创建的算法适合解决一个问题，但不适用于另一个问题。 理解如果算法稍有改变，那么它将能够解决相关问题。 不要犹豫，扔掉别人算法的一半，以便更好地解决当前问题。
程序员为任务或一类任务创建解决方案。 这是专业的本质。 尽可能使用自己或他人代码的现成片段。 一切都很好。
但是，一旦涉及到在计算机外部创建算法，程序员就会突然失去头脑。 我并不是说要像在大学考试中那样在纸上绘制算法图，在这里我们每个人都可以处理。
我说的是“技术的实现”，“框架上的工作”，“强制使用所有工件”。 简而言之，关于宗派。
有点白痴
每个人都知道什么是条件运算符。 没有他，没有生命。 没有体面的算法会起作用。 既不在计算机中，也不在生活中。
现在想象：某个人出现了，例如John，并且注意到BASIC中有一个条件语句。 我拿起它，弄清楚了，确定了-是的，它没有任何作用。
假设约翰很笨。 但是他决定征服世界。 去出售BASIC。 不是语言本身，而是某种“最酷的软件开发技术”，其核心链接是……在完成课程之前，John不会说。
好的，当然有课程爱好者，特别是因为价格不高。 他们来了，听了，喘着粗气。 最酷的软件开发方法的主要元素是条件运算符。 我们听了很多关于条件语句的信息。 例如，如何将其变成多选运算符。 他们再次喘着粗气-多么强大的条件运算符。
一半的观众是程序员。 嘶哑，回家了。 另外四分之一是经理。 他们变得深思熟虑，提出了疑问，有人决定在家中实施这种炫酷的技术。 最后一个季度与约翰相同。 他们说服了这家伙创建了一家专营店，社区，证书颁发机构和特遣队大学。
该课程的程序员重新开始工作，不再想起条件运算符。 但是一个小时后，经理们来了，宣布现在将按照最酷的方法进行软件开发。 是的，这与条件运算符有关。 一般来说，最好用基本的语言编写。
程序员的胆怯甚至胆怯的反对都被忽略了。 诸如“该死的是条件运算符，它无处不在”之类的短语被认为是试图炫耀的尝试。 车轮旋转了。
John很快意识到，仅一个条件运算符是不够的。 还应该有一个循环，子例程，变量，数组等。 我们应该以某种方式称呼所有这些……总而言之……噢，让它成为神器！ 不多不少！
最主要的是：在方法论中增加一个条款，即最酷的软件开发方法论是整体的，整体的知识。 因此，不能将任何一块扔掉。 而且您无法添加任何内容-它会停止工作。 正如它写的那样。
多亏了约翰和他的朋友们的热情，根据清单，现在全世界使用的不是条件运算符，而是条件运算符，不是循环，而是循环等。 那些了解情况愚蠢的人早已退休或闭嘴。 最近来的人坚信，条件运算符是John创建的最酷的软件开发技术的一部分。 所有其他条件运算符都是令人痛苦的外表，褪色的副本和一片从上下文中撕裂的知识。
任何敢于在Internet上投票的人（或者，天哪，在团队内部），都将受到激烈的谴责和愤怒的侮辱-您，靴子，看不到有条件运营商的好处！ 如果不幸的人要求解释与C ++，javascript甚至1C中的条件运算符的含义和区别是什么，他将得到“无法解释”，“您听不懂”或“阅读指南”的答案。
工具和算法
每个人都知道什么是条件运算符，以及如何在算法中使用它。 同样，每个人都可以理解，例如，带有已记录任务的标签。 贴纸出现在scrum之前，并居住在scrum之外。 查看会计，供应商或卖方的计算机。 他们还没有消除在监视器上悬挂一堆带有紧急任务的贴纸的习惯。 密码将写在其中一张贴纸上。
任何技术都可以轻松分解为工具，原理和关系。 就像将任何算法分解成不同形式和用途的图形一样-算法的开始和结束，动作，条件，子例程。
任何技术都有范围。 并非所有事物都绝对存在-有更合适的环境，更少。 与算法相同。
任何技术都可以修改。 扔掉零件，添加新零件，修改特定工具。 就像算法一样。
任何技术都可以整体或分段混合。 占一半，一个占另一个的四分之一，另一个占四分之一-自己发明。 创建应用程序或服务时，这对您来说很明显。
没错，问题仍然存在-如果方法改变了，该方法会成为方法吗？
以下是回答此问题的方法，例如著名的Scrum指南：
“ Scrum的角色，工件，规则和事件不会更改。 尽管可以使用此框架的各个元素，但结果不能称为Scrum。 Scrum仅作为一个整体框架存在，但可以容纳其他技术，方法和实践。”
有点像约翰和他的条件运算符，不是吗？ 看起来，如果您愿意的话就改变，只是不会混乱。 结果将是-地狱知道。 为了以防万一，他们指出您可以尝试在里面塞一些东西。 但是主干必须保留。 否则...甚至令人难以置信。
真的很恐怖吗？ 如果将某些工件扔掉或更换，将会发生什么？ 而且，有什么意义呢？ 他们来自哪里？ 为什么会像作者所决定的那样相信它们只能以这样的组合工作？
让我们尝试找出零件。
冲刺和冲刺积压
顺便说一句，很棒的工具。 大概在一千年前发明的。 人们总是以不同的方式来称呼它，但最常见的可能是“计划”。 而人类-“在一定时期内要做一定数量的工作”。
对我来说，作为1Sniku，它被称为空间日历计划（OKP）。 它广泛用于生产和销售计划。 例如，经理每月的销售计划是一百万卢布，这是积压和冲刺。 有时一个数字就足够了，有时会按产品组进行细分，或者对市场进行限制，或者如果公司的策略要求，甚至还会有特定的项目清单。
生产更加容易。 衬套-1000个，轴-2000个，转子-500个 举例来说，这是每周计划。 他是生产站点每周冲刺的积压。 没错，工人不能解释这不是计划，而是冲刺。
与广泛的时间管理相比，该工具是不错的选择，当时程序员的任务池是根据人工成本估算的，并按某种标准排序，并且每个任务都有最后期限。 在生产中，这称为轮班计划或车间计划，然后从中创建生产任务，其中包含零件和半成品，技术操作，材料，投入和产出的列表（从何处获取和在何处传递结果）。
对于程序员来说，车间计划不能很好地进行，这里没有什么要讨论的。 在特定机器模型上的零件的处理时间已经很长时间并且非常准确了。 服务频率-也是。 材料评估的充分性。 采取行动。 干扰批量生产计划实施的变化通常不会产生重大影响。 如果这样做的话，有很好的方法来分析和消除它们。
程序员的变化更加强大。 他不是机床，因为一些从销售或生产部门进入IT部门的经理不希望这样做。 因此，车间计划（任务+期限）不适合程序员。 所以明智的人想出了-您需要提升到一个更高的水平，而不是在几分钟内安排表演，而是在一段时间内增加音量。 只有他们想出了另一个名字-sprint和积压。
填写日历生产计划是基于类似于冲刺积压的形成原理。 甚至有这样的事情-“选择计划”。 有同一个销售部门的需求（=大量积压），有生产量（=数量的团队能力），还有明确的选择标准-销售量，每个职位的获利能力，客户参数（例如付款条件）。 为生产计划打分-立即查看您获得的大致财务结果。 这不是短暂的“发布”。
这个工具有什么缺点吗？ 当然，像其他任何东西一样。
如果您了解，冲刺积压工作是相同的车间计划，只是没有井井有条的问题解决顺序。 因此，所有任务都有一个截止日期-冲刺结束。 一旦任务有一个截止日期，就会出现不愉快的效果-在冲刺开始时，活动可能比结束时显着减少。
这就是任何人类心理学的工作方式。 无论是一项任务还是积压的订单，您总是想在执行期开始时徘徊。 特别是在需要给出“巨大”结果的最后一刻，请从过去的时间稍作休息。 当然，有些人稳定而有节奏，整个星期都以相同的速度工作，但是大多数人在星期三某个地方开始“正常工作”。
是否可以在没有sprint及其积压的情况下进行？ 很简单
例如，“尽快”应用该工具。 通常，这不是Praporsky的举止，而是同一车间计划的一种正常策略（尽快，尽快）。 这意味着问题将“停留”在时间间隔的开始，即 在星期一而不是星期五之前，采取“尽可能最后，ALAP”策略。
在这种情况下，无需进行此类规划。 有积压的产品，有优先权，有一条规则“尽快”。 你先做。 完成-您需要第二个。 等等-从围栏到晚餐。 冲刺，或更确切地说，其本质，即 您可以用来理解和分析生产力的时间长度（一周到一周，一个月到一个月等）。
该策略“尽快”有什么缺点吗？ 当然是一百万。 首先，一个人会很快感到疲劳。 其次，他会觉得自己像机床。 第三，他很可能会逃跑-使用带有积压的普通冲刺。 或者他们只是设置任务并等待结果。 一般来说，在哪里比较平静。 但是实践表明，如果按照常识认为这是一项规划策略，而不是运动衫，那么“尽快”有可能存活数年。
是否有可能引发冲刺及其积压？ 不行 不是因为这些是同一Scrum的独特概念，而是因为这是每个人以一种或另一种形式使用的自然规划方法。 有多种变体，一种原则-您需要在一定时间内进行一定量的工作。
像冲刺这样的工具是技术的独特且关键的元素吗？ 不行 这与说在键盘上键入代码是某种技术的独特概念是一样的。 几乎所有文本都在键盘上键入。
Scrum板
形式上，板子不是人工制品或规则，但我认为也值得一提，因为人与人之间有一个相当明显的模式：混乱是带有贴纸的板子。
通常，您在这里自己了解所有内容。 上面贴有写任务的贴纸的板并不是唯一的。 粗略地说，这是一个跨平台的工具。 我的妻子在冰箱上有时会雕刻待办事项清单，尽管她对任何混乱一无所知。
这个工具好吗？ 这取决于要比较的内容。 是的，也许是一个好人。
例如，它使您可以快速评估任务池周围的情况。 在计算机或任何其他电子设备中，需要翻转任务-通常所有内容都无法显示在一个屏幕上。 因此，一目了然。
另一个重要的优点是团队的整体可用性。 您可以随时查看，不进入任何系统，进行搜索，进行选择等。
许多人喜欢董事会的非虚拟性质。 毕竟，所有内容都是虚拟的，不会用手触摸。 在这里-请至少舔一下。 在这方面，有些人喜欢软木板。 区别在于纸质和电子书之间。
特别是对于Scrum板，可以注意到将两部分分离的优点-它是在工作中完成的。 贴纸的家庭处理涉及扔掉已经完成的贴纸-不太好，因为 进步似乎更糟。
Scrum板有什么缺点吗？ 当然可以 像任何董事会一样。
首先是家庭生活-草稿，劣质贴纸，不良笔迹，破坏活动。 结果，任务丢失和管理混乱。
在董事会上，进展不是很明显。 一般来说，对于冲刺-是的。 今天，昨天-不。 因此，需要进行日常讨论。
具体来说，如果生活比“计划的”-“完成的”更为复杂，则任务状态在Scrum板上不可见。 看板板看起来更好。
如果团队在地理上分散，则董事会不允许正常工作。 因此，出现电子板。
在我看来，电子板肯定是宗派主义的标志。 她失去了平时的所有好处，但是由于某些未知的原因，她继续使用它。 可能只是因为它是一个董事会。 方法论的一部分。
通常，工具就像工具。 在某些情况下-很好。 在某些情况下，这很糟糕。
Scrum在没有董事会的情况下可以工作吗？ 很简单 并经实践证明。 而且，由于董事会不是强制性产物，因此有可能继续称呼scrum-scrum。
Scrum大师
这个奇迹角色是谁？ 是什么感觉
有很多选择。 例如，Scrum Master就像运动训练师。 例如，有一个足球俱乐部。 产品的所有者有一个经理，负责定义团队的目标。 教练是帮助团队实现这些目标的人。
在通常的生产环境中，没有教练-如果足球俱乐部像那样工作，老板只会在比赛前来到更衣室，然后说：“去赢。” 当他们输了的时候，他会对骗局感到满意。 他将某人赶出去，威胁某人，等等。 像工厂。
就像Scrum管理员一样，教练是团队和经理之间的提供者。 当然，教练拥有更大的力量-他不是领导者。 但是结果也需要他更快，更容易理解-没有人会等到他帮助那里的某个人。 像Scrum管理员一样，教练也了解团队的运作方式，即 他只是设置任务，并说明如何解决它们。 建立联系，激励，创造和维持气氛等。
另一个比喻是排长，一些特种部队。 这是一名游戏教练。 与下属一起执行任务，以相同的方式解决战斗任务。 在业余时间，他负责指导技能的准备和提高，新设备的开发以及体育锻炼。 当然，他在心理学方面一直与团队合作-激励，支持和帮助。 当然，有时采用特殊的方法，但目标是一个-排的最大战斗力。
与这些家伙相比，Scrum master是一个免费的加载器。 对于结果并不特别负责。 似乎缺乏正式的权威被认为是一种优势-他是一名领袖军人，但实际上他会变得不负责任。 可以在不影响结果的情况下无休止地提供帮助吗？ 当他们将他们踢出局时，请寻找其他团队为他们提供便利。
是否可以更改或删除Scrum管理员的角色？ 当然可以 例如，将此角色与产品所有者结合。 我知道在《方法论》中写道，最好不要这样做-这将阻止主持人提供帮助。 但是，另一方面，它将增加明确的目标和责任。 当目标是可以理解和可衡量的时，便利就会从一种可选的，难以理解的废话转变为一种直接影响结果的非常具体的有形职责。 像教练或小队。
没错，然后称他为Scrum Master的意思就消失了。 这可能是团队领导者-不要忘记“领导者”是领导者。 领导者不仅是手中的旗帜，而且还要有动力，目标，保持能力，介绍新的工作方法，培训能力等。 简而言之，命令的驱动程序。 在内部发展的意义上，在取得成果的意义上。
如果用sctima中的timlida替换master，会发生什么？ 不能再将其称为Scrum了-抛弃了其中的关键角色之一。 它将如何影响结果？ 如果根本没有Scrum管理员？ 如果其功能受命令污染，贝尔宾是如何被推荐的？
一个促进，另一种激励，第三种监督规则的执行。你自己很有可能过这样的生活。合计
好吧，一切，那么原理很明确。像任何其他技术一样，Scrum是由组件或工具编织而成的算法。谁编织的？好吧，比方说Jeff Sutherland和Ken Schwaber。想象一下，两个人Jeff和Ken创建了一个组件，该组件在Web应用程序的开发中带来了很多好处。您在github中挖了它，安装了它，然后尝试了-哇，太酷了！有效！事实是，它变得更好了！然后，在某些时候，此组件中的某些内容开始使您烦恼。例如，调用他的方法似乎还不够多态。您进入源代码并发现...你在那里能找到什么？是的，什么都可以。例如，借用您不喜欢的东西。或借用的组件将是正确的，但会被歪曲地使用。或直接指示好的组件的特定版本，但是它发展良好，并且很久以前就变得凉爽得多，但是开发人员不想改编更高级别的组件。或者，您在算法中发现一块大小不错的块，可以很好地占用资源，但不会给您的项目带来任何特殊的好处。你会怎么做？当然，每个人都会回答不同的问题。有人甚至不会进去。有人会分叉并修复他们不喜欢的东西。当然，更新会带来一些问题。虽然不是事实，但Scrum之类的东西多年来并未改变。有人会写信给开发人员。我不知道他们会怎么回答。有人只是获取源组件，然后以自己的方式重新组装它们-根据特定项目或产品的需要。您可以使用任何技术执行相同的操作。我想写“有可能，有必要”，但并没有强加我的意见-所有人都做出决定。我想以Goldratt报价结尾。这可能是唯一开发出一些方法，坦诚地谈论其更改，适应，布局以及最重要的是对功能原理的理解的知名人士之一。, . , – . , , . – ( — ) . , , . , .