《構(gòu)建之法》筆記

軟件公司 = 軟件 + 商業(yè)模式

軟件 = 程序 + 軟件工程

程序 = 算法 + 數(shù)據(jù)結(jié)構(gòu)

工程的定義

創(chuàng)造性地運(yùn)用科學(xué)原理，設(shè)計(jì)和實(shí)現(xiàn)建筑、機(jī)器、裝置或生產(chǎn)過(guò)程；或者是在實(shí)踐中使用一個(gè)或多個(gè)上述實(shí)體；或者是實(shí)現(xiàn)這些實(shí)體的過(guò)程

軟件工程是什么？

軟件工程是把系統(tǒng)的、有序的、可量化的方法應(yīng)用到軟件的開(kāi)發(fā)、運(yùn)營(yíng)和維護(hù)上的過(guò)程。

軟件工程包括下列領(lǐng)域：軟件需求分析、軟件設(shè)計(jì)、軟件構(gòu)建、軟件測(cè)試和軟件維護(hù)。

軟件工程和下列的學(xué)科相關(guān)：計(jì)算機(jī)科學(xué)、計(jì)算機(jī)工程、 管理學(xué)、數(shù)學(xué)、項(xiàng)目管理學(xué)、質(zhì)量管理、軟件人 體工學(xué)、系統(tǒng)工程、工業(yè)設(shè)計(jì)和用戶(hù)界面設(shè)計(jì)

軟件開(kāi)發(fā)過(guò)程有什么特別的難題？

1. 復(fù)雜性（Complexity）

軟件可以說(shuō)是人類(lèi)創(chuàng)造的最復(fù)雜的系統(tǒng)類(lèi)型。大型軟件（操作系統(tǒng)、辦公軟件、搜索引擎）有超過(guò)百萬(wàn)行的源代碼，上萬(wàn)個(gè)不同的文件。而軟件工程師通常一次只能看到30—80行源代碼（相當(dāng)于顯示器的一屏），他們的智力、記憶力和常人差不多。軟件的各個(gè)模塊之間有各種顯性或隱性的依賴(lài)關(guān)系，隨著系統(tǒng)的成長(zhǎng)和模塊的增多，這些關(guān)系的數(shù)量往往以幾何級(jí)數(shù)的速度增長(zhǎng)。

2. 不可見(jiàn)性（Invisibility）

軟件工程師能直接看見(jiàn)源代碼，但是源代碼不是軟件本身。軟件以機(jī)器碼的形式高速運(yùn)行，還可能在幾個(gè)CPU核上同時(shí)運(yùn)行，工程師是“看”不到自己的源代碼如何具體地在用戶(hù)的機(jī)器上被執(zhí)行的。商用軟件出現(xiàn)了錯(cuò)誤，工程師可以看到程序在出錯(cuò)的一瞬間留下的一些痕跡（錯(cuò)誤代號(hào)、大致的目標(biāo) 代碼位置、錯(cuò)誤信息），但是幾乎無(wú)法完整重現(xiàn)到底程序出現(xiàn)了什么問(wèn)題。

3. 易變性（Changeability）

軟件看上去很容易修改，修改軟件比修改硬件容易多了。人們自然地期待軟件能在下面兩種情況下“改變”：

a) 讓軟件做新的事情；

b) 讓軟件適應(yīng)新的硬件。但是與此同時(shí)，正確地修改軟件是一件很困難的事情。

4. 服從性（Conformity）

軟件不能獨(dú)立存在，它總是要運(yùn)行在硬件上面， 它要服從系統(tǒng)中其他組成部分的要求，它還要服從用戶(hù)的要求、行業(yè)系統(tǒng)的要求（例如銀行利率 的變化）。

5. 非連續(xù)性（Discontinuity）

