“方法”這個(gè)詞很常用，但并不簡(jiǎn)單。大部分會(huì)出現(xiàn)一種現(xiàn)象，做了一些事情，解決了很多問(wèn)題，但是當(dāng)別人問(wèn)自己是采用什么方法來(lái)指導(dǎo)自己工作時(shí)并 不能清楚的說(shuō)出來(lái)。大部分工作是被事情推著走，而并沒(méi)有在“方法”的指導(dǎo)下有序的進(jìn)行工作。從精益開(kāi)發(fā)角度來(lái)看，缺少”方法“，摸著石頭過(guò)河，這勢(shì)必造成 很多浪費(fèi)，所以我比較關(guān)注如何總結(jié)出適用的方法來(lái)支持團(tuán)隊(duì)的工作。我在網(wǎng)上搜了很多地方，還沒(méi)有看到有哪里或者哪本書(shū)系統(tǒng)的講解了IT方法論的知識(shí)，如果 有的話希望大家多推薦一下。本篇我將結(jié)合敏捷來(lái)來(lái)談?wù)処T方法論。

方法定義

　　在需求過(guò)程中對(duì)新事物溝通時(shí)很重要的一個(gè)就是對(duì)術(shù)語(yǔ)的解釋，這樣大家知道談?wù)摰牟粫?huì)有偏差。所以我們首先需要清晰的定義什么是方法。在《 軟件工廠應(yīng)用 》一文開(kāi)頭指出，方法論是基于大量實(shí)踐的高度抽象之上，加上理論的加工后才形成的一套體系。這個(gè)說(shuō)法有點(diǎn)太抽象，所以我準(zhǔn)備再借用一篇論文《 Method Engineering: Engineering of Information Systems Development Methods and Tools 》里的概念來(lái)說(shuō)明。原文如下：

