减肥瘦身三部曲 - 敏捷开发
2010-12-24 13:08
218 查看
1) 注重概念和架构设计,而轻详细设计
敏捷开发中,注重概念和架构设计,而轻详细设计。这里的概念设计,可以看成是为什么要做这个产品或模块,强调的是产品的路线规划、市场趋势、客户价值、技 术趋势等。架构设计,可以看成从整体上看,概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。详细设计,则是具体的设计 和做法、API接口等。
一个产品,特别是面向行业的产品,概念设计和架构设计非常重要,需要考虑行业未来的发展方向,产品在市场中横向和纵向的比较,技术的发展方向,和每个模块 的投入和收益的比例等,这样才能尽可能保证产品沿着正确的方向前进。在产品中新增或删除一个模块需要非常谨慎,因为一旦新增模块被客户使用,以后就很难在 产品中去掉这个模块。还需要考虑产品各个版本之间的兼容性,以及客户的升级迁移。所以,在开始正式开发之前,通过概念设计和架构设计,梳理思路是非常必要 的。
2) SWOT分析
以前在做项目时,大多是从技术角度来考虑哪一些功能模块需要做,哪一些功能模块先做,而没有一个系统化的分析方法。造成的结果是有一些功能模块投入很多资源,却并不一定是客户最想要的。
在敏捷开发中,更加注重客户需求。如果对产品进行SWOT分析,就能选出付出最小工作量,但能获得最大价值的模块。
SWOT分析阶段会在概念设计和架构设计之后进行,输入是概念设计和架构设计,输出是模块的重要度和需要的时间。这样按照性价比可以进行排序,选出最能符合市场的模块。
一款产品哪个模块重要,哪个先做,需要花多少资源和时间投入,花这么多时间和资源的模块是否在客户心中有相应的重要程度等,这些都是由这款产品的市场策略来决定。所有产品都是为了市场和赢利为目的,Agile方法更好地帮助企业实现了这一点。
3) 业务和客户,而非技术驱动
这点说是体会,也可以说是教训。在我们的产品开发过程中,在某一新版本中重新设计了老版本的某一个重要模块,而引发了几个问题:一是,新版本的模块和老版 本模块的兼容性问题,导致老版本客户无法平滑的迁移到新版本;二是,新版本的改进是纯技术方面的重新实现,不管对客户而言,还是对内部的架构而言,都没有 明显好处;最后导致的结果是我们花了很多资源和人力去重新实现,但是在最后由于种种考虑还是废弃了重新实现的模块,依然沿用老模块。
在产品的敏捷开发中,虽说拥抱变化,但不盲目变化。产品的改动需要经过概念设计、架构设计以及SWOT分析后,三思而后行。敏捷开发中也强调"在整个项目开发期间,业务人员和开发人员必须天天都在一起工作",确保技术人员能够开发出客户需要的产品。
4) 时刻考虑版本兼容性
敏捷开发,废除了过多冗余的文档和繁杂的设计,强调拥抱变化。但作为产品,敏捷开发不意味着盲目地去变化。
当设计变动、API接口重构、配置文件变更时,要时刻考虑产品的架构、规划路线图,老版本的兼容性,及迁移平滑性。否则,随着版本的增多,必将面对着大量的维护工作。
5) 轻文档,但非无文档
敏捷开发强调沟通的重要性,而轻冗余文档。但敏捷开发并不意味着无文档。在敏捷开发过程中,适量的文档还是很有帮助,有助于整理思路,加快沟通和讨论。
我们产品中的文档包括:概念设计文档、架构图、当前版本要实现的功能列表,以及SWOT分析。
这些文档在每个产品版本开始之前会有产生,在每个迭代的过程中根据业务人员和市场的反馈也会有一些变更。通过我们实践证明,这对产品的思路、沟通讨论都非常有帮助。
而且这些文档,大多是几页PPT,书写和维护工作都很小。
敏捷开发中,注重概念和架构设计,而轻详细设计。这里的概念设计,可以看成是为什么要做这个产品或模块,强调的是产品的路线规划、市场趋势、客户价值、技 术趋势等。架构设计,可以看成从整体上看,概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。详细设计,则是具体的设计 和做法、API接口等。
一个产品,特别是面向行业的产品,概念设计和架构设计非常重要,需要考虑行业未来的发展方向,产品在市场中横向和纵向的比较,技术的发展方向,和每个模块 的投入和收益的比例等,这样才能尽可能保证产品沿着正确的方向前进。在产品中新增或删除一个模块需要非常谨慎,因为一旦新增模块被客户使用,以后就很难在 产品中去掉这个模块。还需要考虑产品各个版本之间的兼容性,以及客户的升级迁移。所以,在开始正式开发之前,通过概念设计和架构设计,梳理思路是非常必要 的。
2) SWOT分析
以前在做项目时,大多是从技术角度来考虑哪一些功能模块需要做,哪一些功能模块先做,而没有一个系统化的分析方法。造成的结果是有一些功能模块投入很多资源,却并不一定是客户最想要的。
在敏捷开发中,更加注重客户需求。如果对产品进行SWOT分析,就能选出付出最小工作量,但能获得最大价值的模块。
SWOT分析阶段会在概念设计和架构设计之后进行,输入是概念设计和架构设计,输出是模块的重要度和需要的时间。这样按照性价比可以进行排序,选出最能符合市场的模块。
一款产品哪个模块重要,哪个先做,需要花多少资源和时间投入,花这么多时间和资源的模块是否在客户心中有相应的重要程度等,这些都是由这款产品的市场策略来决定。所有产品都是为了市场和赢利为目的,Agile方法更好地帮助企业实现了这一点。
3) 业务和客户,而非技术驱动
这点说是体会,也可以说是教训。在我们的产品开发过程中,在某一新版本中重新设计了老版本的某一个重要模块,而引发了几个问题:一是,新版本的模块和老版 本模块的兼容性问题,导致老版本客户无法平滑的迁移到新版本;二是,新版本的改进是纯技术方面的重新实现,不管对客户而言,还是对内部的架构而言,都没有 明显好处;最后导致的结果是我们花了很多资源和人力去重新实现,但是在最后由于种种考虑还是废弃了重新实现的模块,依然沿用老模块。
在产品的敏捷开发中,虽说拥抱变化,但不盲目变化。产品的改动需要经过概念设计、架构设计以及SWOT分析后,三思而后行。敏捷开发中也强调"在整个项目开发期间,业务人员和开发人员必须天天都在一起工作",确保技术人员能够开发出客户需要的产品。
4) 时刻考虑版本兼容性
敏捷开发,废除了过多冗余的文档和繁杂的设计,强调拥抱变化。但作为产品,敏捷开发不意味着盲目地去变化。
当设计变动、API接口重构、配置文件变更时,要时刻考虑产品的架构、规划路线图,老版本的兼容性,及迁移平滑性。否则,随着版本的增多,必将面对着大量的维护工作。
5) 轻文档,但非无文档
敏捷开发强调沟通的重要性,而轻冗余文档。但敏捷开发并不意味着无文档。在敏捷开发过程中,适量的文档还是很有帮助,有助于整理思路,加快沟通和讨论。
我们产品中的文档包括:概念设计文档、架构图、当前版本要实现的功能列表,以及SWOT分析。
这些文档在每个产品版本开始之前会有产生,在每个迭代的过程中根据业务人员和市场的反馈也会有一些变更。通过我们实践证明,这对产品的思路、沟通讨论都非常有帮助。
而且这些文档,大多是几页PPT,书写和维护工作都很小。
相关文章推荐
- 减肥瘦身三部曲 - 敏捷开发
- 敏捷开发产品管理系列之三:产品用户群规划
- 如何从架构和测试推动敏捷开发_课程大纲
- 《 敏捷软件开发》已开始连载
- 11月10日 14:00~16:00 上海敏捷开发沙龙
- 【敏捷开发】浅谈对Agile Scrum的认识
- 张左峰的歪理邪说 之 对于瀑布式开发和敏捷开发在网游开发中的应用
- 敏捷开发之Scrum扫盲篇
- 敏捷开发不利于架构设计?
- 从持续交付看敏捷开发的自相似性(敏捷开发的心跳)
- 敏捷开发中的MoSCoW优先级排序方法
- 敏捷开发原则
- 软件开发模式介绍和对比(瀑布、迭代、敏捷等)
- 敏捷开发学习笔记——用户故事与多职能团队
- 敏捷开发
- 敏捷开发一千零一夜读书笔记之敏捷初探
- 一个使用敏捷开发平台构建的应用系统
- 敏捷开发中史诗故事与用户故事的颗粒度
- 敏捷开发“松结对编程”实践之六:大型团队篇|后记(大型研发团队,学习型团队,139团队,师徒制度,人员招聘,职业生涯规划)
- 敏捷开发流