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

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

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

敏捷神話

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

另一個(gè)錯(cuò)誤的看法是敏捷不適用于受監(jiān)管的行業(yè)。然而，Perforce 自己在 2018 年對(duì)醫(yī)療設(shè)備開發(fā)市場（無疑是最受監(jiān)管的市場之一）進(jìn)行的調(diào)查發(fā)現(xiàn)，到那時(shí)，超過三分之一的受訪者已經(jīng)轉(zhuǎn)向敏捷。有趣的是，我們?cè)絹碓蕉嗟貜奶幱趪?yán)格監(jiān)管環(huán)境中的公司那里聽到，他們已經(jīng)——或即將——擁抱敏捷。

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

可追溯性

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

這是一個(gè)例子。在敏捷開發(fā)中，尤其是 Scrum 中，工作項(xiàng)被分解成更小的部分，并在固定的時(shí)間范圍內(nèi)完成，稱為 sprint 或迭代。這意味著管理人員必須確保每個(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é)制。有了這個(gè)結(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)化。

人們需要工具

敏捷從根本上講是關(guān)于人的，但鑒于工具發(fā)揮著重要的支持作用，因此必須確?？勺匪菪圆皇芄ぞ邚?fù)雜性的阻礙。例如，如果需求存儲(chǔ)在 Word 文檔中，問題在 Atlassian 的 Jira 中進(jìn)行跟蹤，代碼存儲(chǔ)在 Git 或 SVN 或 Microsoft TFS 等其他系統(tǒng)中，跟蹤和跟蹤是碎片化的，因此風(fēng)險(xiǎn)增加。同樣，如果這些團(tuán)隊(duì)正在實(shí)施不同的項(xiàng)目管理方法，每個(gè)方法都有不同的標(biāo)準(zhǔn)、流程或控制，那么這種可追溯性可能難以實(shí)現(xiàn)。

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

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

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

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

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

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

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

審核編輯：郭婷