《实例化需求》读书笔记

背景

一直以来我都是从事软件研发、兼顾项目管理工作,在项目开发中,总是会遇到一些各种各样的问题,我也曾试图在项目中推动过类似于敏捷这样的项目管理方法,但是最终却收效不大。随着我工作经验的逐渐累积,发现不同的项目、不管是敏捷还是非敏捷、不管是如何失败的,其中对于用户需求的把控都是一个非常关键的因素。

用户需求,就是笼子里的狮子,你不放出来,受伤的是狮子,你放出来,受伤的是你自己。

在项目过程中,我们倾向于输出一份沉甸甸的需求文档,但是这份需求文档等项目做完了,往往会过时而用处不大。由于无穷次变更或开发者们对于需求的理解层次不同,设计业务领域的项目经理,显然不可能对软件的实现部分进行全方位的掌控,对于一些比较大的项目,掌握全局就已经很不错了,更不用说代码了,然而一切业务都凝聚在代码中,这些代码是如何实现用户需求的?
—-取决于开发者的经验,科学表明,一切靠经验来实现传承的知识体系,都是魔法。

概述

前段时间,我听张逸老师《领域驱动设计实践》课程中了解到《实例化需求》这本书,于是下单购买了,期待能获得一些启迪。
《实例化需求》是一本介绍软件工程方法论的书,这本书没有源代码、也没有特定工具的使用说明。在这本书中,他收集了来自现实世界、真实的团队以及切实的经验,同时也引入了一些建议,他希望通过这本书能够帮助大家使用这些组织过程或模式去建立活文档系统,从而提高软件项目的可控性。
在传统的项目开发中,尚且可以要求每个产品持续很长的时间,例如,一般都是以月为单位,甚至以年为单位。但是在互联网开发中,交付时间往往被压缩到一周为单位、甚至以天为单位,所以大量的前期软件设计和详细的需求分析环节将不复存在,而且传统的手工测试也耗时漫长,也被更加科学的自动化测试所替代。在这样的背景下,文档随时会过时,因此使用Axure原型软件设计高保真的UI交互原型是普遍的选择,如果有需求变更,就对原型进行修改,然后再通过原型推动功能的变更。
在作者的官方网站上,他认为《实例化需求》是一组过程模式,可以协助软件产品的变更,确保有效地交付正确的产品。 这里所说的正确产品,指的是该软件能满足客户或企业用户提出的商业需求,或者能达成预定的商业目标;同时它要具备一定的灵活性,未来能以相对平稳的投入接受后续改进。
作者认为,要有效的构建正确的产品,传统的软件开发实践首先需要满足一下几点:
1、保证所有项目干系人和交付团队的成员都对需要交付哪些东西有一致的理解。
2、有准确的需求说明,这样交付团队才避免有模棱两可和功能缺失造成的无谓返工。
3、有用来衡量某项工作是否完成的客观标准。
4、具有指导软件团队或团队结构变更的文档。
而基于Axure进行设计再推动职能团队完成功能开发的模式,看似满足了上述目标,避免了过度的需求文档造成的浪费、也能够很好的解释用户需求,但是却更关注于用户交互过程、无法涉及面子之下的里子、返工和功能维护让需求的验证过程变得越来越不可控,终输出的软件产品,顶多只能算一个花里胡哨的绣花枕头而已。
由于软件产品每周都要交付,作者认为,比较合理的解决方案应该带来如下好处:
1、避免过度说明需求从而产生浪费,避免花时间在开发前会发生改变的细节上。
2、有一种可靠的文档,可以解释系统的行为,据此我们可以很容易的修改系统行为。
3、可以有效地检查系统行为与需求说明的描述是否一致。
4、以最小的维护成本维护文档的相关性和可靠性。
5、适合短迭代和基于流的过程,这样能为即将开展的工作提供技术足够的信息。
这也是实例化说明渴望达到的目的,作者对许多企业进行了访谈,总结了实例化需求的应用案例,他认为通过引入实例化需求可以达到以下收益。。
1、更有效的实施变更。作者将其中的最重要的经验称为活文档(living documentation)的广泛应用是有长期受益的。这本书广泛涵盖了这一部分的内容。文中如是说

“活文档是系统功能的一个信息源,它与程序代码一样可靠,但易于使用和理解。它能帮助团队共同分析变更所带来的影响并讨论潜在的方案。团队还可以为新的需求扩展已有的文档,长此以往,可以使得需求说明和实施变更更有效。”

2、更高的产品质量。由于预期明确,验证变得更有效率。
3、更少的返工。由于需求写作更好,使团队确保对预期达成共识。
4、同一项目不同角色的活动协调得更好。改善写作形成定期的交付流程。

关键过程模式

作者总结了在实施实例化需求中的一些关键过程模式:
1、从目标中获取范围。许多软件在开始之前,期望由客户、产品负责人、商业用户来确定工作的范围,而商业用户明确他们的需求之后,软件交付团队就依次实现,但是由于用户不是专业的软件设计师,因此他提出的需求,固然是他所要求的,但并非是他真正需要的。所以关键模式就是从目标中获取需求,用户专注于传达所需功能希望达到的目的和期望由此带来的价值,而交付团队则致力于提出解决方案。
2、协作需求。不依赖于个人去收集正确的需求,而是与商业用户一起协作指定解决方案,这可以让我们充分利用团队的知识和经验,还创造了需求的集体所有制,让每个人都能参与到交付过程中。
3、举例说明。在编程语言实现过程中,成功的团队不会等待需求被精准表述,而是举例说明需求。用一些额外的实例用于说明边界情况,或重点标识出系统中某些特别有问题的地方,这样可以清楚功能分歧和不一致的地方,避免由误解或解释不到位导致的返工。
4、提炼需求。关键实例必须精简才有用,通过移除多余信息并为开发和测试过程创建一个具体、精确的上下文。软件的目标是该做什么,而不是该怎么做。
5、自动化验证时,不改变需求说明。
6、频繁验证。通过频繁验证,团队可以快速发现系统与需求说明之间的任何差别。团队成员可以更好的与用户交流,并决定如何处理。他们可以不断地同步系统和可执行的需求说明。
7、演化成活文档系统。活文档系统告诉系统可以做什么,并与代码一起确切可靠,但具有更好的可读性。

问题思考

这本书与其他介绍软件理论的书籍一样,知识量比较稠密,阅读过程中花费了不少时间,如豆瓣上有网友说的:

读一本书,如果能给你带来一点感悟,那就赚回书钱了。如果带给你两三点感悟,花费的时间也就值了。如果带给你五六点,甚至七八点,那就可以为作者捐款以示感谢了。**。**

这本书也是大概如此,书的重点其实是引入行为驱动开发(BDD),并让需求变得可执行的过程,让这套方法论实践起来大概需要花费更长的时间,但是也可以成为软件设计者们思考的一个方向。
个人认为,引入Cucumber这样的自动化测试工具,使用行为驱动设计的方法进行软件需求的描述编写活文档、然后再将其引入到测试过程中,或许有点难,但是也可以尝试使用这样的分析方法来设计我们的需求。
尤其是当需求不明确的时候,如果使用原型分析法或其他描述方法来定义需求,往往可能不够具体,则可以考虑使用图表或实际例子来描述,并创造性的给角色取一些花名,可以让需求的描述过程变得更加的生动。


1、《https://www.infoq.cn/article/specification-by-example-book/》《实例化需求》采访与书评。