学会拥抱需求变化

本文是翻译,版权归原作者所有


简介

本文讨论了旧式学校软件工程原则如何使我失败,以及我如何学会了拥抱变化。我分享它,是希望它能够帮助其他人更好地理解敏捷软件开发的一个核心原则:计划之外的需求响应。

敏捷的困惑

敏捷软件开发原则最初提出是在13年前。不幸的是直到今天,关于 它是什么 和 它如何应用 仍然有很多困惑。我多将此归因于一个事实:它变成了流行行话,”敏捷“成为了”好“的同义词,普遍存在的两天scrum培训削弱了敏捷软件开发宗旨的真实意图。

我认为你不得不真正理解瀑布软件开发的痛苦和失败,这样才能理解到底是什么驱动了那些17位软件开发大师聚集起来沟通 为什么他们的行业被扰乱了 以及 他们如何使之回到正轨。

走出校门的程序员新手

在1996年我是一个年轻的、刚刚毕业的有理想的软件开发新手。我急于把在学校学到的、新形成的对软件工程原则的理解 应用到工作中去。

那时候我在一个神经系统科学实验室工作,为一名研究人员及其同事开发数据获取和分析软件。我当时下决心要给他们打造一款他们想象不到的最好的软件。

宏伟理想

我开始从老板那里认真收集了一系列需求,并让他在上面签字。然后我把他以前使用的软件重写了,我花了数月才觉得我所做的足够强大到可以让他使用了。需求文档上有很多功能,还有很多他没有提到的、但我认为他会喜欢的功能。我以漂亮的面向对象框架为傲,因为我能够增加很多他将来可能会提出来的更多功能。

打击

好吧,6个月的艰苦工作以后:他一个新功能都不喜欢,新软件没有以前软件的某些功能(也没有放在需求文档里),对此他比较失望。我也苦恼,他太不尊重需求,也没有因为我增加的所有新功能给我足够的肯定。当然这是防御性思维,事实上让他失望已经让我疯掉了。

客户服务的金科玉律是”客户永远是对的“。这样,客户总是我的老板,但是照此执行我会把事情搞砸的!该怎么办呢?我是按照软件工程课本的要求做的呀。

现实

仔细思考一番(一些是困惑)我意识到问题不在我,也不在客户,问题是我在学校学到的软件开发原则一直以来忽视了人类的本性。人们并不真正知道他们到底想要什么,当他们试用的时候,他们的需求和期望不断地变来变去。换句话说,我学到了软件开发的一条真理:

需求在持续变化。

一套新的原则

从那以后,我发誓尽早给客户演示软件,根据反馈增量式地改善功能。即:不需要为应付根本不会有的功能需求所打造的庞大软件框架,不需要根本不会要的令人震惊的功能,不需要从客户那里抑制软件因为软件只要”刚刚好“。

最后的话

我使用这些原则已经15年了,我经常看到它们出现在关于最好的软件开发实践的文章里,且比我表达得更完美。只是核心思想仍然多多少少地被 很多自称已经采用了”敏捷“工程原则的大型组织 误解和忽视。

通过分享我的个人经历,或许敏捷开发原则对你稍稍清晰了些。牢记:敏捷不是scrum会议、速度评估(velocity calculations)、计划扑克(Planning Poker)、或任何进度假象。把自尊放一边,直接与客户合作。

致谢

感谢花时间看我以前做为软件开发者的个人经历,希望你能喜欢。我也想给我以前的老板Dr. Matthew Shapiro一个大大的“thank you”,是他激发了我对软件开发的热爱,他一直极具耐心、支持我、富有灵感。

原文地址:http://www.codeproject.com/Articles/719907/Learning-to-Embrace-Changing-Requirements

译文:学会拥抱需求变化 》| 腊八粥