Every time requirements are changed (or increased) so should
the estimate to complete and,
the assessment of risk
Start giving updated estimates (even if you have to guess) and lists of risks every time you get an updated or new requirement. This will help your manager make the connection.
Try to do this in a spirit of helpfulness--"for planning purposes"--so that you aren't perceived as obstructive or lacking "can-do attitude." Remember that estimates can (in theory) come down, and risks can be reduced.
Business requirements are going to change no matter where you work. It's not your fault, it's not your boss's fault, it's not anybody's fault. The entire point of taking the requirements on piecemeal is to encourage you to think about the problem at hand, not some other problem that you might or might not need to solve. It's quite liberating once you get into the rhythm of it.
Think of upfront design as premature optimization. You may not need it, and even if you know you need it, you'll know more about your design two weeks from now than you know about it today. It'll help you solve your engineering problem with the best possible knowledge about the state of your code.
That having been said, edg is absolutely right. When you add more requirements, the estimate changes. This isn't the fault of the developers or anyone else; more work means more work no matter how you square it. If your boss doesn't realize that adding requirements will result in a larger estimate for the project you need to explain to him that Agile isn't a magic bullet that allows you to add more features without paying anything for them.
顺便说一句，它与质量保证和测试自动化的投资非常相似。 您现在支付一些费用，只有在您测试代码 X 次后才会得到回报。 如果代码永远不改变那就是浪费精力。 但每个人都知道大多数代码都会改变......
Agile Simple Design doesn't mean don't do ANY design/architecture up front. It means do the minimal design up front, so that you will not pay a horrible price for reasonable change requests.
The art/craft in all of this is in how to slice the architecture in a way that allows:
relatively fast convergence on overall architecture/infrastructure - on the order of days per months of estimated development time.
developing "just enough" architecture/infrastructure per each feature/requirement
doing the right balance of preparations for the future compared to focus on the features of today.
Its important that your Product Owner is aware of all of this balancing act as well, and you work collaboratively. He should understand that if you disregard all thinking for the future, each change will be very costly. There is a price to be paid for flexibility.
Its btw very similar to investment in QA and test automation. You pay something now, that will pay off only after X times you test the code. if the code never changes it was a waste of effort. but everyone knows that most code changes...
在我看来，如果你不知道软件应该解决什么问题，你就无法开发软件。 如果需求是小部分，太小而无法监督问题，那么我只会提出有关似乎缺失的部分的问题。 就像：“好吧，所以软件应该做 X，但这是否也意味着 Y 或者 Z？因为如果它是 Y 那么......但如果它是 Z 那么......”当然，如果经理处于中间提取需求后他无法回答，但至少他知道仍然存在影响开发的未决问题。
First of all this issue seems quite sensitive, so all I wrote below is just my personal opinion, and not necessarily a wise thing to do.
In my opinion you cannot make software if you do not know what problem it should solve. If requirements come in small parts that are too small to oversee the problem, then I would just fire questions about the parts that seem to be missing. Like: "okay so the software should do X, but does that also mean Y or otherwise maybe Z? Because if it is Y then ... but if it is Z then ..." Of course if the manager is in the middle of extracting the requirements then he cannot answer, but at least he knows that there are still open issues that influence development.
About no lead time for design: design and development are an iterative process that could go hand in hand. It is just how you name the thing. If the manager wants to see some code at the end of the day, okay then I would just use the first half of the day to design and the second half of the day to make some code based on that design. If the manager does not want to see the design, fine with me then I'll just show the code.
发布评论
评论（5）
每次需求发生变化（或增加）时，
每次收到更新或新的需求时，开始提供更新的估计（即使您必须猜测）和风险列表。 这将帮助您的经理建立联系。
试着本着乐于助人的精神——“出于计划的目的”——这样你就不会被认为是阻碍或缺乏“能做的态度”。 请记住，估计（理论上）可以下降，风险也可以降低。
Every time requirements are changed (or increased) so should
Start giving updated estimates (even if you have to guess) and lists of risks every time you get an updated or new requirement. This will help your manager make the connection.
Try to do this in a spirit of helpfulness--"for planning purposes"--so that you aren't perceived as obstructive or lacking "can-do attitude." Remember that estimates can (in theory) come down, and risks can be reduced.
无论您在哪里工作，业务需求都会发生变化。 这不是你的错，这不是你老板的错，这不是任何人的错。 零碎地考虑这些要求的全部目的是鼓励您思考手头的问题，而不是您可能需要或可能不需要解决的其他问题。 一旦你进入它的节奏，它就会变得非常自由。
将前期设计视为过早优化。 您可能不需要它，即使您知道需要它，两周后您对您的设计的了解也会比今天更多。 它将帮助您通过尽可能了解代码状态来解决工程问题。
话虽这么说，edg 说得绝对正确。 当您添加更多要求时，估算会发生变化。 这不是开发人员或其他任何人的错；而是。 更多的工作意味着更多的工作，无论你如何计算。 如果你的老板没有意识到添加需求会导致项目的估算更大，你需要向他解释敏捷并不是让你无需支付任何费用即可添加更多功能的灵丹妙药。
Business requirements are going to change no matter where you work. It's not your fault, it's not your boss's fault, it's not anybody's fault. The entire point of taking the requirements on piecemeal is to encourage you to think about the problem at hand, not some other problem that you might or might not need to solve. It's quite liberating once you get into the rhythm of it.
Think of upfront design as premature optimization. You may not need it, and even if you know you need it, you'll know more about your design two weeks from now than you know about it today. It'll help you solve your engineering problem with the best possible knowledge about the state of your code.
That having been said, edg is absolutely right. When you add more requirements, the estimate changes. This isn't the fault of the developers or anyone else; more work means more work no matter how you square it. If your boss doesn't realize that adding requirements will result in a larger estimate for the project you need to explain to him that Agile isn't a magic bullet that allows you to add more features without paying anything for them.
敏捷简单设计并不意味着不预先进行任何设计/架构。
这意味着预先进行最小化设计，这样您就不会为合理的变更请求付出可怕的代价。
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 次后才会得到回报。 如果代码永远不改变那就是浪费精力。 但每个人都知道大多数代码都会改变......
Agile Simple Design doesn't mean don't do ANY design/architecture up front.
It means do the minimal design up front, so that you will not pay a horrible price for reasonable change requests.
Scott Ambler talks about Change Cases - http://www.agilemodeling.com/artifacts/changeCase.htm
James Coplien talks about Agile Architecture - 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/
The art/craft in all of this is in how to slice the architecture in a way that allows:
Its important that your Product Owner is aware of all of this balancing act as well, and you work collaboratively. He should understand that if you disregard all thinking for the future, each change will be very costly. There is a price to be paid for flexibility.
Its btw very similar to investment in QA and test automation. You pay something now, that will pay off only after X times you test the code. if the code never changes it was a waste of effort. but everyone knows that most code changes...
购买您的经理这本书。 这就是我所做的，效果很好:)
Buy your manager this book. That's what I did, and it worked great :)
首先这个问题看起来很敏感，所以我下面写的只是我个人的观点，并不一定是明智的做法。
在我看来，如果你不知道软件应该解决什么问题，你就无法开发软件。 如果需求是小部分，太小而无法监督问题，那么我只会提出有关似乎缺失的部分的问题。 就像：“好吧，所以软件应该做 X，但这是否也意味着 Y 或者 Z？因为如果它是 Y 那么......但如果它是 Z 那么......”当然，如果经理处于中间提取需求后他无法回答，但至少他知道仍然存在影响开发的未决问题。
设计几乎没有前置时间：设计和开发是一个可以齐头并进的迭代过程。 这就是你如何命名这件事。 如果经理想在一天结束时看到一些代码，那么我会用前半天的时间进行设计，然后用后半天的时间根据该设计编写一些代码。 如果经理不想看到设计，那好吧，我就只展示代码。
First of all this issue seems quite sensitive, so all I wrote below is just my personal opinion, and not necessarily a wise thing to do.
In my opinion you cannot make software if you do not know what problem it should solve. If requirements come in small parts that are too small to oversee the problem, then I would just fire questions about the parts that seem to be missing. Like: "okay so the software should do X, but does that also mean Y or otherwise maybe Z? Because if it is Y then ... but if it is Z then ..." Of course if the manager is in the middle of extracting the requirements then he cannot answer, but at least he knows that there are still open issues that influence development.
About no lead time for design: design and development are an iterative process that could go hand in hand. It is just how you name the thing. If the manager wants to see some code at the end of the day, okay then I would just use the first half of the day to design and the second half of the day to make some code based on that design. If the manager does not want to see the design, fine with me then I'll just show the code.