人們比較容易理解連續(xù)的系統(tǒng)：增加輸入，就能看到相應(yīng)輸出的增加。但是許多軟件系統(tǒng)卻沒(méi)有這樣的特性，有時(shí)輸入上很小的變化，會(huì)引起輸出上極大的變化。 這些特性的前四個(gè)是佛瑞德·布魯克斯 （FredBrooks Jr.）在No Silver Bullet一文中提到的，第五個(gè)特性是瓦茨拉夫·拉里奇（Vaclav Rajlich）提到的

個(gè)人開(kāi)發(fā)流程Personal Software Process（PSP）

軟件團(tuán)隊(duì)的模式

一窩蜂模式

例如小朋友們剛開(kāi)始踢足球的時(shí)候，大家都一窩蜂地去搶球，球在哪里，一堆人就跟到哪里，這樣的模式可以叫一窩蜂模式（Chaos Team）。

不能否認(rèn)，這樣的團(tuán)隊(duì)也有，只不過(guò)他們?cè)谶@樣的模式下存活的時(shí)間一般都不長(zhǎng)，沒(méi)有機(jī)會(huì)讓別人很好地觀(guān)察。一窩蜂模式可能是一個(gè)歡樂(lè)而隨意的模式，但這是一個(gè)好的團(tuán)隊(duì)形式么？

當(dāng)然不是。要把一群小朋友培養(yǎng)成一個(gè)團(tuán)隊(duì)，需要時(shí)間

主治醫(yī)師模式（Chief Programmer Team，Surgical Team）

就像在手術(shù)臺(tái)上那樣，有一個(gè)主刀醫(yī)師，其他人（麻醉，護(hù)士，器械）各司其職，為主刀醫(yī)師服務(wù)。這樣的軟件團(tuán)隊(duì)中，有首席程序員（Chief Pro-grammer），他/她負(fù)責(zé)處理主要模塊的設(shè)計(jì)和編碼，其他成員從各種角度支持他/她的工作 （后備程序員、系統(tǒng)管理員、工具開(kāi)發(fā)、編程語(yǔ)言專(zhuān)家、業(yè)務(wù) 專(zhuān)家）。佛瑞德·布魯克斯 （Frederic BrooksJr.）在主管IBM System360項(xiàng)目時(shí)就采用了這種模式。在一些學(xué)校里，軟件工程的團(tuán)隊(duì)模式往往從這一模式退化為“一個(gè)學(xué)生干活，其余學(xué)生跟著打醬油”。

明星模式（Super-star Model）

主治醫(yī)師模式運(yùn)用到極點(diǎn)，可以蛻化為明星模式，在這里，明星的光芒蓋過(guò)了團(tuán)隊(duì)其他人的總和，2004年到2012年的“翔之隊(duì)”就是一個(gè)例子。 明星也是人，也會(huì)受傷，犯錯(cuò)誤，如何讓團(tuán)隊(duì)的利益最大化，而不是明星的利益最大化？如何讓團(tuán)隊(duì)的價(jià)值在明星隕落之后仍然能夠保持？是這個(gè)模式要解決的問(wèn)題。真正有巨大成就的明星都能意識(shí)到團(tuán)隊(duì)的作用，

邁克爾·喬丹說(shuō)過(guò)，“Talent wins games, team work wins championship.”

社區(qū)模式（Community Model)

社區(qū)由很多志愿者參與，每個(gè)人參與自己感興趣的項(xiàng)目，貢獻(xiàn)力量，大部分人不拿報(bào)酬。這種模式的好處是“眾人拾柴火焰高”，但是如果大家都只來(lái)烤火，不去拾柴；或者撿到的柴火質(zhì)量太差，最后火也就熄滅了。“社區(qū)”并不意味著“隨意”，一些成功的社區(qū)項(xiàng)目（例如開(kāi)發(fā)和維護(hù) Linux操作系統(tǒng)的社區(qū)），都有很?chē)?yán)格的代碼復(fù)審和簽入的質(zhì)量控制

業(yè)余劇團(tuán)模式（Amateur Theater Team）