　　我還是很認(rèn)可這個(gè)定義，因?yàn)樗x得比較豐富，指出來(lái)方法應(yīng)該包含哪些主要內(nèi)容，我從中用黑體字標(biāo)識(shí)出了我認(rèn)為重要的部分。它指出方法（method）是一個(gè)基于理論（way of thinking），包含一套指南和規(guī)則的 approach (針對(duì)某一問(wèn)題的解決處理方法），并且這個(gè)方法結(jié)構(gòu)化為一套系統(tǒng)化的開(kāi)發(fā)活動(dòng)。

方法框架

　　Aydin從通用方法工程理論出發(fā)提出了一套通用框架，這個(gè)框架包括三個(gè)元素： a philosophy, a framework and supporting tools and techniques. Aydin的論文我以前找過(guò)，但沒(méi)有找到，只能從《A method for Requirements Management and modeling》 的一些介紹來(lái)理解了。如果有人找到了希望共享一下：）

　　價(jià)值觀（ philosophy ）部分包含所有基本的原則、假定和約束，這些部分關(guān)注需求方法，定義范圍并且決定了方法的組成?？蚣埽? framework ）包含一些模板、規(guī)則和樣式來(lái)展現(xiàn)案和歸類(lèi)不同的方法元素（例如產(chǎn)品、交付物和流程步驟）。工具和技術(shù)（ The tools and techniques ）支持特定方法步驟來(lái)實(shí)現(xiàn)最終產(chǎn)品。

　　Aydin方法框架在初始階段能夠用來(lái)結(jié)構(gòu)化方法，但是由于還是比較抽象，所以仍舊比較難以實(shí)施。所以有其他方法研究者提出另一套框架，這個(gè)框 架用來(lái)開(kāi)發(fā)（developing）、理解（understanding）和結(jié)構(gòu)化模型方法（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

　　思考方法是一些范式、基本觀點(diǎn)或者價(jià)值觀，它能夠回答“為什么”的問(wèn)題。Scrum是敏捷方法中的一種實(shí)踐框架，所以敏捷宣言的價(jià)值觀也是它的價(jià)值 觀?！禨crum敏捷項(xiàng)目管理》前言二最后指出，Scrum的運(yùn)作原理桶豐田公司持續(xù)成功的原因一樣，包括三個(gè)方面：企業(yè)哲學(xué)基礎(chǔ)、管理文化和技術(shù)工具。 其哲學(xué)基礎(chǔ)是授權(quán)于項(xiàng)目開(kāi)發(fā)團(tuán)隊(duì)，以及滿足客戶需求。 軟 件開(kāi)發(fā)是一種腦力投入，如果不能保證開(kāi)發(fā)人員的自愿投入，產(chǎn)品則肯定會(huì)打折扣，有研究證明一個(gè)愿意投入的開(kāi)發(fā)人員和一個(gè)不愿意投入的開(kāi)發(fā)人員效率相差在三 倍以上，對(duì)組織的貢獻(xiàn)更是在十倍以上。在團(tuán)隊(duì)從里到外深刻理解集體負(fù)責(zé)和自組織后，Scrum方能有效運(yùn)作。團(tuán)隊(duì)成員只有實(shí)現(xiàn)集體負(fù)責(zé)，承諾在固定時(shí)間內(nèi) 交付實(shí)際產(chǎn)品后，才能算真正掌握了Scrum。 其管理文化植根于“幫助他人完成目標(biāo)”這一理念。 敏捷方法尊重人性，強(qiáng)調(diào)效率。敏捷方法強(qiáng)調(diào)面對(duì)面的溝通，通過(guò)現(xiàn)場(chǎng)客戶、站立會(huì)議、結(jié)對(duì)編程等方式來(lái)保證溝通的有效。 其主要技術(shù)工具是通過(guò)學(xué)習(xí)過(guò)程作出基于適時(shí)的決 策 。 溝通和反饋是一切的基礎(chǔ)，即時(shí)的反饋是擁抱變化的前提條件。

The Philosophy of Scrum

敏捷開(kāi)發(fā)之 4句敏捷宣言

The way of working

　　工作方法描述了如何應(yīng)用方法，它包含一些在開(kāi)發(fā)過(guò)程中可能采用的一些任務(wù)，包括任務(wù)的分解和排序，以及對(duì)任務(wù)的執(zhí)行和決策的制定提出正式的指導(dǎo)和建議。

Scrum 本身并不是方法論，它只是一個(gè)框架，它 只定義了高層次的管理流程，如下圖所示。它并不涉及具體開(kāi)發(fā)方法或者人員的有效溝通技巧等。這些沒(méi)有涉及的領(lǐng)域需要桶其他理論和技能互為補(bǔ)充，以確保項(xiàng)目的成功。

　　Scrum的核心在于迭代，整個(gè)過(guò)程只有三個(gè)角色。產(chǎn)品負(fù)責(zé)人的職責(zé)是利用產(chǎn)品backlog，督促團(tuán)隊(duì)優(yōu)先開(kāi)發(fā)具有價(jià)值的功能，并在其基礎(chǔ)上繼續(xù) 開(kāi)發(fā)。產(chǎn)品負(fù)責(zé)人必須頻繁檢視產(chǎn)品代開(kāi)發(fā)需求的優(yōu)先級(jí)，以便將最具價(jià)值的功能安排在下一個(gè)迭代中完成。團(tuán)隊(duì)的責(zé)任是開(kāi)發(fā)軟件功能，他們是自組織團(tuán)隊(duì)，團(tuán)隊(duì) 所有成員對(duì)每一次迭代和整個(gè)項(xiàng)目共同負(fù)責(zé)，不單做考核。Scrum Master則需要對(duì)Scrum過(guò)程負(fù)責(zé)，向所有項(xiàng)目參與者講授Scrum方法，負(fù)責(zé)實(shí)施Scrum，確保它既符合企業(yè)文化，又能交付預(yù)期利益，還需督促 全體成員遵從Scrum規(guī)則和實(shí)踐。

　　啟動(dòng)Scrum項(xiàng)目所需的最簡(jiǎn)約計(jì)劃包括：一份愿景及產(chǎn)品Backlog。愿景描述項(xiàng)目開(kāi)發(fā)原因和預(yù)期目標(biāo)。愿景可能描述商業(yè)運(yùn)作方式將發(fā)生哪些改變，主 要特性和功能如何為客戶創(chuàng)造收益，以及對(duì)市場(chǎng)的預(yù)期影響。產(chǎn)品backlog將定義交付愿景時(shí)，系統(tǒng)應(yīng)滿足的功能性和非功能性需求，它需事先劃分優(yōu)先級(jí)并經(jīng)過(guò)初始預(yù)估（預(yù)估的目的是了解每個(gè)需求自身及相對(duì)與其他需求的規(guī)模）。

　　在Sprint第一天召開(kāi)sprint計(jì)劃會(huì)議，這個(gè)會(huì)議分為兩部分，計(jì)劃會(huì)議1由PO、SM和Team參加，主要是從產(chǎn)品backlog中挑 選出需要放 到當(dāng)前sprint下的既定產(chǎn)品backlog，然后由SM、Team參加計(jì)劃會(huì)議2，把既定產(chǎn)品backlog的故事拆分成任務(wù)進(jìn)行估算，PO也可以一 起參加這個(gè)部分來(lái)了解具體的開(kāi)發(fā)細(xì)節(jié)。sprint周期在spirnt計(jì)劃會(huì)議2正式開(kāi)始。開(kāi)發(fā)過(guò)程中，團(tuán)隊(duì)每天召開(kāi)每日站會(huì)（Daily Scrum），溝通團(tuán)隊(duì)成員間工作進(jìn)度和進(jìn)行任務(wù)協(xié)調(diào)。Sprint周期結(jié)束時(shí)，需要召開(kāi)Sprint評(píng)審會(huì)議，由團(tuán)隊(duì)向產(chǎn)品負(fù)責(zé)人和其他利益相關(guān)者展示 當(dāng)前sprint周期內(nèi)的產(chǎn)品開(kāi)發(fā)情況。產(chǎn)品負(fù)責(zé)人根據(jù)團(tuán)隊(duì)這次 Sprint 所發(fā)布的版本，評(píng)審相關(guān)的 Backlog 中的問(wèn)題，檢查是否已達(dá)到 Sprint 的目標(biāo)。評(píng)審會(huì)議結(jié)束后會(huì)進(jìn)行回顧會(huì)議，通過(guò)總結(jié)以往的實(shí)踐經(jīng)驗(yàn)來(lái)提高團(tuán)隊(duì)生產(chǎn)力。

Software Development Theory

Scrum's Implementation

Scrum之 流程和術(shù)語(yǔ)

Scrum 之 product Backlog

Scrum之 Sprint計(jì)劃會(huì)議

Scrum之 站立例會(huì)

Scrum之 評(píng)審會(huì)議

Scrum之 回顧會(huì)議

The way of controlling

　　控制方法解決項(xiàng)目開(kāi)發(fā)的管理方面的問(wèn)題，提供一種機(jī)制來(lái)管理工作方法（way of working），它包含計(jì)劃和計(jì)劃評(píng)估?；跈z查點(diǎn)和基線，計(jì)劃和計(jì)劃評(píng)估被劃分為多個(gè)階段?？刂品椒ê湍Ｐ头椒ê凸ぷ鞣椒ɑハ嗦?lián)系，不能單獨(dú)來(lái)看每個(gè)方法。

