敏捷文档真的轻了吗?

ke, 08 June 2020

[ agile  ]

在日常辅导团队的过程中有一个问题是大家问的比较多,直观上理解有些困难,更别说实际的使用。“敏捷需要文档吗?”这个问题,在一个组织对于不同的角色,同一个角色但不同开发背景的人,答案都不一样。这篇文章想由浅入深的对敏捷开发需要的文档进行讨论。

简单的答案是“需要”。

敏捷开发和瀑布流程对文档的要求

我们知道敏捷开发和瀑布流程在开发周期时间上明显不同,一个是迭代开发,迭代周期(1~4周),一个是阶段-门限开发,周期(1~n月),在交付一个可运行的小功能上两种开发方式需要的时间明显不同。敏捷只需要几周,瀑布则需要按月来交付。这个周期时间的不同会导致在文档上花的时间的不同。

如上图我们说敏捷开发是轻文档,而瀑布是重文档式的流程。

重量级文档流程

先来说重量级文档,在瀑布流程下,我们被要求从商业分析,市场分析,产品需求收集,产品设计,开发分析,开发,UT,测试,集成测试,系统测试,到发布这些阶段,对应于商业需求文档(BRD), 市场需求文档(MRD),产品需求文档(PRD),概要设计(HLS),详细设计(LLS),测试策略,测试计划,测试用例,测试报告,整个开发流程大概需要这些文档。Winston W. Royce(瀑布流程发明者,1970年发表)认为开发流程和制造业的流程相似,如果在每个阶段我们都做好充分的分析设计,那么整个项目最终是不会有很大偏差的。 到这里我们要回答两个问题:

  • 这个理论正确吗?
  • 1970发明的方法还适用于现在的市场环境,商业环境和研发技术吗?

这个理论正确吗?在不考虑任何成本的情况下,花更多的时间在每个阶段可以提升每个阶段的正确性。在后续任何阶段发现错误,都可以回到最初的阶段。比如在测试阶段发现前面有个功能的设计错误了,那么完全可以回到产品需求收集阶段进行修改,同时进行相应文档变更,PRD,HLS,LLS,测试用例变更。那么这个理论正确吗?在不考虑任何成本的情况下,这个理论可行。但如果考虑成本呢?

我们在一个产品或项目构建的早期,能想清楚所有要解决的用户问题,所有的功能,所有的技术依赖吗? 经验说明根本不可能,不然变更控制委员会(CCB)设立来做什么?就是变更太多控制不住,需要一群人来控制。


我们的业务,领域知识是随着产品不断的开发过程中,不断学习获得的,如果前期在缺乏大量产品知识的时候,我们要进行大量的需求设计,这时期会产生大量的低质量需求,大量错误的假设导致后期的返工。

1970发明的方法还适用于现在的市场环境,商业环境和研发技术吗?

大家回想一下1970年代的产品与技术,那个时候以科研系统为主流,unix系统在那时诞生,使用汇编和C语言为主要编程语言。那个时候市场竞争并不激烈,计算机还没有用于个人。所以在70年代左右开发的系统复杂,昂贵,而且没有多少市场竞争,开发一套系统往往耗时几年。这个时候开发一套系统成本很高,周期很长,使用重文档的流程开发,产生的浪费,往往被高成本,长时间的交付掩盖住了。

到了现在个人市场,商业市场都有了长足的发展,交付周期被缩短到了几周,甚至于每天上线多次。重文档的流程弊端凸显,要么根本就无法完成这些文档,要么对文档进行大量的裁剪,要么文档落后代码几公里再也无法同步。在快速高效的开发流程里写出这些高质量的文档变得不可能,也不必要,因为这些文档从一开始价值就不高。重文档流程的组织在商业交付上越来越慢,最后深陷泥潭,被新型的独角兽企业一遍又一遍的冲击,最后不得不转型开发流程寻求突破。

敏捷开发中的文档

敏捷文化在90年代后期开始逐渐重塑了整个软件行业。以重视反馈,减少浪费,团队协作为核心,整个开发文档也遵循其核心价值。
那么在敏捷中我们怎么写文档,才能高效,高质量,低成本的完成我们的交付呢?

关于需求文档:

之前说到在前期业务人员,市场人员,产品经理会输出BRD,MRD,PRD,这些文档的目的和价值是什么呢?
这些文档的核心目的是帮助组织的业务目标和产品对齐,在敏捷里面不仅希望目标对齐,同时还希望最大化使用这些文档,通过这些文档实现以下目的:

  • 业务目标和产品目标对齐
  • 理解的一致性
  • 文档和代码保持一致
  • 自动化验收系统

这样可以最大化的提升文档的价值,文档用于业务人员,产品经理,开发人员,测试人员理解一致,文档和代码始终一致可以实时反应代码情况,同时文档又用于产品交付的自动化验收。

用户故事

敏捷里面提倡使用用户故事来描述需求,通过用户故事团队随时讨论,澄清需求,同时通过用户故事的验收标准(AC),帮助开发团队各角色明确需求的验收范围。 通过用户故事的INVEST原则,帮助我们提高交付效率,理解需求价值。

用户故事的INVEST原则

实例化需求

敏捷里面提出了实例化需求的一组模式,帮助达到上述的目标,在实例化需求里面提倡:

  1. 产品要从商业目标去得到需求的范围,要理解需求背后的”why”“who”,理解商业用户期望的结果是什么
  2. 需求是协作产生的,通过工作坊商业干系人,领域专家,开发团队一起完成需求的梳理和澄清
  3. 使用实例来描述需求,开发团队和商业用户一起识别系统的关键实例
  4. 精炼实例,实例需要呈现用户的需要,避免过多的实现细节
  5. 实例化需求实现自动化验收

前面几点还是比较容易理解,主要第5点很多产品经理觉得不可思议了,我写的需求还可以变为自动化验收测试系统?是的,现在有很多支持实例化需求的平台,如: Concordion,FitNesse.

Concordion实例化需求:

自动化验收框架:

这里不具体讲解实例化需求验收部分,这个以后专题讲解。

关于设计文档:

说了需求部分,那么开发设计部分呢?以前的HLS,LLS怎么更有价值,减少浪费呢?

敏捷里面认为:

  • 代码的设计体现在代码自动化测试里面,这样代码的设计通过自动化测试代码实现,这时测试代码和实现代码保持一致,通过测试反应方法设计意图,反应功能设计的意图。
  • 领域模型,领域的知识用领域模型反映,通过领域模型实现开发人员和领域专家理解一致性
  • 通过富文本注释实现,代码不仅要自注释,而且通过图文并茂的富文本注释体现设计思路

UT
领域模型
富文本注释

关于测试文档:

在测试方面,提倡代码质量集体负责,测试人员并不是最后的守门员,而是作为测试专家,把测试方面的技能传递给开发人员,让开发人员对自己的功能充分测试,并完成自动化单元测试,自动化验收测试。最后测试文档变成了一个一个的自动化测试用例代码。

总结:

在如今要求高效率,高质量快速交付的环境下,敏捷的轻量级文档流程,并不是真的“轻”了,而是聚焦于消灭成本高,浪费高,价值低的文档,通过自动化的方式提升文档的价值。作为产品,开发,测试的人员更需要锻炼基本功,提升整个交付过程的效率和质量。