這樣的團(tuán)隊(duì)在每一個(gè)項(xiàng)目（劇目）中，不同的人會(huì)挑選不同的角色。在下一個(gè)劇目中，這些人也許會(huì)換一個(gè)完全不同的角色類(lèi)型。各人在團(tuán)隊(duì)中聽(tīng)從一個(gè)中央指揮（導(dǎo)演）的指導(dǎo)和安排。在學(xué)生實(shí)踐項(xiàng)目或培訓(xùn)項(xiàng)目中，這樣的事情經(jīng)常發(fā)生。

秘密團(tuán)隊(duì)（Skunk Work Team）

一些軟件項(xiàng)目在秘密狀態(tài)下進(jìn)行，別人不知道他們具體在做什么。蘋(píng)果公司1980年代在研發(fā) Macin-tosh之后的系統(tǒng)時(shí)，就有兩三個(gè)團(tuán)隊(duì)在不同時(shí)期進(jìn)入秘密狀態(tài)開(kāi)發(fā)。21世紀(jì)的一些創(chuàng)業(yè)團(tuán)隊(duì)也是處 于類(lèi)似狀態(tài)。這種模式的好處是：團(tuán)隊(duì)內(nèi)部有極大的自由，沒(méi)有外界的干擾（不用每周給別人介紹項(xiàng)目進(jìn)展，聽(tīng)領(lǐng)導(dǎo)的最新指示等等），團(tuán)隊(duì)成員有極大的投入。

特工團(tuán)隊(duì)（SWAT）

就像電影電視中的特工組《加里森敢死隊(duì)》等一樣，軟件行業(yè)的一些團(tuán)隊(duì)由一些有特殊技能的專(zhuān)業(yè)人士組成，負(fù)責(zé)解決一些棘手而有緊迫性的問(wèn)題。例如2000年之前，很多公司都需要專(zhuān)業(yè)人士去解決Y2K問(wèn)題。這些團(tuán)隊(duì)成員必須了解傳統(tǒng)語(yǔ)言和老式系統(tǒng)，才能勝任這樣的任務(wù)。現(xiàn)在還有 一些專(zhuān)門(mén)做網(wǎng)站安全性服務(wù)的團(tuán)隊(duì)，也屬于這一類(lèi)型。

交響樂(lè)團(tuán)模式（Orchestra)

想象一下交響樂(lè)團(tuán)的演奏，有下面的特點(diǎn)。

家伙多，門(mén)類(lèi)齊全。

各司其職，各自有專(zhuān)門(mén)場(chǎng)地，

演奏期間沒(méi)有聊天、走動(dòng)等現(xiàn)象。

演奏都靠譜，同時(shí)看指揮的。

演奏的都是練習(xí)過(guò)多次的曲目，重在執(zhí)行。

當(dāng)某個(gè)軟件領(lǐng)域處于穩(wěn)定成長(zhǎng)階段的時(shí)候，眾多大型軟件公司的開(kāi)發(fā)團(tuán)隊(duì)就會(huì)采取這種模式，例如微軟公司的Office軟件，從Office97、Office XP、Office2003、Office2007到Office2011、 Office2013……

爵士樂(lè)模式（Jazz Band）

從外行看熱鬧的角度看，和交響樂(lè)團(tuán)相比，這種模式有以下特點(diǎn)。

不靠譜。他們演奏時(shí)都沒(méi)有譜子。沒(méi)有現(xiàn)場(chǎng)指揮，平時(shí)有編曲起到協(xié)調(diào)和指導(dǎo)作用（和邁爾斯合作的編曲吉爾·伊文斯 （GilEvans）也是很有造詣的音樂(lè)家）。 也有模式，邁爾斯（姑且稱(chēng)之為架構(gòu)師）先吹出主題，然后他走到一旁抽煙去了，其余人員根據(jù)這個(gè)主題各自即興發(fā)揮；最后邁爾斯加入，回應(yīng)主題，像是對(duì)曲子的總結(jié)。 人數(shù)較少。評(píng)論家歸納邁爾斯·戴維斯的特點(diǎn)是：

