2.Web开发过程流程图

转自:https://blog.csdn.net/hello_simon/article/details/19993343

最近公司在进行一系列新模块的开发,在痛苦开发的过程中,大家不时在一起进行总结等思维体操活动。上周六中午加班,几位同事一起聊了聊最近协同开发的感受,我从中受益匪浅。

首先提到过于民主化的开发模式导致了交流成本的增加,这些成本分散了研发人员真正用于开发的精力,显得很不划算,但是针对这个现象,一直没有可行的解决 办法。其次是一些具体的合作开发模式导致无法控制整体进度。我们按照自己的思路,针对目前的实际情况,勾勒了一个理想化的开发流程。

  点击左上角图片可以看到这个流程图,以下是对各个字母所代表的连线的注解:

  a、项目经理与公司决策层的沟通,以确定这个需求有没有足够的人手和可行性去实现,以及与现有产品的依存关系。
  b、公司决策层与市场/策划部门的交流,这个过程将进行的相当充分,并且是反复、长期的,它致力于从用户的角度对需求进行细化和分解。
  c、市场部门需要针对细节问题与项目经理交流,以确定这个需求有没有可行性去实现。
  d,e,j、这是整个产品的架构设计过程,分为ui架构设计和程序架构设计两部分。首先架构师需要与项目经理达成思想上的一致,随后进行设计。这个设 计必须是便于分工、维护和扩展的,而且要能够承受一定强度的原型开发压力。ui架构师将根据界面逻辑对产品实施分割,对每个界面上需要放置的内容了如指 掌。程序架构师在与全体开发人员民主讨论后,制定出自底至顶的程序层次(例如class、library等等),并划分出功能模块(例如首页、内容列表、 后台管理、帮助系统等等)。ui架构师与程序架构师之间需要就功能划分、文件命名规则等等达成一致意见,并不断在开发中完善思路。
  f、美工使用photoshop等工具设计界面,并完成图片切割工作。
  g、网页设计师负责书写静态模板。如果人手缺乏,这个位置可从程序开发人员中抽调。
  k、美工与网页设计师之间需要进行一些协调。一些美工的设计思维并不能完美的体现在网页上,因此需要不断的磨合与修正,达到双方都满意的结果。但相对来说,美工完成的作品并不需要做太多的改动,因此这里采用单向箭头标示。
  h、对底层逻辑(如类、方法、库的设计),以及相关文档的整理。如有精力可以进行小规模的测试,确保日后的开发工作顺利进行。
  i、当底层接口以及相关文档完成后,模块化的拼接将变的比较轻松,这个流程将完成基本模块到外部功能的构建工作。
  l、这是程序开发人员需要付出最多交流成本的地方。很多的底层模块在拼接过程中需要进行变动,例如增减参数,修改类、属性、方法的名称,将类、属性、方法移动位置等等。同时,外部的实现需要随着底层模块的更改、优化进行相应的调整。
  m、产品成型后,将交付测试部门进行测试。测试部门返回一个报告,发送给项目经理和程序开发人员。在小规模的开发团队里,项目经理可以充当质量保证的角色,前提是他对项目的开发过程有一定程度的了解,否则,应当指派一名专门的质量保证人员来处理bug列表。
  n、测试部门返回的报告本来是可以发给所有程序开发人员的,但不幸的是,测试人员只跟界面打交道,他们只注重结果,而不注重实现原理。因此bug列表 一般需要交给负责界面逻辑的开发人员进行整理,然后分发给各个成员加以更正。在小规模的开发团队里,界面逻辑和底层逻辑可能是由相同的一批人来实现的,那 么他们需要一个bugzilla来协同处理这些bug。我们也建议测试人员使用同一套bugzilla系统提交bug报告。

 

  最后总结几点:一、详细分工的目的是为了降低交流成本。二、实际情况会使得开发工作复杂化,所以流程模型要能适应原型开发工作。三、文档和标准化的规范是极其重要的,它可以使开发过程工厂化,提高代码质量和可维护性。

 

