核電行業敏捷實踐

在核電行業，安全是生命線。《核電廠質量保證安全規定》及其一系列相關法規，對我國核電建設的質量保證提出了必須滿足的要求，其中所有涉及核安全的產品，均必須實現“雙向可追溯，全程可監控”。因此，為了拿到民用核安全設備設計、制造許可證，核電行業的控制保護系統往往采用瀑布模型作為系統研發模型，并引入質量控制（QC）、質量保證（QA）、驗證與確認（V&V）等多種角色確保質量。那么，核電行業又是因何與敏捷開發方法結緣的呢？

本文從中國某核電公司（下稱“公司”）在將科研與開發分離時面臨的困惑談起，介紹了該公司在科研項目中引入敏捷開發方法的做法，以供業界參考。

科研與開發的分離

某核電公司是一家專業從事核電站儀控系統研發的公司。2010年以前，公司的項目大致可分為工程項目、研究項目和開發項目。其中，工程項目直接面向核電站最終用戶，需要利用核電站大修換料期的短短一個多月的時間完成安裝、調試并實施，時間緊、任務重、質量要求極高，而每耽誤一天造成的核電站停機損失數以千萬元；研究項目和開發項目的成果則直接為工程項目服務。由于公司有面向核島、面向常規島及面向生產管理層的多條產品線在同時進行研發并配合工程實施，由此產生了大量的定制版本。隨著項目的增多，實施及產品維護困難凸顯。

為了更好地平衡質量、時間與人員投入等之間的矛盾，基于各產品線存在技術相似性的特點，公司按照“統籌規劃、兼顧長遠”的原則，對研發與工程實施體系自下向上進行了重構，并把其劃分為技術平臺、產品平臺、解決方案三個層級（見表1）。

通過將技術平臺獨立切割，公司將現有產品中技術難度或風險較高的部分分離出來，利用單獨的科研活動進行處理，在技術平臺研究未取得成果時，也可以將第三方成熟穩定的技術或組件等應用于產品平臺，有效避免了工程項目實施期間可能遇到的重大技術問題。而在當前技術問題解決后，科研活動可以轉向更先進的技術開展預研，確保公司“研究一代、開發一代、實施一代”的戰略規劃得以落地。

此外，通過技術平臺、產品平臺及解決方案的劃分，公司避免了大量針對工程項目的定制產品的出現，事實上節省了公司的實施及運維成本，使得核電數字化儀控系統的研發順利進行。

科研活動帶來的新問題

2010年，公司成立研發中心，主要從事核電站數字化儀控系統技術平臺的管理，以及利用研究室和實驗室為主體的強大的科研能力進行科學研究（含硬件、軟件、結構件等）。

在成立之初，基于以往的行業經驗，研發中心科學研究采用的多是產品研發的瀑布模型，但經過近半年的實踐發現，瀑布模型過于“笨重”，不適合“需求難以鎖定、技術邊學邊用”的快速變化的科研項目。

為了解決這個問題，研發中心嘗試在科學研究的管理環節引入敏捷開發方法，但這又帶來了新的問題。

（1）公司已通過軟件能力成熟度集成模型（CMMI）3級（已定義級），正處在向CMMI 4級（量化管理級）的轉變過程中。原有的產品研發體系要求，需求不鎖定就首先解決需求問題，技術不明確就先完成技術知識的儲備，否則不能進入下一階段。同時，所有的相關技術文檔、人員角色安排也是基于CMMI體系，因此引入敏捷開發方法相當于引入一套新的體系，需要重新梳理相關流程。

（2）核電行業“全程可控”的思想與敏捷開發方法的“小步快跑、快速迭代”的理念之間存在著一定的矛盾。因此，研發中心需要統一大家的思想，尤其是領導層的思想。同時，研發人員還需要掌握敏捷開發方法的技巧，適應新的工具，而這些都需要一個過程。

敏捷開發方法的引入與改進

對現有研發體系的影響

引入敏捷開發方法的第一步，就是要考慮如何與公司現有產品研發與工程實施體系相融合。

對于公司來說，通過劃定解決方案、產品平臺與技術平臺的層級，切分了工程實施、開發活動及科研活動的邊界。但邊界的切分不代表要求的降低，科研活動同樣要以滿足核安全質量要求為前提。敏捷開發方法引入科研活動，首先要考慮的是流程的改進如何滿足質量的要求，要能夠保證科研活動輸出成果的質量，并能夠提供相應的度量方法（見圖1）。

另外，由于科研活動成果服務于產品平臺的開發，在采取了敏捷開發方法后，科研團隊的開發節奏與產品平臺開發團隊的瀑布式開發節奏產生了差異。從最終用戶優先的角度出發，科研團隊的迭代成果必須服從和服務于產品平臺的開發周期，不論其處于什么階段。

制定策略與目標

由于敏捷開發方法的引入與公司現有管理思路、管理體系存在較大差異，研發中心制定了“分階段、分步驟，先試點、后推廣”的引入策略，并通過實施過程中取得的效果逐步統一大家對敏捷開發方法的認知。

第一階段，研發中心目前有軟件、硬件及結構件三大類工作，從便于引入及實施的角度考慮，首先選取1～2個軟件類科研課題進行試用，分析試用過程中遇到的問題，總結經驗，建立流程、模板、規范，從而具備基本推廣條件。

第二階段，擴大試點范圍，推廣至研發中心其他軟件類項目，積累更多經驗，完善流程、模板、規范，具備進一步推廣條件。

第三階段，推廣到研發中心所有項目，并適應性調整流程、模板、規范，修改研發中心規章制度。

