In agile, is it ok for the business team to relax and give requirements at will? (Some requirements given during the final sprints were altering the entire design of our app)
It is OK (albeit not wise ;-)... so then an agile development team would tell them "fine guys, this would cost this amount of extra time and consequently this much schedule slippage."
If they are willing to pay the price, all's well.
If they decide that maybe the new feature is not that urgent after all, all is well too.
If they insist on including the new requirements and keeping the original schedule, that project is not agile :-(
Or, its the development team's mistake not foreseeing the numerous possibilities of the application and not having a concrete design that could have welcomed abnormal changes?
I don't think the design should be ready to welcome any kind of changes and any new features - that would only lead to bloatware, and a lot of extra work which in the end proves useless.
Agile projects should have some sort of roadmap too, so that the developers have at least a rough idea where the product is supposed to be in a year's time etc. This would allow them to plan forward and extend the design to make room for probable future changes.
If business doesn't give timely information about the roadmap (or if it proves unreliable), that is (usually - barring really unforeseen market/environment changes) business' fault. If the team did not use that info wisely, it's their fault.
Agile doesn't mean you don't have requirements or specifications or you can be free and easy with them. The business leads need to know what they want. The benefits of being agile is that if you do need to change paths, you can do that in an easier way, so you can adapt quickly.
Requirements changing will be painful no matter what your development methodology. There still has to be a strong clear plan, at least at that point in time.
我同意 Péter Török 的回答，但敏捷团队或敏捷团队经理也有责任教导业务团队，如果他们将新需求推迟到下一个需求阶段，项目每轮都会交付更好的结果。由于一轮应该为 30 - 90 天，因此大多数新要求可以等待。少数要求不能等待，需要有时间和进度成本。
Agile projects are supposed to have requirements gathering, design, analysis, coding, testing; just like the waterfall development model. However, in an agile project, the phases are supposed to cover less ground and therefore, happen faster.
I agree with Péter Török's answer, but its also the responsibility of the agile team or the agile team manager to teach the business team that the project will deliver better results each round if they postpone new requirements until the next requirements phase. Since a round is supposed to be 30 - 90 days, most new requirements can wait. The few requirements that can't wait, need to have a time and schedule cost.
Opinion of a Scrum Master here. It sounds like the business is lacking a clear knowledge of what 'agile' is, or how they implement it. Agile needs to be applied with structure, whether that be Scrum or Kanban or something similar. Too often it is a synonym for 'we don't design or document' things.
If you are meaning a team using Scrum, this would be manageable as long as the Product Owner and Scrum Master are on top of their game.
If the business team are giving requirements 'at will' that do not align, it is up to the Product Owner to take these on board, and prioritise a list of tasks prior to sprint planning. If they don't align with what has already been done, they may be estimated as large stories, due to the need for refactoring etc. by the team. It will then be up to the Product Owner to decide if it is worth proceeding with them despite the size, or working on alternative stories that align with work already done.
This would be a tough environment for the whole Scrum team to work in, but you would expect the business to see the lost value by changing direction between sprints, and hopefully align the product to a direction before too long. It certainly is not the development teams fault for not anticipating this, I would more say the Scrum Master and Product Owner need to have some serious words with the business units involved.
There needs to be a buffer between the sprint and the backlog.
The Business Team own the backlog and the prioritisation of the stories in the backlog but once the Dev team have committed to x number of stories in the sprint then it is unwise for the business team to tinker with its content. If you find this happens I would suggest shortening the length of the sprints.
If however a super urgent new requirement comes up that just cannot wait for the next sprint then another story/stories of similar points value have to be removed.
It is important that the business team manage their backlog so that in the sprint planning meeting the next set of stories are fully specked, prioritised and ready to go.
In agile, is it ok for the business team to relax and give requirements at will?
Yes, it's ok to change requirements (maybe not relax), but in our teams we will not disrupt or change the scope of the sprint unless the work currently in scope of the sprint is made redundant as a result of the new requirements added to the product backlog by the product owner (not the sprint backlog). Also note that if you commit to 100 points worth of work in a sprint, you complete 80 points and the the requirements change enough for the sprint to be disrupted then the team has still delivered 80 points that sprint based on the POs original requirements. (important when dealing with external clients)
its the development team's mistake not foreseeing the numerous possibilities of the application and not having a concrete design that could have welcomed abnormal changes?
We have a very high-level understanding of the overall features/project being worked on, however before we accept User Stories (broken downs chunks of the feature/project) we ensure that we fully understand what the Product Owner wants. If the product owner is unsure then we will ask the person whom does know. Note I am not saying that you plan out the whole project, you only nail down 1 or 2 sprints worth of user stories.
(This is how I do it, but there is no prescriptive rules, every agile rule make Agile less Agile - My opinion)
There is a general notion that business and development work together on daily basis and do that not primary in written form, but as well face to face (often to review or plan stuff). The idea is not to make too much assumptions on the future, but some and go with these.
Having done this as a coder, the only advice I can give: Setup for change. As you learn about your framework, the product side learns about the business. If you run into problems like these: Its actually important that you fix this problem. This is what you have sprints for: Fail at something and then fix it after a retro. Doing this for a while should lead to a sane organized process how to get all the requirements at the right moment.
However: Proper engineering has hurt no-one yet as well as proper security and requirements engineering. If you need to do this despite your agile process: so be it.
发布评论
评论（7）
没关系（尽管不是明智；-）......所以敏捷开发团队会告诉他们”好人，这会花费大量的额外时间，从而导致如此严重的进度延误。”
我认为设计不应该准备好欢迎任何类型的更改和任何新功能 - 这只会导致臃肿软件，以及大量额外的工作结果证明是没用的。
敏捷项目也应该有某种路线图，以便开发人员至少有一个粗略的想法，产品在一年内应该在哪里等等。这将使他们能够向前规划并扩展设计，为 未来可能发生的变化。
如果企业没有及时提供有关路线图的信息（或者事实证明它不可靠），那就是企业的错（通常 - 除非真正不可预见的市场/环境变化）。如果团队没有明智地使用这些信息，那是他们的错。
It is OK (albeit not wise ;-)... so then an agile development team would tell them "fine guys, this would cost this amount of extra time and consequently this much schedule slippage."
I don't think the design should be ready to welcome any kind of changes and any new features - that would only lead to bloatware, and a lot of extra work which in the end proves useless.
Agile projects should have some sort of roadmap too, so that the developers have at least a rough idea where the product is supposed to be in a year's time etc. This would allow them to plan forward and extend the design to make room for probable future changes.
If business doesn't give timely information about the roadmap (or if it proves unreliable), that is (usually - barring really unforeseen market/environment changes) business' fault. If the team did not use that info wisely, it's their fault.
敏捷并不意味着您没有需求或规范，也不意味着您可以自由轻松地使用它们。业务主管需要知道他们想要什么。敏捷的好处是，如果你确实需要改变路径，你可以用更简单的方式做到这一点，这样你就可以快速适应。
无论您的开发方法是什么，需求变化都会很痛苦。至少在那个时间点仍然必须有一个强有力的明确计划。
Agile doesn't mean you don't have requirements or specifications or you can be free and easy with them. The business leads need to know what they want. The benefits of being agile is that if you do need to change paths, you can do that in an easier way, so you can adapt quickly.
Requirements changing will be painful no matter what your development methodology. There still has to be a strong clear plan, at least at that point in time.
敏捷项目应该有需求收集、设计、分析、编码、测试；就像瀑布式开发模型一样。然而，在敏捷项目中，各个阶段应该覆盖更少的范围，因此发生得更快。
我同意 Péter Török 的回答，但敏捷团队或敏捷团队经理也有责任教导业务团队，如果他们将新需求推迟到下一个需求阶段，项目每轮都会交付更好的结果。由于一轮应该为 30 - 90 天，因此大多数新要求可以等待。少数要求不能等待，需要有时间和进度成本。
Agile projects are supposed to have requirements gathering, design, analysis, coding, testing; just like the waterfall development model. However, in an agile project, the phases are supposed to cover less ground and therefore, happen faster.
I agree with Péter Török's answer, but its also the responsibility of the agile team or the agile team manager to teach the business team that the project will deliver better results each round if they postpone new requirements until the next requirements phase. Since a round is supposed to be 30 - 90 days, most new requirements can wait. The few requirements that can't wait, need to have a time and schedule cost.
这里是 Scrum Master 的意见。听起来企业对什么是“敏捷”或如何实施它缺乏清晰的了解。敏捷需要与结构一起应用，无论是 Scrum、看板还是类似的东西。很多时候，它是“我们不设计或记录”事物的同义词。
如果您指的是使用 Scrum 的团队，只要产品负责人和 Scrum Master 处于领先地位，这就是可以管理的。
如果业务团队“随意”提出不一致的需求，则由产品负责人将这些需求纳入考虑范围，并在冲刺计划之前确定任务列表的优先级。如果它们与已经完成的事情不一致，由于团队需要进行重构等，它们可能会被估计为大故事。然后，由产品负责人决定是否值得继续使用它们（尽管规模很大），或者是否值得研究与已完成的工作相一致的替代故事。
对于整个 Scrum 团队来说，这将是一个艰难的工作环境，但您会期望业务部门通过改变冲刺之间的方向来看到损失的价值，并希望不久之后就能将产品调整到一个方向。这当然不是开发团队没有预料到这一点的错，我更想说的是 Scrum Master 和产品负责人需要与所涉及的业务部门进行一些严肃的交谈。
Opinion of a Scrum Master here. It sounds like the business is lacking a clear knowledge of what 'agile' is, or how they implement it. Agile needs to be applied with structure, whether that be Scrum or Kanban or something similar. Too often it is a synonym for 'we don't design or document' things.
If you are meaning a team using Scrum, this would be manageable as long as the Product Owner and Scrum Master are on top of their game.
If the business team are giving requirements 'at will' that do not align, it is up to the Product Owner to take these on board, and prioritise a list of tasks prior to sprint planning. If they don't align with what has already been done, they may be estimated as large stories, due to the need for refactoring etc. by the team. It will then be up to the Product Owner to decide if it is worth proceeding with them despite the size, or working on alternative stories that align with work already done.
This would be a tough environment for the whole Scrum team to work in, but you would expect the business to see the lost value by changing direction between sprints, and hopefully align the product to a direction before too long. It certainly is not the development teams fault for not anticipating this, I would more say the Scrum Master and Product Owner need to have some serious words with the business units involved.
冲刺和积压之间需要有一个缓冲区。
业务团队拥有待办事项和待办事项中故事的优先级，但是一旦开发团队在冲刺中承诺了 x 个故事，那么业务团队修改其内容是不明智的。如果您发现这种情况发生，我建议缩短冲刺的长度。
然而，如果出现一个超级紧急的新需求，而不能等待下一个冲刺，那么必须删除另一个具有相似点值的故事。
业务团队管理他们的积压工作非常重要，以便在冲刺计划会议上充分确定下一组故事、确定优先级并准备好进行。
There needs to be a buffer between the sprint and the backlog.
The Business Team own the backlog and the prioritisation of the stories in the backlog but once the Dev team have committed to x number of stories in the sprint then it is unwise for the business team to tinker with its content. If you find this happens I would suggest shortening the length of the sprints.
If however a super urgent new requirement comes up that just cannot wait for the next sprint then another story/stories of similar points value have to be removed.
It is important that the business team manage their backlog so that in the sprint planning meeting the next set of stories are fully specked, prioritised and ready to go.
是的，改变需求是可以的（也许不能放松），但在我们的团队中，我们不会破坏或改变冲刺的范围，除非冲刺范围内当前的工作由于添加到冲刺中的新需求而变得多余。产品负责人的产品待办事项（不是冲刺待办事项）。另请注意，如果您在冲刺中承诺完成 100 点的工作，那么您完成了 80 点，并且需求变化足以使冲刺中断，那么团队仍然根据 PO 的原始需求交付了 80 点冲刺。 （与外部客户打交道时很重要）
我们对正在开发的整体功能/项目有非常高层次的了解，但是在接受用户故事（功能/项目的细分块）之前，我们确保完全理解产品负责人的需求。如果产品负责人不确定，我们会询问了解的人。请注意，我并不是说您规划了整个项目，您只确定了 1 或 2 个冲刺的用户故事。
（我就是这样做的，但是没有规定性的规则，每条敏捷规则都会让敏捷变得不那么敏捷——我的观点）
Yes, it's ok to change requirements (maybe not relax), but in our teams we will not disrupt or change the scope of the sprint unless the work currently in scope of the sprint is made redundant as a result of the new requirements added to the product backlog by the product owner (not the sprint backlog). Also note that if you commit to 100 points worth of work in a sprint, you complete 80 points and the the requirements change enough for the sprint to be disrupted then the team has still delivered 80 points that sprint based on the POs original requirements. (important when dealing with external clients)
We have a very high-level understanding of the overall features/project being worked on, however before we accept User Stories (broken downs chunks of the feature/project) we ensure that we fully understand what the Product Owner wants. If the product owner is unsure then we will ask the person whom does know. Note I am not saying that you plan out the whole project, you only nail down 1 or 2 sprints worth of user stories.
(This is how I do it, but there is no prescriptive rules, every agile rule make Agile less Agile - My opinion)
不行，随意提出要求是不行的。
人们普遍认为业务和开发每天都会一起工作，并且主要不是以书面形式进行，而是面对面（通常是审查或计划事情）。我们的想法不是对未来做出太多假设，而是做出一些假设并顺应这些假设。
作为一名编码员完成此操作后，我能给出的唯一建议是：为更改做好准备。当您了解框架时，产品方也会了解业务。
如果您遇到这样的问题： 解决这个问题实际上很重要。这就是冲刺的目的：在某件事上失败，然后在回顾后修复它。这样做一段时间应该会导致一个健全的有组织的过程，如何在正确的时刻获得所有需求。
然而：正确的工程以及正确的安全和需求工程还没有伤害任何人。如果您需要这样做，尽管您的流程很敏捷：那就这样吧。
No, it is not ok to give requirements at will.
There is a general notion that business and development work together on daily basis and do that not primary in written form, but as well face to face (often to review or plan stuff). The idea is not to make too much assumptions on the future, but some and go with these.
Having done this as a coder, the only advice I can give: Setup for change. As you learn about your framework, the product side learns about the business.
If you run into problems like these: Its actually important that you fix this problem. This is what you have sprints for: Fail at something and then fix it after a retro. Doing this for a while should lead to a sane organized process how to get all the requirements at the right moment.
However: Proper engineering has hurt no-one yet as well as proper security and requirements engineering. If you need to do this despite your agile process: so be it.