The kind of up front requirements that would cause a developer to think twice about a project, would be those which indicate that the client are likely to be a nightmare to work with:
an obsession with one particular, unsuitable technology or presentation style
insisting on 'security' with glaringly obvious vulnerabilities
In an agile project, it's good to show a client the current state of the partially working system at an early stage, and get feedback, using this information to help design the subsequent parts of the system. If a client is too fixed on ideas of the final product then they might not be able to give useful feedback at this stage, and the final product may be not as good as it could have been.
This something that can be quite problematic with Agile. Some teams will use it as an excuse to not have a plan as they want to be 'adaptable'. Requirements can help to focus on the software architecture, which is something else that is not always given much focus in some Agile teams. It is points like these that lead me to believe that Agile should just be principles but not a methodology. Digital Animal wrote an interesting article about how Agile can be used in such a way that it stops being effective. For some teams, it is better to learn from what is great about Agile and use it to build a methodology that works for them. http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=CZcb6f
发布评论
评论（3）
前期要求没有什么问题。事实上，在起航之前知道您要去哪里是很有帮助的！
敏捷很大程度上取决于能够适应，因此，如果需求发生变化，您就不会陷入您不想要的东西。
There's nothing wrong with up-front requirements. In fact it helps to know where you're heading before you set sail!
Agile is a lot about being able to be adaptable, so that should requirements change you're not locked into something you don't want.
那种会导致开发人员对项目三思而行的预先要求，将表明客户可能会成为一场噩梦：
在敏捷项目中，最好在早期阶段向客户展示部分工作系统的当前状态，并获得反馈，使用这些信息来帮助设计系统的后续部分 如果客户过于专注于最终产品的想法，那么他们可能无法在这个阶段提供有用的反馈，并且最终产品可能不会那么好。
The kind of up front requirements that would cause a developer to think twice about a project, would be those which indicate that the client are likely to be a nightmare to work with:
In an agile project, it's good to show a client the current state of the partially working system at an early stage, and get feedback, using this information to help design the subsequent parts of the system. If a client is too fixed on ideas of the final product then they might not be able to give useful feedback at this stage, and the final product may be not as good as it could have been.
这对于敏捷来说可能是一个很大的问题。 一些团队会以此为借口不制定计划，因为他们想要“适应”。需求可以帮助我们专注于软件架构，而在一些敏捷团队中，软件架构并不总是得到太多关注。正是这样的观点让我相信敏捷应该只是原则而不是方法论。 Digital Animal 写了一篇有趣的文章，介绍了如何使用敏捷方法使其不再有效。对于某些团队来说，最好学习敏捷的优点，并使用它来构建适合他们的方法。 http://digitalanimal. com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=CZcb6f
This something that can be quite problematic with Agile. Some teams will use it as an excuse to not have a plan as they want to be 'adaptable'. Requirements can help to focus on the software architecture, which is something else that is not always given much focus in some Agile teams. It is points like these that lead me to believe that Agile should just be principles but not a methodology. Digital Animal wrote an interesting article about how Agile can be used in such a way that it stops being effective. For some teams, it is better to learn from what is great about Agile and use it to build a methodology that works for them. http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=CZcb6f