在具體實施目標方面，第一階段主要為梳理出符合研發中心軟件方面的科研流程，使得平臺、產品的研發與科研能夠更好地配合。此階段的具體工作如下：①思想方面，通過多次培訓，統一相關人員的思想，掌握敏捷開發方法和技巧；②流程方面，結合當前公司流程、模板、規范與敏捷開發方法的特點，建立起一套符合試點項目類型的敏捷項目實施管理流程；③組織方面，具備基本的推廣條件，如培養出敏捷教練、提出組織敏捷轉型建議等。

基于嚴格的行業規定、公司整體對敏捷開發方法了解程度欠佳等因素，在第一階段，研發中心采取了以Scrum框架為主、結合使用XP極限編程的最佳實踐的方式，以便于擴展和改進。

統一認識

對于核電行業來說，標準的符合性是非常重要和嚴肅的問題。以安全軟件研發為例，為了證明研發出來的軟件是安全的，研發機構必須嚴格按照IEEE 1228或者IEC 61508等標準中規定的每一步來執行，任何刪減都會影響軟件安全的認定。

但對于敏捷開發方法來說，是否也是這樣？是否必須完全按照Scrum或者XP等來做，才可以稱之為敏捷開發方法？

在開始時，大家對于這個問題爭論不休，每個人都有自己的看法。研發中心最終采取“擱置爭議，摸索前行”的方式，在實踐中解決問題。在進行最終總結時，大家取得了共識：對于公司來說，敏捷開發方法不是某種特定的框架，不能局限在Scrum或XP中，符合敏捷宣言核心價值的實踐才是敏捷。在表現形式上，敏捷開發方法是符合公司實際情況的最佳實踐的集合。

團隊角色再定義

在組建敏捷開發團隊時，研發中心首先面對的就是相關角色的定義。

一個標準的敏捷開發團隊通常包括產品負責人（Product Owner，PO）、敏捷教練（Scrum Master，SM）、團隊成員，分別負責需求管理、敏捷開發過程管理及具體的開發工作。但按照研發中心現有流程，每個科研項目僅有一個項目經理，負責整體管理項目，協調處理各類匯報及各種關系。在試點開始階段，試點項目按照要求分別確定了PO、SM與團隊成員，將原項目經理根據業務能力的特點分別歸入PO或SM的角色。

但隨著試點開展，大家發現，研發中心領導往往習慣與原項目經理溝通一切，而原項目經理在與PO或SM發生爭論時，也往往習慣用行政權威解決問題。因此，在試點后期，研發中心將PO與SM的角色合一，并由原項目經理統一扮演，能力上的不足則通過培訓來解決。經過這樣調整，試點項目運轉更加流暢。

精簡低效的會議

按照Scrum結合XP的框架，試點項目開始階段分別定義了迭代計劃會議、每日站會、產品列表休整會、迭代評審會議、迭代回顧會議、發布計劃會議等多種形式，這也同樣遇到了問題。

科研項目的用戶，由通常意義上的最終用戶變為了產品平臺的開發團隊，而產品平臺的開發團隊首先需要滿足工程項目所確定的里程碑，自身業務較為繁忙。另外，產品平臺開發團隊的業務范圍與科研團隊不同，對于科研團隊具體研究過程并不關注，往往提出時間與應用的要求以后，就不愿過多地參與討論過程。因此，本應全部會議都參加的用戶，逐步演變至在迭代計劃會議結束后，就不再出現。基于此，試點項目最終整合了迭代計劃會議、迭代評審會議、迭代回顧會議、發布計劃會議，將相關工作在每個迭代的開始階段進行。只是保留了產品列表休整會和每日站會，在每周和每天開始時對工作進行討論與調整。

找準用戶，講好“故事”

由于用戶的變化，科研項目的用戶故事事實上下沉到了軟件和硬件的需求層面，而研發中心賦予科研團隊技術攻關的要求，也使得用戶故事的范圍進一步擴大，擴展至了設計、編碼、測試等產品開發各個階段。由于產品平臺開發團隊面向工程項目，其應用科研成果過程中出現的影響工程項目里程碑的關鍵技術問題，也必須同樣緊急追加至用戶故事列表中。

此外，在實際工作中，科研團隊認識到，研究型的用戶故事的工作量估算非常困難。科研團隊成員的分工較為明確，而每個人通常只對自己熟悉的業務領域擅長，導致采用計劃撲克牌進行工作量的估算形同虛設，每個迭代周期的任務量往往不飽滿或者超負荷。

為了解決上述問題，試點項目將迭代周期調整為一周、兩周甚至三周可選；加粗了用戶故事的顆粒度，不再追求每一項都清晰可控；給團隊預留在研究過程中的動態調整時間，并通過每日站會及每周的產品列表休整會有針對性地調整用戶故事列表，允許產品團隊臨時增加緊急任務。但敏捷撲克作為一種溝通工具仍然保留下來，因為它使得大家對于任務的認識趨于一致。

經過上述調整，敏捷開發方法終于能夠應用于軟件科研項目管理過程中，并初步與公司現有流程體系融合在一起。

結語

公司在成長過程中，會有很多轉變。作為一家核電行業的傳統研發企業，公司如何平衡科研與開發的關系，在實踐過程中既能滿足監管的要求，又能滿足公司研發的需要，一直困擾著管理層。敏捷開發方法盡管誕生于互聯網行業，但同樣可以應用于傳統行業。正如敏捷宣言所說“個體和互動高于流程和工具，工作的軟件高于詳盡的文檔，客戶合作高于合同談判，響應變化高于遵循計劃”，只要其中有一項應用場景是符合公司需求的，那就可以考慮引入敏捷開發方法，在實踐中加以吸收和轉化，設計出符合自身實際情況的流程，這也是推動公司不斷進步的動力。

由玉偉，高級工程師，曾就職于北京某核電公司，現就職于國家藥品監督管理局信息中心，從事信息化規劃、設計及開發相關工作。