強(qiáng)調(diào)個(gè)性化的表達(dá)，強(qiáng)有力的互動(dòng)，對(duì)變化的內(nèi)容有創(chuàng)意的回應(yīng)。這看上去跟“敏捷的開(kāi)發(fā)模式”有點(diǎn)類(lèi)似。這樣的團(tuán)隊(duì)模式和上面的“交響樂(lè)團(tuán)模式”在很多方面都對(duì)立，但是兩種模式都產(chǎn)生了很受歡迎的音樂(lè)作品，因此不能簡(jiǎn)單地說(shuō)孰優(yōu)孰劣

功能團(tuán)隊(duì)模式（Feature Team)

很多軟件公司的團(tuán)隊(duì)最后都演變成功能團(tuán)隊(duì)，簡(jiǎn)而言之，就是具備不同能力的同事們平等協(xié)作， 共同完成一個(gè)功能

在這個(gè)功能完成之后，這些人又重新組織，和別的角色一起去完成下一個(gè)功能。他們之間沒(méi)有管理和被管理的關(guān)系。大型軟件公司里的不少團(tuán)隊(duì)都是采用這種模式。

這些功能小組也稱(chēng)為 Feature Crew，小組內(nèi)的交流比較頻繁。約翰· 巴克斯在1955年管理 FORTRAN語(yǔ)言項(xiàng)目時(shí)，就用了類(lèi)似的團(tuán)隊(duì)架構(gòu)。

巴克斯以蜂窩狀的架構(gòu)來(lái)組織工作。每個(gè)小組都由一到三個(gè)人組成，每個(gè)小組都是一個(gè)有自主權(quán)的單元，可以自由選用最有利于他們完成工作的任何技術(shù)。但是，每個(gè)小組必須與其他小組就編程規(guī)范達(dá)成一致……

官僚模式（Bureaucratic Model）

這種模式脫胎于大機(jī)構(gòu)的組織架構(gòu)，幾個(gè)人報(bào)告給一個(gè)小頭目，幾個(gè)小頭目報(bào)告給中頭目，依次而上。

這種模式在軟件開(kāi)發(fā)中會(huì)出問(wèn)題。因?yàn)槌蓡T之間不光有技術(shù)方面的合作和領(lǐng)導(dǎo)，同時(shí)還混進(jìn)了組織上的領(lǐng)導(dǎo)和被領(lǐng)導(dǎo)關(guān)系。

跨組織的合作變得比較困難，因?yàn)楦髯灶^頂上都有不同的老板。這種模式如果應(yīng)用不好，最后會(huì)變成“老板驅(qū)動(dòng)”的開(kāi)發(fā)流程

開(kāi)發(fā)流程

寫(xiě)了再改模式（Code-and-Fix）

史蒂夫·邁克康奈爾（Steve McConnell）在這里提到了不少開(kāi)發(fā)流程。第一個(gè)提到的開(kāi)發(fā)流程 ——Code-and-Fix，看起來(lái)和一窩蜂團(tuán)隊(duì)模式非常像。

這個(gè)流程也有好處，不需要太多其他準(zhǔn)備或相關(guān)知識(shí)，大家上來(lái)就寫(xiě)代碼，也許就能寫(xiě)出來(lái)，寫(xiě)不出來(lái)就改，也許能改好。當(dāng)面臨下面的任務(wù)時(shí)，也許這個(gè)方法是有用的。

“只用一次”的程序

“看過(guò)了就扔”的原型

一些不實(shí)用的演示程序

但是，要寫(xiě)一個(gè)有實(shí)際用戶(hù)、解決實(shí)際需求的軟 件，這個(gè)方法的缺點(diǎn)就太大了。要注意的是，許多學(xué)校里的軟件工程作業(yè)的要求符合上面那三點(diǎn)，所以難怪同學(xué)們覺(jué)得沒(méi)有必要用其他的開(kāi)發(fā)方法，“寫(xiě)了再改”足矣！

