如果您无法用手指来描述组织，部门或工作的总体结构，则说明您的工作效率低下。
效率和透明度从来都不是一回事。 您可以透明地做无效的事情，并有效地做不透明的事情。
建立工作结构是一个复杂的，独立的过程，带有一点大胆的感觉。 因为我们不仅需要勇气和反思能力（“我们工作效率低下，为什么？”），而且还需要具有优雅的堆砌能力。
优美的堆是创建结构的关键。 看来“我们不需要，我们工作正常，为什么我们需要额外的层次”，但实际上-一层周到的层次会将您的工作提升到一个新的水平。 它是一堆，但是很优雅。 诸如依赖注入或使用Photoshop代替绘画之类的东西。
如果现在您认为“不，一切对我们有效”-甚至不要希望。 无效地。 即使您绝对，完全，永远不会陷入工作中，您也只会生活在幻想中。 这是不可能的。 效率是一个他妈的过程，不是既定过程。 并且必须由特定人员提供此过程。 和其他-支持。 不是因为“他们这么说”，而是因为每个人都会好起来的-每个人都会在感到舒适和有效率的情况下工作。
简而言之，我们称赞我们堆优美的想法是“无礼的结构鸟”或“开发流程”。 现在，我们将描述他，并且在争执中，我们还将吃掉几只狗。
为什么需要
开发流程旨在履行以下4个义务：
开发流程是一个
系统创建工具。
系统
系统由要素组成，要素是不同的，“当前”贯穿其中-工作过程。 在IT中，“对话”是我们与之合作的代码，设计，文档和其他内容。
系统缺失如果您不知道当前处于“私人流程”的哪个阶段（例如，“开发功能”），并且不知道您处于“一般流程”的哪个阶段（例如，在产品所有者，母版和设计师的Scrum之后的第四阶段），以及哪个舞台应该追随你，他的回归标准是什么，还有许多其他小事情……
或者，如果您知道，但是对于您的工作，项目经理应该坐在您旁边，并提醒您在那一刻应该正确地做些什么（不要将自己从显示器上移开，然后是以下程序）...
或者，如果您只是觉得自己效率低下...
...那么很可能您没有系统。
系统无法正常运行并非所有闪闪发光的黄金。 并非所有V12都在引擎盖下。 最重要的是-即使每个引擎在行驶中，也并非每个引擎都能正常工作（您好，深受爱戴的汽车行业）。
拥有一个适当的工作系统很重要，因为这是我们的信心。 在他的工作中，在整个系统的工作中。 您将立即发现问题，大多数问题都可以解决。
运转中的发动机发出声音。 他有节奏，愉快。 如果有问题，主机的敏感耳朵会听到它的声音。 吱吱作响，打喷嚏，节律紊乱，敲门。 它会缓慢或迅速地损坏引擎，而当您在戒指内的三卢布钞票上抵押一美元时，“商业机器”就会崩溃。
在人们的工作系统中，这些噪音-违反截止日期，不满，人员流失，员工低调，向下一个部门提出问题-等等。 一个好的经理带着张开的超灵敏定位器在办公室里走来走去，而不是耳朵。 他知道即将来临的暴风雨，他感到压力已经下降。 他听到所有的短暂叹息，注意到他缩回的眼睛。 他是系统。
开发流程：系统
DF系统包含两个部分-通用流程（系统整体上的功能）和专用流程（其各个部分的功能）。
总流量
该系统由组合成一个结构的元素组成，以实现预期的目标。
IT部门的目标是在正确的时间，正确的质量发布产品。 系统元素-流程中的参与者：产品所有者，项目经理，Scrum管理员，开发人员，设计人员，测试人员，技术作家...这些都是要素，并非始终存在。 有时角色会合并。 您需要突出显示您的元素。
您需要突出显示您的元素。 写下它们并绘制第一个流向箭头。 这称为通用流。
所有者→SM→设计师，开发人员→测试人员→技术作家任务是将元素组合成一个结构，并显示可能进行哪些专业互动。 非专业-设计师和产品的所有者共同生活是没有必要的。 这只是必要的角色。 所有者不应与设计者或开发者进行交互。 只有Scrum大师。 只。 Scrum大师。
当我们突出显示这些箭头的交互时，我们必须显示第一个给出的，第二个返回它作为反馈。 这样系统开始运行。
所有者→提供任务说明→SMSM将为所有者和其他所有者重新制定它。 评估任务-近似-会自行完成。 但是SM的任务-从一个简单的描述，应用一个优美的堆，使SUFFICIENT_DESCRIPTION。 在与团队合作之前，他将讨论并分发其中的部分内容。
SM→零件给→设计师和开发商DO包含一个方案，所有可能的状态以及更多其他内容（我还不想堆积）。 每个人都能发挥作用。 并非总是同时。 通常，设计器是开发者之前的一个冲刺。
在每天的集会上，设计师和开发人员都会收到SM的反馈，从而使他对任务的愿景恢复。 我们确保我们以相同的方式理解一切。 这需要25-28秒。 而且可以节省数小时和数周。
开发人员→在他的私人流程（稍后会详细介绍）之后，将代码→传递给测试人员开发人员提供代码，测试人员查看TO的一部分，并完成其流程。 测试人员的反馈适用于SM→“积极”（即他如何理解任务），适用于开发人员→“消极”-仅在其中断的情况下。
在出现问题之前，开发人员不知道自己的代码已经过测试。
我认为
一般流程的正确表述如下。 第一个过程给第二个过程，第二个过程返回“正”或“负”反馈，并在“常规”流程中进一步移动。 积极反馈是相信一切都会按预期进行； 负面反馈-显示出问题的原因和原因。
私人流量
在本文中，我将以所有者，CM和开发人员的私有流程为例。 如果您有兴趣，那么我将发布其余的工作。
主人
主要目标问题陈述（待办事项←描述），请阅读反馈
接下来是什么当任务由所有者制定时，SM会描述任务→导致Sufficient_Description。
反馈来自SM重新编写任务，并与所有者快速讨论关键里程碑，包括时间表。
与...互动SM
SM主要目标接受任务，将其转化为Adequate_Description的形式，评估任务，分发，阅读反馈
接下来是什么向员工分配任务
反馈来自设计师，开发人员，测试人员，技术作家
与...互动所有者，设计师，开发人员，测试人员，技术作家
开发者
主要目标功能开发和错误修复。 在General Flow中，他从SM接收任务，并在他的专业活动的帮助下实现了这些任务（git流，rebase流，feature流等）。
接下来是什么他可以提出修改建议，并与SM和Designer讨论。
反馈来自CM，设计师，测试员
与...互动设计师（SM），（重要-他无法与测试人员进行互动）
（在此描述中，我不太喜欢该方案，
这是我对演示文稿进行的另一种描述，我更高兴使用它。但是我正在探索各种选择，尝试，磨练，结果却是这样。）
在干渣中
开发流程解决了以下问题：
- 流程结构
- 解决问题
- 提供反馈
- 提供一种我们还没有说过的通用语言
主要优点-每个人都知道发生了什么，该怎么做以及没有进行不必要的工作。
Scrum Masters有很多工作（Timlid，CTO）。 但是应该是这样，他是这种方法的主要牵引者。
非常简短干燥的演讲保持黑暗或创建大胆的结构。 我们提供我们的鸟，但是它很大，在第一近似中，这只是一部分。 我们比任何情况都需要更多。 因此，我问你-把所有的狗都挂在我身上，我想破解一个更好的话题。
（我不得不削减很多以缩小文章的大小，至少可以缩小一点。因此，我可能会遗漏一些东西，但是我会尽快纠正它，写出来。）