别说敏捷了,你连瀑布都没做对
作者:Winston W. Royce 博士
译者:Seaborn Lee 李小波
审校:Lance Zhang 张宁宁
简介
计算机程序开发职能
一个更加宏伟的软件开发方法如图二所示。
图三描述了这种模式下的连续开发阶段之间的迭代关系。
我相信这个概念,但上面描述的这种实现方式有很大的风险并可能导致失败。图 4 呈现了这个问题。
必须注意的是,前面的讨论跳过了分析和编码阶段。当然,跳过这两个阶段而生产软件是不可能的,但通常这两步相对容易管理,而且对需求,设计和测试的影响也更小。在我的经验中,有完整的部⻔分析轨道力学,航天飞机姿态测量,有效载荷的活动的数学优化等等,但是当这些部⻔完成了他们困难复杂的工作后,后续的编码环节只涉及数行串行算法代码。如果在他们执行困难复杂的分析工作中犯了一些错误,也只需要对代码做一些微小的改动就能修复,不需要颠覆其他的开发基础。
不管怎样,我相信前面陈述的过程大体上是好的。后续的讨论,呈现五个附加的特性,必须添加到这个基本过程以消除大部分的开发⻛险。
第一步:先做程序设计
这个过程是如何实现的呢?下面的步骤是必须的。1)由程序设计师开始设计过程,而不是分析师或程序员。
2)冒着犯错的⻛险也要进行设计,定义和分配数据处理模式。分配过程,功能,设计数据库,定义数据库过程, 分配执行时间,基于操作系统设计界面和处理模式,描述输入和输出过程,定义预操作程序。
3)编写系统概览文件,要可理解,信息丰富的并且是实时的。每一个工作人员都必须对系统有基本的理解。至少 一个人深入理解系统,部分来自于不得不编写系统概览。
第二步:把设计文档化
偶尔,我也被叫去评审其他软件设计的进度。我的第一步是调查文档的状态。如果文档是严重缺失的,那么我 的第一个建议很简单。替换项目管理。停止一切与文档无关的活动。把文档完善到可接受的标准。没有非常高度的文档,管理软件开发是基本不可能的。举个例子,让我提供以下估算作为对比。要采购 500 万美元的硬件设备,我会期待一个 30 ⻚的规格说明,以提供足够的细节来控制采购。要采购 500 万美元的软件,我会期待差不多1500 ⻚的规格说明来达到相同的控制度。
为什么需要这么多文档?
1)每一个设计师,必须和接口设计师沟通,和他的经理沟通,也可能和客户沟通。口头的记录不够实在,不足以提供足够的基础来为接口或管理决策提供依据。可接受的文字描述强制设计师提供明确的位置和提供实在的完成的证据。它防止设计师隐藏在一月接一月的“已完成 90%”的现象。
2)在软件开发的早期阶段,文档是规格说明和设计。直到开始编码,这三个名词(文档,规格说明和设计) 指向同一个东⻄。如果文档不好,那么设计也不好。如果文档不存在,那设计也不存在,人们只思考和谈论设 计,有一些价值,但不多。
3)好文档真正的金钱价值,从开发流程中的测试阶段开始,并且持续为运行和重新设计提供价值。文档的价值可以被描述为三个每位项目管理者都要面对的具体场景,
a)在测试阶段中,有好的文档,管理者能够把工作人员的注意力集中在程序错误上。没有好的文档,每一个错误,无论大小,都会被一个人分析过,而这个人很可能就是一开始犯了这个错误的人,因为他是唯一理解编程领域的人。
b)在运行阶段中,有了好的文档,经理可以让专业的运行人员来运行程序,不仅更好地完成工作,还更便宜。没有好的文档,就只有构建这个软件的人才能运行它。相对而言,这帮人对运行的兴趣不大,也没有专⻔做运行的人做得好。必须指出,在运行场景下,如果出现挂起,首先挨骂的就是软件。不管是为了赦免软件, 还是平复指责,软件文档都必须清晰明了。
c) 在运行初期,当系统改进井然有序,好的文档让我们可以有效地重新设计,更新和改造某些领域。如果文档不存在,那么在重新设计时,通常整个已有的运行软件框架都得报废,哪怕是相对适度的改动。
图六展示了前文所述的各步骤对应的文档计划。
注意,这六个文档是在交付最终产品的过程中同步产生的,文档 1,3,4,5,6 是已更新和实时的。
第三步:做两遍
关于成功的第二条重要准则是围绕该产品是否完全原创的。如果正在谈论的是首次开发的计算机程序,那么对关键设计和运行领域范围内的关注就尤为重要,以至于最终交付给客户部署运行的版本,实际上是第二版。图七通过模拟来展示了该如何执行。
第四步:计划,控制和监控测试
前面的三个建议,在分析和编码之前设计程序,完整地用文档记录,构建一个试验模型,都是旨在在进入测试阶段前发现和解决问题。然而,尽管做了前面那些,还是有一个测试阶段,还是有重要的工作要做。
1)测试过程的很多部分都得到了测试专家最好的处理,测试专家不需要贡献到原始设计中。如果有人争论说 只有设计师才能执行彻底的测试,因为只有他们才理解他们构建的东⻄,这肯定是一个文档没有做好的信号。依我看来,如果有好的文档,产品保证专家会把测试工作做得比设计师更好。
2)大部分明显的错误,可以很容易地通过肉眼检查来发现。任何一点分析和代码都应该指定一名没有参与之前分析和编码的人来肉眼检查一遍。他们应该能发现诸如缺少负号,丢了两个元素,跳转到了错误的地址等等可通过校对来发现的分析和编码错误。别用计算机来干这类工作,因为太贵了。
3)用某种数值检查来测试程序中的每一条逻辑路径,至少一遍。如果我是客户,我不会接受交付,直到这个过程被完成和认证。这个步骤能发现主要的编码错误。
这个测试过程听起来很简单,对于大型复杂计算机程序,要下决心用可控的输入值测试每一个逻辑路径相对困 难。实际上,还有人可能会说那是几乎不可能的。尽管如此,我还是坚持建议要对每一个逻辑路径做一次真实的检查。
4)消除了简单的错误后(它们总是占大多数,并且它们掩盖了大的错误),就该把软件移交到测试区域,以达到检验的目的。在合适的时机,合适的人手里,电脑本身就是最佳的检验设备。关键的管理决策是:什么时候是最佳时机?谁是合适的人?来做最终的检验。
第五步:客户参与
总结
往期精彩回顾▼
优普丰十年敏捷推广的心得总结(上篇)之 “从零到一的信心加持”
逆袭自述 | 抑郁、轻生、自闭的中年程序员到开挂的IT诗人,逆袭到底有多难?
Business Analysis可视化表达软件业务需求分析课程(BA)
近期公开课程安排▼
进阶敏捷教练A-CSM认证-上海-2020年2月28-29日线上授课 讲师:Jacky Shen 申健
大规模敏捷-Certified LeSS PractitionerCLP认证-杭州2020年3月12-14日 讲师:Yi Lv吕毅
规模化敏捷-Certified LeSS Basic CLB认证-北京-2020年3月12日 讲师:Jacky Shen 申健
Certified Scrum Master(CSM)认证-北京2020年3月13-14日 讲师:Jacky Shen 申健
Certified Scrum Product Owner (CSPO)认证-北京2020年3月15-16日讲师:Jacky Shen 申健
Certified Scrum Master(CSM)认证-深圳-2020年3月14-15日 讲师:Bill Li 李国彪
Certified Scrum Master(CSM)认证-上海-2020年3月20-21日 讲师:Bill Li 李国彪
可视化表达软件业务需求分析BA-上海2020年3月27-28日 讲师:Stephen Wang 王洪亮
可视化表达软件业务需求分析BA-深圳-2020年4月3-4日 讲师:Stephen Wang 王洪亮
Certified Scrum Product Owner (CSPO)认证-深圳2020年4月24-25日 讲师:Jacky Shen 申健
Certified Scrum Master(CSM)认证-上海-2020年4月24-25日 讲师:Vernon Stinebaker 史文林