如何在敏捷方法论中进行创新[关闭]

可以说一句话，敏捷方法在对需求了解甚少或涉及新颖性的环境中很好。但是，应将其应用于需要彻底创新的地方吗？如果是，怎么办？

如果您要考虑的事情在行业中是未知的，或者甚至被认为是不可能的，那么可能很难想象用户故事和相关任务。例如，通过将广义相对论分解为史诗，冲刺和任务来设计广义相对论，是否会使艾伯特·爱因斯坦（或他向之报告的假设雇主）受益？如果答案是“是”，那么应该采用哪些特殊的措施来帮助敏捷方法与爱因斯坦获得革命性见解的方法一起发挥最佳作用？

举一个特定的软件示例，假设年份为2008，并且您想使用WCF提供COMET或“ 长轮询 ”类型的功能。您对“以前的工作”的所有研究都没有结果，甚至您还读过一个MSDN博客说这是不可能的。

再者，可以为用户故事和任务带来什么调整或“风味”，以适应此Endeaver的发明性（或胆大？）？还是可以断定这项工作具有创新性（在2008年），最好还是将其作为无方向的智囊团活动，这会更好吗？

在两个星期的冲刺状态下工作的创新者当然不希望每次放弃一个死胡同的任务而开始从事新的任务，而该任务是在定义冲刺时未曾设想的，因此他不想被击落。同样，当冲刺结束并且没有交付任何工作代码或工作方法时，创新者也不应被管理层击倒。即使在这些情况下，也需要一种将努力标记为“成功”的方法。在这种“死胡同”的追求中，创新者可能再经过一三个冲刺，最终找到可行的方法。

敏捷如何让管理层知道，尽管有一些挫折，每个冲刺还是“不错”的？如何进行管理，以使燃尽图看起来并不荒谬？

标题问题是，创新是指在敏捷中表现出色的团队中较小规模的创新发展。

关于“金卡日”的文章总结了最佳答案。

摘要（措辞，以及我自己的解释可能并不反映作者的意图）：

• 开发人员可以识别出与他们想进行的工作相关的有趣的（目标是刺激性的）目标。
• 在团队（包括产品负责人）批准之后，这些扩展目标就变成了“金卡”。
• 鼓励团队抽出一天的时间来处理这些“金卡”。
  • 通常，这恰好是在星期五，因此它成为“金卡日”。
• 关于Scrum，金卡的安排和跟踪与其他任何待办事项一样。团队将需要证明他们的结果。

关于应用“金卡”，还有其他一些要点（不在该文章中）：

• 不要让一个团队成员乐在其中。应该鼓励每个团队成员花一些创造性的时间，每隔一段时间参加一次“金卡日”。
• 沿着同样的思路，尝试使“金牌”成为团队努力（相对于个人任务），并将该任务作为社交（团队建设）时刻加以利用。

实质性的问题是，创新是指研究（数月至数年的艰苦工作）有可能找不到任何有用的解决方案的真正风险。

这个较早的问题是，在研究环境中适合使用哪种极限编程技术？涵盖了这个问题的大部分内容。

（免责声明：我写了该问题的答案之一，尽管不是选定的。）

总结是，软件研究工作可以快节奏进行。它要求其参与者根据新信息（通过吸收发现/学习的思想并综合新思想）确定优先级。它之所以显得“缓慢”，是因为它“只有在成功的情况下才显示成功的果实很慢”。

有关项目管理Beta版的问题- 将项目经理纳入研究团队的利弊是什么？-也涵盖相同的理由。

在精神上，是的。

正如mouviciel的回答所指出的那样，软件研究的精神与敏捷宣言的精神是一致的。接下来我要讨论的是，高风险研究是否可以适合作为组织或管理方法的敏捷（“实践中的敏捷”）。

在实践中，您必须回答一些问题。
此列表并不详尽...

我们必须回溯一下敏捷方法论是如何形成的。

当项目有赞助者时，通常使用敏捷方法。此外，发起人资助该项目的意愿是有限的；它希望在为项目提供一段时间的资金后，会定期交付一些具有可用质量（可能可交付）的软件。

在这个问题上的研究工作是指“潜在的不可解决的努力”。换句话说，尽管涉及人员的所有意图和勤奋，这种工作的本质具有最终失败的风险。

这不是ScrumButt样式的清单。
这更多是预检清单，可以预测“ Que Sera，Sera”是否更好

1.预先透明。是否向项目的发起人告知了项目风险性质的真相？

2.发起人的意愿。发起人是否意识到风险并愿意继续提供资金？

发起人需要承担的风险要高于典型的业务项目或典型的软件/ IT /敏捷项目。并非每个赞助商都符合此条件。如果不合适，那么专业人员退出该项目将是一个很好的选择。

3.整个项目的透明度。是否定期将项目的真实状态告知发起人？

这是通过滥用状态更新之间的时间间隔来阻止隐藏项目中的挫折或迫在眉睫的失败的尝试。

4.发起人的积极参与。赞助商是否有兴趣了解每一个尝试的细节，起伏，承诺和局限性？

软件研究的问题在于，可能存在许多错误的线索-错误的肯定（相信一种方法会奏效，但最终没有成功）和错误的否定（声称不可能做某事，只能由其他人来证明）。 。

敏捷项目允许团队（包括发起人和利益相关者）承担经过计算的风险。“已计算”是指风险承担者被充分告知。如果发起人不愿意了解项目的实质内容，那么发起人将没有完整的信息来自行计算（判断）风险。

