如何避免分析瘫痪?

  分析瘫痪是项目的可怕黑洞。那么,如何认识到你可能处于分析瘫痪状态呢?以下是一些可能提示你的症状。             

  1. 需求发展似乎永远持续下去              
  2. 新版本的系统需求文档不断发布,同时也伴随着流失的感觉。             
  3. 大量实质性变更被引入基准之后,很久才被引入到业务需求文档中。             
  4. 为了“完整性”,所有需求都以多种方式使用许多不同的模型来记录,但是并没有增加任何清晰             
  5. 该小组被指示,需求完成后才可进行编码。             

  与其发现自己正陷于分析瘫痪中,不如从一开始就避免它,您可以执行以下操作:

  1. 记住,你的终端产品不是需求文档,而是软件。              
  2. 根据您的项目、时间表、团队文化等选择适当的SDLC。一些项目使用传统的瀑布方法工作得很好,而另一些则不能。             
  3. 你的要求永远不会完美。争取“足够好”,同时确保你避免了需求上的重大差距。当需求被认为是“足够好”和你将如何定义“足够好”时,作为一个团队来决定。问:在确定发展之前,什么是可接受的风险量?确定谁将审查需求,并成为决策过程的一部分,他们是“足够好”。这可能包括业务分析师、客户、内部利益相关者、开发人员和测试人员。
  4.  不要用“因为”来描述事物。模拟事务是个复杂的事,避免书面语言却过于简单。  
  5. 不要在需求部分的早期就进行UI设计。等到需求接近结束并进入SDLC的“设计”环节再开始。          

  这是一些能真正避免分析瘫痪的措施,但它也并不是万无一失。来源于Karl Weigers关于软件需求陷阱的一次演讲。

业务分析设计

猜你喜欢