2008年10月15日,星期三,06:21

在短时间内定义需求

由Martin Crisp撰写
最近的行业研究表明,现代软件项目平均将40%的精力用于返工。结果,超过60%的软件项目超支了预算,错过了计划,并大大减少了交付的功能。如果对如何设置需求没有一个清晰的想法,大多数软件开发项目将面临重大的返工或完全失败。 在过去的几年中, 敏捷方法似乎正在帮助减少这一问题。 本白皮书将探讨在敏捷团队中捕获需求的技术。

维基百科说:“ 敏捷软件开发 是指在整个项目生命周期中促进开发迭代,开放式协作和过程适应性的一组软件开发方法。”

因此,如果我们使用体育类比,那么使用敏捷方法来开发软件就像一系列的短跑比赛。开发人员仅专注于成功完成下一个迭代(通常要在几周之内完成),而他们则专注于定义实现该短期目标的要求。

换一种说法, 敏捷团队不会产生任何对于使团队清楚短期内的期望并不是绝对关键的需求规范。因此,问题就变成了:您如何确定“足够”满足下一个迭代的需求? 

在确定对敏捷团队的要求时,确定要提供什么技术以及提供多少细节级别时,需要考虑许多因素。 这些注意事项应包括: 

  • 团队规模和团队成员的接近度
  • 团队的技能和经验
  • 团队之前曾经合作过吗?
  • 要求的复杂性
  • 软件的复杂性。

牢记以上注意事项,您将需要确定要使用的技术以及使用这些技术时需要提供的详细信息。

常用技术包括:

言语交际。口头交流,也许使用白板来捕捉关键思想,通常是定义需求的最快方法。 但是,这种方法在最初的速度中所能弥补的,并不能确保所有利益相关者都参与其中。另外,与会人员可能并没有完全记得会议结束后的决定。 很难回忆起两周前讨论过的细节,这太容易了。 这可能会导致开发和测试期间对需求的误解,并将反映在不正确的产品用户指南和培训材料中。因此,您最初可能节省了时间,但从长远来看却浪费了更多时间。

那么,什么时候比书面交流更好? 敏捷方法可以促进面对面的互动,但是在团队分散在全球甚至整个城市的情况下,这可能是不切实际的。 仅依靠口头交流是不得已的选择,只有在短期时间收益比这种方法可能造成的长期问题更有价值的情况下,才可以使用。 

故事卡.  敏捷开发团队中一种流行且有价值的技术是创建故事卡。 这些故事卡往往会提供基于文本的描述,说明谁想做什么以及为什么要做,以及屏幕图片和一些测试场景。 该技术对于非常小的特征非常有效,但对于集成并依赖于其他特征的较大或更复杂的特征可能无法很好地扩展。 

需求清单。从产品范围界定出发,通常一个常见的地方是创建一个分层的“需求列表”,以文本形式捕获功能需求,技术需求,业务驱动因素等的有组织的分组列表。 这些文字描述通常足以清楚地说明要求是什么 例如,诸如“应用程序必须支持IE 6和IE 7”之类的技术要求实际上并不需要任何其他说明。 但是,诸如“应用程序必须能够定义哪些用户可以访问特定功能和数据”之类的要求将需要更多细节。 重点是仅扩展真正需要更多细节的需求。 

用例流程。有时为了真正理解更复杂需求的整体流程,需要用例流程或模拟来捕获“足够多”的需求。 但是,从我的角度来看,使用“用例”记录复杂的逻辑或业务规则(例如授权逻辑)通常不是一个好主意。这些类型的要求通常可以用文本或表格格式更好地记录下来。例如,一个简单的2x2表显示一个轴上的角色,以及它们在另一轴上可以做什么,这是一种比将替代流嵌入用例中更有效的方式来传达授权业务规则。

模拟。模拟可以为真正的概念带来巨大的价值,但是将每个细节添加到模拟中可能会花费太多时间。而且,坦率地说,开发人员有时很难对仿真进行逆向工程并提取一组离散的需求。 对于敏捷团队成员而言,阅读一张简单的表来显示谁可以做什么,要比进行模拟并对相同的信息进行反向工程要容易得多。而且,可能花费太多时间进行复杂的模拟,而这些模拟却没有为他们花费的时间和精力增加足够的价值。 

每个人在何时使用哪种技术传达需求方面都会有自己的偏好,但是关键是团队可以一起工作并就何时使用不同的技术达成共识,而不是在明显可以使用时“强制”使用某种技术。另一种方式更容易完成。

一般资料库。无论您决定使用哪种技术来记录需求,将这些需求详细信息/工件保存在中央存储库中并以​​有组织的方式将它们彼此链接对于敏捷团队的集体成功至关重要。 依靠人们来跟踪无尽的电子邮件踪迹以及带有手动维护的链接的简单文档存储库并不是解决之道。 人们太忙了,无法执行此操作,并且很可能数据存储库不会保持最新。 因此,任何存储库都需要尽可能地根据工件的组织方式自动创建和维护这些链接。例如,如果用例引用给定步骤上的屏幕,则该屏幕应自动链接到存储库中的该步骤。

那么,您怎么知道足够的细节呢? 当事情需要更多细节时,您的团队会通知您。 敏捷团队中的一部分工作是期望在整个项目中都需要澄清需求。 在传统瀑布中,这几乎是不鼓励的,并且是在变更管理的良好意图下进行的。 但是,在敏捷领域内,它是人们期望和接受的,这需要一些时间来适应敏捷新手。

回顾

这个主题比这篇小文章所涵盖的要深得多,但是关键点是

  • 在所需的细节水平上做出明智的决定,但希望在开发过程中进行调整。
  • 为您要描述的需求选择正确的技术。  
  • 确保您拥有一个集成的中央存储库,该存储库将多个需求工件链接在一起。 


马丁·克里斯普 是Blueprint Systems的CTO。可以通过以下方式与他联系 [email protected]

 

©BA Times.com 2020

麦格雷戈徽标白色网站