携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第9天，点击查看活动详情
本系列文章的上一部分讲到了互联网公司中敏捷开发的基本流程里的第一步，需求调研。在需求调研完成后，就可以输出需求调研结果了。需求调研结果的质量直接决定了下一阶段产出——需求说明书的质量。正所谓是“先苦后甜”，其实软件开发领域也大抵如此，在前期做的工作多，那么后面的工作相对来说就会轻松不少，这个观点在后续的流程中还会不断提到。
需求说明书，要从一个用户的视角来提出用户故事（user story）。这里有很多不错的工具，可以帮助梳理用户故事。UML中的用例图，就是一个不错的工具。用例图包括参与者、系统边界、用例，这其中还可以使用一些特殊的语义，比如继承、包含、扩展等。在这一阶段，产品需求和技术需求的差异在于，技术需求的描述相对而言更偏向白盒一点，比如可能会把请求和响应中一些具体字段的要求都定义清楚。
这里顺便讨论一个用例图这个工具里面我个人认为比较有迷惑性的一个语法，那就是扩展（extend）和包含（include）。其实只要记住一点即可：假定A包含B，即用例图中A指向B，则去掉A，B将无法使用，假定D是C的扩展，即D指向C，则D是对C的增强型描述，暗含的意思是在事件流中C执行的情况下D不一定需要执行。
在需求说明书写完后，就要进入需求评审环节了。这里根据公司、团队规模的大小，可能会存在类似初评、细评这样的环节。这是因为公司规模大了之后，团队分工会更加细致，可能会出现跨团队的协作，那么此时就会有人力的安排冲突，需要根据优先级以及其他因素进行协调与采取折中策略。如果一个公司一开始只有10个人不到，那可能每个人都基本需要是全栈工程师才能cover所有业务研发的推进，但是如果一个公司如果有了100、甚至1000个人，那么此时可能就会分化出更多负责展示层逻辑的前端、客户端，以及更多负责业务逻辑实现的后端，这其中还会有更复杂的一些分工演进，在后面的文章中可能还会讨论到这块内容。
一旦涉及到协调，就需要引入项目管理工具。其实一款项目管理工具主要是依靠图这一数据结构来实现的，本质上是一个AOV网，也就是用顶点（或者叫节点）来代表具体活动，每个顶点都有自己的一些属性，其中比较重要的就是预计开始时间、预计结束时间、实际开始时间、实际结束时间，边（或者叫弧）则自然而然地代表着依赖关系，假如节点A有一条边指向节点B，那么代表着必须先完成A，才能进行B。这种将时间、人、依赖整合起来管理的方式对于合理地规划人力、让需求按期上线至关重要。
