這幾個模型經(jīng)常容易弄混～ 下面來辨析一下他們叭～

文章目錄

1. 概述這幾個方法論的定義/原則

2. 從多個角度對比這幾個方法論

方法論的定義與原則

精益——精益起源于日本豐田公司的“TPS”（豐田生產(chǎn)方式）。

精益的準(zhǔn)則：

1、Eliminate Waste（消除浪費(fèi)）

2、Build Quality In（嵌入質(zhì)量）

3、Create Knowledge（創(chuàng)造知識）

4、Defer Commitment（延遲決策）

5、Deliver Fast（快速交付）

6、Respect People（尊重他人）

7、Optimize the Whole（整體優(yōu)化）

精益的核心是：不停地（無情地）消除任何不增加價值的工作。

敏捷——敏捷軟件開發(fā)一開始就是立足于如何做好一個軟件產(chǎn)品。

敏捷軟件宣言（敏捷軟件開發(fā)的準(zhǔn)則）：

我們正在通過親身實踐以及幫助他人實踐，探尋更好的軟件開發(fā)方法。通過這項工作，我們建立了如下價值觀：

1.? 個體和互動勝過流程和工具。

2. 可以工作的軟件勝過詳盡的文檔。

3. 客戶合作勝過合同談判。

4. 響應(yīng)變化勝過遵循計劃。

也就是說，雖然右項也具有其價值，但我們認(rèn)為左項具有更大的價值。

值得補(bǔ)充的是：所謂的scrum，xp編程，看板這三個概念，不能稱作方法論，更傾向于是一種實踐的方法。其中，scrum和xp編程傾向于是敏捷，看板傾向于精益

設(shè)計沖刺——設(shè)計沖刺脫胎于設(shè)計思維，是谷歌提出的一個5天快速解決重大問題的方法論。

主要流程是：

星期一，描述問題，提煉出要集中解決的問題。

星期二，頭腦風(fēng)暴，團(tuán)隊成員在紙上列出備選方案。

星期三，由一個成員引導(dǎo)大家對備選方案做出抉擇，并將選中的方案轉(zhuǎn)化為可測試的猜想。

星期四，快速搭建一個原型。

星期五，做一個小規(guī)模的用戶測試，并收集用戶的反饋。

方法論的辨析

精益和敏捷的同：

精益一開始并不是在互聯(lián)網(wǎng)領(lǐng)域中提出來的，但是它適用于互聯(lián)網(wǎng)領(lǐng)域。精益和敏捷本身就是相互支持的一個狀態(tài)，它們的背后是類似的價值觀和科學(xué)性。

精益和敏捷都是真的有產(chǎn)品的產(chǎn)出。

精益和敏捷的異：

在實踐中，敏捷更傾向于做產(chǎn)品的0-1的過程。精益更傾向于做產(chǎn)品的1-100的過程，做大平臺、大規(guī)模的運(yùn)行。（因為精益脫胎于工業(yè)化生產(chǎn)的豐田，規(guī)模大）

設(shè)計沖刺和另兩個的同：

都有著團(tuán)隊高效合作、小步迭代、用戶參與的思想。

設(shè)計沖刺與另兩個的異：

設(shè)計沖刺不要求做出真正的產(chǎn)品，它更傾向于是在對產(chǎn)品需求轉(zhuǎn)換、功能設(shè)計階段的時候做的一種方法。設(shè)計沖刺是幫助團(tuán)隊“想清楚做的是什么”的一種方法。而敏捷與精益是要求把產(chǎn)品“做出來”。

另外注意下，原型和最小可行產(chǎn)品的異同。敏捷中的最小可行產(chǎn)品是真產(chǎn)品（只做優(yōu)先級高的功能），設(shè)計沖刺里的原型可以是“假的”。

如果覺得文章還可以ヽ(^?^)?，記得點贊關(guān)注我呀！