敏捷和DevOps詞彙表
阿新 • • 發佈:2019-01-02
本詞彙表是旨在說明敏捷與DevOps中各種術語。
由於敏捷與DevOps存在緊密的聯絡,在講述DevOps時需要引用到大量的來自敏捷的詞彙,因此本文試圖做些整理
詞彙名稱 | 對應英文 | 說明 |
---|---|---|
重構 | Refactor | 指保持某個物件的外在行為不變,優化其內部結構。程式碼重構是重構的一種。 |
程式碼重構 | Code refactor | 保持程式程式碼的外在行為不變,優化程式碼。在面向物件程式設計中,典型的是保持類的對外行為不變,優化類的內部結構。 |
測試驅動開發 | Test driven development | 利用測試方法來驅動軟體程式的設計和實現。其方法主要特徵是先寫測試程式,然後再編碼使其通過測試。常見的測試驅動開發可以分為單元測試驅動開發和驗收測試驅動開發 |
單元測試驅動開發 | Unit test driven development | 利用單元測試方法,典型採用xUnit類工具,來驅動程式的設計和實現,其方法主要特徵是先寫單元測試程式,然後再編碼使其通過測試。 |
驗收測試驅動開發 | Acceptance test driven development | 利用驗收測試方法,典型採用自動化介面或介面測試方法,來驅動軟體程式的設計和實現。其方法主要特徵是先寫自動化介面或介面測試,然後再編碼使其通過測試。 |
時間箱 | Time box | 在限定的時間長度內開展活動,以時間為結束標誌。 |
迭代 | Iteration | 重複反饋過程的活動,其目的通常是為了逼近所需的目標或結果。每一次對過程的重複被稱為一次“迭代”,而每一次迭代得到的結果會被用來作為下一次迭代的初始值。 |
敏捷迭代 | Agile Iteration | 指每次按照相同的開發方式短期的開發軟體的部分,或前期開發並不詳盡的軟體,每次開發結束獲得可以執行的軟體,以供各方干係人觀測,獲得反饋,根據反饋適應性的進行後續開發,經過反覆多次開發,逐步增加軟體部分,逐步補充完善軟體,最終開發得到最後的軟體。敏捷迭代包括了迭代和增量。 |
特性驅動開發 | Feature Driven Development | 簡稱FDD,最初由Peter Coad 及其同事作為面向物件軟體工程使用過程模型而構思的,然後在其上擴充套件並增強了Coad的工作,描述了一個可用於中、大型軟體專案的適應性敏捷過程。主要包括開發全域性模型、構造特徵列表、特徵計劃、特徵設計、特徵構建五個協作。 |
回顧會議 | Retrospective Meeting | 這是在Scrum中所要求的會議,也可以在非Scrum的環境下運用。回顧會議旨在對前期中的人、關係、過程和工具等等各方面進行檢驗。檢驗應當確定並重點發展那些進展順利的,和那些如果採用不同方法可以取得更好效果的條目。在回顧會議的最後,團隊應該選擇將要在下個迭代中要採取的改進。 |
燃盡圖 | Burn Down Chart | 用圖形化的方式來表述隨著時間的推移,對需要完成的工作的一種視覺化表示。燃盡圖有一個Y軸表示待完成的工作,常見的是待完成的故事點數、待完成的工時、待完成的使用者故事數量,X軸表示時間,一般的,刻度是工作日。理想情況下,該圖表是一個向下的曲線,隨著剩餘工作的完成,“燒盡”至零。 |
計劃會議 | planning meeting | 這是在Scrum中所要求的會議。計劃會議旨在對馬上進行的迭代進行估算, 澄清並選擇待開發項,識別後續行動。 |
使用者故事 | User Story | 從使用者的角度出發去描述一個待開發產品的各種外在行為。所有使用者故事的集合體現了產品對使用者的價值(或商業價值)。 |
速度 | velocity | 表示開發的快慢,常見有兩種演算法:1)迭代完成的故事點數;2)每人天完成的故事點數 |
敏捷思維 | Agile Thinking | 與敏捷精神、敏捷理念、敏捷價值觀等詞彙接近,目前沒有客觀嚴格的定義,一般理解為源自於敏捷宣言的理念,包括了注重團隊協作、尊重個體、擁抱變化、快速響應、注重溝通、注重價值交付、增量交付可用軟體等。 |
敏捷方法框架 | Agile method framework | 是指一種系統的闡述了軟體開發核心領域並給出了面向全域性框架的方法論,其由多個敏捷開發實踐根據此框架有機的組合而成。比如Scrum、XP、FDD、DSDM。 |
敏捷實踐 | Agile practice | 是指一種符合敏捷宣言的解決特定的、區域性的問題的開發方法。比如單元測試驅動開發、燃盡圖、使用者故事等等。 |
敏捷管理實踐 | Agile management practice | 指敏捷開發實踐中處理人員互動、資訊交流的實踐,比如計劃會議、回顧會議、燃盡圖。 |
敏捷工程實踐 | Agile engineering practice | 與敏捷技術實踐是同義詞,指敏捷開發實踐中與程式碼實現、測試、設計、需求分析等密切相關的實踐,比如重構,測試驅動開發,演進設計,持續整合,自動化測試等等。 |
敏捷技術實踐 | Agile technical practice | 與敏捷工程實踐是同義詞,指敏捷開發實踐中與程式碼實現、測試、設計、需求分析等密切相關的實踐,比如重構,測試驅動開發,演進設計,持續整合,自動化測試等等。 |
自組織 | self-organizing | 在自然科學領域,自組織(self-organization)是指混沌系統在隨機識別時形成耗散結構的過程。 在軟體工程領域,從字面意思上,可以理解為指向著已自組織(英文是self-organized)前進,其基本特徵是每個個體都有自主性,又能整合出整體的特徵。 |
增量 | Incremental | 是指在以前的迭代的基礎上增加的可用功能。 |
每日構建 | Daily build | 每日自動進行編譯,然後執行自動化測試對構建進行驗證,並給出報告。 |
持續整合 | Continuous Integration | 指當代碼提交後,馬上啟動自動編譯、自動化測試來快速驗證軟體,從而儘早地發現錯誤和程式碼衝突。 |
持續交付 | Continuous delivery | 指當代碼提交後,能夠快速並自動的啟動編譯、打包、安裝到執行環境,中間過程可以安排各類自動測試,從而保證交付質量。一般的,持續交付包括持續整合 |
持續部署 | Continuous Deployment | 持續的自動的部署到生產環境,一般理解,持續部署是持續交付的一種形式 |
每日站立會議 | Daily standup meeting | 在Scrum方法中,每個衝刺的每一天,都會舉行的一種專案狀況會議。會議準時開始,時長不超過15分鐘,所有成員都需要站立。每位成員回答3個問題。1、今天你做了什麼?2、明天你計劃做什麼?3、有什麼問題阻礙了你? |
產品待辦列表 | product backlog | 是指產品需求的列表(Backlog的條目可以是使用者故事)。產品負責人根據商業價值對列表的條目進行排序,團隊按照順序進行開發。 |
史詩 | epic | 通俗來說就是大型使用者故事。一般由許多較大的、不確定的需求組成,本身具有更低的優先順序。因此,不能直接通過它進行迭代規劃,而是要先把它劃分成較小的、真正的使用者故事。 |
應用部署 | Application Deployment | 部署編譯後結果到執行環境 |
製品管理 | Artifact Management | 編譯後製品的管理,一般相同原始碼的編譯後製品儘量只生成一次 |
完成的定義 | Definition of Done | 與退出條件、成功標準類同 |
資訊科技服務管理 | ITSM (Information Technology Service Management) | 主要覆蓋了軟體上線後的運維,最近其範圍有向軟體開發升級方面的延伸。ITIL是ITSM的一種實施 |
質量檢查 | JKK Ji-Kotei-Kanketsu | 來自日文,有逐級逐段嚴格檢查的意思,確保質量,JKK的概念是一種完美狀態:在你所處在的工作流程中不要做低質量的工作,不接受流程早期就出現錯誤的輸出,不把糟糕的情形輸出到下一個流程。 |
服務級別協議 | Service Level Agreement-SLA | 根據不同的級別制定不同的服務協議,常見的協議要素有時間要求,比如在多少小時內解決 |
單件流 | One-piece-flow | 一種為了實現適時適量生產,致力於生產同步化的最小批量生產方式,如再加上看板的運用,就徹底地實行了JIT了。來自生產企業的定義:指的是通過合理的制訂標準生產流程並安排好每個工序的人員量、裝置量,使每個工序耗時趨於一致,以達到縮短生產週期、提高產品質量、減少轉運消耗的一種高效管理模式 |
在製品 | Work-in-Progress WIP | 包括正在加工的產品和準備進一步加工的半成品 |