复盘一下最近接需求的开发过程

最近接了一个比较大的需求，复盘了一下自己这段时间的开发过程，总体觉得是寥寥草草的，开发的过程中很难受，有几个方面的感受：

1. 需求很大，无从下手。
2. 无从细化。做了一版软件设计之后就没有看得懂，mgr肯定是不管的，合作方又看不懂，就僵住了，然后就被催进度，踉踉跄跄地边写代码，边改代码，感受不到自己的设计能起多大的作用，只有了一个初始框架而已，然后就细化不下去了。
3. 感觉自己被推着走。各种利益方都提各自方面的适配需求，改了一个昏天黑地，每次改都要从头看一遍自己的代码，感觉自己写的代码，改到最后自己已经失控了。

我理解这过程中肯定是缺失了一些关键步骤的，才会如此难受，我觉得这个关键步骤应该是需求分析和详细设计。

需求分析阶段感觉可以分为功能点拆分、计划排期、功能归类三个部分。

功能点拆分

用户故事（英语：User story）是指在软件开发和项目管理中用日常语言或商务用语写成的句子。User Story 是用户需求的简化表达，用一两句话表达完整的想法。User Sotry 只要求写下最有价值不能被忘记的东西，而这些内容足够帮助估算工作量以及与客户沟通。

User Story强调通过一个简单的情境，具体的描述出软件在「使用人」的手上，是怎样被「操作」的。这样的描述可以让开发人员尽快能的贴近使用者的真实需求，而不是做错重点。

User Sotry 描述了一个又一个的情景，可以帮助开发人员和沟通人员达成一致的目标。常见的user story写法是：作为 <xxx角色> 我想要做 <yyy 的功能>，以便<实现 zzz 的好处>。一条 User Story 只能有一个 User 角色。

功能点排优先级

User Sotry可以帮助与客户之间进行很好的沟通，因为是情境描述文字，客户可以很轻松的根据这些情境排定优先顺序。将写出来的 User Story ，按照重要和优先级顺序分为三种类型：Must Have / Should Have / Nice to Have。然后只做 Must Have 部分，其次再做 Should Have，Nice to Have 部分暂时不做。

 

功能归类与接口定义

功能归类的一个明显标志应该是从user story转化为test case。

在形成test case之后就可以使用TDD的方法，定义接口，定义test case，最后定义接口的实现，完成开发的过程

详细设计——直面需求变更

在需求变更的时候，需要根据TDD的工作流，先变更test case，然后变更接口，最后变更接口的实现，这样一切就会井然有序。