敏捷科研

转载自：http://www.infoq.com/cn/articles/agile-academic-research

作者Professor Orit Hazzan & Sergey Tozik ，译者 徐涵 发布于 2014年8月26日 |

敏捷开发方法流行于软件开发行业，它也吸引着学术与企业界的一些科研工作者，他们试图弄清那些令团队具备敏捷特征的社会过程，并研究这些过程对团队效率的影响。

我们一直在考虑，运用敏捷原则是否能够对广大科研工作者（当然也包括上述研究敏捷方法与团队的研究者）有帮助。

据我们所知，目前还没有研究者提出过一种“以敏捷的方式”来开展科研的方法；也就是说，“学术敏捷流程”还尚未建立。

开发敏捷科研原则

敏捷软件开发的“12条敏捷原则”也可以转换到学术科研上来，如下表所示。

敏捷科研原则	敏捷软件开发原则
假如把科研看成是“产品”，那么“客户”要么是 a) 负责你的论文的那个学术期刊编辑（他代表期刊读者），或者是 b）学位论文评审委员会。你的导师是这些客户的绝佳代理人。提前把部分结果或中间结果作为论文发表出来，将有助于提高成功几率。	我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
围绕着论文、科研提案或毕业论文的草稿来组织工作。大概每几个月完成一个“接近可发表”的产品，即便还没攒够足以发表所需的“特色”。	经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
欣然面对来自导师、评审人和同行的批评。欣然面对研究方向的调整，即使在截止日期逼近之时——它们有助于改进最终产品。	欣然面对需求变化，即使在开发后期也一样。敏捷过程为了客户的竞争优势而掌控变化。
频繁向导师汇报进展，获取有用的建议，不要怕被认为愚蠢（你当然不蠢）或不专业。	业务人员和开发人员必须相互合作， 项目中的每一天都不例外。
研究者多是内在积极的，而研究助理们则不一定。给他们安排一些有价值、有意思的研究任务，为他们提供环境并支持他们，相信他们可以完成任务。如果必须独自做研究，通过交替从事有意思的任务来实现自我激励，不要把无聊任务的周期拉得太长。	激发个体的斗志，以他们为核心搭建项目。 提供所需的环境和支援，辅以信任，从而达成目标。
和导师、同行和助理等面对面交谈。会议好过电话；电话好过电子邮件、Google Docs或Dropbox。	不论团队内外，传递信息效果最好效率也最高的方式是 面对面的交谈。
演化中的工作草稿是度量进度的首要标准。	可工作的软件是度量进度的首要标准。
试图保持稳定的速度——不要赶，也不要耽误。创建某种看板似的系统来帮助你保持一个可控的工作状态。把任务完成；不要又拖延又觉得内疚。	敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
写作风格并非遥不可及。具备清晰写作和管理科研环境与记录的能力，将增强科研的质量与敏捷性。	坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
关注于研究目标与研究问题。	以简洁为本，它是极力减少不必要工作量的艺术。
经常与同行和同事探讨方法和结果。	最好的架构、需求和设计出自自组织团队。
学会反思。把反思结果写入工作日志。与导师和同事讨论你的见解。作为科研工作者，你的自我提升便是科研进展。	团队定期地反思如何能提高成效， 并依此调整自身的举止表现。

将敏捷开发方法运用于科研实践

为了验证我们的想法是否在真实科研环境中有效，我们在扎根理论定性研究方法中运用了敏捷原则与方法。扎根理论（Grounded Theory）是Glaser和Strauss于上世纪60年代年提出的一种定性研究方法，并最终发展为一系列研究方法（参见Hoda的文章《Grounded Theory for Geeks》，该文对扎根方法做出了幽默而精妙的总结）。

扎根理论方法强调理论产生于实地数据，而不是用数据来支持或证伪一个先验性假设。在思考谁将受益于敏捷原则时，我们首先想到了扎根理论。

我们参照敏捷软件开发的方法，开发了一套扎根理论实践原则，也许它们有助于以“敏捷的方式”来开展扎根理论研究：

• 专注于向客户或其代理人交付可工作的产品。

  就学术科研而言，产品要么是博士学位论文，要么是投往同行评审（peer-reviewed）期刊或会议的论文。对于前者，要满足的客户是学位论文委员会；对于后者，是审稿人和期刊编辑。对于初级研究者，也许资深研究者将成为这些客户的代理人，并承担起“现场客户”的角色。

• 在迭代中交付，按sprint工作

  敏捷原则要求频繁交付有用的产品原型。就科研活动而言，论文草稿即原型。每隔数周或数月完成一个论文草稿，将有助于减少拖延，并且可以随时应付在研讨会或学术会议上发言的需求——这种机会随时可能出现。

