敏捷方法的好處（尤其是更快的上市時(shí)間）是有據(jù)可查的，但對于汽車、航空航天和醫(yī)療設(shè)備等合規(guī)驅(qū)動(dòng)型市場中的嵌入式軟件團(tuán)隊(duì)來說，過渡到敏捷可能是一個(gè)挑戰(zhàn)。需要可追溯性和文檔來證明合規(guī)性，但這可能與敏捷精神相矛盾，敏捷精神仍然遭受與方法一起成長的不準(zhǔn)確的神話。事實(shí)上，只要采用正確的方法和工具策略，敏捷和合規(guī)性就可以舒適地共存，而不會有太多的妥協(xié)。至關(guān)重要的是可追溯性，在這種情況下，這意味著將需求與運(yùn)行測試和解決問題聯(lián)系起來。借助可靠的可追溯性，您不僅可以提供滿足審計(jì)要求所需的證據(jù)，還可以支持更好的透明度和跨團(tuán)隊(duì)跟蹤，這也有助于協(xié)作。

一個(gè)好的起點(diǎn)是定義我們所說的敏捷開發(fā)，因?yàn)檫@個(gè)術(shù)語雖然眾所周知，但經(jīng)常被誤解。在最簡單的層面上，敏捷是一種松散的方法，基于對客戶需求的關(guān)注、跨職能團(tuán)隊(duì)協(xié)作和對變化的響應(yīng)（而不是嚴(yán)格遵循記錄在案的計(jì)劃和時(shí)間表）。許多開發(fā)方法，包括一些最近的混合方法，都屬于敏捷的保護(hù)傘，包括：Scrum，Kanban，Scrumban，Kanplan和Scaled Agile Framework（SAFe）。

敏捷神話

無論哪種風(fēng)格的敏捷，都存在一些常見的誤解，例如，敏捷缺乏結(jié)構(gòu)或控制，或者需要在質(zhì)量上進(jìn)行權(quán)衡。這兩個(gè)神話都不是真的：結(jié)構(gòu)、控制和質(zhì)量保證都可以內(nèi)置到敏捷流程中。

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

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

溯源

可追溯性有助于回答這個(gè)問題，“如果有什么變化，還有什么會受到影響？重要的是，可追溯性可以根據(jù)向后和前向可追溯性來定義。向后可追溯性是檢查設(shè)計(jì)或構(gòu)建的內(nèi)容是否由上游需求證明是合理的。轉(zhuǎn)發(fā)可追溯性是檢查在后期生命周期階段是否解決了所需的問題。

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

人們需要工具

敏捷從根本上講是關(guān)于人的，但鑒于工具起著重要的支持作用，必須確保可追溯性不會受到工具復(fù)雜性的阻礙。例如，如果需求存儲在 Word 文檔中，問題在 Atlassian 的 Jira 中跟蹤，代碼存儲在 Git 或其他系統(tǒng)（如 SVN 或 Microsoft TFS）中，則跟蹤和跟蹤是分散的，因此風(fēng)險(xiǎn)會增加。同樣，如果這些團(tuán)隊(duì)實(shí)施不同的項(xiàng)目管理方法，每個(gè)方法都有不同的標(biāo)準(zhǔn)、流程或控制，則很難實(shí)現(xiàn)這種可追溯性。

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

過渡到敏捷 – 最佳實(shí)踐

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

其次，敏捷最好從團(tuán)隊(duì)層面開始。通過本地化錯(cuò)誤步驟，組織既可以降低風(fēng)險(xiǎn)，又可以使成功更容易實(shí)現(xiàn)。在團(tuán)隊(duì)級別吸取的經(jīng)驗(yàn)教訓(xùn)可以擴(kuò)展到部門級別，然后（如果適用）在整個(gè)組織范圍內(nèi)應(yīng)用。

第三，參與過渡的團(tuán)隊(duì)必須有明確的流程和共同的命名法。例如，需求是作為用戶故事編寫的，還是將兩者混合使用？估計(jì)值是以天、小時(shí)還是故事點(diǎn)來衡量？角色是否需要重新定義，例如，業(yè)務(wù)分析師是否需要接受Scrum Master的培訓(xùn)？這些問題（以及更多問題）應(yīng)該盡早解決，以便高管、經(jīng)理和團(tuán)隊(duì)說同一種語言，因此能夠在迷失方向的時(shí)候進(jìn)行充分的溝通。

當(dāng)然，還有無數(shù)其他考慮需要做，其中許多是無法計(jì)劃的，所以只能在它們出現(xiàn)時(shí)解決。雖然它已經(jīng)成為陳詞濫調(diào)，但必須理解唯一不變的是變化。

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

審核編輯：郭婷