你好 我是
gitpab 。 很高兴认识你。 使我变得更容易监督程序员。 我花了开发人员在Gitlab中记录的时间，并计算出谁花了多少时间来处理这些任务。 对于整个项目。 有传言说，在我的帮助下，大老板们会考虑分期付款的薪水和项目的盈利能力。 确实是。 在我的帮助下，您可以提高软件项目的利润。 现在，我将告诉您如何为您的团队和个人带来帮助。
我的工作方式
我上班没有休息，没有睡觉和午餐时间。 听起来很吓人，但是您可以通过在服务器上部署我来看到这一点。 幸运的是，自述文件中包含有关如何执行此操作的说明。
不要忘记在我应该遵循的配置中注册项目。 我将每小时检查一次Gitlab，然后从那里重新学习一遍-新的冲刺，任务，评论，注销时间，有关参与者的信息。
展望未来，我会说我自己看起来像这样：
这是我的仪表板，主要指标如下。 其中最有趣的是Balance。 它反映了开发人员目前必须支付多少小时，反之亦然。
但是现在，让我们按顺序进行。 我决定说说自己是有原因的。 事实是，我个人看到了很多不同的项目和不同的项目经理。 没什么私人的，请让我先向您介绍一下这项技术，我们的母亲。
gitlab中的项目
我本人是Scrum的支持者。 因为Scrum是除其余技术之外最糟糕的技术。 现在，我将在此处复制我们的内部文档，新员工必须阅读该文档。
方法论董事会
冲刺的主要工具是董事会。
板上有几列。 在每一列中，任务按照优先级从高到低的顺序排列。 列表顶部的任务具有更高的优先级。 因此，您需要从头开始处理工作任务。
- 待办事项列出了在不久的将来尚未开发的任务。 通过这些任务，我们在里程碑中形成冲刺。
- 要做。 冲刺开始时，当前冲刺的任务将传输到“待办事项”列。
- 在做。 当开发人员开始执行任务时，他将其从“待办事项”转移到“正在执行”。 这将与新分支母版创建一个单独的分支。 分支名称必须与任务编号匹配。
- 代码审查。 当任务完成并且开发人员确定一切正常时，他将当前的master分支拉入task分支并将任务转移到Code review列。 Tim领导者从“核心审阅”列中检查任务，如果一切正常，则将分支与主任务中的任务合并，然后将任务转移到“测试”列。
- 测验 测试人员从“测试”列中检查任务的性能。 如果一切正常，则将其关闭（转移到“已关闭”）。
- 闭馆 这些任务已完全完成，不再需要开发人员的注意。 它们不一定与客户一起生产，但是将在下一个版本中交付。
时间
在开始开发之前，应评估每个任务。 为此，必须在任务注释中指定
/estimate 5h评估可用于正确计划Sprint，而不会使任务过多。
要标记在任务上花费的时间（例如1.5小时），您必须使用以下格式对任务进行注释
/spend 1h 30m该消息必须由任务注释（而不是在任务主体或其他位置）中准确指示，在这种情况下，此时间将落入有关所花费时间的报告中。
时间报告在Gitpab中。
冲刺
冲刺计划在里程碑进行。
当任务转移到“已关闭”时，冲刺完成百分比会自动增加。
发布和发布说明
版本使用SemVer样式的0.0.5格式标签标记。 将描述添加到标记（即变更日志）中。
提交要求
每个任务都应在与master不同的分支中解决。 分支的名称，格式为
< > 。 例如：443。
每个提交都应包含一个小的，逻辑上完整的更改。
如果任务很繁琐，则不应通过一次提交来限制任务。 相反，任务应采用许多提交的形式。 每次提交不必工作。 最终版本将在大师级水平上大放异彩。
在任务很简单并且可以一次提交解决的情况下，只需在提交的注释中通过网格写入问题编号即可。 示例：＃452。
如果任务很繁重并且分成许多提交，那么建议在任务编号后加一个小解释。 示例：＃493级联删除文档文件。
在将分支与主任务中的任务合并之前，您需要将master分支与任务合并到该分支，并将任务发送给审阅/测试代码。
缺少什么
简短的说明，但这有助于在我的项目中构建Scrum。 它没有说什么。 我们甚至为此想出一些时髦的术语。 在！ 简易装置 酷吧？ 简易装置 铁鸡蛋学科。 铁蛋学科。 在没有适当注意开发过程的情况下，任何与该项目有关的指令都将停止。
我为什么有用，Gitpab
本文作者负责其活动的团队由编外人员组成-所有工作均按时间付费，专门用于项目。 我必须说，以高质量的方式管理这样的团队有点像宝石。 团队越大，跟踪它就越困难。 还有很多要注意的地方。
- 有没有开发商挂断电话？
- 他们对任务的贡献是否超出其价值？
- 发票是否专门针对该期间进行的工作开具发票？
- 我们现在欠开发商多少钱？ 对所有开发人员而言？
- 我们超出了项目预算吗？
我，Gitpab，一路回答所有这些微妙的问题，并解决其他问题。
注销时间
仅这份报告就值得。 您可以在此处根据所需标准过滤注销时间。
让我告诉你一个故事。 一旦我们无情地朝着最后期限前进。 该项目以高质量和负责任的方式完成，一切进展顺利，而我们已经完成了任务的工作，而在截止日期前一周突然向我们发送了63条评论。 布拉德尼·唐斯（Bla-raodny Dons）董事关系的细微差别使得必须将这些任务关闭一周，这样我们才不会被拖延付款。 这并不是说这些任务非常困难；这些只是对系统“舔”的评论。 但是我们以每冲刺20个的速度完成了任务。 在整个项目过程中，团队每周最多可容纳40个任务。 如何执行多一倍半？ 根据评估，这些任务被推迟了几个星期。
但是随后产生了一个想法。 团队有我，Gitpab。 因此，作者建议本关键周的预算所有者将费率提高一半半，前提是该费率专门适用于这些评论。 在Gitlab中为所有这些任务分配了单独的标签并开始编码。 我认为可以鼓励这样的决定，但是对团队来说，这是一个很好的建议。 每周冲刺全部63个任务都已关闭。 说真的 63和高质量。
为了计算保费，我们只需为每个参与者过滤掉该标签在该期间的注销时间。
成绩任务
为什么要评估任务？ 首先，如上所述，以免在冲刺中获得太多收益。 我支持团队尽可能多地完成任务。 如果有时间，请在此过程中采取其他措施。 因此，团队在客户面前看起来更有利可图，因为它做出了尊重的真正承诺，甚至比承诺要多。
但是还有其他原因。 另一个故事。 团队中有一位开发人员，他想花更多的时间来完成任务，而不是花时间。 有时是5倍，有时是10倍以上。 作者不是很喜欢。 但是，我必须说，除了这种细微差别外，该开发人员适合所有人。 不想发生冲突或安排摊牌。 当时，我们并未评估所有任务。 在吉帕（Gitpab）中，不难发现很多时间只花在了宝贵的工作上。 他们毫无例外地开始评估所有任务，这有所帮助。
我，Gitpab，为您提供了一种工具，可以协调估计和实际在任务上花费的时间。
客户报告
在此过程中，我节省了准备冲刺工作报告的时间。 看，您打开了Sprint，并且有一个现成的报告。 只需在Gitlab中启动新标签，然后从sprint复制描述即可。 它已经在Markdown中。
在Gitlab中复制粘贴：
客户承认，与在项目过程中加入他们的Gitlab的团队合作非常好，并且还每周提供有关所做工作的详细报告。
有时，某些业务客户会要求一些
疯狂的绝世绝技清单，并列出其执行状态。 在这种情况下，为这样的列表创建单独的标签并不时卸载由标签过滤的这些任务非常方便。 只需单击“导出到csv”按钮。 伙计，你知道有时会节省多少时间吗？
钱款
每个项目参与者可以指定每小时的工作费率：
具有财务权利的用户会看到此部分以及余额。 这里的余额以小时为单位-预付了几个小时（绿色）。 或者您需要支付多少小时（红色）。 方便吧？
但这还不是全部。 下注时，您可以设置费用-您需要支付多少，这样一个人才能下注。 对于每个，这是其百分比。
等等，还不止这些。 有一个付款界面。 在这里，您可以查看付款记录和已付费时间。
并且在付款时，会自动考虑已支付的时数，并考虑成本。
如果您有固定状态的员工，那么合理的问题是-为什么这会给维持付款带来麻烦？ 我同意，您不需要它。 但是，如果您按小时收费，那么这样的工具非常方便。 付款时，您不必根据花费的时间生成报告，只需查找报告上次结束的位置即可。 不会有任何混乱，您也不会捕获意外已经付款的工作。 而且您将不会错过无薪时间。
现在，您需要做的就是查看员工的余额，并向该人投入足够的资金，以使其余额变为绿色。
项目预算
由于您现在有了每个问题的数字，因此计算它们的数量并不困难。 因此，您将了解项目是否超出预算：
类似的统计数据基于冲刺。
嗨Gitpab，您的作者什么时候可以工作？
分解任务，监视进度，协调团队，以及上面描述的所有其他事项，再加上您可能会认为这会花费很多时间。 当然，这会浪费时间。 但是，这比不受控制的浮动项目要好得多。 如果我的作者没有让我成为现实，那么他将成为一名失落的经理，他忘记了IDE的外观（不要与IED混淆，请参见上文）。 多亏了我，他成功地将代码吐出了不少于他的同事们。
总结一下
上面已经介绍了该技术，以及如何与Gitpab结合使用Gitlab来帮助您遵循该技术。 这对于作者来说效果很好。 也许您想自己改变一些东西。 没问题，改变，自己调整。 最后，您可能有一个目标-进行高质量的项目并从中获利，而我，Gitpab，在此方面将为您提供帮助。
现在在工作室里有个饼干
顺便说一下，我是由一位好叔叔（本文的作者）创建的。 他太善良了，他让我敞开心open。 我会对
Github上的星星感到高兴。
我几乎忘记了最重要的事情。 我是一个工具。 我的一位熟人，一位成功的企业家和一位简单的俄罗斯亿万富翁说，这些工具不起作用。 人们工作。 我希望你明白我的意思。 利用，我为您服务。 成功的项目。
ps：我调查了出版物，发现了很多缺点。 当您提出减号时，请不要懒于评论，我对反馈很感兴趣。