　　軟件開(kāi)發(fā)對(duì)于管理存在兩個(gè)極端：一個(gè)是沒(méi)有任何的管理成本，所有的工作都是為了軟件的產(chǎn)出，這種方式往往導(dǎo)致軟件開(kāi)發(fā)過(guò)程的混亂，產(chǎn)品質(zhì)量低，士氣 也很低落。另一個(gè)是大量管理活動(dòng)的加入，評(píng)審、變更管理，缺陷跟蹤，雖然管理活動(dòng)的加入能夠在一定程度上提高開(kāi)發(fā)過(guò)程的有序性，但是成本卻因此提高，更糟 糕的是，很容易導(dǎo)致團(tuán)隊(duì)的低效率，降低創(chuàng)新能力。因此，敏捷方法視圖尋找一個(gè)平衡點(diǎn)，用低成本的管理活動(dòng)帶來(lái)最大的產(chǎn)出，即軟件的高質(zhì)量。系統(tǒng)越復(fù)雜，集權(quán)管理導(dǎo)致失敗的可能性越大，Scrum應(yīng)用 自組織 、自管理原則 ，授權(quán)于項(xiàng)目開(kāi)發(fā)團(tuán)隊(duì) ，通過(guò)頻繁運(yùn)用“ 檢查－調(diào)整 “周期加速創(chuàng)造更具價(jià)值的軟件，它帶來(lái)較低的管理成本和高質(zhì)量的產(chǎn)出。

