三、“敏捷开发”下前端做的事情与他人的事情
看到的大多数技术博客都是前端技能点相关，很少有看到系统的关于前端开发流程的分析与研究。
1. 业务的开发流程
首先明确一点，我这里描述的是一个敏捷小组，包含人员有限，可以独立完成一个项目。这里之所以从业务的开发流程说起，是因为对于整个项目的流程属于更大的范畴，需要更多的人，甚至包含老板，因此，只能将范围约定到业务范围里面。对于整个项目，
当然，有人说，“前端没有业务”。
业务的特征：
- 可以被交付给客户的；
- 满足客户单个需求的；
- 可以在一个短期时间内完成的；
- 明确边界与范围；
- 可以被量化的；
对于单个业务，从项目的视角来看，开发流程如下图所示：
从前端的角度来看，如下图：
2. 前端需要做的事情
从上图中，我们发现，前端处于产品、UI人员的下游，后端人员的中下游，处于测试人员的上游；在提测阶段与测试人员互为上下游。
前端需要根据别的岗位的要求，完成：
- 需要根据产品文档，产出符合功能要求的软件产品；
- 需要根据UI人员的设计稿，产出样式合格的软件产品；
- 需要根据后端人员的接口返回数据，来填充软件的展示数据；
- 为测试人员提供可测试的版本，根据测试人员反馈的问题，来修改或者修复软件。
3. 前端难么
在许多人看来，前端开发并不难。这种误解源于大家在思考业务时，通常采用“流程控制”的思维方式来表达复杂性。以制作香烟为例，可能会被描述为：
- 制作过滤嘴；
- 制作烟草部分；
- 拼合在一起。
这种思维方式适用于状态流转非常确切的场景，如后端开发。然而，前端开发的过程更加复杂。通常，上面的3步只是前端开发需要首先实现基础结构。
在此基础上，还需要对美观性、舒适性等方面进行大量完善。而这些方面，客户和其他角色往往忽视，或者认为是理所当然的。对于客户能直观看到的事物，一般人会认为“不难”。
需求方通常认为，美观、舒适等细节简单且易于实现，因此这些内容常被忽略。人们有“抓大放小”的本能，但正是这些细枝末节需要前端开发投入大量时间来完善。
总结以下几点：
- 前端开发的基础结构部分确实不难，因此其重要性常被低估。
- 然而，在美观性和易用性方面，前端开发需要投入大量时间和精力，这些地方会产生许多细节和不可预知的情况。
此外，前端开发者在处理大量细节时，通过脑力难以全面感知和衡量。经验表明，在业务需求开发上，前端代码复用性较低。例如，第一次开发登录功能可能需要3个工作点，第二次开发即使流程一致，也仍需3个工作点。
综上所述，尽管前端开发在基础结构部分并不复杂，但在细节完善上需要大量时间和精力，这一点常被忽视和低估。
4. 前端,请提出你的要求
很少看到前端开发人员对“上下游“提出过要求，明确界限。
首先，我们看一下前端在一个迭代计划里面的完整生命周期
可以看到，真实的开发周期需要很多节点。每个节点，我们都要对合作岗位提出自己的 合理要求。这里，我罗列一下每个阶段，前端对于合作岗位的要求，以及前端在当前阶段需要做的事情。
由于流程太长，我这里用一张Excel生成的图片来说明（点击放大）。
总结
作为前端，要明白自己的定位，要明白开发的流程；
作为前端开发，一定要有自己的原则，明确自己的边界，明确他人的定位；
作为“底层”，一定要讲规则，有效利用规则，可以“保护”自己；
对于其他岗位，一定要“严格要求，宽于落地”；按照上面各个阶段对其他岗位的的要求，去要求其他岗位；提前把规则确立好，弹性的去验证“对于他人的要求”，“严于立法，选择执法”，这样才能让自己的工作更有效，才能做的更长久。
