我有一些开发经理似乎不理解或不了解软件设计和实现的困难。
这些经理认为流程和方法完全解决了这个问题，我很难向他们解释说不是这样，你不能读一本关于最新流程时尚的书，希望通过应用它们来获得结果。
我最近的挫败感是说服我的经理 （a）尽可能给我要求不是零食，而是更大的要求。 （b）让我的团队有时间思考如何设计，剔除一些替代方案，制定实施草图，计划任务等。
由于敏捷方法论和对它的解释表明不做前期设计（与瀑布中的BIG前端设计相反），产品所有者可以随时改变要求，因此挫折感更加复杂。< / p>
到目前为止，我没有取得多大成功，不得不忍受由此产生的挫败感。 你能给我一些可以说服这些经理的论据吗？
修改-1 ： 回顾已经完成，但并不总是在每个冲刺结束时，问题都会出现。但正如我所提到的，我的经理并不理解设计提前期的需要以及对零食要求的挫败感。
修改-2 我对改变要求没有任何问题。我知道会是这样，但想象一下：你想要一个小功能开始，然后你不断添加更多。经过几次迭代后，设计无法再处理它，需要重新设计（不重构）。如果相关功能一起进行调查，首先可以通过前期设计更好地解决这个问题。它不是BDUF，它的自然方式（我称之为软件工程常识）。
我的经理不明白为什么我要求时间重新设计（有几次我称之为重构，以便它符合Agile的做法，但它确实是重新设计的）而不是开发和演示新功能。
答案 0 :(得分：4)
每次要求改变（或增加）时都应该
每次获得更新或新要求时，都会开始提供更新的估算值（即使您必须猜测）和风险列表。这将有助于您的经理建立联系。
尝试以乐于助人的精神 - “为了计划目的” - 这样做，这样你就不会被视为阻碍或缺乏“可以做的态度”。请记住，估计可以（在理论上）降低，风险可以降低。
答案 1 :(得分：3)
无论您在哪里工作，业务要求都会发生变化。这不是你的错，这不是你老板的错，也不是任何人的错。零碎地满足要求的全部意义在于鼓励您思考手头的问题，而不是您可能需要或可能不需要解决的其他问题。一旦你进入它的节奏，这是非常自由的。
将前期设计视为过早优化。您可能不需要它，即使您知道自己需要它，您也可以在两周后了解更多有关您的设计的信息。它将帮助您利用有关代码状态的最佳知识解决您的工程问题。
有人说过，edg是绝对正确的。添加更多需求时，估计值会更改。这不是开发人员或其他任何人的错;无论你如何平衡，更多的工作意味着更多的工作。如果您的老板没有意识到添加要求会导致对项目的更大估计，您需要向他解释敏捷不是一个神奇的子弹，它允许您添加更多功能而无需支付任何费用。
答案 2 :(得分：1)
敏捷简单设计并不意味着不要事先做任何设计/架构。 这意味着预先进行最小化的设计，这样您就不会为合理的变更请求付出可怕的代价。
Scott Ambler谈论变革案例 - http://www.agilemodeling.com/artifacts/changeCase.htm James Coplien谈到敏捷架构 - 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/
所有这些中的艺术/工艺是如何以允许的方式切割架构：
重要的是，您的产品负责人也要了解所有这些平衡行为，并且您需要协同工作。他应该明白，如果你忽视所有对未来的思考，每一次改变都将是非常昂贵的。灵活性需要付出代价。
它的投资与质量保证和测试自动化非常相似。你现在支付一些东西，只有在你测试代码X次之后才会得到回报。如果代码永远不会改变，那就是浪费精力。但每个人都知道大多数代码都在变化......
答案 3 :(得分：0)
购买您的经理this book。这就是我所做的，而且效果很好：）
答案 4 :(得分：0)
首先，这个问题似乎非常敏感，所以我在下面写的只是我个人的意见，并不一定是明智的事情。
在我看来，如果你不知道应该解决什么问题，你就不能制作软件。如果要求的小部分太小而无法监督问题，那么我就会解决有关似乎缺失的部分的问题。喜欢：“好吧所以软件应该做X，但是这也意味着Y或者其他可能Z？因为如果它是Y然后......但如果它是Z那么......”当然如果经理在中间提取要求然后他无法回答，但至少他知道仍存在影响发展的公开问题。
关于设计没有准备时间：设计和开发是一个可以齐头并进的迭代过程。这就是你如何命名的东西。如果经理想在一天结束时看到一些代码，那么我只需要使用当天的前半部分进行设计，然后使用当天的后半部分来制作基于该设计的代码。如果经理不想看到设计，那么对我来说很好，我只会展示代码。