本詞彙表是旨在說明敏捷與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 | 包括正在加工的產品和準備進一步加工的半成品 |