惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

小众软件
小众软件
A
About on SuperTechFans
博客园 - Franky
Engineering at Meta
Engineering at Meta
Recent Announcements
Recent Announcements
云风的 BLOG
云风的 BLOG
B
Blog
Microsoft Security Blog
Microsoft Security Blog
L
LangChain Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
U
Unit 42
Martin Fowler
Martin Fowler
Y
Y Combinator Blog
Stack Overflow Blog
Stack Overflow Blog
博客园 - 叶小钗
Vercel News
Vercel News
Apple Machine Learning Research
Apple Machine Learning Research
The Cloudflare Blog
Last Week in AI
Last Week in AI
腾讯CDC
Microsoft Azure Blog
Microsoft Azure Blog
爱范儿
爱范儿
V
V2EX
G
Google Developers Blog

博客园 - 一一九九

Introduce to MEF (Study)- one 【wpf】AnimatedTabControl 如何显示内容 [wpf]设置Application的ICO Error: does not contain a static 'Main' method suitable for an entry point [wpf] Can you outline a story-driven process with Concordion? Your First Concordion.Net Project (Part 5)-Running Specs with Gallio Your First Concordion.Net Project (Part 4)-More Specifications! Your First Concordion.Net Project (Part 3)-Adding Specifications Your First Concordion.Net Project (Part 2)-Setting Up Visual Studio Your First Concordion.NET Project (Part 1)-What is Concordion.Net? [Specification by Example][ch5 Deriving scope from goals]-[读书笔记]-[4] [Specification by Example][ch5 Deriving scope from goals]-[读书笔记]-[3] [Specification by Example][ch5 Deriving scope from goals]-[读书笔记]-[2] [Specification by Example][ch5 Deriving scope from goals]-[读书笔记]-[1] [Specification by Example][ch4 Initiation the changes]-[读书笔记] [Specification by Example][ch3 Living documentation]-[读书笔记] [Specification by Example][ch2 key process patterns]-[读书笔记] Binding Resource
[Specification by Example][ch1 key benefits]-[读书笔记]
一一九九 · 2012-01-06 · via 博客园 - 一一九九

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.

image

为了有效的构造正确的产品,软件开发实践需要遵循以下规则:

  • 确保所有的利益相关人和发布团队以相同的方式理解需要发布的是什么。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.

传统上,构建正确的产品需要完善的大的功能规范,文档和长时间的测试。今天,在以周为单位进行的软件发布周期中,这个不再发挥作用,我们需要一个能够帮我们解决以下问题的解决方案:

  • 避免过度的功能规范细化的浪费。避免花费了太多的时间在产品发布之前会发生变化的细节上。Avoid wasteful over-specifying; avoid spending time on details that will change before a piece of work is developed.
  • 有一个可靠的能够帮我们解释系统是什么的文档,这样我们能够很容易的应对变更。Have reliable documentation that explains what the system does so we can change it easily.
  • 能有有效的查证系统在功能规范基础上如何实现的。Efficiently check that a system does what the specifications say.
  • 通过最小的维护代价来保持文档的相关性以及可靠性。keep documentation relevant and reliable with miniamal maintenance costs.
  • 能够将所有的这些纳入到短周期的基于流程的迭代中,这样那些在即将到来的任务中信息会保持同步更新。Fit all this into short iterations and flow-based processes, so that the information on upcoming work is produced just-in-time.

image

尽管这些目标第一眼看起来是存在冲突的,但是很多团队成功的满足了这些目标。作者调查了30个团队的50个项目,识别了共同的模式和实践,这些项目采用了一个比较好的方式来构造正确的软件:Specification By Example。

Specification By Example 带来的主要收益有:

  • 更有效的应对变化。 由于有Living 文档 ,一个描述了系统功能的可靠的信息来源,能够更好的分析变化带来的潜在影响,也能够更好的分享知识。Implementing changes more efficiently – They had living documentaion- a reliable source of information on system functionality-which enabled them to analyze the impact of potential changes and share knowledge effectively.
  • 更高的产品质量。Higher product quality- They defined expectations  clearly and made the validation process efficient.
  • 更少的重复工作。 Less rework – they collaborated better on specifications and ensured a shared understanding of the expectations by all team members.
  • 团队不同成员之间更好的协作。 Better alignment of the activities of different roles on a project- Improved collaboration led to a more regular flow of delivery.