瀑布模型（Waterfall Model）

當(dāng)軟件行業(yè)還在年幼的時(shí)期，它從別的成熟行業(yè) （硬件設(shè)計(jì)，建筑工程）借用了不少經(jīng)驗(yàn)和模 型。在那些“硬”的行業(yè)中，產(chǎn)品大多遵循 [分析→ 設(shè)計(jì)→實(shí)現(xiàn)（制造）→銷(xiāo)售→維護(hù)] 這個(gè)流程。 由于在“硬”行業(yè)中產(chǎn)品一旦大規(guī)模生產(chǎn)，要再返 回去修改時(shí)就非常困難，甚至是不可能的。因此 這個(gè)模型描述了單向的、不可逆的生產(chǎn)過(guò)程

“最終產(chǎn)品直到最后才出現(xiàn)”是很令人頭痛的局限 性，考慮這個(gè)制造汽車(chē)的故事。

你（用戶(hù)）提出要發(fā)動(dòng)機(jī)、車(chē)身、車(chē)窗、方 向盤(pán)、加速踏板、剎車(chē)、手剎、座位、車(chē) 燈…… 生產(chǎn)商按照瀑布模型流程給你設(shè)計(jì)、生產(chǎn)， 六個(gè)月后交付。 看到樣車(chē)后…… 你提出—我當(dāng)初忘了一件小事，要有倒車(chē) 燈： 當(dāng)?shù)管?chē)的時(shí)候，倒車(chē)燈會(huì)亮。

生產(chǎn)商說(shuō)： 我要重新設(shè)計(jì)車(chē)尾部，加上倒車(chē)燈，把車(chē)底 拆開(kāi)，安裝線(xiàn)路，修改傳動(dòng)裝置把倒車(chē)檔和 倒車(chē)燈聯(lián)系起來(lái)……我得重新開(kāi)始。 你說(shuō)：這不是很小的一件事么？這是小事還 是大事？那么，瀑布模型有適用范圍么？我 認(rèn)為有： 如果產(chǎn)品的定義非常穩(wěn)定，但是產(chǎn)品的正確 性非常重要，需要每一步的驗(yàn)證 產(chǎn)品模塊之間的接口、輸入和輸出能很好地 用形式化的方法定義和驗(yàn)證 使用的技術(shù)非常成熟，團(tuán)隊(duì)成員都很熟悉這 些技術(shù) 負(fù)責(zé)各個(gè)步驟的子團(tuán)隊(duì)分屬不同的機(jī)構(gòu)，或 在不同的地理位置，不可能做到頻繁的交流

瀑布模型的各種變形

1、生魚(yú)片模型

這個(gè)模型解決了各個(gè)步驟之間分離的缺點(diǎn)，同時(shí) 也帶來(lái)了一些困擾—究竟什么時(shí)候上一個(gè)階段會(huì) 結(jié)束呢？

2、大瀑布帶著小瀑布

在這種瀑布群下，要把各個(gè)子系統(tǒng)統(tǒng)一到最后做 系統(tǒng)測(cè)試（System Testing）的階段，難度不是 一般的大啊！另外，在這樣的開(kāi)發(fā)流程中，用戶(hù) 只有到了最后才能看到結(jié)果，用戶(hù)真是等不起

漸進(jìn)交付的流程（Evolutionary Delivery），MVP和MBP

這個(gè)流程是史蒂夫·邁克康奈爾（Steve McConnell）在1996年總結(jié)的，但是它其實(shí)已經(jīng) 很接近現(xiàn)在大家談?wù)撦^多的迭代式開(kāi)發(fā)流程。當(dāng) 系統(tǒng)的主要需求和架構(gòu)明確之后，軟件團(tuán)隊(duì)進(jìn)入 了一個(gè)不斷演進(jìn)的evolution循環(huán)中：[開(kāi)發(fā)→發(fā)布 →聽(tīng)取反饋→根據(jù)反饋?zhàn)龈倪M(jìn)]