即使赞助者愿意承担财务风险，如果它也不愿也承担决策风险（并接受自己选择的后果），那么赞助者也不适合这种高风险的研究项目。

5.研究团队是否可以通过运行软件而不是演示幻灯片的形式来展示（展示）他们的进度？

该问题适用于预期最终结果将运行软件的研究项目。演示幻灯片对于解释CS理论可能很有用，但也可能被滥用以隐藏软件实现中的挫折（或完全没有）。软件演示旨在阻止此类滥用。

6.即使发起人决定在项目中的任何时间停止资助，研究团队能否提供部分有价值的软件产品？

该问题仅在个案基础上相关。一些研究项目是渐进式的。他们可能有多个里程碑和可交付成果。它要求研究团队确定其方法的优先次序，以偏爱“先挂最少的果实”或“成本最低的方法来证明可行性”。

一些研究项目不是渐进式的：提供单个非常具体的技术突破。这是一个命中或错过。对于此类项目，唯一的增量成果是研究工作和原型制作，甚至是学术出版物。但是，这些“非消耗性”的可交付成果对于某些类型的赞助者来说是有价值的，这些赞助者是大学，研究资助机构和希望建立学术信誉的知名公司。

但是，具有此类特征的研究项目也可能会喜欢“牛仔编码”方法，如下所述。这些被恰当地称为“骇客”，它们确实发生在学术界。

由于大多数学术研究的时间长短，通常会以一年或一年以上的承诺提供学术风格的研究资金。医学研究资金（学术和商业）可能需要更长的时间。另一方面，典型的商业资助研究可能会在不通知的情况下终止，或者将其资源（人力）完全分配给其他项目。

7.研究团队如何衡量筒仓与跨职能的规模？

某些类型的研究团队非常孤立。通常，这会在“多学科”项目中发生-涉及到每个学科的一名成员。结果，因为他们的知识和技能不重叠，所以任何人都不能接管另一位成员的任务，甚至是很小的任务。困难还将扩展到沟通和任务定义。

极端孤立的团队仍然可以从一些Scrum仪式（例如每日站立会议）中受益，但是除了“仪式”之外，可能没有太多互动。需要高度社交化的敏捷教练来吸引团队讨论和建立信任。

8.如果存在敏捷教练，那么教练是否规定了较短的迭代周期，装箱和提供时间估计？

这些敏捷实践中的每一种都会给某些类型的研究项目带来困难。但是，据报道，一些熟练的研究小组能够将这些实践应用到高级研究中。由于没有这些专家团队内部如何进行敏捷教练的详细信息，因此我们可能无法知道如何克服这些困难。

9.研究团队是否一致投票赞成采用Solo开发风格，而不是其他任何方法？

编辑： 较早的版本使用短语“牛仔编码”，这暗示缺乏专业精神。但是，独奏开发和牛仔编码之间是有区别的，并且此清单中的情况可能使独奏开发成为合理的选择。

这个问题表明，有些程序员更喜欢拥有大量的开发内容。如果研究团队主要由这种类型的程序员组成，并且鉴于团队成员的技能组合是不可替代的（请参见前面的技术孤岛），则可能必须向团队成员授予他们期望的东西，以换取他们的技能和劳动。

单独开发和牛仔编码之间的主要区别在于，在单独开发中，可以采用《乔尔测试：更好的代码的12个步骤》中列出的做法，例如使用版本控制，构建自动化以及在添加新功能之前修复错误。 。

在某些情况下，有利于每个成员进行单独开发，而在某些情况下，有利于牛仔编码。

如果最终目标是“提出要点”，则牛仔编码将受到青睐，因为这表明技术上是可能的。除了在下一个DEFCON®上进行出色的介绍外，对交付或质量都没有要求。

最后一个问题。如果情况不允许敏捷团队进行突破性的研究，那么他们如何利用创新技术？

照常营业。让其他公司（或学者，黑客的个人或团队，创业公司等）首先解决难题，然后从他们那里购买/许可技术。几十年来，软件行业一直在遵循这些原则。

强调以敏捷方法论展示早期工作的原型迫使团队首先寻找现有的解决方案，这是一件好事，因为它可以使团队免于进行一些多余的工作。

返回敏捷宣言：

1. 个人与流程和工具之间的互动
2. 通过全面的文档工作软件
3. 客户合作而非合同谈判
4. 响应计划变更

这些价值观都禁止创新。实际上，与瀑布相比，创新在敏捷方面的嵌套更好。

但是，可能会发生，通常的敏捷实施对软件项目施加了一些限制创新的约束，例如期限（冲刺的时间范围是期限）或成本。但这不是敏捷的问题，而是当前工作组织的问题。

我不这样认为。敏捷就是要吃巧克力大象-承担一项大任务并将其分解为可管理的块，这些块不仅可以交付，而且可以定期交付。

研究型项目不适合这种情况-除非您的项目可以分解成小块，每两周才能展示一次（或更长时间），否则敏捷不会说2周是您的sprint必须花费的时间，这是我有史以来最好的敏捷项目进行了6周的冲刺）

我不会尝试的。我会采用一些您认为对您有用的敏捷工具，而忽略那些无效的工具。太多的人认为敏捷的意思是“您必须按照Scrum教程中的说明必须做的所有事情，并且永远都不能自由裁量”，这种方法非常不敏捷。