敏捷方法的好處是有據(jù)可查的，但是在合規(guī)驅動的市場中，向敏捷過渡對于嵌入式軟件團隊來說可能是一個挑戰(zhàn)。

敏捷方法的好處——尤其是更快的上市時間——已得到充分證明，但對于汽車、航空航天和醫(yī)療等合規(guī)驅動市場中的嵌入式軟件團隊來說，向敏捷過渡可能是一個挑戰(zhàn)設備。需要可追溯性和文檔來證明合規(guī)性，但這可能與敏捷精神相矛盾，敏捷精神仍然受到與方法論一起出現(xiàn)的不準確神話的困擾。事實上，只要采用正確的方法和工具策略，敏捷和合規(guī)性可以輕松共存，無需過多妥協(xié)。最重要的是可追溯性，在這種情況下，這意味著將需求與測試運行和解決的問題聯(lián)系起來。憑借可靠的可追溯性，您不僅可以提供滿足審核要求所需的證據(jù)，

一個好的起點是定義我們所說的敏捷開發(fā)的含義，因為這個術語雖然眾所周知，但經(jīng)常被誤解。在最簡單的層面上，敏捷是一種松散的方法論，它基于關注客戶需求、跨職能團隊協(xié)作和響應變化（而不是嚴格遵循記錄在案的計劃和時間表）。許多開發(fā)方法論，包括最近的一些混合方法，都屬于敏捷范疇，包括：Scrum、看板、Scrumban、Kanplan 和規(guī)模化敏捷框架 （SAFe）。

敏捷神話

無論敏捷是哪種風格，都存在一些常見的誤解，例如，敏捷缺乏結構或控制，或者需要在質量上進行權衡。這兩個神話都不是真的：結構、控制和質量保證都可以構建到敏捷過程中。

另一個錯誤的看法是敏捷不適用于受監(jiān)管的行業(yè)。然而，Perforce 自己在 2018 年對醫(yī)療設備開發(fā)市場（無疑是最受監(jiān)管的市場之一）進行的調查發(fā)現(xiàn)，到那時，超過三分之一的受訪者已經(jīng)轉向敏捷。有趣的是，我們越來越多地從處于嚴格監(jiān)管環(huán)境中的公司那里聽到，他們已經(jīng)——或即將——擁抱敏捷。

那么這些公司的工作原理是什么？這是團隊如何在敏捷框架上執(zhí)行的問題，無論他們使用哪種敏捷方法，可追溯性都是關鍵。憑借可靠的可追溯性，組織幾乎可以使用他們希望的任何流程進行交付。

可追溯性

可追溯性有助于回答“如果發(fā)生變化，還會影響什么？”這個問題。重要的是，可追溯性可以根據(jù)向后和向前可追溯性來定義。向后追溯是檢查設計或建造的東西是否符合上游要求。前向可追溯性檢查在生命周期的后期階段是否解決了所需的問題。

這是一個例子。在敏捷開發(fā)中，尤其是 Scrum 中，工作項被分解成更小的部分，并在固定的時間范圍內(nèi)完成，稱為 sprint 或迭代。這意味著管理人員必須確保每個工作項（及其較小的部分）具有適當?shù)臏y試覆蓋率。這種可追溯性需要從項目一開始就明確定義“父”和“子”項目之間的結構——換句話說，不同元素的關系和影響。這些工作的最終結果——在開發(fā)的所有階段都努力完成——是一個跟蹤矩陣，使組織能夠了解哪些需求、測試和問題是相互關聯(lián)的。這樣的跟蹤矩陣提供了一種簡單的方法來進行前向和后向影響分析，并最終提供現(xiàn)成的問責制。有了這個結構和數(shù)據(jù)，無論使用何種交付方法或流程，決策者都可以在變更發(fā)生之前了解變更的影響并管理和降低風險。雖然曾幾何時，可追溯性矩陣是手動創(chuàng)建的——例如，在 Excel 電子表格中——這些手動方法并不適合當今復雜的軟件環(huán)境。因此，越來越多的組織正在使用他們的 ALM 工具使流程自動化。

人們需要工具

敏捷從根本上講是關于人的，但鑒于工具發(fā)揮著重要的支持作用，因此必須確保可追溯性不受工具復雜性的阻礙。例如，如果需求存儲在 Word 文檔中，問題在 Atlassian 的 Jira 中進行跟蹤，代碼存儲在 Git 或 SVN 或 Microsoft TFS 等其他系統(tǒng)中，跟蹤和跟蹤是碎片化的，因此風險增加。同樣，如果這些團隊正在實施不同的項目管理方法，每個方法都有不同的標準、流程或控制，那么這種可追溯性可能難以實現(xiàn)。

對于希望在不增加風險的情況下實現(xiàn)某種程度的敏捷性的嵌入式開發(fā)人員來說，適當?shù)墓ぞ呖梢韵蛑辽贉p少進入障礙。例如，應用程序生命周期管理 （ALM） 工具可以與 Atlassian 的 JIRA 集成，以提供端到端的可追溯性、測試和需求管理，同時還提供合規(guī)性報告和審計所需的數(shù)據(jù)。

過渡到敏捷——最佳實踐

首先是需要高管的支持。與任何其他主要的組織計劃一樣，如果沒有 C 級的全力支持，敏捷將無法通過不可避免的阻力和障礙。

其次，敏捷最好從團隊層面開始。通過定位錯誤步驟，組織既可以降低風險，又可以使成功更容易實現(xiàn)。團隊級別的經(jīng)驗教訓可以擴展到部門級別，然后，如果適用，可以在整個組織范圍內(nèi)應用。

第三，作為過渡的一部分的團隊必須有一個清晰的流程和共享的命名法。例如，需求是寫成用戶故事還是兩者結合使用？估計是以天、小時還是故事點來衡量的？是否需要重新定義角色，例如，是否需要將業(yè)務分析師培訓為 Scrum Master？這些問題（以及更多問題）應該盡早得到解決和解決，以便高管、經(jīng)理和團隊使用相同的語言，從而能夠在可能迷失方向的時候進行充分的溝通。

當然，還有無數(shù)其他的考慮需要考慮，其中許多是無法計劃的，因此只能在它們出現(xiàn)時加以解決。雖然它已成為陳詞濫調，但必須理解唯一不變的就是變化。

所有這一切都必須在許多行業(yè)不斷發(fā)展的監(jiān)管和合規(guī)背景下發(fā)生。未來為這些組織帶來什么難以預測，但合規(guī)性已成為日常業(yè)務生活中越來越重要的一部分，無論是確保道路上汽車的安全、協(xié)助患者護理的設備，還是使物聯(lián)網(wǎng)成為一個更可靠和安全的環(huán)境在其中進行操作。同時，敏捷等方法的速度和靈活性——無論它是否被正式標記——正被各種組織積極使用，以創(chuàng)造競爭優(yōu)勢。在一個敏捷性需要與合規(guī)性共存的世界中，很高興知道這是絕對可能的，只要通過正確的文化、工具和流程來解決，所有這些都以可追溯性為基礎。

審核編輯：郭婷