产品开发经验总结..docVIP

[产品开发经验总结] 软件产品背后的冰山一角 2010-08-18 01:31 by 道法自然, 2042 visits, 收藏, 编辑 做一个正规的软件产品从来都不是一件简单的事情，除了产品本身涉及的技术因素之外，还有更多的非技术因素。本文仅描述一个小公司的团队在一个软件产品从想法到实现过程中涉及的工具和这些工具提供的功能与作用。由于我们经验有限，描述内容会有纰漏，请多多指正。不过，我们倒是体会到开发一个可用的产品有多困难了。反正呢，说或者说别人都要比自己亲自实践和实现来得容易的多得多了。因此，我也越来越觉得应该学会如何去尊重别人看似傻瓜的东西。就像有人在批评这个产品、那个产品，如果这个产品是你自己做的，你就不一定会那么说了。当然，也希望能够分享你们的任何想法和建议了。首先，我们来看一下，用户在使用我们产品涉及的大概的交互内容（A～D的图片可以快速浏览过去）。 A 安装包界面? 安装包功能选择：支持VS2005/2008/2010? 安装成功 B 安装后界面安装后文件夹 C 使用? 开发时可以使用模板快速建立一个宿主或者插件??Manifest编辑器远程控制工具，开发、调试和部署用 D 帮助和用户向导? API说明书??使用向导 在对上面一个产品有了一个大概的印象之后，我们便来看一下这个产品在设计和实现过程中涉及的一些东西。 1 想法 一个有意义的产品绝对是为了解决某些问题而诞生的，否则就没有任何价值。而价值的衡量是相对于其要解决的问题来评判的。如果一个软件产品并不是用来解决问题，基本就没有存在的意义。因此，有价值的想法，一般出自于你碰到的各种问题，如果你的一个想法能够解决很多人的问题，那么这个产品具有很高的价值了。 当然，要提出一个好的想法并不那么容易。并不是有了高价值的想法就可以去实践。事实上，有价值的想法仅仅是初步而已，因为这个想法还必须具有可行性。每一个有价值的想法也或多或少有其它的问题伴随而来。当综合考虑各个问题之后，我们或许才能够下一个比较理智的决定。不过，这个决定并不是那么容易的，我至今一直都在摸索中。 2 概念设计 当有了一个软件产品的想法后，我们便开始琢磨该如何来实现这个产品。一开始，我们对产品并没有太清晰的认识，比如产品要提供什么功能来解决用户的问题、这个功能如何来使用等等。这个时候意识比较模糊。 在概念设计阶段，我一般使用“白板 + 白板笔 + 带有相机功能的Touch HD”工具组合进行。使用白板笔在白板上做一些头脑风暴的快速设计，然后通过Touch HD照相，并且保存下来。保存下来以后可以打印然后贴在白板上做一些细化，直到头脑已经有了软件产品模拟运行的初步印象为止。概念设计图例 3 功能规范 概念设计仅是一些初步的图片，思维跨度会大一些。因此，需要有一个比较规范且易于理解的功能描述，即功能规范文档。这个文档是对概念设计的进一步细化。我们可以根据实际情况来设计。一般而言，功能文档会描述出系统的重要用例。不得不提到一点，设计一个复杂系统的时候，最好的方法是从High Level的方式来俯视整个应用系统，然后根据设计的机器、组件、人物、运行环境等比较大的因素来划分成不同的小系统，从而获取更多的细节。功能规范图例 4 用户使用场景说明书 此外，如果是SDK之类的产品，最好还需要设计一下每一个公开的API涉及的用户使用场景。用户使用场景是对产品发布后用户使用的模拟，从而可以优化API的设计。API设计的目标是确保50%～70%的功能能够让用户非常简单的应用，让剩下的功能可以是高级功能。用户使用场景说明图例 5 进度安排 该概要设计和功能规范设计的同时，我也会着手开始安排整个项目的进度。目前是直接采用Project。进度安排也是由上到下的方式开始，从大的开始，再细分任务，并根据每一个的能力初步估计一下大概时间。然后由不同的人进行审计，由他们再次更新进度。需要知道的是，进度不可能是准确的，一般而言，我们需要在整体估计的时间上上浮二十个点，甚至更高。进度安排图例 6 设计规范 设计是产品实现过程的一个重要环节，从Agile角度考虑，为了节省人力和时间，我们只是对一些重要的算法、重要的功能、重要的类进行比较详细的设计。当然了，我也相信简单的功能我们团队的这些人一定能够胜任。留下设计规范文档的好处是维护、测试，以及培训会来的容易的多。在我们产品开发中，我一般会把系统设计的接口类定义好、把重要的算法描述好，然后交由其它人开发实现。因此，我强烈推荐VS自带的类图工具。设计规范图例 7 实现 到这一步，我想实现应该比较简单了。只是要让团队形成一个统一的开发规范。我们使用了Framework Design Guideline中的设计与开发原则进行规范化的开发。FDS PPT，