



























2012-01-06 13:22 一一九九 阅读(412) 评论() 收藏 举报
前言:
在Internet的时代,软件开发的主题是软件的发布速度。 在20年前,软件的周期可能持续若干年并且以月来进行里程碑测量,而我们现在一个软件产品的周期以月为单位,以周或者天来进行迭代,软件进入了快速发布的时代。那些需要长周期的计划,需要从上倒下的设计以及详细的需求分析的时代已经过去了。
在这么巨大的变化下,文档很容易变得过时了。需要保持更新的详细规范和测试计划是被认为是浪费资源的。在当前以周为迭代周期的日子里,那些每日进行商业分析和测试的人对于要做什么经常是困扰的,那些认为不受文档缺少影响的开发人员则浪费时间在重复工作和维护那些并不需要的功能上。和之前把时间浪费在构建大计划上相比,现在的研发人员把时间浪费在打造错误的产品上。[Insead of spending time building big plans, they waster weeks polishing the wrong product].
在过去的几年,软件界一直在探索如何正确的构建产品,探索各种能够确保高质量的技术实践和思想。但是正确的建造产品和建造正确的产品是两个不同的事情。But budinging the product right and building the right product are two different things.
为了有效的构造正确的产品,软件开发实践需要遵循以下规则:
确保所有的利益相关人和发布团队以相同的方式理解需要发布的是什么。Assurance that all stakeholders and delivery team members understand what needs to be delivered in the same way.
精确的功能规范确保发布团队避免由于模糊的歧义的功能差距而进行的重复的工作导致的资源浪费。 Precise specifications so delivery teams avoid wasterful rework caused by ambiguities and functional gaps.
客观的描述工作完成的方法。An Objective means to measure when a piece of work is complete.
能够应对产品特性和团队变化的文档。 Documentation to faciliatate change, in terms of both software features and team structure.
传统上,构建正确的产品需要完善的大的功能规范,文档和长时间的测试。今天,在以周为单位进行的软件发布周期中,这个不再发挥作用,我们需要一个能够帮我们解决以下问题的解决方案:
尽管这些目标第一眼看起来是存在冲突的,但是很多团队成功的满足了这些目标。作者调查了30个团队的50个项目,识别了共同的模式和实践,这些项目采用了一个比较好的方式来构造正确的软件:Specification By Example。
Specification By Example 带来的主要收益有:
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。