大家好。 我经常看到同样的情况，尤其是在外包领域。 各种项目的团队缺乏清晰的工作流程。
最重要的是，程序员不明白如何与客户以及彼此之间进行沟通。 如何建立开发优质产品的持续流程。 如何计划你的工作日和冲刺。
所有这一切最终会导致错过最后期限、加班、不断地摊牌谁应该受到责备，以及客户对一切进展的地点和方式感到不满。 很多时候，所有这些都会导致程序员甚至整个团队的变化。 客户流失、声誉恶化等等。
有一次，我刚刚完成了这样一个项目，其中充满了所有这些乐趣。
没有人愿意对这个项目（一个大型服务市场）负责，营业额很糟糕，客户只是感到痛苦和沮丧。 有一次CEO来找我说，你有必要的经验，所以这是你手里的牌。 自己承担这个项目。 如果你搞砸了，我们将关闭该项目并将所有人踢出。 它会成功，会很酷，然后按照你认为合适的方式领导它并发展它。 结果，我成为了该项目的团队负责人，所有的事情都落在了我的肩上。
我做的第一件事是从头开始开发一个与我当时的愿景相符的工作流程，并为团队编写了工作描述。 实施它并不容易。 但一个月左右的时间，一切都安定下来，开发商和客户都习惯了，一切都安静而舒适。 为了向团队表明，这不仅仅是“茶杯里的风暴”，而是真正摆脱困境的出路，我承担了最大的责任，消除了团队中不愉快的惯例。
一年半的时间已经过去了，项目的开发没有加班，没有“激烈的竞争”和各种压力。 老团队中的一些人不想这样工作并离开了；相反，其他人则对透明规则的出现感到非常高兴。 但最终，团队中的每个人都非常积极，并且完全了解这个庞大的项目，包括前端和后端。 包括代码库和所有业务逻辑。 甚至已经到了这样的地步：我们不仅仅是“划船者”，而且我们自己提出了许多业务流程和新功能，这些业务流程和新功能都是企业喜欢的。
由于我们采取了这种方法，客户决定从我们公司订购另一个市场，这是个好消息。
由于这适用于我的项目，也许它也会对某人有所帮助。 所以，帮助我们拯救项目的过程本身是这样的：
“我最喜欢的项目”项目的团队合作过程
a) 内部团队流程（开发人员之间）
- 所有问题均在 Jira 系统中创建
- 每项任务应尽可能详细地描述并严格执行一个操作
- 任何功能，如果足够复杂，都可以分解为许多小任务
- 团队将功能作为一项单一任务来工作。 首先，我们共同开发一个功能，将其发送进行测试，然后再进行下一个功能。
- 每个任务都被标记，用于后端或前端
- 有多种类型的任务和错误。 您需要正确地指出它们。
- 完成任务后，将转入代码审查状态（在本例中，为同事创建拉取请求）
- 完成任务的人会立即跟踪他执行此任务的时间。
- 代码审查通过后，PR 获得批准，然后执行此任务的人员将其合并到主分支，之后将其状态更改为准备部署到开发环境。 服务器.
- 准备部署到开发服务器的所有任务均由团队负责人（他的职责范围）部署，如果事情紧急，有时也由团队成员部署。 部署完成后，从准备部署到开发的所有任务都会转移到状态 - 准备在开发上测试
- 所有任务均由客户测试
- 当客户在开发人员上测试了任务后，他将其转移到准备部署到生产的状态
- 为了部署到生产，我们有一个单独的分支，我们仅在部署之前合并主分支
- 如果在测试过程中客户发现错误，他会将任务返回以进行修订，并将其状态设置为已返回以进行修订。 这样我们就可以将新任务与未通过测试的任务分开。
- 因此，所有任务从创建到完成：待办事项→开发中→代码审查→准备部署到开发→开发上的质量检查→（返回开发）→准备部署到生产→生产上的质量检查→完成
- 每个开发人员都独立测试他的代码，包括作为站点用户。 除非确定代码可以工作，否则不允许将分支合并到主分支中。
- 每项任务都有优先级。 优先级由客户或团队负责人设定。
- 开发人员首先完成优先任务。
- 如果系统中发现不同的错误，或者一项任务由多名专家共同完成，开发人员可以相互分配任务。
- 客户创建的所有任务都会交给团队负责人，团队负责人会对这些任务进行评估，然后要求客户修改这些任务或将其分配给其中一名团队成员。
- 所有准备部署到开发或生产的任务也会交给团队负责人，由他独立决定何时以及如何执行部署。 每次部署后，团队负责人（或团队成员）必须将此情况通知客户。 并且还将任务的状态更改为准备好进行开发/继续测试。
- 每天的同一时间（对我们来说是 12.00 点）我们在所有团队成员之间举行会议
- 会议上的每个人，包括组长，汇报他们昨天做了什么以及今天打算做什么。 什么不起作用以及为什么不起作用。 这样整个团队就知道谁在做什么以及项目处于什么阶段。 这使我们有机会预测并在必要时调整我们的估计和截止日期。
- 在会议上，团队负责人还谈到了项目中的所有变更以及客户未发现的当前错误的级别。 所有错误都会被整理出来并分配给每个团队成员来解决。
- 在会议上，团队负责人向每个人分配任务，考虑到开发人员当前的工作量、他们的专业培训水平，并且还考虑到特定任务与开发人员当前正在做的事情的接近程度。
- 在会议上，团队负责人制定架构和业务逻辑的总体策略。 之后整个团队对此进行讨论并决定进行调整或采用此策略。
- 每个开发人员在单一架构和业务逻辑的框架内独立编写代码并构建算法。 每个人都可以表达自己的实施愿景，但没有人强迫任何人这样做而不是其他方式。 每一个决定都是合理的。 如果有更好的解决方案，但现在没有时间，那么就在fat中创建一个任务，以供将来重构某部分代码。
- 当开发人员承担一项任务时，他会将其转移到开发状态。 所有与客户澄清任务有关的沟通都落在开发人员的肩上。 可以向团队领导或同事询问技术问题。
- 如果开发人员不理解任务的本质，而客户也无法清楚地解释它，那么他就会继续下一个任务。 团队负责人将采用当前的方案并与客户进行讨论。
- 每天，开发人员应该在客户的聊天中写下他昨天完成了哪些任务以及今天将完成哪些任务
- 工作流程按照 Scrum 进行。 一切都分为冲刺。 每个冲刺持续两周。
- 冲刺由团队负责人创建、填充和结束。
- 如果项目有严格的截止日期，那么我们会尝试大致估计所有任务。 我们将它们组合在一起进行冲刺。 如果客户尝试向冲刺添加更多任务，那么我们会设置优先级并将一些其他任务转移到下一个冲刺。
b) 与客户合作的过程
- 每个开发人员都可以而且应该与客户沟通
- 不能允许客户强加自己的游戏规则。 有必要以礼貌和友好的方式向客户表明我们是我们领域的专家，只有我们必须建立工作流程并让客户参与其中
- 理想情况下，在开始实现任何功能之前，有必要为该功能（工作流）创建整个逻辑过程的流程图。 并发送给客户确认。 这只适用于复杂且不明显的功能，例如支付系统、通知系统等。 这将使我们能够更准确地了解客户到底需要什么，保存该功能的文档，并确保我们自己免受客户将来可能说我们没有按照他的要求做的情况。
- 所有图表/流程图/逻辑等。 我们将其保存在Confluence/Fat中，并要求客户在评论中确认未来实施的正确性。
- 我们尽量不给客户增加技术细节的负担。 如果我们需要了解客户的需求，那么我们会以流程图的形式绘制原始算法，以便客户可以自己理解并纠正/修改所有内容。
- 如果客户在项目中发现错误，那么我们会要求您在zhira 中详细描述它。 它是在什么情况下发生的、何时发生的、客户在测试过程中执行了哪些操作顺序。 请附上屏幕截图。
- 我们每天（最多每隔一天）尝试部署到开发服务器。 然后客户开始测试功能，项目并没有闲着。 同时，这向客户表明该项目正在全面开发，没有人给他讲童话故事。
- 经常发生客户不完全了解他的需求的情况。 因为他正在为自己创建一个新的业务，其流程尚未建立。 因此，一种非常常见的情况是，我们将整段代码扔进垃圾桶并重新设计应用程序逻辑。 由此可见，您不应该用测试涵盖所有内容。 通过测试仅覆盖关键功能，然后仅进行保留是有意义的。
- 在某些情况下，团队意识到我们没有按时完成任务。 然后我们对任务进行快速审核并立即通知客户。 作为摆脱这种情况的出路，我们建议按时推出重要且关键的功能，并将其余的留给发布后。
- 如果客户开始从他的头脑中提出不同的任务，开始用手指幻想和解释，那么我们要求他向我们提供一个页面布局和逻辑流程，该逻辑应充分描述整个布局的行为和它的元素。
- 在承担任何任务之前，我们必须确保此功能包含在我们的协议/合同条款中。 如果这是一个超出我们最初协议的新功能，那么我们必须为此功能定价（（预计完成时间 + 30%）x 2），并向客户表明我们将花费这么多时间来完成它，加上截止日期按估计时间乘以二进行调整。 让我们更快地完成任务 - 太好了，每个人都会从中受益。 如果没有，那么我们已经为您提供了保障。
c) 我们在团队中不接受的：
- 缺乏承诺、缺乏冷静、健忘
- “喂早餐。” 如果你无法完成任务并且不知道如何完成，那么你需要立即通知团队领导，而不是等到最后一刻。
- 一个尚未证明自己能力和专业水平的人的皱眉和吹嘘。 如果它被证明了，那么在正派的范围内这是可能的:)
- 各种形式的欺骗。 如果任务未完成，则您不应将其状态更改为已完成并在客户端聊天中写入其已准备就绪。 电脑坏了、系统崩溃、狗咬笔记本电脑——这一切都是不可接受的。 如果确实发生不可抗力事件，必须立即通知团队负责人。
- 当专家始终离线并且工作时间很难联系到他时。
- 队伍中不允许有毒害行为！ 如果有人不同意某件事，那么大家就聚在一起集会，讨论并决定。
我有时会向客户提出一些问题/论文，以消除所有误解：
- 你们的质量标准是什么？
- 如何判断一个项目有没有问题？
- 如果违反我们关于更改/改进系统的所有建议和建议，所有风险仅由您承担
- 项目的任何重大更改（例如，各种额外流程）都可能导致出现错误（我们当然会修复这些错误）
- 几分钟之内不可能了解项目发生了什么样的问题，更不用说立即修复它了
- 我们致力于特定的产品流程（Zira 中的任务 - 开发 - 测试 - 部署）。 这意味着我们无法回复聊天中的整个请求和投诉流程。
- 程序员只是程序员，不是专业的测试人员，无法保证项目测试的正确质量
- 最终测试和验收生产任务的责任完全由您承担
- 如果我们已经承担了一项任务，则在完成当前任务之前我们不能立即切换到其他任务（否则这会导致更多错误并增加开发时间）
- 团队中的人员较少（由于假期或疾病），但工作量较多，我们没有时间回应您想要的一切
- 我们要求您在没有在开发人员上测试任务的情况下部署到生产环境 - 这只是您的风险，而不是开发人员的风险
- 当您设置的任务不明确、没有正确的流程、没有设计布局时，这需要我们付出更多的努力和实施时间，因为我们必须代替您做额外的工作量
- 任何有关错误的任务，如果没有详细描述其发生情况和屏幕截图，都不会让我们有机会了解出了什么问题以及如何修复此错误
- 该项目需要不断完善和改进，以提高性能和安全性。 因此，团队将部分时间花在这些改进上
- 由于我们按小时加班（紧急修复），所以我们必须在其他日子进行补偿
通常，客户立即就会明白软件开发中的一切并不那么简单，仅靠愿望显然是不够的。
一般来说，仅此而已。 我把大量的谈判和所有流程的初始调试留在了幕后，但结果，一切都顺利了。 我可以说这个过程对我们来说成为了一种“银弹”。 来到该项目的新人从第一天起就可以立即参与工作，因为所有流程都被描述，并且图表形式的文档和架构立即让我们了解了我们在这里所做的事情。
PS 我想澄清一下，我们这边没有项目经理。 它是在客户这边。 根本不是技术人员。 欧洲项目。 所有沟通均仅使用英语。
祝您的项目中的每个人好运。 不要精疲力尽，并尝试改进您的流程。
来源在我的 .
来源： habr.com
