♎️ 🍺 🐵 同时进行Ajile（监狱监狱）和Waterfall项目 👨🏽‍🎨 👨🏽‍🎓 👺

有许多现成的，经过时间考验的框架可以组织工作流程，在其中很好地描述了方法和原理。如果我们组装汽车，请使用看板，准备一个饼图-精益，开发一个自定义网站-PMBoK。重要的是要考虑到每个项目都是独特的并且需要对方法进行调整，但是总的来说，对于您的情况，很可能已经有足够有用的解决方案。为自己建立流程，我花了所有的钱。

它是

他在一家初创公司工作。一个产品，一个小团队，没有严格的时间限制。可以这么说，以最纯粹的形式使用了Scrum和看板。我们在Trello中写下了任务，并将其拖到4个板上：想法，我们需要做到这一点，在工作中，它已经准备就绪。为了讨论工作进度，他们每天打电话给他们，每周一次，他们计划下一个冲刺的任务。一切都像人一样。

已经成为

在稍微改变了开发过程之后，我去了网络工作室寻求新的体验。在那里，首先，他对与客户合作的灵活性感到惊讶，并且，如果没有讽刺意味，那就缺少任何系统。

为了展示大局，我将举一个非常简化的示例。
客户A：我需要为此类日期的事件开发一个登陆页面。
项目经理（MP）：好的，我们会在某个日期之前完成。
客户B：紧急对网站进行以下更改。
MP：好的，请尽快添加。

接下来，MP同意客户A的估算，将任务写入跟踪器，创建单独的项目和未连接的板。告诉团队该怎么做。开发人员开始削减工作，完成后，经理将结果展示给客户。

系统中的条目如下所示：

问题

维护方法非常合乎逻辑，但是会出现以下问题：

客户和团队
任务之间缺乏可见的联系，通常在表中找到业务任务，并在Jira中反编译。当开发人员编写另一种API方法时，要了解谁会使用它，您需要去找经理并再次澄清。
不正确的优先级排序
Designer会报告布局过早完成（是的，这也会发生）。他问：下一步该怎么做？MP设置第四个项目的任务，列表中的第一个。最终，他意识到第一个项目的第四项任务更为重要。
没有视觉范围的工作范围，
不同项目中的任务。没有人愿意将它们放在首位或搜索目录。当我结束时，问：下一步该怎么办？
按时间和员工分配的负载不均匀
显然Vasya和Petya目前正在做什么，很难说两周后谁会忙，以及他们的任务是否相等。
在计划完成时间时，未考虑其他项目的任务，因此
要求我们更改站点上的链接。哦，很简单，今天就开始吧。然后经理回忆起另一个站点上存在严重错误。结果，链接改变了，根据客户的说法，团队延长了一周的时间。

也许在这个带有编辑和登录页面的示例中，它看上去并不可怕，因为所有这些都很容易记住，但实际上，可能同时有5个项目，每个项目有40个任务。许多项目来自其他经理。根据他们的心情选择董事会，任务类型，方法论。

转换瓜

要创建系统，首先必须将数据转换为单一格式。通过转换要移交给我处置的实体的数量，我设法得出以下概念：

我认为从图中可以清楚地看到一切，但是在Jira中的实现有一些细微的差别。让我们使用示例分析每个实体。

有了项目的概念，无论是在社区还是在Atlassian的心中，一切都是明确的。这是旨在在有限的时间内获得结果的一系列动作。例如：开发一个网站，在整个生命周期内支持该应用程序，创建一个广告公司。

史诗（发行）-孤立的大型项目：个人帐户，购物篮，产品目录。在这里，分歧已经开始。吉拉（Jira）有一个实体-史诗，但我仍然使用发布。

事实是，为了实现正确的结构，必须具有3个嵌套级别，在撰写本文时，Jira具有2 +1的嵌套（历史和任务位于同一级别）。 +1是一个子任务，我没有考虑到它，因为它缺乏灵活性和对父代的强大绑定，因此它具有补码而不是嵌套的功能。

您可以使用组件或sprint来代替发布，但出于我的目的，它们看起来不太成功。出于同样的原因，史诗被用来记录故事。这种结构中的

