详细设计
首先为什么需要详设？
肯定有人会喷，现在都谈敏捷了，你那是瀑布那一套了，现在谁还弄详设，然后就被鄙视了。如果是这样我就想问下，什么是敏捷？什么时候应该敏捷？先回答好了这两个问题再BB，哥也是经历过敏捷的人，13年在一家做数字工厂的创业公司，被公司副总忽悠做项目经理，当时作为一个码农的我来说，本身比较迷茫感觉天天敲代码不是我要的，觉得白富美离我太远。所以就想做产品经理，憧憬做一个响当当的产品出来，享誉中国，当然我得解释一下，此产品经理不是被玩坏的那种UE产品经理，而是正儿八经的产品经理。刚好遇到此副总，跟我聊了后就看上我了，美其名曰看上我的才，觉得我有当产品经理的潜力，然后我就飘飘然的去了。去了之后就让我先从项目经理干起，这儿的项目经理只管项目（需求调研、文档编写、项目资源协调…）不管技术。副总当时推得就是敏捷，因为本身干的是传统行业，一开始都是瀑布过来的，副总觉得瀑布有很多问题，所以准备推敏捷，我当时也是第一次接触敏捷，所以老大丢给了我一堆书，其中一本我记得是叫《敏捷项目管理》的书，然后就让我抱着啃，也恬不知耻的跟着其它项目组体验了敏捷的落地…。那段时间是我悠闲、迷茫的时光，一开始用latex跟公司弄宣传册，然后跟项目，去鸟不拉屎的地方，夏天跟客户喝着“枝江”聊着需求，其实挺怀恋的…。
扯远了，后来在现在的公司，公司又请人做了一次敏捷培训，内容其实跟我之前看的书差不多，只是里面有一个概念是我比较深刻的就是讲师说了一个词语叫“小瀑布”，大概意思就是取敏捷和瀑布的各一部分。为什么呢？就是因为传统的瀑布确实是太重周期太长了，而且对客户的要求高，因为瀑布都是白纸黑字写好合同定功能需求的。你想想客户如果没想好，那是不是就麻烦了。但是事实是往往客户是不可能百分百知道自己要什么的或者说不可能百分百描述清楚自己要什么的。这个时候敏捷就有优势了，敏捷在我看来其实就是工作理念的转变，讲求的是快速迭代，讲求用户参与，讲求跨职能，这样就能很大限度的避免走偏。
小瀑布在我们团队是咋用的呢，主要包括：
- 首先团队是跨职能的，需求、产品、测试、研发都同属于一个团队，且团队的目标是一致的。
- 前期除了User Story，还会进行需求评审，会出UCD文档，研发会出详设。
- Daily Scrum不强制要求。
- 没有Sprint Review
为什么我们会这样是因为我们本身不是一家互联网企业，对快速响应要求没那么高，我们是一家传统的toB企业，有自己的产品，很少接项目做，有稳定的渠道，不过也存在瓶颈，在这样的情况下，做新产品，我们则采取了现在的小瀑布的形式。至少目前来讲是很适合的。
ok，扯得有点多了，我们还是来说说详设。
0.1版详设
因为之前的详设没有一个特别正式的模板，接着0.2功能迭代需要写详设，领导让我和另外一个同事整一个详设的样板出来，跟领导过了几次，搜集了一下意见，最终中心思想只有一个，让新旧研发、测试、技术大佬都能看明白。
所以最终出的模板是这样滴：
这个模板稍微复杂了一些，但是他的好处在于说明了上下文，说明了依赖项，说明了核心逻辑，所以基本上出来的东西大家都能看懂，也能而且能评估难度和工作量等。
0.2版详设
这版详设是在产品0.3.3迭代后出现的修改，是在0.1基础上的一些精进，精进了依赖项和核心逻辑说明。
- 0.2把外部依赖项单独拎出来，这样能更加清晰表述自己所需要的支持，并且让对方知道。
- 0.2把核心逻辑也着重提出来，0.1核心逻辑更多在于文字描述和UML图，0.2的要求是用伪代码+UML的形式进行核心逻辑的说明，核心思想就是贴近代码让详设更加实用。
详设最实用的地方：是为了让你思考更加缜密，并且获得反馈。
未来的期望：
当然这版详设也不是最终版，以后会持续精进，最终的目标是直接不要文档。
甚至我们刚进的一个架构师提出的愿景是：全部用类似单元测试的代码+注释的形式写详设，详设是否存在问题，看单元测试是否通过，我觉得是很美好的…..路很长。
名词解释
Sprint
可理解为一个迭代
Scrum
Scrum 可以理解成是一个框架，此框架让产品管理和工作技术的相对成效更加清晰地显现出来，以便您可以持续改进产品、团队和工作环境。
Daily Scrum
每日站会
User Story
用户故事，可以理解为一个场景或者一条需求。