• 每个sprint专注于具体的科研活动

  如下所述，研究者一次专注于一个sprint，从而可以限制“在制品（Work-In-Process）”的数量。

  • 数据收集sprints专注于计划、执行和记录面谈（一个或几个），录制并记录观察环节，或者分析一批文档。在数据收集sprints中，研究者也要做一些初步的数据分析。本阶段的结果可用于更新论文草稿中的“研究数据”部分。
  • 理论构建sprints专注于推进扎根理论。这是通过进行深度数据分析、记录研究日志和逐步更新论文草稿中的“理论”部分来实现的，因为理论源于数据。
  • 文献调研sprints专注于阅览学术论文，并写出批判性摘要。批判性摘要的重点可以是列出相关主张和想法，并指出他们在相关知识体系中的位置。本阶段的结果可用于论文草稿中的“介绍”和”文献调研“部分，另外也可用在理论构建sprints中。
  • 产品稳定化sprints专注于文档编辑（重构）。研究者在阶段对已完成的迭代进行反思，并尝试应用学到的经验教训，以改善下一轮迭代，指引项目走向目标，甚至在必要时改变目标。研究者在对过往迭代进行回顾调查的同时，可以更新论文草稿的”方法论“部分——在扎根理论研究中，这意味着对理论路线进行反思，而不是直接沿用特定的方法论。
• 使用项目backlog和进展追踪

  在sprints推进项目的过程中，可以创建一个backlog。列出要与哪些信息提供者面谈、安排面谈和观察活动，以及收集待研究的文档与论文等，都有助于创建backlog。之后，研究者可以从backlog中拉取任务，作为下一个sprint。空backlog将有碍项目进展。不过，由于总能找到待研究的论文，因此当项目处于"旱季"、又缺少其他信息源的时候，可以由文献调研sprints顶上。研究者甚至可以投入一整个sprint来推进backlog，这叫“创建backlog” sprint。

• 反思过去，改进未来

  敏捷要求反思和回顾过去，从而指引项目，提高效用、效率和专业性。研究者们（尤其是那些兼职研究人员）经常独自工作，因此抓住每一个反思和获得反馈的机会十分重要。由于反思总免不了带有一些情感因素，因此研究者应当充分利用与导师和同事面对面交谈的机会来进行反思，而不是讨论研究本身——后者通过网络或电话亦可完成。扎根理论认为，研究者的反思属于方法论中的一部分，因此，记录在研究日志里的反思，或许在论文草稿的“摘要”部分能够用上。

• 记录推进产品演化的信息

  随着研究的推进和文稿的更新，许多记录和备忘被人遗忘。研究者们在关注最终产品的同时，不应忘记那些看上去不重要、但随着研究的演进可能变得关键的信息。所以，应该把文稿归档并管理起来，以便可以随时检索过去的信息。

  该档案包括：

  • 反应研究者在不同阶段对知识体系的理解的各种知识图，以及信息资源（如学术论文、科研备忘等）的链接。
  • 面谈和观察活动的记录，信息提供者们签署的同意书，和用于数据提取的文档。
  • 中间层数据分析，以及反映研究者对数据的见解与想法的备忘录。
  • 记录着研究进展与研究者反思的研究日志。

  由于档案的实施，我们还在试验阶段，这里我们只给出管理档案的一种选择，即根据论文草稿的结构来组织档案。

结论

学术研究和软件开发都产生有关信息的制品——要么是以计算机代码为形式存在的逻辑，要么是科研出版物里蕴含的知识，所以，相似的原理在这两类活动当中或许是相通的。

本文介绍了如何将敏捷原则运用于学术科研领域，并制订了”敏捷科研“原则的首稿。我们还就扎根理论定性研究方法如何运用这些原则提出了实践指导，其中采用的是和敏捷开发差不多的方法。

敏捷意味着更快交付更好、成本更低的软件，我们希望以类似的方式来进行科研，从而可以更快、更便宜地带来丰富且有用的知识，进而有利于科学研究社区与实践者社区。

作者简介

Orit Hazzan教授在以色列理工学院（Technion - Israel Institute of Technology）获得共计四个学位。其中三个学位来自科学技术教育系（1989年 学士学位，1991年硕士学位，1995年博士学位），另外2000年还获得工业工程系的工商管理硕士（MBA）学位。她于2000年10月加入科学技术教育系，并从2011年1月起担任系主任。她关注于计算机科学与软件工程教育方面的研究。Hazzan教授已经在实行同行评审的学术期刊和会议上发表论文 约100篇，并参与了三部学术专著的编写。

 

Sergey Tozik 拥有魏茨曼科学研究所（Weizmann Institute of Science）物理学理学硕士学位和以色列理工学院（Technion - Israel Institute of Technology）系统工程工学硕士学位。目前，他在Orit Hazzan教授的指导下在职攻读博士学位。他的研究兴趣包括系统集成师专业特征与培训。这项研究与履行首席集成工程师（Chief Integration Engineer）的职责相交叉。首席集成工程师一方面负责系统之系统（Systems-of-Systems）集成与测试方法的开发，另一方面负责集成工程师的培训。