敏捷科研

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

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

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

开发敏捷科研原则

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

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

为了验证我们的想法是否在真实科研环境中有效，我们在扎根理论定性研究方法中运用了敏捷原则与方法。扎根理论（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）集成与测试方法的开发，另一方面负责集成工程师的培训。

查看英文原文： Agile Research