這個(gè)軟件什么時(shí)候才最后完成呢？下面幾個(gè)條件

滿(mǎn)足一個(gè)即可。

時(shí)間到了。

錢(qián)花光了。

用戶(hù)滿(mǎn)意了（或者很不滿(mǎn)意，不再給錢(qián) 了）。

在漸進(jìn)交付的流程中，我們假設(shè)一下，當(dāng)用戶(hù)看 到第一個(gè)版本的時(shí)候，他們就對(duì)這個(gè)產(chǎn)品很不滿(mǎn) 意，完全沒(méi)有任何購(gòu)買(mǎi)或使用的意愿。在這種情 況下，整個(gè)團(tuán)隊(duì)為第一版所做的各種投入都浪費(fèi) 了。這個(gè)問(wèn)題的一個(gè)根源是：產(chǎn)品團(tuán)隊(duì)得到用戶(hù) 的反饋太晚了。那么，我們能否讓用戶(hù)更早地給 產(chǎn)品團(tuán)隊(duì)反饋？

從2009年開(kāi)始，一些互聯(lián)網(wǎng)產(chǎn)品 團(tuán)隊(duì)在試驗(yàn)MVP方法：MVP——Minimal Viable Product，最小可行產(chǎn)品，又稱(chēng)為Minimal Feature Set，最小功能集。

具體的做法是：把產(chǎn) 品最核心的功能用最小的成本實(shí)現(xiàn)出來(lái)（或者描 繪出來(lái)），然后快速征求用戶(hù)意見(jiàn)。例如，一個(gè) 社交網(wǎng)站已經(jīng)有很多用戶(hù)，都是免費(fèi)的，產(chǎn)品團(tuán) 隊(duì)想設(shè)計(jì)一個(gè)付費(fèi)的VIP服務(wù)，MVP的做法可以 是這樣—在目前的用戶(hù)入口頁(yè)面中加一個(gè)“VIP服 務(wù)”的鏈接，指向一個(gè)簡(jiǎn)單的 介紹頁(yè)面（用最小成 本做出來(lái)）。觀(guān)察到底有多少用戶(hù)點(diǎn)擊這個(gè)鏈 接。如果點(diǎn)擊量太小，那么這個(gè)VIP服務(wù)就不用 做了。另一個(gè)例子，一個(gè)團(tuán)隊(duì)要打造一個(gè)餐飲推薦服務(wù)，原來(lái)的V1計(jì)劃包括網(wǎng)站要適配三種瀏覽 器，餐館登錄和上傳數(shù)據(jù)，手機(jī)客戶(hù)端（安卓和 iOS），以及手機(jī)和網(wǎng)站的同步，用戶(hù)之間的互動(dòng)，菜譜管理，照片管理，等等。這個(gè)計(jì)劃如果 全部實(shí)現(xiàn)，估計(jì)要花一年時(shí)間，但是在這一年時(shí) 間中用戶(hù)沒(méi)法提供任何反饋（因?yàn)榇蟛糠止δ芏?沒(méi)能實(shí)現(xiàn)好）。如果用MVP的思路，團(tuán)隊(duì)會(huì)找出 最關(guān)鍵、最小的功能集（用戶(hù)用iPhone應(yīng)用能看 到北京市某個(gè)區(qū)的餐館推薦），快速實(shí)現(xiàn)，三個(gè) 月就可以聽(tīng)到用戶(hù)的反饋。這樣是不是會(huì)更好？ MVP的指導(dǎo)思想和漸進(jìn)交付相似，但是它更強(qiáng)調(diào) 更早獲得用戶(hù)反饋，為此可以在產(chǎn)品完成之前就發(fā)布，它也強(qiáng)調(diào)產(chǎn)品的核心價(jià)值（產(chǎn)品最區(qū)別于 競(jìng)爭(zhēng)產(chǎn)品的地方），為了突出核心功能，別的輔 助功能可以不考慮或者用別的平臺(tái)提供的服務(wù)來(lái) 代替。 正如所有的方法論那樣，MVP也有它的適用范圍，和它相對(duì)應(yīng)的，是Maximal Beautiful Product（最強(qiáng)最美產(chǎn)品，MBP）的思路，如果 對(duì)用戶(hù)的需求了然于心，或者產(chǎn)品團(tuán)隊(duì)比用戶(hù)更 了解用戶(hù)的需求，為何不把產(chǎn)品最全、最美的形 態(tài)展現(xiàn)出來(lái)，一舉征服用戶(hù)？大家可以回顧第一 版的iPhone（2007年）和 iPad（2010），它們 是MVP么？顯然不是。如何能做到MBP？這對(duì)產(chǎn)品團(tuán)隊(duì)有更高的要求