　　《過(guò)程動(dòng)態(tài)學(xué)，建模及控制》指出，“在過(guò)程運(yùn)行根本機(jī)制相當(dāng)簡(jiǎn)單易懂的情況下，典型做法是采用預(yù)定義的（理論的）建模方式。若過(guò)程復(fù)雜程度超出預(yù)定義方式的能力范圍，便應(yīng)選用經(jīng)驗(yàn)性方式。”Scrum承認(rèn)軟件開(kāi)發(fā)的復(fù)雜性（需求、技術(shù)和人），實(shí)施經(jīng)驗(yàn)性方式。 實(shí)施經(jīng)驗(yàn)性過(guò)程控制方法時(shí)，有3大支柱：可見(jiàn)性、檢查及適應(yīng) 。 可見(jiàn)性 是 指對(duì)過(guò)程控制者來(lái)說(shuō)，過(guò)程中對(duì)最后結(jié)果有影響的方面必須清晰可見(jiàn)，而且必須真實(shí)可信，例如Scrum中對(duì)于完成的定義必須團(tuán)隊(duì)都有清晰的認(rèn)識(shí)。過(guò)程中的各 個(gè)方面必須頻繁檢查，例如進(jìn)行代碼評(píng)審等。適用就是經(jīng)過(guò)檢查后，調(diào)整工作需要盡快展開(kāi)，以減少進(jìn)一步的偏差。Scrum會(huì)進(jìn)行每日站會(huì)，溝通每日進(jìn)展情況 以作調(diào)整，每個(gè)sprint后還會(huì)進(jìn)行回顧會(huì)議，以便反饋到下一個(gè)sprint中。

　　Scrum方法中沒(méi)有傳統(tǒng)意義上的項(xiàng)目經(jīng)理，取而代之的是Scrum Master，他承擔(dān)領(lǐng)導(dǎo)、指導(dǎo)和教練工作。軟件開(kāi)發(fā)工作的性質(zhì)決定了會(huì)有大量復(fù)雜問(wèn)題的出現(xiàn)，Scrum Master無(wú)權(quán)直接命令開(kāi)發(fā)團(tuán)隊(duì)，他有責(zé)任講授怎樣使用Scrum來(lái)處理項(xiàng)目中遇到的每個(gè)新的復(fù)雜問(wèn)題，解決這些問(wèn)題離不開(kāi)努力工作、智慧和勇氣。

　　Scrum的運(yùn)作基礎(chǔ)是個(gè)人和團(tuán)隊(duì)的承諾，而非嚴(yán)密的規(guī)劃及控制。但自組織團(tuán)隊(duì)不是無(wú)管理團(tuán)隊(duì)，它必須制定計(jì)劃并有針對(duì)性的進(jìn)行報(bào)告，才能管理自身工作。sprint backlog是團(tuán)隊(duì)履行職責(zé)的可視表現(xiàn)。

Scrum and Process Improvement

Development: Empirical or Planned?

The way of modeling

　　模型方法定義了一些模型語(yǔ)言，使用符號(hào)，結(jié)合文檔進(jìn)行分析，并可以可視化的來(lái)描述架構(gòu)需求。

　　Scrum中可以有一些基本概念，如backlog、Story、Task，Story有優(yōu)先級(jí)、Task有估算時(shí)間等，這些在開(kāi)發(fā)過(guò)程中都需要使用一種方式表達(dá)出來(lái)，以下為別人使用Excel對(duì)產(chǎn)品backlog和sprint backlog進(jìn)行描述的兩個(gè)示例：

Simple Product Backlog Example

Simple Sprint Backlog Example

Scrum Rules

The way of supporting

支持方法尋找有用的工具、培訓(xùn)、文檔來(lái)協(xié)助支持信息系統(tǒng)的開(kāi)發(fā)。

“項(xiàng)目快速啟動(dòng)”方案是為期兩天的培訓(xùn)，確保缺少Scrum經(jīng)驗(yàn)的新團(tuán)隊(duì)能啟動(dòng)項(xiàng)目。

以下為別人對(duì)Scrum工具的描述：

Scrum工具大比拼---流行Scrum工具一網(wǎng)打盡

推薦三款Scrum項(xiàng)目管理工具

The way of communicating

溝通方法描述了對(duì)開(kāi)發(fā)過(guò)程中的各個(gè)環(huán)節(jié)、工作成果等如何進(jìn)行溝通，也包含在模型方法中定義的抽象概念如何通過(guò)文本或者圖形符號(hào)來(lái)表達(dá)清楚。

Scrum通過(guò)任務(wù)看板來(lái)查看任務(wù)，通過(guò)燃燒圖來(lái)查看項(xiàng)目進(jìn)展情況。

用“看板圖”實(shí)現(xiàn)敏捷項(xiàng)目的可視化

FAQ's

從IT方法論來(lái)談Scrum