您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 需求管理 > 正文

需求变更管理你?还是你管理需求变更?

发表于:2018-10-05 作者:Allan 来源:博客园
  最近做外包有很多感悟,比较之前做产品的开发,外包显得更紧张一些,在时间上卡的紧。
  有时候想好好的做一个具有高性能、高可维护性、高可扩展性的优雅的设计,可是到最后,发现总是在时间紧迫中草草的收尾,或者偏离初衷。
  上司是个不爱技术的程序员~他的开发格言是用最普通的办法(最好不用设计不用思考抬手能做的办法),最快的时间干完活,交活之后啥都不用管,然后做下一个项目。
  可以理解这是标准的向钱看的做法。
  而我呢,总是对项目有一堆的想法要尝试,这种情况下时间观念上的冲突显得尤为突出,且不讨论谁目光长远吧,回归正题。
  接下来想讨论的是,如何管理好需求变更,如何在我们紧张的项目时间上有条不紊的拥抱变化,在有限的时间内做更有意义的事。
  项目变更的起因有很多种,比如:
  1.新的业务或市场条件导致产品需求变更
  2.新的客户需求,要求更改系统产生的数据、和系统提供的服务
  3.企业改组扩大/缩小规模,导致项目优先级或团队成员变更
  4.预算或进度安排限制,导致产品重新定义。
  面对这样多的变化,首先我们应当摆正心态,坦然的接受变化,而不是抵触变化。需求变更存在整个软件开发周期之中,无论是前期设计开发,还是后期的测试验收,无处不在,如果你一见到需求变更就心烦,哈哈,那么,可以确切的告诉你一定是个天天不开心程序员。
  那样的生活太黑暗了……
  怎么样来改变呢,行之有效的处理各种变化是彰显我们设计能力的时候。什么的设计能力?设计高可为维护性软件的能力!
  当变更发生,首先确认参与者职责。
  职责:
  1.在需求变更发生时项目经理的职责是:
  2.通知变更:保证通知到每一个利益成员。
  3.组织变更评估:评估必须所有共同利益者参与
  4.做好记录: 防止日后没有查询依据,无法追溯。
  5.跟踪变更进度
  6.开发人员的职责
  7.实现维护代码变更控制的技术
  8.收集变更影响范围。
  9.评估变更时间。
  基线:在需求变更中一个重要的概念。
  随着时间流逝,所有参与者得到丰富的知识,这些知识成为了变更的推动力,并且造成了很多软件工程师难以接受的事实:
  大多数变更是合理的!
  在这样的情况下,我们就要制定基线。它能帮助我们在不阻碍合理变更的条件下控制变更。
  有变的就要有不变的,所谓不变就称为架构。在成为基线之前我们可以随意的地变更。然后一旦成为基线,就像单向的门要经过全体参与者的评审。