例項化需求的概念和流程

2021-09-30 21:45:55 字數 2098 閱讀 5718

最近一段時間在關注一種新的敏捷模式,當然這裡說新,是由於目前很少看到有專案在應用,其實這種模式很早就已經誕生了。乙個偶爾的機會,在苦尋敏捷測試的 過程中,無意中看一本書,關於如何提高敏捷過程中需求、開發和驗收的測試效率,讓我很是感興趣,這本書名《例項化需求:團隊如何交付正確的軟體》。可能是 由於翻譯的原因,讀起來給我的幫助並不是那麼大,但至少先讓初步了解他的思想,我想這就是最大的幫助了,因為我確實接受了他。

關於如何處理需求說明與測試,不同的組織使用不同的名稱,或者說是不同的定義,但他們都有一套共同的核心原則與思想,而且當你接受他了之後,我們便可以認為他們本質上是一致的。通常有如下定義:

● 敏捷驗收測試

● 驗收測試驅動開發

● 例項驅動開發

● user story測試

● bdd行為驅動開發

● 例項化需求說明(specification by example)

對於以上的概念,我想大家都不陌生,但可能都是乙個概念,因為沒有實踐。當具體去實踐,其實就發現跟我們平時的流程相對也很容易理解,只是方式不一樣, 或者執行流程不一樣,當然這裡要說的就是不同,那就是方法。方法都是總結出來,多實踐之後,提煉出來的就是適合我們的方法。就如同我們在實施了一段時間之 後,突然有一天有人問我什麼是bdd(行為驅動開發),我發現我很疑惑,我不理解。但細想,我現在做的流程不就是bdd嗎,而我現在做的流程準確來說被定 義為例項化需求,但這個概念似乎不能把開發和測試給拉進來,而用bdd來定義,似乎就一瞬間把需求、設計、開發和測試拉繫結在了一起。

何為bdd?其實就是通過真實使用者的行為來定義我們需要開發出什麼樣的產品來,個人理解。但再結合例項化需求,就會發現,我們就是把使用者的行為通過乙個實 例化的過程描述出來,然後整理成設計、開發和測試都能看懂的,當然最重要的是使用者也能看懂,而且使用者看完之後就認可,這就是我想要的,這就是bdd,也就 是例項化需求過程。

它既不是傳統的需求文件,也不是設計文件,更不是測試用例文件,但適用於從需求、設計、開發和測試的每乙個階段,而且都是從使用者的角度為出發點的。那我就認為那就是我們想要的過程模式。

以下為例項化需求說明的主要過程模式:

當我們獲取乙個業務目標時,將按照上述流程圖來生產例項化需求過程

● 從目標中獲取範圍

通過使用者提供的需求描述,我們將這些描述轉變成另一種使用者能夠理解且真實使用者實際地行為方式,這裡就要引入user story使用者故事的概念。然後以客戶的業務目標為起始,然後通過協作界定可以實現目標的範圍。這裡最關鍵的就是與使用者更密切地溝通,通過不斷細化,確認 這才是使用者想要的功能。

● 從協作中制定需求說明

之所以要提出協作制定需求說明,目的是讓需求、設計、開發以及測試都參與進來,發揮整個team的知識和經驗,力求讓專案的干係人都更多的參與到交付過程中。

● 舉例說明

舉例說明其實是專案需求交流過程中不可或缺的,團隊中不同職能人都有,而且每個人的業務背景不同,通過舉例說明的方式可以讓目標更一致。

● 提煉需求說明

協作過程中的開發討論可以建立大家對相關領域的共識,但最終得到的例項往往包含很多不必要的細節。而關鍵例項必須是精簡的。提煉需求說明的過程,其實就伴隨著例項化需求的產生,且這些提煉好的例項就可以當作交付的驗收條件。

● 頻繁驗證

頻繁驗證的依據就是提煉需求產生的例項化需求,它是所有過程實施中都必須要反覆進行的工作。需求通過頻繁驗證與使用者進行頻繁確認;設計通過例項 化需求來頻繁驗證設計是否滿足使用者的需求;開發通過例項化需求頻繁驗證**中業務邏輯;測試通過例項化需求來頻繁驗證交付的功能,並作為最後驗收測試的依 據。

● 演化出乙個文件系統

通過以上的這些流程,最後演化出乙個文件系統。之所以稱為文件系統,主要是體現它的可靠性、權威性。所有設計、開發、變更以及測試過程都以此為出發點來考慮,並及時更新,長久維護。

例項化需求過程的核心就是與使用者站在一起,從溝通開始,不斷舉例、細化、精簡到統一確認。

***********************************=分割線******************************==

例項化需求 概念

最近一段時間在關注一種新的敏捷模式,當然這裡說新,是由於目前很少看到有專案在應用,其實這種模式很早就已經誕生了。乙個偶爾的機會,在苦尋敏捷測試的過程中,無意中看一本書,關於如何提高敏捷過程中需求 開發和驗收的測試效率,讓我很是感興趣,這本書名 例項化需求 團隊如何交付正確的軟體 可能是由於翻譯的原因...

敏捷開發每日一貼 需求管理和例項化需求

需求管理和例項化需求 軟體開發的最大問題之一往往是需求,而且它也很容易的被作為替罪羊。在公司專案延遲和出大問題的最大藉口,就是 需求不清楚 需求變更 那把需求早點弄清楚不就行了嘛?聽著挺容易,但要做好它卻很困難。敏捷迭代起來以後是否會好點呢?理論上會好點,因為需求在乙個迭代中東西會少點,更容易理清楚...

物件導向例項化流程分析

class myclass object def new cls print new return super myclass,cls new cls def init self print init def call self print call if name main obj myclass...