新兴船
快速摘要：一个项目即将失败。每个人都觉得这不能满足最后的期限。但该应用最终按时发布且没有错误。那怎么可能？
我想告诉您一个宏伟的为期两个月的项目背后的真实故事，我的团队完成了该项目，对我们的组织产生了巨大影响。以开发人员为领导者，这是一次非常压力，挑战性和充满惊喜的旅程。我打算揭示为什么情况变坏，以及前端团队如何通过一套明智的决策来设法驾驭自己的船。
故意从前端的角度对项目进行解释，以避免出现模糊的演示文稿的风险。
来自六个部门的9个人总共被分配了两个月的时间（大约9周）。 UX设计是预先完成的，因此不包含在总持续时间中。
快速成长的公司通常会投资于新员工并改变层次结构。在涉及的所有9个人中，有2名是新员工（PO和设计），有2名具有一年的组织经验，在所有6个团队中，有3个是新组建的，其余的则进行了一定程度的重组。新成立的UX团队广泛地关注Figma中的UI，由内容管理员提供的翻译支持，这些内容管理员可以转换部门。最重要的是，使用PO构建应用程序对我们来说是新的-这些职责过去曾经由项目经理来履行。
整个图片中我在哪里？您可能知道答案。是的，我也是新成立的前端开发人员网络应用程序团队的一员。直到这一刻，我们仍位于围绕特定长期公司产品组成的不同跨职能团队中。
动态的环境，新的同事，新的公司结构。对于期限紧迫的雄心勃勃的项目而言，这是危险的组合。
该应用程序的目的是使客户能够轻松地找到其订阅数据并对其进行操作，从而大大减少了相关支持凭单的数量。
为了使事情变得更复杂，该项目必须考虑所有产品开发过程中拖延的所有服务，附加产品和用户边缘情况。
休假回来后，我立即陷入了困境，不知道这个新项目是关于什么的。所有计划和修饰会议都已经过去，并且已经组建了团队。同时，它留给了各个方面以某种方式进行自我组织并找到自己的出路。我感到非常不舒服和焦虑：没有任何信息可以开始，没有初始设置，但是最明显的事实可能是缺乏明确的领导。为了填补空白，许多项目管理任务“自然地”分配给了前端团队，从那以后需要额外的时间进行协调。
简要说明一下：通常，项目失败是由一些常见因素决定的。尼古拉斯·扎卡斯（Nicholas Zakas）在他最近的时事通讯之一（“对错误的思考”中）将它们归类为：技能，运气和隐藏信息。通过这种组合，它们会影响决策的结果，但是所有这些通常都适用于IT项目。
除少数例外，您可以控制决策所需的技能，还可以发现隐藏的信息（尽管有时看不到什么地方），但是运气完全不受控制。
回到这个故事，我不得不承认，这是一个隐秘信息的雷区，直到最后一个版本发布时，这些信息才会弹出。存在所有所需的技能，甚至更多。从来没有发生过意料之外的事件，如果您愿意的话，可以称其为运气。发现和处理看不见的用例或错误的假设是该项目最常见的瓶颈。
没有专职的PM或没有完全可用的项目负责人会导致经常分心处理组织活动。
对领域的理解不够充分（尤其是对新员工而言）与开发过程中后期发生的更改数量有关。位置越高，效果越差。
领域知识的空缺导致不明确或过于狭窄的需求，这是由于在计划阶段没有积极地让具有良好认识的人参与。
如果将人员聚集在一个跨职能部门的项目周围，则不必协调六个不同的团队将是不必要的工作。
当然，所有这些含义并没有让我们放弃，而是被迫（至少是前端开发人员）刻意解决代码和管理方面的问题领域。
但是，您可能会问，为什么开发人员应该分担组织负担？您不能简单地将其传递给采购经理或高层管理人员吗？毕竟，这是他们的工作，您只是在编写代码，对吗？这些都是合法的问题，我们问了很多遍，尽管如此，该项目最终还是由开发团队故意领导的。我们是负责开发的人。
无论团队何时发现自己处于项目风暴中，IT实践都可以证明，最好的策略是让经验丰富的开发人员在船上航行。这应该继续进行，直到可以在具有计划阶段和迭代的正常温度下运行该过程为止，换句话说，当风暴已经过去时。
极限编程（XP）的创建是为了响应需求变化的问题领域。您的客户可能对系统应该做的事情不甚了解。您的系统可能会每隔几个月更改一次功能。在许多软件环境中，动态变化的需求是唯一不变的。这是XP将成功而其他方法无法成功的时候。
何时应该很好地使用XP的引言描述了我当时所处的情况。我们的技术研究团队处于领先地位，因为：我们了解质量保证和后端开发人员对领域的了解，我们的前端团队可以提供快速的反馈循环，我们更接近UI，并且足够灵活以允许后期更改。
这是正确的举动。应该将这种情况视为特殊情况，但应尽可能避免。没有什么比固定工作，尽力而为好了，而PM则负责处理跨团队链接。每个人都坐在他们的座位上，不会有太大的惊喜。话虽如此，我也理解这很大程度上是一厢情愿的想法。严酷的事实是，大多数公司都不敏捷，或者没有遵循任何结构化的方法，也没有采用诸如SCRUM或看板之类的框架。我是看板迷，但即使是它的明显好处也很少足以说服组织如今尝试一下。尽管进行了无休止的讨论，并在诸如SCRUM fx。之类的敏捷框架上进行了大量投资，但大多数公司都依赖XP，即使他们没有意识到这一点。开发人员的职责与PM，市场营销，SEO，设计等重叠，这不是巧合。
我们在前端制定了灵活的策略来应对项目的不确定性，并迅速意识到仅凭出色的代码不足以使我们取得成功。
我的同事都是技术熟练的人，很少面对他们无法解决的技术挑战，而零星的事件（例如Covid-19危机）非常难以预测，也很难为之准备。考虑到这一点，该策略的重点主要放在处理隐藏信息上，并最大程度地减少其对项目的负面影响。
解决每个问题最终将在整个过程中促进更多的数据发现，并为您提供方便的工具来处理传入的变更请求。
我决定对这个突如其来的项目采取积极行动，并举行了启动会议，以组织所有人并建立起一定的信心。议程是：
这是第一次见面的机会，让您有一种感觉，项目终于在进行中。进一步的定期同步会议被设置为讨论阻止者，进度或以前收集的新信息。
显而易见，质量保证和后端团队最了解大多数基本用例。在这种情况下，两项活动有所帮助：
每天都要进行部署，因此质量保证和后端始终可以执行一些操作。
在这里讨论自上一版本以来的任何新发现，并将它们转变为开发任务。
不完整的需求通常是在“最终” UI设计中“解决”的，并且通常在QA将他们的手放在前端原型上时才被捕获。以下配方用于回答：
发行带有虚假后端和英文文本的可用原型以允许快速反馈循环是一个好主意，因为通常可能还不存在端点，翻译和可用于生产环境的文本也可能正在进行中。
当使用频繁更改的先决条件（其中WET代码库将启用几乎没有副作用的快速干预）时，DRY原理毫无用处。
频繁的更改通常会带来技术债务。处理显式代码的一种方法是编写显式代码，并在相同的位置/组件中进行少量重构来传达每个调整。这项投资在以后的每一次变化中都会得到回报。
无论如何都要保持高测试标准。他们保证没有错误的发行版。为每个新功能或边缘情况编写测试很重要，因为它还利用了我们对成千上万个新添加和删除的混乱状态的信心水平。
最差的组合之一是主动编码的程序员，他同时需要管理一个项目。必须以任何方式避免这种情况，或者如果不可能的话，在短时间内非常明智地使用它。
在组织同步会议和处理迭代循环时，我和我的同事通过轮班来分担负担。
从状态更新，需求讨论到会议计划，一切都在Slack中完成。
我必须承认我没有为这个项目加班。这会产生一种错误的成功感，进而欺骗您下次重复相同的错误。
通过应用上述策略，我们取得了令人惊讶的结果，我想提出一些数字。该项目本身并不冗长（9周），但是在任务和完成的迭代方面看来很繁重。在其艰巨的期限内启动，我们在发布后两个月的前端报告了零个错误-我基本上按了部署按钮并继续前进。同时，我们的工作在支持方面产生了巨大的影响，每周报告的与域名相关的门票减少了约250张。
与同一公司环境中的其他项目相比，XP项目一致报告了更高的程序员生产力。
“对错误的思考”-Nicholas Zakas撰写的“本月最佳通讯” Scrum已死。 所有的新国王Kail看板-从实际角度看看板相对于SCRUM的一些好处 WET代码库-Dan Abramov的视频，介绍为什么WET方法通常更适合代码协作。 该时事通讯包括前端帖子，我不会在博客上发布的想法以及对接下来的内容的先睹为快。