最近公司在进行一系列新模块的开发,在痛苦开发的过程中,大家不时在一起进行总结等思维体操活动。上周六中午加班,几位同事一起聊了聊最近协同开发的感受,我从中受益匪浅。

首先提到过于民主化的开发模式导致了交流成本的增加,这些成本分散了研发人员真正用于开发的精力,显得很不划算,但是针对这个现象,一直没有可行的解决 办法。其次是一些具体的合作开发模式导致无法控制整体进度。我们按照自己的思路,针对目前的实际情况,勾勒了一个理想化的开发流程。

  点击左上角图片可以看到这个流程图,以下是对各个字母所代表的连线的注解:

  a、项目经理与公司决策层的沟通,以确定这个需求有没有足够的人手和可行性去实现,以及与现有产品的依存关系。
  b、公司决策层与市场/策划部门的交流,这个过程将进行的相当充分,并且是反复、长期的,它致力于从用户的角度对需求进行细化和分解。
  c、市场部门需要针对细节问题与项目经理交流,以确定这个需求有没有可行性去实现。
  d,e,j、这是整个产品的架构设计过程,分为ui架构设计和程序架构设计两部分。首先架构师需要与项目经理达成思想上的一致,随后进行设计。这个设 计必须是便于分工、维护和扩展的,而且要能够承受一定强度的原型开发压力。ui架构师将根据界面逻辑对产品实施分割,对每个界面上需要放置的内容了如指 掌。程序架构师在与全体开发人员民主讨论后,制定出自底至顶的程序层次(例如class、library等等),并划分出功能模块(例如首页、内容列表、 后台管理、帮助系统等等)。ui架构师与程序架构师之间需要就功能划分、文件命名规则等等达成一致意见,并不断在开发中完善思路。
  f、美工使用photoshop等工具设计界面,并完成图片切割工作。
  g、网页设计师负责书写静态模板。如果人手缺乏,这个位置可从程序开发人员中抽调。
  k、美工与网页设计师之间需要进行一些协调。一些美工的设计思维并不能完美的体现在网页上,因此需要不断的磨合与修正,达到双方都满意的结果。但相对来说,美工完成的作品并不需要做太多的改动,因此这里采用单向箭头标示。
  h、对底层逻辑(如类、方法、库的设计),以及相关文档的整理。如有精力可以进行小规模的测试,确保日后的开发工作顺利进行。
  i、当底层接口以及相关文档完成后,模块化的拼接将变的比较轻松,这个流程将完成基本模块到外部功能的构建工作。
  l、这是程序开发人员需要付出最多交流成本的地方。很多的底层模块在拼接过程中需要进行变动,例如增减参数,修改类、属性、方法的名称,将类、属性、方法移动位置等等。同时,外部的实现需要随着底层模块的更改、优化进行相应的调整。
  m、产品成型后,将交付测试部门进行测试。测试部门返回一个报告,发送给项目经理和程序开发人员。在小规模的开发团队里,项目经理可以充当质量保证的角色,前提是他对项目的开发过程有一定程度的了解,否则,应当指派一名专门的质量保证人员来处理bug列表。
  n、测试部门返回的报告本来是可以发给所有程序开发人员的,但不幸的是,测试人员只跟界面打交道,他们只注重结果,而不注重实现原理。因此bug列表 一般需要交给负责界面逻辑的开发人员进行整理,然后分发给各个成员加以更正。在小规模的开发团队里,界面逻辑和底层逻辑可能是由相同的一批人来实现的,那 么他们需要一个bugzilla来协同处理这些bug。我们也建议测试人员使用同一套bugzilla系统提交bug报告。

  最后总结几点:一、详细分工的目的是为了降低交流成本。二、实际情况会使得开发工作复杂化,所以流程模型要能适应原型开发工作。三、文档和标准化的规范是极其重要的,它可以使开发过程工厂化,提高代码质量和可维护性。

转载于:https://www.cnblogs.com/sharpest/p/8003911.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值