I have had a few development managers who don't seem to understand or appreciate the difficulties of software design and implementation.
我有一些开发经理似乎不理解或不了解软件设计和实现的困难。
Such managers believe that processes and methodologies completely solve the problem and I have a tough time explaining to them that it is not so and that you cannot read a book on the latest process fad and hope to get results by applying them as is.
这样的管理者认为流程和方法完全解决了这个问题,我很难向他们解释说不是这样,你不能读一本关于最新流程时尚的书,并希望通过原样应用它们来获得结果。
The latest frustration I have is to convince my manager to (a) Give me requirements not piece-meal but a larger set as far as possible. (b) Give my team lead time to think about how to design, thrash out a few alternatives, work out an implementation sketch, to plan out the tasks etc.
我最近的挫败感是说服我的经理(a)给我的要求不是零食,而是尽可能更大的一套。 (b)让我的团队有时间思考如何设计,剔除一些替代方案,制定实施草图,计划任务等。
The frustrations are compounded because of Agile methodology and the interpretation of it that says not to do up-front design (as against BIG up-front design in Waterfall), product owner can change requirements at any time and so son.
由于敏捷方法和对它的解释表明不做前期设计(与瀑布中的BIG前端设计相反),产品所有者可以随时改变要求,因此挫折感更加复杂。
So far I haven't had much success and have to put up with the resulting frustrations. Can you give me some arguments that can convince such managers?
到目前为止,我还没有取得多大成功,必须忍受由此产生的挫败感。你能给我一些可以说服这些经理的论据吗?
EDIT-1: Retrospectives are done, though not always at the end of every sprint, and the problems are brought up. But as I mentioned, my manager doesn't appreciate the need for design lead time and the frustrations with piece-meal requirements.
编辑-1:回顾已经完成,但并不总是在每个冲刺结束时,问题都会出现。但正如我所提到的,我的经理并不理解设计提前期的需要以及对零食要求的挫败感。
EDIT-2 I don't have a problem with changing requirements. I understand that it will be so, but imagine this: You want a small feature to begin with and then you keep adding more around it. After a few iterations, the design cannot handle it anymore and a redesign (not refactoring) is required. This could have been solved better with an upfront design in the first place, had the related features been investigated together. Its not BDUF, its the natural way of doing it (what I call software engineering common sense).
编辑-2我没有改变要求的问题。我知道它会是这样,但想象一下:你想要一个小功能开始,然后你继续添加更多的功能。经过几次迭代后,设计无法再处理它,需要重新设计(不重构)。如果相关功能一起进行调查,首先可以通过前期设计更好地解决这个问题。它不是BDUF,它的自然方式(我称之为软件工程常识)。
My manager doesn't understand why I ask for time to redesign (a few times I just call it refactoring so that it fits the Agile way of doing it, but it really is redesign) and not developing and demoing new features.
我的经理不明白我为什么要求时间重新设计(有几次我称之为重构,以便它符合Agile的做法,但它确实是重新设计的)而不是开发和演示新功能。
5 个解决方案
#1
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/
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/
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...
它的btw与QA和测试自动化的投资非常相似。你现在支付一些东西,只有在你测试代码X次之后才会得到回报。如果代码永远不会改变,那就是浪费精力。但每个人都知道大多数代码都在变化
#2
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.
尝试以乐于助人的精神 - “为了规划目的” - 这样做,这样你就不会被视为阻碍或缺乏“可以做的态度”。请记住,估计可以(理论上)降低,风险可以降低。
#3
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.
有人说过,edg是绝对正确的。添加更多需求时,估计值会更改。这不是开发人员或其他任何人的错;无论你如何平衡,更多的工作意味着更多的工作。如果你的老板没有意识到添加要求会导致对项目的更大估计,你需要向他解释敏捷不是一个神奇的子弹,它允许你添加更多功能而无需支付任何费用。
#4
Buy your manager this book. That's what I did, and it worked great :)
在这本书上买你的经理。这就是我所做的,而且效果很好:)
#5
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.
在我看来,如果你不知道它应该解决什么问题,你就不能制作软件。如果要求的小部件太小而无法监督问题,那么我就会解决有关缺少部件的问题。喜欢:“好吧所以软件应该做X,但是这也意味着Y或者其他可能是Z?因为如果它是Y然后......但如果它是Z那么......”当然如果经理在中间提取要求然后他无法回答,但至少他知道仍存在影响发展的公开问题。
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.
关于设计没有准备时间:设计和开发是一个可以齐头并进的迭代过程。这就是你如何命名的东西。如果经理希望在一天结束时看到一些代码,那么我只需要使用当天的前半部分进行设计,然后在下半天使用该设计制作一些代码。如果经理不想看到设计,那么我很好,我只会展示代码。
#1
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/
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/
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...
它的btw与QA和测试自动化的投资非常相似。你现在支付一些东西,只有在你测试代码X次之后才会得到回报。如果代码永远不会改变,那就是浪费精力。但每个人都知道大多数代码都在变化
#2
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.
尝试以乐于助人的精神 - “为了规划目的” - 这样做,这样你就不会被视为阻碍或缺乏“可以做的态度”。请记住,估计可以(理论上)降低,风险可以降低。
#3
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.
有人说过,edg是绝对正确的。添加更多需求时,估计值会更改。这不是开发人员或其他任何人的错;无论你如何平衡,更多的工作意味着更多的工作。如果你的老板没有意识到添加要求会导致对项目的更大估计,你需要向他解释敏捷不是一个神奇的子弹,它允许你添加更多功能而无需支付任何费用。
#4
Buy your manager this book. That's what I did, and it worked great :)
在这本书上买你的经理。这就是我所做的,而且效果很好:)
#5
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.
在我看来,如果你不知道它应该解决什么问题,你就不能制作软件。如果要求的小部件太小而无法监督问题,那么我就会解决有关缺少部件的问题。喜欢:“好吧所以软件应该做X,但是这也意味着Y或者其他可能是Z?因为如果它是Y然后......但如果它是Z那么......”当然如果经理在中间提取要求然后他无法回答,但至少他知道仍存在影响发展的公开问题。
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.
关于设计没有准备时间:设计和开发是一个可以齐头并进的迭代过程。这就是你如何命名的东西。如果经理希望在一天结束时看到一些代码,那么我只需要使用当天的前半部分进行设计,然后在下半天使用该设计制作一些代码。如果经理不想看到设计,那么我很好,我只会展示代码。