敏捷的流程

敏捷開(kāi)發(fā)原則

1. 盡早并持續(xù)地交付有價(jià)值的軟件以滿(mǎn)足顧客需求

2. 敏捷流程歡迎需求的變化，并利用這種變化來(lái) 提高用戶(hù)的競(jìng)爭(zhēng)優(yōu)勢(shì)

3. 經(jīng)常發(fā)布可用的軟件，發(fā)布間隔可以從幾周到幾個(gè)月，能短則短

4. 業(yè)務(wù)人員和開(kāi)發(fā)人員在項(xiàng)目開(kāi)發(fā)過(guò)程中應(yīng)該每 天共同工作

5. 以有進(jìn)取心的人為項(xiàng)目核心，充分支持信任他們

6. 無(wú)論團(tuán)隊(duì)內(nèi)外，面對(duì)面的交流始終是最有效的 溝通方式

7. 可用的軟件是衡量項(xiàng)目進(jìn)展的主要指標(biāo)

8. 敏捷流程應(yīng)能保持可持續(xù)的發(fā)展。領(lǐng)導(dǎo)、團(tuán)隊(duì) 和用戶(hù)應(yīng)該能按照目前的步調(diào)持續(xù)合作下去

9. 只有不斷關(guān)注技術(shù)和設(shè)計(jì)，才能越來(lái)越敏捷

10. 保持簡(jiǎn)明—盡可能簡(jiǎn)化工作量的技藝—極為重要

11. 只有能自我管理的團(tuán)隊(duì)才能創(chuàng)造優(yōu)秀的架構(gòu)、需求和設(shè)計(jì)

12. 時(shí)時(shí)總結(jié)如何提高團(tuán)隊(duì)效率，并付諸行動(dòng)

敏捷的步驟

第一步：找出完成產(chǎn)品需要做的事情—Product Back-log。

Backlog翻譯成“積壓的工作”、“待解決的問(wèn)題”、“產(chǎn)品訂單”，都可以。產(chǎn)品負(fù)責(zé)人主 導(dǎo)大家對(duì)于這個(gè)Backlog進(jìn)行增／刪／改的工 作。每一項(xiàng)工作的時(shí)間估計(jì)單位為“天”。

第二步：決定當(dāng)前的沖刺（Sprint）需要解決的事情—Sprint Backlog。

整個(gè)產(chǎn)品的實(shí)現(xiàn)被劃分為 幾個(gè)互相聯(lián)系的沖刺（Sprint）。產(chǎn)品訂單上的 任務(wù)被進(jìn)一步細(xì)化了，被分解為以小時(shí)為單位。 如果一個(gè)任務(wù)的估計(jì)時(shí)間太長(zhǎng)（如超過(guò)16個(gè)小 時(shí)），那么它就應(yīng)該被進(jìn)一步分解。訂單上的任 務(wù)是團(tuán)隊(duì)成員根據(jù)自己的情況來(lái)認(rèn)領(lǐng)。團(tuán)隊(duì)成員 能主導(dǎo)任務(wù)的估計(jì)和分配，他們的能動(dòng)性得到較 大的發(fā)揮。

