梦想，梦想
在寒冷的秋天晚上，我们和3D可视化应用程序的开发人员聚集在厨房里……喝咖啡……并思考……关于开发的参考机构。
-我的敏捷朋友为我工作：冲刺，故事点，所有事物...
-是的，我们至少会进行审查...
事实是，在那些日子里，我们之间的关系并不十分顺利。 例如，将项目存储在git中是非常不寻常的：
- 有几个存储库，每个部分包含一个项目。
- 有些存储库是通用的，有些仅与某些项目有关，有些仅与一个有关。
- 要获得工作副本，您必须下载所有存储库的内容并将它们放在特定的文件夹中。
由于我们正在使用3D图形，然后使用了“控件+模板（屏幕上元素的位置，转换的逻辑）”的概念，更具体地说，事情是这样的：
- 在处理控件时，提交会随基本控件一起移至存储库，并且可能随资源一起移至存储库（如果已经使用的三维模型必须在其他地方使用）；
- 当使用控件和模板时（例如，如果有必要在帮助面板下替换应用程序中的背景），则必须使用资源将图片上传到资源库，并使用模板在资源库中编辑布局。 如果背景是用皮肤（单一样式）制作的，则可能涉及3个存储库。
通过这种方法，代码审查可以节省成本：
- 开发是在一个分支中进行的；
- 一个任务的更改影响了几个存储库，并跟踪与哪个任务有很大问题的提交有关的内容。
结果，由于在审查过程中缺乏“从错误中学习”，交流经验，分析彼此的代码的能力，开发人员无法足够快速地提高其技能。 并开发应用程序“更快”-这是必要的。 为了将开发速度保持在可接受的水平，在每个新项目中，人们都从事与以前项目中的任务相似的任务。 即 如果有人以前使用过3D地图，那么他一次又一次地获得了与地图有关的任务，或者如果有人曾经开发了“图表”组件，那么他注定要图形。 这有其自己的逻辑，因为 更快地，任务是由遇到相似或相同的人来完成的。 结果，结果表明开发人员只专注于特定的事物，并且不能互换。
至于开发方法和清晰的工作流程，由于多种原因，它们也未得到应用。 从这一事实开始，有必要花大量时间思考所有概念和开发过程，最后是没有人提出这一事实。 作为最近到来的员工，我和这些家伙都无权进行重组。 它仍然只是抱怨和梦想。
“有梦想的地方总是有机会”
当然，对我来说，作为一个对工作无动于衷的人，目标是改变现状。 否则，如果我不能积极影响现有流程并为人们提供这样的工作条件以使他们能够发挥自己的能力并加以改善，那么我的活动的意义是什么？ 将创建应用程序，将纸上设计的想法具体化的人们的发展变成项目和整个公司的发展。
达到目标的好机会是开发我们平台的新可视化模块。 这个项目与其他项目不同，因为 这不是平台上应用程序的开发，而是平台本身一部分的实现。 因此，在这里，我们并不局限于在许多git仓库中存储和使用项目的奇怪概念，在我看来，这是引入代码审查的绝佳机会。
顺便说一句，在这里，我们做了什么一个好的冬天的早晨，我用介绍Gitflow的建议攻击了项目建筑师。 起初，他认为我的想法是自相矛盾的，但是有其原因：某些标准模型并不总是合适的。 但是，在沟通过程中，我们为该项目开发了最合适的选项，我们现在正在成功使用它。
我们修改后的Gitflow如下：
- 有一个主分支（我们称其为master，但是您可以给任何名称以免混淆）；
- 吉拉（Jira）有一个冲刺，它由积压的任务组成，这些任务由一个微目标联合在一起；
- 开发人员将任务从sprint中打开的任务列表中移至进度，并从master创建一个功能分支，在其功能分支的名称中指示任务代码（例如PLAYER-55）；
- 任务工作完成后，开发人员将其工作提交审查：通过Gitlab创建一个合并请求以掌握并通过注释将合并任务的链接转移到Review on Jira；
- 如果审阅完成并且所有讨论都关闭了，那么Jira中的任务关闭，功能分支合并到master中并删除；
- 如果审阅后有任何注释-在Jira中，任务将从审阅中重新发现，并且算法从头开始运行，只是已经创建了功能分支。
当所有任务都关闭时，我们进入发布阶段：
- release分支被称为远离master，这称为两位，例如release-3.0，其中3是项目的版本号，0是release分支的编号（分别地，下一个release分支将称为release-3.1，依此类推。 ）;
- 对发布候选者进行了进一步的测试（通常是开发小型演示）；
- 如果在测试过程中未发现缺陷，则候选发布版本已准备好进行生产：发布分支中的最后一次提交用由3位数字组成的生产标签进行标记（例如prod-3.0.0，其中3是项目版本号，0 -发布分支号，0-生产版本号），那么发布分支将卡在master中，而不是删除，这与传统的Gitflow不同；
- 如果仍然发现缺陷，则将它们作为错误注册在Jira中，然后错误修复过程类似于使用功能分支中的任务（仅从发行版而不是从母版检查），并且在关闭所有错误时，我们放下生产标签，版本将输出到产品，并且发行分支合并到主版本中，而不会被删除。
如果在生产中发现错误，则还应达成协议：
- 此版本销售版本的发布分支中也将进行此类错误的工作，如果非常紧急，则将其标记为热修复，并在团队负责人的发布分支中直接进行；
- 否则，处理此类错误的方法类似于处理候选版本中发现的错误。
那么，为什么还要Gitflow呢？- 进入功能分支是一种引入评论的方法，它使您可以分享经验，提高团队资格的整体水平，并且最重要的是，结果是避免将质量低下的代码插入没有共同风格的最终产品中，这很难理解并且充满了错误。
- 我认为许多人都熟悉根据参考条款和规范对项目进行评估，为项目分配预算，根据文档中的要求实施功能的情况，但是在这里，从零开始，老板们会催生一个人，您会听到：“哦，但是让我们在这里添加几个独角兽，客户会喜欢“，”，您是否可以通过单击地图上的某个区域来致电该区域的朋友？ 这将是一颗炸弹，继续执行”，“我们需要添加图例”，“现在也需要删除图例，并且签名也必须”，“删除签名是多余的，将其返回。” 所有这一切都是“免费的，无需注册和SMS”。 然后，在计算实际成本时，事实证明，执行如此少量的任务要花太多时间（毕竟，吉拉（Jira）中的“请求”通常没有注册，因为并非每个开发人员都可以拒绝老板或让他注册他的“请求” ”，这是可以理解的）。 引入了使用Jira代码命名单个分支的规则，并且由于无法将分支合并到master中而没有绑定到Jira，因此消除了未注册工作的存在以及开发人员“开始下载权利”时可能发生的冲突，这要求您在Jira中填写“请求”作为一项任务，并且还可以使您清楚地知道实际完成了多少工作（Jira中的任务由与之关联的代码确认，通过与注册任务的通信来编写代码）。
- 在更新任务状态方面，Gitflow与Jira的联系有助于避免出现多个人同时执行同一任务的情况。 在根据自己的Gitflow阶段更新状态的情况下，每个人都会看到这样的任务已经在进行中或正在审查中，因为它们已经有用于编写代码的功能分支，因此您无需使用它们。 清晰可见的是，谁在做什么和什么工作会互相影响，哪个人应该更频繁地联系并就特定的实现达成一致，以使在合并时不必冗长而痛苦地解决其代码冲突。
- 由于我们正在开发用于创建应用程序的平台，因此值得考虑的是，某人的成品将取决于我们支持该平台的旧版本并引入新版本的政策。 该平台的某些用户可能出于某种原因会使用该平台的最新版本并发现与该平台相关的错误。 如果删除发行分支，则在这种情况下将无法为用户提供帮助，尤其是在新平台实现中删除或修改他们版本中使用的功能时。 因此，保存发行分支可让您向不使用最新版本平台的用户提供支持。
那敏捷呢？
正如您可能已经注意到的那样，我们开始慢慢地遵循敏捷Scrum开发原则，首先是将任务划分为针对微型目标的sprint。
接下来介绍了规划扑克，故事点，团队速度分析和回顾。
参与规划扑克并为任务分配故事点使团队可以更全面地了解该项目，其体系结构，我们通常追求的目标以及应该取得的结果。 人们有机会系统思考，而不仅仅是在任务框架内。 这有利地影响了他们作为专业人员的发展以及项目本身：
- 提供了新的有用功能，因为对于开发人员而言，它变得更清楚了，总体而言，哪些地方可以改进；
- 通常，发现错误和缺陷只有在平台运行时才能变得明显可见。
由于可获得有关sprint中完成的任务数和相应的Story Point的数据，因此有可能分析开发团队的速度，以便将来执行更有效的计划和时序估算。
的确，在这方面，我们的项目框架中存在一些令人烦恼的事情：团队的组成经常发生变化，因为一些开发人员会定期撤离进行紧急项目，而将其替换为无任务的项目。 因此，每次都会重置速度估算值。 在这种情况下几乎是不可能的。 他们提出的唯一方法是收集3-4个冲刺的每个合成的数据，然后尝试确定平均值。
“让我们快点”或三个月的成熟演示应用程序
当然，没有人取消应用程序开发。 尤其是在实现公司的全球目标所必需的情况下。 特别是在非常需要它的情况下。 最近，对于表演的演示应用程序的快速实施的需求已大大增加。
当然，在使用了新的范例之后，我根本不想回到原来的对话中。 然后，我们决定使用新可视化模块的某些部分（作为一个集成系统，尚未为完成这些任务做好充分准备），并以其开发原则为指导。
由于并不是所有的开发人员都参加工作流主题，并且就我们“燃烧”的演示的时间而言，使这些人适应新的开发设备是很大的风险，因此我们试图在过去与希望的未来之间找到一定的“中间地带”。 结果，这是在演示中部分使用新可视化模块的原理时发生的情况：
- 小队。 2-3个开发人员，设计师，测试人员和经理。
- 并行开发（以前先创建控件，然后创建具有应用程序外观和逻辑的模板）。
- 使用诸如Jira中的Story之类的任务。 没有明确的规范和TK，因此我收集了有关应用程序预期行为和外观的所有可用信息，并将其全部放入Story中。 然后对它们进行测试，这引起测试人员之间的积极反应，因为所有信息都集中在一个地方，但同时又被分为功能部分，这有助于验证。 整个团队无需阅读大量正式文本即可正确理解并完成任务。 而且，与带有规范的Word文档不同，故事的更新速度更快，人们很快收到了具有新改进的描述，因此开始更快地实现它们。
- 具有开发分支和主分支的Gitflow，但没有功能：
- 所有开发都在开发分支中进行，但是为了排除未注册任务的存在，每次提交都必须标记有来自Jira的任务代码，并在其框架内进行；
- 解决了计划发布的所有任务后，就组装了一个新版本：团队负责人对开发分支进行了审查，如果一切正常，则将更改合并到主版本中，并分配带有版本号的标签。 如果在审核过程中发现重大错误和违规行为，则将代码发送进行修订，并且只有在输入并重新检查之后，该代码才可以进入母版。
- 版本号用两位数字编号，例如0.1-始终是第一个测试版本号，其中0-表示属于生产版本，1-版本号。 因此，在每个下一个测试版本的数量中，最后一位数字增加，直到测试人员和经理得出结论，该版本已准备好投入生产。 因此，如果这是第四个测试版本（0.4），则它将成为第一个测试版本（1.0），并将相应的标签放置在master分支中。 如果在生产中检测到缺陷，并且将生产版本发送给编辑，则在对所有后续版本（1.1、1.2等）进行编号时，第二个数字也会增加。
因此，在一个月的时间里，我们实施了3个成熟的演示应用程序，这些应用程序受到了好评，并且仍然有用。 以前，我们无法如此迅速地在团队中实现如此多的功能。
以我的拙见
我个人对此有何看法？
- 流程的组织确实会影响结果，并且倾听开发人员自己发明并面向开发人员的开发实践世界，不仅是“时尚，时尚，年轻”，而且是必要的（在通过演示之后，这是几年来的第一次实践，我们继续做剩下的事情）项目，直到交货后再过两周才坐到晚上，这让客户发现可耻的缺陷堆满了汗水）。
- 具有清晰工作流程的项目的混乱，误解和压力较低（人们可以更好地掌握相关信息，并且知道在必要时可以从何处获得信息）。
- 正确使用项目管理工具会影响项目本身及其参与者的开发（由于吉拉特（Gira）Gitlab的开发得到优化，引入了敏捷Scrum原理，因此可以交流团队经验，提高团队技能，更经常地转移初级团队负责人的知识和经验）和中级开发人员）。
这是秘密
尽管有上述结论，但对我来说还有其他显而易见的事情：
-并非每个人都为自己的梦想做好准备。
有时，当我们从侧面观察某些事物时，在我们看来，这是一件好事，有用的事，对成功，正确和参考必不可少。 但是，正如我们所了解的那样，梦想值得成为现实：“这不是我所想象的。” 因此，在工作中：似乎现在给您提供了“正常公司”的工作条件，您将会蓬勃发展。 但是a。 碰巧的是，您不遗余力地尝试向人们提供他们梦想中的成功的保证，但奇迹并没有发生：工作仍然没有高质量完成，并且您了解自己可能已经接受了某人的典型支持厨房对话以实现真正的愿望和梦想的话。
因此，在引入新规则和原则的过程中，我们不仅面临积极的反馈和结果，而且面对正在发生的事情的负面看法。 对于某些人来说，与Jira和Gitlab的合作似乎很麻烦，要改变这种看法非常困难，直到人们遇到由于忽略了公认的工作流程而出现的问题情况。 尽管在Jira上进行了清晰的注册，但仍会不小心执行某些任务，没有考虑故事或问题陈述中的描述或将其视为“个人请求”，也没有执行。
通常，质量低劣或设置实施不当的构建仍然可以发现，并且在构建之间重新打开了一些错误。尽管最终结果在所有演示中都是积极的，但我仍然想到这样一个事实，即负责工作的人，他们关心提供尽可能最高的结果，我们不仅设法实现必要的功能，而且还引入了新功能，优化了应用程序并“加ryushechek。”对于团队中有些人可能负担不起的懒惰或对获得最高质量结果不感兴趣的团队，我们仅在交付后根据客户的额外要求实现了基本功能和几个小功能。然后，也许，我最重要的结论就来了：-不是过程，不是技术-成功的真正关键，而是那些创造，创造并将想法体现为现实的人-人们及其对工作的态度。一个乐于助人的音乐家将影响听众，甚至演奏最便宜，最不舒服的乐器。并给他斯特拉迪瓦里-他会让观众发疯。甚至Stradivarius至少向其提供领先工具制造商的最新发展-一切听起来都不重要。
您可以为人们提供舒适的条件和最先进的技术，但是最终他们的活动不能令人满意，因为“事情总是如此”。而且，即使没有最成功的技术，有时甚至阻碍有能力的实施技术，也有可能获得不俗的结果，因为实现这一目标的人无法负担未完成或做得不好的工作。辨别，支持此类团队成员，倾听他们的意见并为其活动创造有利条件非常重要。技术和流程的组织确实会影响结果，并且非常重要，但是成功的关键在于有才华，负责任和以发展为导向的人员。