目录
- 如何对需求不确定的创新产品进行分析和设计？
- 分析策略
- 原型法
- 基本思想
- 开发步骤
- 原型处理方法
- 优点
- 持续集成
- 概念
- 持续交付
- 持续部署
- 开发流程
- 未来的图书
- 读者的角度
- 作者的角度
- 参考链接
如何对需求不确定的创新产品进行分析和设计？
在实际的软件或系统开发中，需求分析是很费时费脑的事。
一方面，在软件开发初期我们对于产品的预期效果没有一个准确的衡量标准；
另一方面，甲方的需求变的比翻书还快，正如：
哈哈，上面的图纯粹娱乐。
客户的需求总是变这点我也很能理解，需求变才说明软件有生命力，人总是要求越来越好的嘛。
分析策略
在接受客户需求多变这个现实的基础上，用我们的专业技术来做到客户需求变动后我们的调整最小，这个包含技术和服务两方面。
技术上我们尽可能的把架构，代码做得耦合点，梳理出容易变动的部分和不容易变动的部分，用好架构，模式和各种效率工具；
服务上，尽可能的先让客户在没开发前看到实际的软件效果，包含如何交互体验的，怎么展示的等等，减少因为双方理解不一样而导致的调整。
在具体的软件设计中，是采用的什么
设计方法来解决需求的不确定性呢？
以下给出两种方法供参考。
原型法
基本思想
先开发一个简单版 本，即功能少、界面简单的版本，然后再对这个简单版本逐步进行改善（添加或修改功能）， 直至完全满足用户需求。初始精简版程序称为原型（prototype）。
开发步骤
原型法的开发步骤共分为以下四个步骤
确认基本需求；
创建原型；
向用户演示或交付用户试用，获得反馈意见；
改善原型；回到（3），重复（3）、（4），直至用户最终认可
可见，原型技术不是对整个问题按照“设计、实现、测试”的过程来开发，而是先按此过程创建一个原型，然后根据用户反馈再重复此过程来改善原型。
这样，通过许多“设计－ 实现－测试”小循环，原型逐步得到改善和扩展，直至成为最终产品。因此原型法也称为“螺 旋式开发”。
原型法适合于大型程序开发中需求分析难以一次完成的场合，也常用在程序用户界面设计领域。
原型处理方法
原型法开发中的原型可以有两种处理方法
（1）一开始构造的原型就是最终产品的核心，后续工作都是对原型的改善，通过不断的积累和修改最后得到符合用户需求的产品。开发过程中，原型尽管功能不完善，但一直是可用的，甚至可以作为在最终产品交付前 的替代产品
（2）初始创建的原型只是作为与用户进行交互的工具，通过不断展 示给用户看而获得反馈并改进。等到用户认可原型，该原型即被丢弃，开发者将基于用户已经确认的需求开始正式开发产品。这种做法称为“快速原型法”，因为其主要目的是尽快构 造系统模型，强调的是开发速度。
优点
- 用户可以通过实际使用的体验来评价软件产品是否合意，而不是仅凭开发者口头的描述；
- 开发者和用户可以在开发过程中发现以前没有考虑到的需求 或问题；
- 开发者可以在产品开发的早期就获得用户反馈，避免在开发后期来修改设计，因为越往后，修改的代价就越大
持续集成
概念
持续集成指的是，频繁地（一天多次）将代码集成到主干。
它的好处主要有两个。
（1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
（2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
Martin Fowler说过，"持续集成并不能消除Bug，而是让它们非常容易发现和改正。"
与持续集成相关的，还有两个概念，分别是持续交付和持续部署。
持续交付
持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
持续部署
持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。
持续部署的前提是能自动化完成测试、构建、部署等步骤。
开发流程
根据持续集成的设计，代码从提交到生产，整个过程有以下几步。
提交
流程的第一步，是开发者向代码仓库提交代码。
所有后面的步骤都始于本地代码的一次提交（commit）。
第一轮测试
代码仓库对commit操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。
测试有好几种。
- 单元测试：针对函数或模块的测试
- 集成测试：针对整体产品的某个功能的测试，又称功能测试
- 端对端测试：从用户界面直达数据库的全链路测试
第一轮至少要跑单元测试。
构建
通过第一轮测试，代码就可以合并进主干，就算可以交付了。
交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。
常用的构建工具如下。
- Jenkins
- Travis
- Codeship
- Strider
Jenkins和Strider是开源软件，Travis和Codeship对于开源项目可以免费使用。它们都会将构建和测试，在一次运行中执行完成。
第二轮测试
构建完成，就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。
第二轮是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。
需要强调的是，新版本的每一个更新点都必须测试到。如果测试的覆盖率不高，进入后面的部署阶段后，很可能会出现严重的问题。
部署
通过了第二轮测试，当前代码就是一个可以直接部署的版本（artifact）。将这个版本的所有文件打包（ tar filename.tar *）存档，发到生产服务器。
生产服务器将打包文件，解包成本地的一个目录，再将运行路径的符号链接（symlink）指向这个目录，然后重新启动应用。这方面的部署工具有Ansible，Chef，Puppet等。
回滚
一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。
未来的图书
书在人类社会的发展中扮演着重要的角色。
我们从小学开始就背诵这些金句：
读书破万卷，下笔如有神
书籍是人类进步的阶梯
书犹药也，善读之可以医愚
这些名人名言都在述说着书籍、读书对于一个人的发展是何其重要。
然而，现在还有多少人能够真正静下心来好好地读完一本书呢？
做研究的关注文献、论文；做开发的关注博客、github。
在上个世纪还担负着知识唯一载体的书似乎突然就变得没那么重要了，甚至于纸质书都面临着消亡的危机。
那么，图书该如何发展才能追赶并再次成为主要的信息、知识载体呢？
下面通过读者和作者两个角度，对未来的图书进行畅想。
真的是畅想。。若您觉得荒谬，还请一笑而过。
读者的角度
我平常爱看一些科幻小说，因为这些图书的作者构思实在奇特。
就拿之前的《流浪地球》来说，虽然在理论上不可能实现，但是带着地球脱离太阳系这种事想想都觉得神奇。
但是有时候读书的时候，你会感到困惑：因为你发现你get不到作者写这段话的意义何在，也就是说你没办法脑补了。这是很令人苦恼的。
那么，如果未来的图书能够在你打开书本的瞬间将你带到作者所营造的世界，这样的图书似乎就有意思起来了。
未来的图书可以结合
VR以及人工智能技术
在用户读到精彩的桥段时，通过探测读者此时肾上腺素的浓度，可以分析出读者此刻对于当前阅读的文字很感兴趣，那么此时就可以通过虚拟现实技术来为用户营造一个与文字适配的氛围。
未来的VR还可以根据读者阅读的书籍的不同来构建虚拟现实，打开一本玄幻小说，就能够带着读者快速了解作者所构建的世界，这样便不会有斗气化马这种事了。
作者的角度
从作者角度来看，自然希望自己的书看的人多且收益高是最好的。
但是就目前而言，无论是纸质书还是电子书，这两点在短时间内都难以做到。
从一个普通的读者看来，我在选购书籍的时候会很纠结，因为我不知道这本书的内容是否对我有所帮助或者它的故事是否精彩。
我一般来说都是通过豆瓣读书的评分等判断的，也就是说仅通过作者和书籍的名字我很难下决心要不要买这本书，特别是在这本书还是刚刚出版的情况下。
那么，我联想到电影在上映前常常会有一个
预告片，以此来吸引观众。因此，图书是不是也能够结合之前提到的
VR，由AI技术分析整本书后大概展现书中的精彩、亮眼的部分，以此来吸引读者们。
这样，通过这种形式的推广，读者就能够很直观地感受到这本书的内容好坏，从而好的图书就会鹤立鸡群、快速地传播开来。
***
参考链接
原型法
原型法：MBA百科
阮一峰
开发模型
知乎问题