想說愛你不容易——關於在軍軟開發中應用敏捷模型的幾點思考
敏捷自打誕生之日起，就深得大多程式設計師的歡心。
敏捷宣言的4個核心價值觀：
-
個體和互動高於流程和工具
-
工作的軟體高於詳盡的文件
-
客戶合作高於合同談判
-
響應變化高於遵循計劃
僅僅敏捷宣言中的“工作的軟體高於詳盡的文件”這一條價值觀就值得大多數程式設計師的擁護。況且，敏捷就是以人為本的開發模型，而重視人的作用就是要加大對程式設計師的重視，作為程式設計師誰不願意擁抱敏捷呢？
受到程式設計師歡迎的敏捷開發能夠及時響應開發，快速交付可用版本，實踐中已經有了一些成功案例，甚至包括在一些高可靠高安全需求的軟體專案。可是，敏捷開發要真正用於軍軟開發就要解決一些水土不服的問題。
-
使用者問題
敏捷模型中要求有現場客戶或客戶代表，客戶是深度參與到軟體開發當中的。而在軍軟開發當中，軟體開發的使用者需求大多數都不是來自終端使用者，而是來自組織內的系統組。系統組除了提供軟體開發的使用者需求之外，還有對外協調和溝通的任務、系統設計和開發、聯試、試驗等任務，系統組像敏捷模型的現場客戶那樣深度參與軟體開發是一件不可能完成的任務。
-
需求問題
敏捷開發不要求形成需求規格說明這樣的完整的文件後才開始軟體開發活動，它是以“使用者故事”的形式提交需求給開發人員，開發人員據此開發。而這個使用者故事通常只是從使用者使用的場景提出的需求，很難滿足關於需求的準確性、一致性、可測量等的原則性的要求。開發人員在拿到這樣的“使用者故事”後，還需要同現場客戶一起落實需求的細節才能進行開發。而一旦現場客戶對需求描述不準確，甚至時不時提出一個異想天開的需求，那對於軟體開發來說就是一場災難。
在《重構極限程式設計——XP的實踐與反思》一書中就已經對於敏捷開發的這種沒有一個有效的需求確認提出了質疑，甚至把一些敏捷開發失敗的案例也歸結於此。
對於軍軟開發來說，即使在前期不形成一個完整的需求規格說明文件，但有效的需求確認還是必須要做的。開發人員和系統組對於“使用者故事”（假設軍軟開發也採用這樣的需求表達方式）描述的需求要達成一致理解，對於“使用者故事”的需求細節也應由系統組做進一步的確認。形式上可以先不形成任務書和需求規格說明，但需求評審和必要的簽署應當是需要的。
-
設計問題
敏捷開發中沒有整體架構設計的階段，架構設計是基於當前開發的需求建立的，隨著開發的需求增多，通過重構的方式來不斷優化架構。
對於軍軟來說，多數情況下都是大部分需求已經明確，少部分需求待定。如果是這樣的話，就應該先做好整體架構設計，考慮架構的健壯性、可擴充套件性，減少重構的次數。畢竟重構的次數越多，代價越高。
-
測試問題
敏捷開發沒有專門的測試階段。敏捷開發的測試主要是在功能實現的過程中由開發人員進行的單元和整合測試（這裡有藉助自動化工具實現的持續整合和自動化測試，也有TDD的應用在裡面）。一些大廠在實施敏捷開發時也會在程式碼部署到生產環境之前前先部署到測試環境上由測試人員完成功能測試。
但是對於質量需求、安全需求更加重視的軍軟開發來說，不僅要考慮測試的敏捷性，更要考慮測試的有效性。
其一，有效的測試不能只做白盒測試不做黑盒測試，有效的測試應當是二者合一，集中兩者的優點。軍軟的測試必須要應用好這兩種測試方法，追求測試的有效性，哪怕為此增加測試成本延長測試周期也是值得的。
其二，軍軟當中的很多嵌入式軟體的驗證對硬體環境依賴巨大，這對於敏捷的自動化測試、持續整合等理念的實現有巨大的阻礙。
-
文件問題
敏捷開發重視軟體功能的實現，不重視文件的詳盡與否。但對於軍用軟體來說，軟體的維護性、保障性是非常重要的一環，而要做好軟體的維護和保障，文件就是不可或缺的。
在實際的軍軟開發過程中，可以考慮中間使用簡化的文件記錄，把形成正式文件的工作放在後期。
所以，軍軟開發要使用敏捷模型，就一定要把敏捷融入到GJB5000當中，吸收其敏捷思想和部分優秀實踐，以優化基於GJB5000標準的原有的重量級的軍軟開發模式，最終形成高效又高質量、高可靠、高安全的軟體開發模式。
這正是：
敏捷誰人不想要，實踐問題要思考
融入五千唯正途，軍軟開發方最好
作者簡介：王小雙，長期從事GJB5000推廣、實施、評價、改進的工作，建立《軟體工程之思》微信公眾號，一直在《軟體工程之思》分享GJB5000、CMMI、軟體工程的知識和感悟。現致力於GJB5000諮詢以及軟體過程改進、軟體工程能力提升的研究工作。