第三步：沖刺（Sprint）。

在沖刺階段，外部人士不能直接打擾團(tuán)隊(duì)成員。一切交流只能通過(guò) Scrum大師（Scrum Master）來(lái)完成。這一措施 較好地平衡了“交流”和“集中注意力”的矛盾。有 任何需求的改變都留待沖刺結(jié)束后再討論。 沖刺期間，每天要開(kāi)一個(gè)每日例會(huì)（Scrum Meet-ing），團(tuán)隊(duì)成員大多站著開(kāi)會(huì)，所以又稱(chēng)每日立會(huì)。大家依次報(bào)告：

我昨天做了啥

我今天要做啥

我碰到了哪些問(wèn)題

每日立會(huì)強(qiáng)迫每個(gè)人向同伴報(bào)告進(jìn)度，迫使大家把問(wèn)題擺在明面上。同時(shí)啟動(dòng)每日構(gòu)建，讓大家每天都能看到一個(gè)逐漸完善的版本。用簡(jiǎn)明的圖表展現(xiàn)整個(gè)項(xiàng)目的進(jìn)度，這個(gè)圖最好放在大家工作的環(huán)境中，或者每天傳達(dá)給 各個(gè)成員：圖表可以是燃盡圖（Burn Down Chart，想象我們把一堆Backlog的木頭給燒光）。沖刺階段是時(shí)間驅(qū)動(dòng)的（Time-boxed），時(shí)間一到就結(jié)束。這個(gè)特點(diǎn)看似不起眼，但其實(shí)它有效地?cái)嗔烁鞣N延期想法的后路，很高明。

第四步：得到軟件的一個(gè)增量版本，發(fā)布給用戶(hù)。然后在此基礎(chǔ)上又進(jìn)一步計(jì)劃增量的新功能和改進(jìn)

敏捷對(duì)團(tuán)隊(duì)的要求

敏捷對(duì)團(tuán)隊(duì)的要求很簡(jiǎn)單：自主管理（Selfmanag-ing）、自我組織（Self-organizing）、多 功能型（Cross-functional），但是這很難做到。 軟件項(xiàng)目的團(tuán)隊(duì)各式各樣

1. 自主管理：以前領(lǐng)導(dǎo)布置了任務(wù)，我們實(shí)現(xiàn)就 可以了，現(xiàn)在要自己挑選任務(wù)；每次Sprint結(jié)束 之后，還要總結(jié)不足，提出改進(jìn)，并且自己要實(shí) 施這些改進(jìn)。“自主管理”不等于“沒(méi)有管理”。

2. 自我組織：以前做好自己的事情就好了，安心下班。現(xiàn)在每個(gè)人要聯(lián)合起來(lái)對(duì)項(xiàng)目負(fù)責(zé)，有人 工作落后了還要幫助他改進(jìn)，項(xiàng)目缺少某類(lèi)資源 還要自己頂上去。

3. 多功能型：以前規(guī)格說(shuō)明書(shū)由PM來(lái)寫(xiě)，測(cè)試 由測(cè)試人員來(lái)做，現(xiàn)在每個(gè)人都全面負(fù)責(zé)，自己 搞定規(guī)格說(shuō)明書(shū)，和別人溝通，同時(shí)自己搞定測(cè)試。

如果你的團(tuán)隊(duì)很弱，那么強(qiáng)行把敏捷（或者其他高級(jí)方法）套在上面也沒(méi)有用，也許還會(huì)適得其 反，往往需要多次Sprint才能讓Scrum走上正軌。 換句話(huà)說(shuō)，如果你的團(tuán)隊(duì)已經(jīng)有這么厲害（自主管理、自我組織、多功能型）的一幫人，那么用不用Scrum都能寫(xiě)好軟件

軟件開(kāi)發(fā)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。