历史（史诗）是业务的任务（客户的愿望）。任务-解决业务问题的可理解的措施。

此外，一些计数器和字段已添加到实体。其中最重要的是用于以1为单位以10为单位评估任务复杂性的标度（理论点）。

系统创建

有数据，那么您需要确定以什么形式以及如何显示它。我为团队创建了一个通用项目，并编写了一个JQL查询以将所有项目中的任务拖入其中（该查询很容易在“问题”部分中生成）。添加了与我们的技术流程相对应的看板板和状态：积压→待办事项→做→检查→测试→匹配→完成。

获得了下图：

现在，所有任务都经过一个生产周期，这是相当普遍的（您无法测试设计，但必须立即将其转移到协议中）。如果任何阶段失败，则将注释添加到任务，并将其发送回“待办事项”。每个任务都有指向项目，客户历史记录（史诗）和史诗（发布）的可见链接。

通过对Jira使用与BigGantt插件（或任何其他插件）相同的JQL查询，可以以甘特图的形式查看任务。更改准备时间，截止日期，注册依存关系，以及查看表演者的负担。折叠历史中的任务，史诗中的历史，即可视化路线图或详细的工作计划。

行政部分

在这些方法中，使用了精益（确定了一系列动作，同时还保留了并行执行任务的可能性），看板（任务从一个专家到另一个专家，很容易确定瓶颈）。来自Scrum的日常会议保持对谁在做什么的理解。他们还评估了故事点中新任务的复杂性。我想要但不能使用冲刺，因为客户有时会更改任务的优先级，并且在冲刺开始后就无法再调整工作量。

会议结束后，将在待办事项中对任务进行优先级排序，指派执行者，并将其转移到“待办事项”中。开发人员在BitBucket中创建一个分支，该任务自动跳转到Doing。完成后，“开发者”将转移到“评论”，然后艺术家切换到另一位开发者。如果一切正常，则“审阅者”进行合并，并且代码在测试服务器上。Jira将任务发送给测试人员。验证后，质量检查会将其转移给经理。那显示了顾客。客户感到满意-代码在日常自动测试的密切监督下被发送到战斗服务器。

感谢这种自动化，感谢我们的devops工程师。我刚刚配置了git事件的状态和执行程序更改。如果您在Atlasian生态系统中工作，这将在业务流程设置中完成。而当使用Bitrix的GitLab时，Redmine将不得不修补。

解决方案

让我们看看我们实现了什么：

客户任务与团队之间缺乏可见的联系。
业务任务在Jira中记录为故事（史诗），可以按完成百分比和甘特图进行查看。执行任务的开发人员可以查看任务所属的故事，然后阅读说明。
不正确的优先级分配器
设计者已经较早完成了任务，因此从“待办事项”列表的顶部选择了一个新的优先级，其中按故事点与成本的比率（卢布中的业务任务）进行优先级分配。
没有可视化表示工作范围，
一个项目中的任务。团队中的每个成员都看到他们如何沿看板董事会（通常的工作流程）前进。已经做了什么，还有什么要做。
按时间和人员分配的负载不均匀
。甘特图使您可以长期规划工作（不断更新）。表演者有个投射。可以看到，执行者一次有2个任务，而某人没有。
在计划完成时间时，不会考虑其他项目的任务。
将新任务添加到任何项目，可以在常规积压中看到。在一个度量标准中为她设置了其他任务的优先级。

计划

某些流程已减少或自动化，但计划中还有更多内容：

生成项目时间和材料的估算

在执行每个任务时，员工会记录其中的时间。了解每个人的每小时费率，他的职位，校正系数（乘以要乘以公司成本要多少倍），就可以生成带有工作和成本列表的表格。

经理之间的自动结算

如果我有任务，但是没有足够的资源来完成任务，请向承包商寻求另一位经理。当需要报告时，我将花在员工身上的时间花在了我的计划中，将收入花在了另一位经理的计划中。

每个月我必须提高所有工作量，与经理核对，在没有任何创造力的情况下进行加减运算。如果所有员工都转换为单一数据格式（在Jira中进行项目的方式），则无需人工干预即可进行所有计算。

同时进行Ajile（监狱监狱）和Waterfall项目

它是