1.2 需求分析与迭代计划
本案例是一个教学项目，它是一个小型的系统，其目标是作为本书的读者交流区，你将看到它如何从简陋走向完善。
它完全开源，有兴趣的读者也可以实际参与到它的功能扩展中。显然，如果我把代码都粘贴到本书中，编辑大人会跟我拼命的。所以我在本书中只摘录并讲解其中适合用来示范技术的功能。
完整的代码会作为一个开源项目托管在GitHub上：https://github.com/ng-nice/code。想要获取源码，请执行命令：git clone git@github.com:ng-nice/code.git，它会把项目源码下载到当前目录的code子目录下，里面会有README.md文件指引你如何运行本项目，以及如何参与开发。
1.系统隐喻
作为项目的第一步，我们会建立一个“系统隐喻”，也就是描述一下我们的系统类似于哪些现有系统，从而让项目组成员更形象地记住目标，也让客户更容易理解目标。当然，世上没有完全相同的系统，描述系统隐喻时要重点描述其与现有系统的不同点。
系统隐喻：一个迷你的论坛系统，侧重交流而不是宣传。与传统论坛/留言板系统相比，本系统更加重视对读者反馈意见的收集和自动化分析。
2.业务目标
系统隐喻过于粗略，接下来我们要定义一个业务目标，这是一个更明确的功能列表。但是，要注意，业务目标不仅仅包含“要做什么”，而且要包含“不做什么”。软件开发中有一个大敌，叫作“需求蔓延”。在这个阶段定义“不做什么”就是为了防范“需求蔓延”。
要做什么
（1）非功能需求。
每个系统只支持一本书。
支持多个作者（包括志愿者），数量预估在10人以下，不会超过百人。
支持多个读者，数量预估在千人左右，不会超过一万人。
防范XSS等常见前端攻击。
防范SQL注入、DDoS等后端攻击。
使用公认安全的后端权限框架，以免出现典型安全问题。
面向读者的功能需求。
允许读者注册。
允许读者登录。
不允许匿名发帖或+1。
对主题进行树状显示。
读者可以发布勘误，作者可以接受“勘误”，或标为“重复”。
读者可以发布问题，作者可以答复问题。
读者可以发布建议，作者可以接受“建议”，或标为“重复”。
其他读者可以对问题或建议进行+1操作，提升作者的关注度。
读者可以通过第三方搜索引擎搜索。
系统可以自动整理FAQ，供读者阅读。
（2）面向作者的功能需求：
作者可以答复问题。
作者可以删除不当主题。这里的删除不是真正的删除，作者仍然可以看到并恢复。
作者可以发布“读者调查”。
作者可以对特定主题进行高亮显示。
系统会自动从内容中提取一批关键字，同时作者也可以手动为文章设置一批关键字。
作者可以进行数据库搜索，不做限制。
支持上传图片和附件，图片和附件最大不超过10MB。
支持提交代码和显式：HTML/CSS/JavaScript/Java，不需要支持其他语言。
作者可以统计出所有提供过建议、勘误的读者，将名字列入下一版中的“贡献名单”。
出于安全原因，读者上传的非图片类附件需要作者审核后才能显示。
不做什么
不做多级权限，只区分作者和读者。
不支持手动配置权限，硬编码权限对应的操作。
不支持读者进行数据库搜索，但对读者的搜索关键字进行统计。
出于版权原因，不支持QQ等表情包，只支持普通的符号表情。
默认读者是善意的，不对内容进行预先过滤，只支持事后删除。
不做专门的回收站，而是让作者就地删除和恢复。
不做全面的视觉美化，但注重“操作友好性”。
3.需求分析
在真正的项目组中，会有一个集体估算“功能点/复杂度”的过程，但是作为单人开发者，就只好“独裁”了。
不过，比估算“功能点/复杂度”的具体数量更重要的是拆分任务、估算风险，并最终决定优先级。在排定优先级之后，我们可以把整个项目划分成多个阶段，每个阶段都可以发布可用的产品版本，这将带来多方面的好处：
产品可以尽早推出，尽早获得回报。
可以尽早为客户方建立信心，而获得客户方的信任，这对软件项目的成功至关重要。
可以尽早发现并控制风险。
可以给项目组成员一段休养时间，防止疲劳作战。
可以留出一些重构和回顾的时间，抽取复用模块。
我们将这些“阶段”称为“基线”（Baseline）。它的英文原词非常形象：多个项目阶段就像是一个个台阶，每完成一个阶段，我们就迈上一个台阶，站在一个稳固的基础（Base）上。有了基线，我们就可以对各期的目标进行隔离，即使下一期目标达不到，我们也随时有一个可用的版本。
这种交付方式称为“迭代式开发”，更形象的说法叫作“小步快跑”。
基线的粒度取决于所用的开发方式，对于敏捷开发，通常基线会划分到一周左右的粒度，即使是传统开发方式，也可以向这个方向努力。基线的内在形式是一个表格，通常包括编号、名称、价值、难度、风险、工作量、优先级等几项，建议用五级评估。其中：
价值是指此项功能对业务的重要性。这往往来自产品经理或客户代表。对于敏捷团队，还要让全体成员理解它的业务价值。要注意，业务价值是有时效性的，当前阶段迫切需要的功能会有更高的价值。随着业务的发展，这些业务价值也会相应变化。
难度是指根据项目组现有技术积累评估出的难易程度。比如“能处理每秒十万人同时下订单”对当前团队来说可能难度较大。难度主要决定人员分工，特别是人员能力。
风险是指不确定性。比如，假设我从来没集成过富文本编辑器，那么虽然我明知它应该很容易，但仍然是一个较高的风险。我可能评估难度为1，风险为3。再比如，我们的某项功能要和一个不够成熟的第三方系统对接，它就会具有很高的风险，可能评估难度为3，风险为5。风险决定项目安排，高风险的任务往往需要先开展SPIKE（技术预研），或者提前安排资源保障或制定备用方案。
工作量是指在一切顺利的情况下需要的时间。比如有些系统对视觉效果的要求非常严格，那么它虽然既没有难度，也没有风险，但是具有很高的工作量。工作量往往影响人员的分工，特别是人员数量。
优先级是前面几项的综合。一般来讲，排定优先级的依据是“性价比”，这里的“性”是指业务价值，“价”则根据难度、风险、工作量进行综合评定；如果时间紧迫，那么高风险的项目会被安排较低的优先级，也就是尽量推到后面的版本中实现；另一方面，如果一项工作不完成，后续的功能就无法实现，它也需要较高的优先级，比如读者注册。这通常由项目经理最终决定，敏捷团队中则往往由客户方和开发方共同商定。
项目管理中有一个误区，就是把本来不是很紧迫的任务故意排得很紧迫，希望以此来提高开发人员的“效率”，但是这往往适得其反—高收益高风险的需求会被缺乏安全感的项目组推到后续版本中。
当然，上面这几项也不是必须全都列出和准确估值的，可以根据不同的项目进行定制，比如团队沟通顺畅，或组里都是能力比较强的成员，那么难度、风险、工作量可以打包评估成一个“复杂度”项或干脆叫“点”。
基线的外在形式则比较多样，既可能是一个Word文档，也可能是一个HTML或Markdown文件，在敏捷开发中，则常常表现为一组故事卡（Story card）。至于采用哪种形式，取决于项目的组织架构和外在条件，没有统一的规定。只要让每个人随时都清楚自己的目标就可以了。比如我在个人开发中就把这些任务加到Evernote中，并且加上复选框，完成一项勾选一项，任务和进展一目了然。
需求评估表见表1-1。
在列出需求评估表之后，可以做出一个简要的项目基线了。
原则上，我们把优先级为5的需求划为第一条基线，部分优先级为4的需求也可以划为第一条基线。其他需求则留待未来实现，但不用提前决定它们到底属于二期还是三期。
于是我们得出了第一条基线，见表1-2。
4.定义导航图
需求分析完毕，我们需要定义一下导航图（Site map）。导航图主要用来体现页面之间的跳转关系。定义完导航图，就可以大致了解整个网站有多少个页面，以及各个页面的大体复杂度。
导航图可以有多种形式。如果需要演示给客户或者老板，那么可以安装一个FreeMind 软件来制作脑图。这个软件是开源的，并且支持各主流操作系统。如果要更高级的效果，也可以使用Sketch（Mac版的收费软件）等软件制作线框图。如果只是用作开发组内部交流，那么可以直接画在或贴在白板上，让每个人一抬头就能看到，这是敏捷开发中常用的方式。如果涉及远程协作开发，或者团队沟通环境不那么顺畅，那么也可以直接写成Markdown文件，并纳入版本管理。
我们先制作一个Markdown格式的导航图。
1.首页
1.发布问题
1.发布勘误
1.帖子(问题/勘误)列表/树
1. +1按钮
1.帖子详情
1.删除按钮（限作者）
1.高亮按钮（限作者）
1.搜索框（限作者）
1.统计（限作者）
1.帖子详情（含主贴、跟帖）
1.回复
1. +1按钮
1.删除本帖（限作者）
1.高亮本帖（限作者）
可以看到，从导航结构来讲，一期需求是非常简单的。这也是很多项目的常态，通过第一期的成功来树立开发方和客户方的信心，后面的开发就会顺利很多。这也是你凭借自己的专业性来对客户负责的表现。
如果第一期的需求很复杂，就要提高警惕了，这可能是项目管理不良或客户沟通不顺畅的信号。除此之外，一期需求过于复杂还容易导致过度设计，引入不必要的复杂性，给将来的重构工作带来困扰。
可以看出，导航图中有一些项其实指向同一功能，但是我们不用在这里消除重复，做导航图的目的是更直观地了解系统概貌，我们会在后面的阶段中消除这些重复。
5.第一个迭代
定义完一期需求，我们就要开始制订项目计划了。通过几次迭代方式来进行：
我们不需要制订一个庞大的计划，只需要划分出第一个迭代的任务就可以了。通常，每个迭代都不应该超过当前项目组一周的工作量。注意，必须根据“当前”项目组的能力进行估算。对于相互之间还不太了解的项目组，宁可使用比较保守的估计。确保第一个迭代的成功无论在维护士气还是客户关系上都非常重要。
把哪些功能放进第一个迭代也很有讲究。划分方式有纵向划分和横向划分两种。
纵向划分方式是一个功能一个功能完成，每开发一个功能就把它完全实现，做完的功能从数据库到用户体验都基本达到发布级质量。这种方式下，通常会把“被依赖”的功能安排在前面，比如用户注册、登录等。
这种方式的优点是只做已经明确的需求，减少无用功。进展到一定阶段后随时可以对外发布版本。这是最简单明了的方式，可能也是很多人正在实际使用的方式，不再展开讲。
横向划分方式是先搭一个粗糙的骨架（会走的骷髅），它难看、缺少细节（如数据有效性校验），但是能在第一时间把大部分流程串起来，甚至可以在第一个迭代进行中就邀请用户参与。在这个阶段中，UX（用户体验设计师）、BA（业务分析师）等可以并行工作：做样板页、细化用户故事。一部分没有任务的研发也可以同步进行SPIKE（技术预研）工作。
这种方式适用于对需求和业务知识还不太熟悉的开发团队，也适用于客户方的需求本身就不够明确的情况，基本上符合从原型演化到正式系统的节奏。对于配合默契的成熟团队，这种方式“高度并行化”的特点可以大幅度提高研发进度。
从表面上看，横向划分方式有点像瀑布模型，但其实并非如此。横向划分方式不是用文档去记载需求，而是用代码去演示需求，并且在尽可能早的时间点上把最终使用者引入开发过程中。
如果和客户沟通比较顺畅，那么很多表面看来应该放在第一期的需求可能会被推到第二期甚至砍掉，这样有助于控制需求的范围。同时，由于其“粗糙”的特点，其开发代价非常小，就算写出来再砍掉也没什么可惜的。
当然，在现实项目中，这两种方式往往是穿插进行的。
第一个迭代先做一个“会走的骷髅”，然后和客户沟通，同时UX并行设计样板页，BA并行写用户故事的细节。
从第二个迭代开始，把客户认为最紧迫的页面实现到发布级质量，提交测试。端到端的“场景测试”也可以开始根据上个迭代完成的“会走的骷髅”来写了，但只需要先保障“乐观流程”（Happy path）的正确性。
从第三个迭代开始，就可以针对已经完成的用户故事写场景测试和进行用户化测试了。
就本书而言，由于需求简单而明确，所以就直接采用纵向划分方式了，而且这种方式也有利于教学。但这并不表示纵向划分优于横向划分，而是它更适合于当前场景。
作为第一个迭代，我们划定的范围是：
10.注册
20.登录（认证与权限体系）
30.主题树
当然，这排不满一周的工作量，但是由于还要穿插写书工作，因此也是一个比较合理的划分。在教学上，它也能示范出足够多的Angular特性。