如何允许敏捷方法的创新
可以这样说，敏捷方法在需求理解不足的环境中很好，或者涉及到重要的新颖性。但是，是否应该在需要彻底创新的地方应用它呢？如果是，怎么做？
如果你所考虑的在行业中是未知的，甚至被认为是不可能的，那么很难想象用户故事和相关的任务。例如，将广义相对论分解成史诗、短跑和任务，是否会使爱因斯坦(或他向其报告的假设雇主)受益？如果答案是“是的”，那么什么特殊的食宿应该结合在一起，以帮助敏捷的方法最好地与爱因斯坦实现革命性洞察力的方式一起工作？
为了给出一个具体的软件示例，想象一下2008年，您希望使用WCF提供彗星或"长轮询“类型的功能。你对“以前工作”的所有研究都没有结果，你甚至读过一位MSDN博主说这是不可能的。
同样，什么调整或“口味”可以引入用户故事和任务，以适应创造性(或大胆？)这个可爱的？或者，是否可以更好地得出这样的结论:这项努力是如此创新(2008年)，最好还是把它作为一个没有方向的智囊团演习？
这位在两周冲刺下运行的创新者当然不想每次放弃一项死胡同的任务而开始从事一项新发现的任务，而这一任务在定义冲刺时并没有被设想过。同样，当sprint结束而没有交付工作代码或工作方法时，创新者不应该被管理人员击倒。即使在这种情况下，也需要有一种方法将这种努力贴上“成功”的标签。在这种“死胡同”的追求中，也许还有一两次冲刺，创新者最终可能会想出一些可行的办法。
敏捷如何让管理层知道，尽管有创新的挫折，每一次冲刺都是“好的”？这是如何管理的，以使烧毁的图表看起来不荒谬？
回答 2
Software Engineering用户
发布于 2014-06-30 07:15:06
回到敏捷宣言：
- 过程和工具上的个人和交互
- 基于综合文档的工作软件
- 合同谈判中的客户协作
- 响应按计划进行的变更
这些价值观中没有任何东西禁止创新。实际上，与瀑布相比，敏捷比创新有更好的巢。
然而，通常的敏捷实现可能会对软件项目施加一些限制创新的约束，例如截止日期( sprint的时间框架是最后期限)或成本。但这不是敏捷的问题，而是当前工作组织的问题。
Software Engineering用户
发布于 2014-06-30 07:57:08
我不认为是这样。敏捷就是吃巧克力大象--承担一项大任务，把它分解成可管理的块，不仅可以交付，而且要定期交付。
研究型项目不适合这样做--除非你的项目可以分解成小块，每两周就可以演示一次(或者更长时间--敏捷说，2周是你冲刺的时候，我曾经做过的最好的敏捷项目有6周的短跑)。
不过我不会试的。我会拿出你认为对你有用的一些敏捷工具，而忽略那些不适用的工具。太多的人认为敏捷意味着“你必须做scrum教程说你必须做的任何事情，永远不允许你谨慎行事”，这种方法非常不敏捷。
https://softwareengineering.stackexchange.com/questions/246432
复制相似问题
腾讯云开发者
