敏捷科研

轉載自: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)集成與測試方法的開發,另一方面負責集成工程師的培訓。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章