做管理型軟件產品一般都要經歷架構階段，而架構又可以簡單分為業(yè)務架構和技術架構，對于架構方法，在我以前的blog中大量的介紹了TOGAF。
使用TOGAF的幾個初衷
在我們開發(fā)軟件時，如果你做過設計和架構工作，那么你會發(fā)現(xiàn)軟件開發(fā)過程中其實存在很多斷溝。
-
業(yè)務架構到技術架構的不一致
- 業(yè)務架構是一撥人做，技術架構師另一撥人做，結果做業(yè)務架構時缺少技術架構的考慮，而技術架構缺少服務于業(yè)務的意識，最終沒有為業(yè)務服務。弄到最后業(yè)務架構和技術架構并不能很好的結合起來，導致還需要很多適配或反復工作。
- 還有一種情況是，業(yè)務架構做完之后扔給技術架構來實現(xiàn)，但是業(yè)務架構提供的東西并不全面，不能提供技術架構的輸入，導致溝通效率極其低下。
-
業(yè)務架構到業(yè)務需求的不一致
- 有些公司雖然崗位分的清楚，但是方法并不清楚。業(yè)務架構是一套方法，需求分析是一套方法，甚至于沒有方法，而是靠著個人能力去做，結果導致架構和需求交付物是獨立的，業(yè)務架構的東西不能順利轉移到需求階段
- 還有時候一個人就負責產品的業(yè)務，架構和需求一起做，這時候沒有方法的指導，其實很容易迷失在業(yè)務細節(jié)。 過早的進入業(yè)務細節(jié)對于產品來說是及其危害的，因為產品架構還未明晰時進入細節(jié)只會浪費時間導致重心偏離方向。
-
業(yè)務架構和實現(xiàn)的不一致
- 業(yè)務架構采用的是業(yè)務語言，而技術實現(xiàn)采用的技術語言，兩者不是同一個語言，很難做到順利過渡，還需要再一次翻譯，有時候甚至在實現(xiàn)階段根本不看業(yè)務架構出來的東西
- 很少有開發(fā)人員清楚產品的業(yè)務架構，那么如何能夠做出好的產品來？
- 開發(fā)產品時，開發(fā)問一句，"做這個對系統(tǒng)有什么價值？"結果發(fā)現(xiàn)需求根本無法追溯回系統(tǒng)的價值點上，有時連需求人員都不知道為什么做了這個功能。如果產品生命周期較長，中間換了好幾撥人來做這個產品了，那么不僅是需求文檔不能追溯，就是靠口頭講也講不清。
從上面可以看書，現(xiàn)實中產品開發(fā)存在的隱性問題其實還是蠻多并且很嚴重的，我也都經歷過。而解決這些問題就必須做到一下幾點：
- 找到一個指導業(yè)務架構的方法和框架
- 結構化架構交付物才有可能把架構知識轉移到開發(fā)環(huán)節(jié)
- 必須有一個業(yè)務開發(fā)平臺來集成業(yè)務架構、技術架構和開發(fā)框架
業(yè)務架構和業(yè)務需求
TOGAF并沒有太多內容來描述如何做業(yè)務需求，但是這是我們必須要做的事情。從上面的闡述能夠發(fā)現(xiàn)，我是希望業(yè)務架構和業(yè)務需求能夠有一種方法進行銜接的。其實業(yè)務架構和業(yè)務需求本身就不沖突，兩者只是處在一個事物在不同層次的東西。架構關注的是更全面、概括、組織方面的東西，而需求關注的是用戶關心的業(yè)務細節(jié)，業(yè)務需求是業(yè)務架構的進一步分析。
在研發(fā)峰會上我講過一次使用TOGAF來做業(yè)務架構，下面是裁剪后的輕型迭代流程和交付物。其中的設計開發(fā)步驟中有Backlog，這個就是從業(yè)務架構和業(yè)務需求的產物。
在我寫的敏捷方法之Scrum.pdf電子書中提到產品backlog是在項目開始的時候，由Product Owner準備的一個根據(jù)商業(yè)價值排好序的客戶需求列表。而在我們工作中，這個產品backlog如果要做到承上啟下的作用，考慮到它來自于業(yè)務架構，而又服務于產品開發(fā)，所以我們會定義一些格式，例如考慮功能的抽象、721的分析以及與開發(fā)框架匹配的文檔組織格式等。
以下的文檔是根據(jù)我所做業(yè)務以及實現(xiàn)框架而做的格式，你可能需要根據(jù)你們自己的情況來制定屬于自己的backlog格式。
制定Backlog的考慮點
- 由于流程可以動態(tài)變化，以靜態(tài)的功能分解和信息結構作為backlog的主要輸入
- 考慮軟件產品線工程，進入開發(fā)前，設計產品的721
- 結合業(yè)務框架的模型抽取來編寫業(yè)務實體以及功能
- 盡量結構化文檔，不采用純文字描述，逐步抽取出具有確定含義的文字
- 術語和規(guī)則作為sprint文檔之外的重要文檔
產品業(yè)務模塊backlog
以下是實際工作中的一個示例：
- 按照子系統(tǒng)、業(yè)務模塊來組織產品backlog
- 每個子系統(tǒng)和模塊都附上唯一的編號，文檔中任何地方都可以引用
- 輸入、輸出表達模塊之間的關系，這個從業(yè)務架構的流程、功能分解中輸入
- 執(zhí)行者和目的對應業(yè)務架構的角色和價值點
- 范圍、工具和技術屬于業(yè)務需求內容
- 7/2/1是根據(jù)業(yè)務、市場來劃分此模塊是通用功能、可變功能還是定制功能
產品模塊功能backlog
產品業(yè)務模塊backlog大部分內容除了7/2/1之外，大部分內容只是業(yè)務架構的另一種表現(xiàn)形式而已。到了需求階段，必須對產品業(yè)務模塊backlog進行細化工作，那就是產品模塊功能backlog：
- 按照業(yè)務模塊、功能點來組織模塊功能backlog
- 抽取公共業(yè)務功能、通用業(yè)務規(guī)則，例如列表模板、通用編輯方式、通用業(yè)務功能，這些通用規(guī)則和說明形成單獨文檔，作為技術架構的輸入
- 業(yè)務規(guī)則列鏈接具體的業(yè)務規(guī)則說，業(yè)務規(guī)則的寫法根據(jù)遇到的規(guī)則類型定義自己的結構化格式
- 功能點仍舊也要做721設計
- 對于非通用性的業(yè)務功能需要描述具體任務操作步驟以及價值點
- 加入關注的非功能性需求，我們現(xiàn)在只加入了效率
- 大多數(shù)情況下，這個文檔的模塊能夠對應到開發(fā)中的實體，功能點能夠對應到界面上的一個按鈕或右鍵等，這樣有利于以后轉向模型驅動平臺下使用設計器來進行產品開發(fā)
術語表
如果術語很多，可以進行分組編號
規(guī)則表
業(yè)務規(guī)則對系統(tǒng)來說是核心內容，這部分內容必須仔細查看。規(guī)則分析得是否正確、完整是系統(tǒng)實現(xiàn)的前提，每個業(yè)務需求通過抽取應該能夠形成一些通性規(guī)則，對于通行規(guī)則可以作為技術框架的輸入，由框架統(tǒng)一實現(xiàn)
一些問題
- 業(yè)務架構需要做到什么粒度？
架構是產品的上層框架，只需要到具體功能模塊以及主要業(yè)務功能就行，具體的業(yè)務規(guī)則和異常處理都不需要考慮，那是需求分析的事情
- 業(yè)務架構是否需要做原型？
需要，只是會很粗，并且不在意具體的UE，但是需求階段的原型應該可以從業(yè)務架構階段的原型中細化下來
- 有沒有統(tǒng)一的規(guī)則表模板？
不同業(yè)務的規(guī)則是不一樣，不同小組的設計能力也是不一樣，不同平臺支持的規(guī)則DSL也是不一樣的，這個需要根據(jù)自己的情況來定義自己的格式，但必須能夠把規(guī)則描述清楚，做到自己、開發(fā)人員和測試人員都能一看就明白
- 需求階段需要出以前的詳細需求規(guī)格說明書嗎？
對于內部來說不需要。但是必須要有原型，還有我上面說的幾個文檔，記住一定要保證同步。
