如何教育开发经理了解软件设计的困难？

Question

我有过一些开发经理，他们似乎不理解或不了解软件设计和实现的困难。

这些管理人员认为，流程和方法完全解决了问题，我很难向他们解释，情况并非如此，你不能读一本关于最新工艺潮流的书，并希望按原样应用它们来取得成果。

我最近的挫折感是说服我的经理(a)给我的要求不是一顿饭，而是尽可能多的一套。(b)让我的团队有时间考虑如何设计，找出几个备选方案，制定一个实施草图，规划任务等等。

由于敏捷方法和它的解释，即不做前期设计(相对于瀑布式的大前期设计)，产品所有者可以随时更改需求，这使人们更加沮丧。

到目前为止，我还没有取得多大的成功，我不得不忍受由此产生的挫折。你能给我一些能说服这些经理的论据吗？

编辑-1：回顾已经完成，尽管并不总是在每一次冲刺结束时完成，并提出了问题。但是，正如我提到的，我的经理不理解设计准备时间的需要和对片式餐需求的不满。

编辑-2我对更改需求没有问题。我知道会是这样的，但是想象一下:首先您想要一个小的特性，然后继续添加更多的功能。经过几次迭代之后，设计就不能再处理它了，需要重新设计(而不是重构)。如果我们一起研究相关的特性，一开始就可以通过预先设计来更好地解决这个问题。它不是BDUF，而是一种自然的方式(我称之为软件工程常识)。

我的经理不明白为什么我需要时间重新设计(有几次我只是叫它重构，以便它符合敏捷的方式，但它实际上是重新设计)，而不是开发和降级新特性。

Answer 1

敏捷简单设计并不意味着不做任何预先的设计/架构。这意味着预先做最低限度的设计，这样你就不会为合理的更改请求付出可怕的代价。

http://www.agilemodeling.com/artifacts/changeCase.htm James谈论敏捷架构- http://www.infoq.com/presentations/Agile-Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney http://blog.jaoo.dk/2009/03/04/handling-architecture-in-the-agile-world/

所有这一切的艺术/工艺在于如何以一种允许：

• 总体架构/基础设施的相对快速收敛--按估计开发时间的每个月天数计算。
• 针对每个特性/需求开发“刚刚足够”的体系结构/基础设施
• 做好对未来准备工作的平衡，要注重今天的特点。

重要的是，您的产品负责人知道所有这些平衡行为，以及您的协作工作。他应该明白，如果你忽视了对未来的所有思考，每一次改变都将是非常昂贵的。灵活性是要付出代价的。

顺便说一句，它非常类似于对QA和测试自动化的投资。您现在支付一些东西，只有在您测试代码X次之后才能得到回报。如果代码从未改变，那就是浪费精力。但每个人都知道大多数的代码变化..。

Answer 2

每次需求改变(或增加)时，都应该这样做

• 要完成的估计，
• 风险评估

每次你得到新的或新的要求时，开始给出最新的估计(即使你不得不猜测)和风险列表。这将帮助你的经理建立联系。

试着以一种乐于助人的精神去做--“为了计划的目的”--这样你就不会被认为是阻碍或缺乏“能干的态度”。请记住，估计值(理论上)可以下降，风险也可以降低。

Answer 3

无论您在哪里工作，业务需求都会发生变化。这不是你的错，不是你老板的错，不是任何人的错。零敲碎打地接受需求的全部目的是鼓励您思考手头的问题，而不是其他您可能需要或不需要解决的问题。一旦你进入了它的节奏，它是相当解放的。

将前期设计视为过早的优化。你可能不需要它，即使你知道你需要它，你将知道更多关于你的设计在两个星期后，比你现在知道它。它将帮助您通过对代码状态的最佳了解来解决您的工程问题。

这么说了，艾格是绝对正确的。当您添加更多的需求时，估计值会发生变化。这不是开发人员或其他人的错；更多的工作意味着更多的工作，不管您如何处理它。如果您的老板没有意识到添加需求会导致对项目的更大估计，那么您需要向他解释，敏捷并不是一颗神奇的子弹，它允许您添加更多的特性，而无需付出任何代价。