“方法”這個詞很常用，但并不簡單。大部分會出現一種現象，做了一些事情，解決了很多問題，但是當別人問自己是采用什么方法來指導自己工作時并 不能清楚的說出來。大部分工作是被事情推著走，而并沒有在“方法”的指導下有序的進行工作。從精益開發角度來看，缺少”方法“，摸著石頭過河，這勢必造成 很多浪費，所以我比較關注如何總結出適用的方法來支持團隊的工作。我在網上搜了很多地方，還沒有看到有哪里或者哪本書系統的講解了IT方法論的知識，如果 有的話希望大家多推薦一下。本篇我將結合敏捷來來談談IT方法論。
方法定義
在需求過程中對新事物溝通時很重要的一個就是對術語的解釋，這樣大家知道談論的不會有偏差。所以我們首先需要清晰的定義什么是方法。在《 軟件工廠應用 》一文開頭指出，方法論是基于大量實踐的高度抽象之上，加上理論的加工后才形成的一套體系。這個說法有點太抽象，所以我準備再借用一篇論文《 Method Engineering: Engineering of Information Systems Development Methods and Tools 》里的概念來說明。原文如下：
consistingof directionsandrules , structured inasystematicwayindevelopmentactivitieswith
correspondingdevelopmentproducts.
我還是很認可這個定義，因為它定義得比較豐富，指出來方法應該包含哪些主要內容，我從中用黑體字標識出了我認為重要的部分。它指出方法（method）是一個基于理論（way of thinking），包含一套指南和規則的 approach (針對某一問題的解決處理方法），并且這個方法結構化為一套系統化的開發活動。
方法框架
Aydin從通用方法工程理論出發提出了一套通用框架，這個框架包括三個元素： a philosophy, a framework and supporting tools and techniques. Aydin的論文我以前找過，但沒有找到，只能從《A method for Requirements Management and modeling》 的一些介紹來理解了。如果有人找到了希望共享一下：）
價值觀（ philosophy ）部分包含所有基本的原則、假定和約束，這些部分關注需求方法，定義范圍并且決定了方法的組成。框架（ framework ）包含一些模板、規則和樣式來展現案和歸類不同的方法元素（例如產品、交付物和流程步驟）。工具和技術（ The tools and techniques ）支持特定方法步驟來實現最終產品。
Aydin方法框架在初始階段能夠用來結構化方法，但是由于還是比較抽象，所以仍舊比較難以實施。所以有其他方法研究者提出另一套框架，這個框 架用來開發（developing）、理解（understanding）和結構化模型方法（structuring modeling methods）。這些研究提出了六種思路（six way）： the way of thinking, the way of working, the way of modelling, the way of supporting, the way of communicating and the way of controlling.
The way of thinking
思考方法是一些范式、基本觀點或者價值觀，它能夠回答“為什么”的問題。Scrum是敏捷方法中的一種實踐框架，所以敏捷宣言的價值觀也是它的價值 觀。《Scrum敏捷項目管理》前言二最后指出，Scrum的運作原理桶豐田公司持續成功的原因一樣，包括三個方面：企業哲學基礎、管理文化和技術工具。 其哲學基礎是授權于項目開發團隊，以及滿足客戶需求。 軟 件開發是一種腦力投入，如果不能保證開發人員的自愿投入，產品則肯定會打折扣，有研究證明一個愿意投入的開發人員和一個不愿意投入的開發人員效率相差在三 倍以上，對組織的貢獻更是在十倍以上。在團隊從里到外深刻理解集體負責和自組織后，Scrum方能有效運作。團隊成員只有實現集體負責，承諾在固定時間內 交付實際產品后，才能算真正掌握了Scrum。 其管理文化植根于“幫助他人完成目標”這一理念。 敏捷方法尊重人性，強調效率。敏捷方法強調面對面的溝通，通過現場客戶、站立會議、結對編程等方式來保證溝通的有效。 其主要技術工具是通過學習過程作出基于適時的決 策 。 溝通和反饋是一切的基礎，即時的反饋是擁抱變化的前提條件。
The way of working
工作方法描述了如何應用方法，它包含一些在開發過程中可能采用的一些任務，包括任務的分解和排序，以及對任務的執行和決策的制定提出正式的指導和建議。
Scrum 本身并不是方法論，它只是一個框架，它 只定義了高層次的管理流程，如下圖所示。它并不涉及具體開發方法或者人員的有效溝通技巧等。這些沒有涉及的領域需要桶其他理論和技能互為補充，以確保項目的成功。
Scrum的核心在于迭代，整個過程只有三個角色。產品負責人的職責是利用產品backlog，督促團隊優先開發具有價值的功能，并在其基礎上繼續 開發。產品負責人必須頻繁檢視產品代開發需求的優先級，以便將最具價值的功能安排在下一個迭代中完成。團隊的責任是開發軟件功能，他們是自組織團隊，團隊 所有成員對每一次迭代和整個項目共同負責，不單做考核。Scrum Master則需要對Scrum過程負責，向所有項目參與者講授Scrum方法，負責實施Scrum，確保它既符合企業文化，又能交付預期利益，還需督促 全體成員遵從Scrum規則和實踐。
啟動Scrum項目所需的最簡約計劃包括：一份愿景及產品Backlog。愿景描述項目開發原因和預期目標。愿景可能描述商業運作方式將發生哪些改變，主 要特性和功能如何為客戶創造收益，以及對市場的預期影響。產品backlog將定義交付愿景時，系統應滿足的功能性和非功能性需求，它需事先劃分優先級并經過初始預估（預估的目的是了解每個需求自身及相對與其他需求的規模）。
在Sprint第一天召開sprint計劃會議，這個會議分為兩部分，計劃會議1由PO、SM和Team參加，主要是從產品backlog中挑 選出需要放 到當前sprint下的既定產品backlog，然后由SM、Team參加計劃會議2，把既定產品backlog的故事拆分成任務進行估算，PO也可以一 起參加這個部分來了解具體的開發細節。sprint周期在spirnt計劃會議2正式開始。開發過程中，團隊每天召開每日站會（Daily Scrum），溝通團隊成員間工作進度和進行任務協調。Sprint周期結束時，需要召開Sprint評審會議，由團隊向產品負責人和其他利益相關者展示 當前sprint周期內的產品開發情況。產品負責人根據團隊這次 Sprint 所發布的版本，評審相關的 Backlog 中的問題，檢查是否已達到 Sprint 的目標。評審會議結束后會進行回顧會議，通過總結以往的實踐經驗來提高團隊生產力。
The way of controlling
控制方法解決項目開發的管理方面的問題，提供一種機制來管理工作方法（way of working），它包含計劃和計劃評估。基于檢查點和基線，計劃和計劃評估被劃分為多個階段。控制方法和模型方法和工作方法互相聯系，不能單獨來看每個方法。
軟件開發對于管理存在兩個極端：一個是沒有任何的管理成本，所有的工作都是為了軟件的產出，這種方式往往導致軟件開發過程的混亂，產品質量低，士氣 也很低落。另一個是大量管理活動的加入，評審、變更管理，缺陷跟蹤，雖然管理活動的加入能夠在一定程度上提高開發過程的有序性，但是成本卻因此提高，更糟 糕的是，很容易導致團隊的低效率，降低創新能力。因此，敏捷方法視圖尋找一個平衡點，用低成本的管理活動帶來最大的產出，即軟件的高質量。系統越復雜，集權管理導致失敗的可能性越大，Scrum應用
自組織
、自管理原則
，授權于項目開發團隊 ，通過頻繁運用“
檢查－調整
“周期加速創造更具價值的軟件，它帶來較低的管理成本和高質量的產出。
《過程動態學，建模及控制》指出，“在過程運行根本機制相當簡單易懂的情況下，典型做法是采用預定義的（理論的）建模方式。若過程復雜程度超出預定義方式的能力范圍，便應選用經驗性方式。”Scrum承認軟件開發的復雜性（需求、技術和人），實施經驗性方式。 實施經驗性過程控制方法時，有3大支柱：可見性、檢查及適應 。 可見性 是 指對過程控制者來說，過程中對最后結果有影響的方面必須清晰可見，而且必須真實可信，例如Scrum中對于完成的定義必須團隊都有清晰的認識。過程中的各 個方面必須頻繁檢查，例如進行代碼評審等。適用就是經過檢查后，調整工作需要盡快展開，以減少進一步的偏差。Scrum會進行每日站會，溝通每日進展情況 以作調整，每個sprint后還會進行回顧會議，以便反饋到下一個sprint中。
Scrum方法中沒有傳統意義上的項目經理，取而代之的是Scrum Master，他承擔領導、指導和教練工作。軟件開發工作的性質決定了會有大量復雜問題的出現，Scrum Master無權直接命令開發團隊，他有責任講授怎樣使用Scrum來處理項目中遇到的每個新的復雜問題，解決這些問題離不開努力工作、智慧和勇氣。
Scrum的運作基礎是個人和團隊的承諾，而非嚴密的規劃及控制。但自組織團隊不是無管理團隊，它必須制定計劃并有針對性的進行報告，才能管理自身工作。sprint backlog是團隊履行職責的可視表現。
Development: Empirical or Planned?
The way of modeling
模型方法定義了一些模型語言，使用符號，結合文檔進行分析，并可以可視化的來描述架構需求。
Scrum中可以有一些基本概念，如backlog、Story、Task，Story有優先級、Task有估算時間等，這些在開發過程中都需要使用一種方式表達出來，以下為別人使用Excel對產品backlog和sprint backlog進行描述的兩個示例：
Simple Product Backlog Example
The way of supporting
支持方法尋找有用的工具、培訓、文檔來協助支持信息系統的開發。
“項目快速啟動”方案是為期兩天的培訓，確保缺少Scrum經驗的新團隊能啟動項目。
以下為別人對Scrum工具的描述：
The way of communicating
溝通方法描述了對開發過程中的各個環節、工作成果等如何進行溝通，也包含在模型方法中定義的抽象概念如何通過文本或者圖形符號來表達清楚。
Scrum通過任務看板來查看任務，通過燃燒圖來查看項目進展情況。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
