敏捷设计/图形架构高级初级中级开发

学习拥抱不断变化的需求

Christopher Diggins

4.82/5 (13投票s)

2014年2月3日

CPOL

4分钟阅读

24222

一个关于不断变化的需求和敏捷软件开发的个人故事

介绍

这是一个关于老式软件工程原理如何让我失败以及我如何学会拥抱变化的故事。我分享它，是希望它能帮助其他人更好地理解敏捷软件开发的一个核心原则：响应变化胜过遵循计划。

敏捷的困惑

敏捷软件开发原则最早是在十三年前提出的。不幸的是，今天人们对它是什么以及如何使用它存在很多困惑。我将这在很大程度上归因于它成为了一个行业流行语，其中“敏捷”与“好”同义，而普遍存在的为期两天的 Scrum 流程培训稀释了敏捷软件开发宣言的初衷。

我认为，你必须真正理解瀑布式软件开发的痛苦和失败，才能理解是什么促使那十七位软件开发大师聚集在一起，找出他们所在的行业为何出了问题以及如何才能重回正轨。

一个刚毕业的年轻程序员

回到 1996 年，我是一名刚从学校毕业的年轻而理想化的软件开发人员。我渴望将我在学校学到的软件工程原理的新理解应用到我的工作中。当时，我在一个神经科学研究实验室工作，为一位研究员和他的同事创建数据采集和分析软件。我希望能做好这份工作，并决心将他们的工具打造成他们想象中的最好的软件。

大想法

我开始项目时，仔细收集了我老板的需求清单，并让他签字确认。然后，我开始对他们之前使用的软件进行大规模的重写。我花了几个月的时间才做到让我引以为傲，可以让他使用。它包含了需求文档中的许多功能，以及许多他未指定但我觉得他一定会喜欢的额外功能！我对自己精心设计的面向对象框架也感到非常自豪，这个框架可以让我轻松添加他可能提出的更多功能。

失望

你猜怎么着，经过六个月的辛勤工作，他并不喜欢我添加的任何新功能，反而对一些缺失的原始软件功能感到不满。那些功能从未被包含在需求文档中。我很沮丧，他怎么能不尊重需求，也不为我添加的所有出色功能赞扬我呢？当然，这是防御性思维，我其实是觉得自己让他失望了。

我回顾了客户服务的黄金法则：“客户永远是对的”。在这种情况下，我的老板就是客户，但这种想法意味着我在某个环节一定搞砸了！怎么会这样？我可是按照软件工程的规则来做的。

领悟

经过一番深思熟虑（有些人可能会称之为痴迷），我意识到问题不在于我，也不在于客户，而是我从学校学到的软件工程原理忽略了基本的人性。人们在尝试之前并不知道自己真正想要什么，他们的需求和愿望也在不断变化。换句话说，我学到了关于软件开发的一个真理：

需求在不断变化。

一套新的原则

从那天起，我发誓要尽早向客户提供可用的软件，并根据他们的反馈进行逐步改进。这意味着：不再提前构建宏大的软件框架以应对从未出现的功能请求，不再添加未经客户要求的意外功能，也不再将软件“完美”后才交付给客户。

结语

这些原则在过去十五年里一直对我很有帮助，我不断在关于软件开发最佳实践的文章中看到它们被提及，而且往往比我在这里表达得更清晰。不幸的是，在许多声称已采用“敏捷”工程原则的大型组织中，核心思想仍然有些被误解和忽视。

分享了我的个人经历后，也许敏捷开发原则对你来说会更容易理解。请永远记住：敏捷不仅仅是关于 Scrum 会议、速度计算、计划扑克，或任何这些过程产物。它关乎放下自我，直接与客户合作。

致谢

感谢您花时间阅读我早期软件开发生涯的这段个人经历，希望您喜欢。我还要特别感谢我以前的老板 Matthew Shapiro 博士，他激起了我对软件开发的热爱，并且一直以来都非常耐心、支持和鼓舞人心。

学习拥抱不断变化的需求

介绍

敏捷的困惑

一个刚毕业的年轻程序员

大想法

失望

领悟

一套新的原则

致谢

推荐阅读