@SparkYu(喻志堅(jiān) 招行 項(xiàng)目經(jīng)理)：敏捷、精益有什么區(qū)別？
@何紅旗[hktxcn.com]（何紅旗-匯科天下-產(chǎn)品）：講當(dāng)敏捷和精益吧，看大家講的多是敏捷，有提精益的，但我不是太理解兩者之間的關(guān)系和區(qū)別
答：先說一個(gè)事實(shí)：敏捷早期受到了精益思想的一些影響，比如Scrum和XP的發(fā)明人都聲稱受到精益思想的啟發(fā)，但這些影響不是根本性的。早年提敏捷時(shí)，較少說到精益。不過最近3，5年情況變了，好像只說敏捷，不帶上精益就一點(diǎn)也不酷。
兩者中，敏捷更容易理解。敏捷就是敏捷（able to move quickly and easily）。具體到產(chǎn)品開發(fā)就是：“更早的交付價(jià)值，更靈活的應(yīng)對變化”，這是一個(gè)目標(biāo)，也是一個(gè)能力要求。至于各種實(shí)踐，其實(shí)都是為這一目標(biāo)服務(wù)的。比如Scrum是管理迭代交付過程的一個(gè)框架，有人可能說不是，說Scrum還是一個(gè)持續(xù)改進(jìn)的框架，但持續(xù)改進(jìn)不也是為了價(jià)值交付嗎？TDD，持續(xù)集成等實(shí)踐都是服務(wù)于這個(gè)目標(biāo)。
精益的目標(biāo)也不復(fù)雜，消除價(jià)值交付過程中的浪費(fèi)，交付更多有用的價(jià)值。它最核心的就是兩個(gè)字“價(jià)值”，體現(xiàn)到產(chǎn)品開發(fā)中就是要“順暢，高質(zhì)量地交付有用的價(jià)值”，就目標(biāo)本身而言，如果順暢，你自然就是敏捷的，精益是涵蓋了敏捷的，但不能因此就說精益更牛，畢竟說大目標(biāo)誰不會啊。精益的核心還是為了實(shí)現(xiàn)這一目標(biāo)背后的方法學(xué)支持。方法學(xué)我沒辦法展開來講，好在，我有一篇完整的文章說了，也做過一次線上分享。大家可以參考。在我的公號（LeanAction）中回復(fù)“精益思想”可以找到這篇文章。
那為什么精益這兩年提得特別多呢，我看到三個(gè)原因。
第一： 產(chǎn)品交付的要求越來越高了。如果只是開發(fā)階段的迭代根本不能做到交付真正的價(jià)值。這時(shí)原先適應(yīng)小團(tuán)隊(duì)和交付階段的Scrum，XP方法搞不定了。我們需要打通組織的整個(gè)價(jià)值鏈，做到所謂前后的真正拉通，規(guī)模和關(guān)聯(lián)復(fù)雜時(shí)還要融合左右，目標(biāo)只有一個(gè)——快速的交付價(jià)值或驗(yàn)證設(shè)想。今天幾乎所有的大規(guī)模敏捷框架（比如SAFe，LeSS）都會把精益思想和實(shí)踐作為基礎(chǔ)，背后就是這個(gè)道理。順便說一句，我個(gè)人是不支持任何大規(guī)模敏捷框架的，包括。
第二：創(chuàng)新的要求越來越高了。敏捷宣言里說，我們要響應(yīng)變化。Scrum和XP的實(shí)踐也是這么做了。但今天互聯(lián)網(wǎng)時(shí)代，要求變得更高了。響應(yīng)變化這個(gè)詞其實(shí)顯得有點(diǎn)被動，它暗含了一個(gè)假設(shè)，就是有人會告訴你改變了，該怎么變。然而，今天這不是事實(shí)了。團(tuán)隊(duì)需要刻意的有計(jì)劃的去探索、去尋求變化，甚至試錯(cuò)這個(gè)詞都不能表達(dá)背后的意義，應(yīng)該是目標(biāo)驅(qū)動地、系統(tǒng)和高效試錯(cuò)。唯有這樣才能交付出有用的東西。在這一背景先產(chǎn)生了精益創(chuàng)業(yè)的方法，精益創(chuàng)業(yè)事實(shí)上是精益思想，在產(chǎn)品創(chuàng)新（而不僅僅是創(chuàng)業(yè)）過程的應(yīng)用。這個(gè)和精益思想有什么聯(lián)系我就不展開了，Eric Ries在《精益創(chuàng)業(yè)》中有很好的闡述。
第三：敏捷的落地和變革非常困難。定義一個(gè)理想的模式是容易的，了解現(xiàn)狀要難一些，但也還好。最困難的是，如何從現(xiàn)狀到達(dá)理想的目標(biāo)。精益方法為此提供了方法學(xué)和實(shí)踐的支持。我在書的第19章，就專門闡述了這一點(diǎn)。我講了怎么化解資源效率和流動效率的悖論，并以流動效率為核心來組織團(tuán)隊(duì)的改進(jìn)過程。這背后其實(shí)就是精益的改進(jìn)思路和實(shí)踐。
總結(jié)一下：
第一：敏捷作為一個(gè)目標(biāo)，就是更早交付和靈活的響應(yīng)變化。它特別重要，但不代表產(chǎn)品交付的全部。
第二：精益強(qiáng)調(diào)是順暢和高質(zhì)量的交付，以及交付的是真正的價(jià)值。
第三：精益作為一個(gè)工具，應(yīng)該主導(dǎo)精益和敏捷的實(shí)施。畢竟創(chuàng)新和價(jià)值交付是產(chǎn)品開發(fā)組織存在的理由。我們應(yīng)該回到這個(gè)根本上來。
不過，很多時(shí)候精益和敏捷一般是混著用的，這沒關(guān)系。重要的是，你應(yīng)該合理應(yīng)用敏捷的實(shí)踐，并掌握精益這個(gè)強(qiáng)大的工具，實(shí)現(xiàn)真正的精益和敏捷的目標(biāo)——順暢（包含靈活）和高質(zhì)量的交付真正的價(jià)值，有力支持業(yè)務(wù)的成功。
@Charles(charles+我愛卡+ 技術(shù)經(jīng)理)敏捷和持續(xù)交付的關(guān)系講講
敏捷是一個(gè)目標(biāo)，也是一個(gè)能力要求，而持續(xù)交付是這個(gè)能力的最核心部分，是集成和標(biāo)志，具備持續(xù)交付能力，其它能力估計(jì)問題也不大。
Jez Humble 給持續(xù)交付的定義是：以可持續(xù)的方式將各類變更（包括新功能、缺陷修復(fù)、配置變化、實(shí)驗(yàn)等）安全、快速地落實(shí)到生產(chǎn)環(huán)境或用戶手中的能力。
按這個(gè)定義，持續(xù)交付不就是敏捷響應(yīng)的能力嗎？不過，持續(xù)交付從字面意義上，偏向工程實(shí)踐，特別是軟件構(gòu)建和部署的Pipeline，但它也應(yīng)該包含組織和管理實(shí)踐。
其實(shí)今天，敏捷、持續(xù)交付、DevOps、精益（產(chǎn)品開發(fā)）是近義詞，每個(gè)社區(qū)也都在努力擴(kuò)展自己的外延，都在拉近自己和業(yè)務(wù)以及創(chuàng)新的關(guān)系，最后也就殊途同歸了。
另外，持續(xù)交付這個(gè)詞，我蠻喜歡的，它指向明確，又有撬動作用。DevOps就不那么明確。但模糊性反而DevOps有更大的想象空間，搞得朋友多多的，誰都為它站臺，特別是云計(jì)算廠商，都號稱自己是DevOps 的enabler。這樣也不錯(cuò)，眾人拾柴火焰高嗎。
@飛翔的心(楊亮+尚科+sm): 進(jìn)行scrum開發(fā)，如果提升團(tuán)隊(duì)的需求拆解能力？
@梅（梅寶強(qiáng)+北森+架構(gòu)師）：產(chǎn)品大特性如果需要跨sprint時(shí)，是否需要拆分成小故事？如何評估和衡量
答：大特性的分解是必要的，因?yàn)檫@樣才能1）更早和更靈活地交付；2）更早的發(fā)現(xiàn)風(fēng)險(xiǎn)；3）方便計(jì)劃安排
拆分有三個(gè)基本要求，1）要足夠小，從迭代的角度，至少要能很容易的放入一個(gè)迭代，理想情況下一個(gè)迭代要能做多個(gè)需求；2）拆完的要端到端（有價(jià)值，能測試，能交付）；3）拆完后還要能看到整體。
為了拆而拆而拆，把拆分當(dāng)成單獨(dú)的工作是常見的誤區(qū)。拆分應(yīng)該是需求組織、分析和澄清的副產(chǎn)品，而不是單獨(dú)的任務(wù)。
具體到實(shí)踐，故事地圖和實(shí)例化需求這兩個(gè)實(shí)踐很有用。其中故事地圖是為了按業(yè)務(wù)場景來組織和規(guī)劃需求。實(shí)例化需求的目的是有效地分析和澄清需求，過去OOA(面向?qū)ο蠓治?所解決的問題，實(shí)例化需求當(dāng)中也會體現(xiàn)，只不過更適合迭代或持續(xù)的交付。實(shí)例化需求，我實(shí)施的時(shí)候覺得是個(gè)比較容易的實(shí)踐，也能解決上面的問題。但是現(xiàn)實(shí)中做好的團(tuán)隊(duì)的確不多，等我有時(shí)間應(yīng)該好好總結(jié)一下才對。
@小魚（匯合發(fā)展-余曉蒨（軟件開發(fā)部門經(jīng)理））：如何讓非IT人員理解敏捷，然后可以一起參與推動敏捷的實(shí)施和改善？
答：敏捷作為一個(gè)目標(biāo)（快速、靈活的交付）本來就是業(yè)務(wù)的目標(biāo)，而IT人員要做的是建立起實(shí)現(xiàn)這一目標(biāo)的能力，我們稱之為IT的敏捷交付能力。
這是前提，那怎么讓非IT的人員理解敏捷呢。那就是要回到業(yè)務(wù)本省，談靈活交付，談端到端的價(jià)值交付，談交付真實(shí)的價(jià)值。這些背后往往包含精益的思想，這部分解釋了為什么最近兩年，突然談敏捷時(shí)，必有精益。
@天外來客（金毅，光環(huán)國際，敏捷咨詢顧問）：WIP經(jīng)驗(yàn)值與案例
答：我在書中用了三個(gè)章節(jié)和大量的案例談WIP這件事，也給出了相應(yīng)的經(jīng)驗(yàn)和方法。
對這個(gè)問題，我在實(shí)施中很少會糾結(jié)。而那些糾結(jié)WIP應(yīng)該是幾的團(tuán)隊(duì)，往往還有更基礎(chǔ)的問題需要解決。那就是要圍繞價(jià)值組織團(tuán)隊(duì)的協(xié)作和交付，打通和可視化端到端的價(jià)值交付流程。有了這個(gè)基礎(chǔ)，你會發(fā)現(xiàn)WIP的設(shè)置和貫徹難度會極大的降低。專注于已經(jīng)開始的價(jià)值，快速完成它們，難道不是很自然的事嗎？
如果團(tuán)隊(duì)看到的只是任務(wù)，這時(shí)要求設(shè)置WIP限制，就會很不容易接受，達(dá)到的實(shí)際業(yè)務(wù)效果也不直接，推廣起來當(dāng)然難。
@追夢(追夢 聯(lián)想 研發(fā))：我想了解的是：敏捷開發(fā)流程的前提是團(tuán)隊(duì)都需要具備敏捷思維，那么如何帶動團(tuán)隊(duì)快速敏捷起來呢？
答：什么是敏捷思維？憑什么你的思維是敏捷的，而我的不是呢？這是我們應(yīng)該思考的。
我不認(rèn)為敏捷思維的說法是錯(cuò)的，但現(xiàn)實(shí)中鼓吹敏捷思維，效果的確不好。這你也看到了。作為個(gè)人應(yīng)該有敏捷思維（不管這種思維是尊重人也好，適應(yīng)性或成長思維也罷），但回到執(zhí)行層面卻不能要求別人有自己所為的“敏捷思維”，更不能以此占據(jù)道德高點(diǎn)。
我們需要的價(jià)值思維和目標(biāo)思維，而把敏捷看成實(shí)現(xiàn)目標(biāo)的方法。所以，第一步應(yīng)該達(dá)成共識的是，我們作為一個(gè)組織應(yīng)該如何交付價(jià)值，我們對外的目標(biāo)是什么，需要什么樣的能力。而后才是需要是是什么樣的敏捷方法，來幫助我們建設(shè)這一能力，和實(shí)現(xiàn)目標(biāo)。
組織存在一定是對外交付價(jià)值，靈活的交付價(jià)值，這一點(diǎn)是沒有異議的。從這個(gè)基礎(chǔ)出發(fā)，我們就有機(jī)會構(gòu)建好基本的共識和選擇正確的方法。這也是為什么我在書中，強(qiáng)調(diào)最多的兩個(gè)字是“價(jià)值”，而后再強(qiáng)調(diào)“價(jià)值的流動”。我強(qiáng)調(diào)的還不夠的是“有用的價(jià)值”，這是我后面要做的。
@小樓聽雨(段智鋒-品騰貿(mào)易-產(chǎn)品總監(jiān))：我想問一下，PMP項(xiàng)目管理和敏捷管理有啥區(qū)別？敏捷方法迭代速度快，在有限的時(shí)間和資源下，如何快速實(shí)現(xiàn)功能開發(fā)交付？用PMP方法管理團(tuán)隊(duì)和利用敏捷管理項(xiàng)目團(tuán)隊(duì)，各有啥優(yōu)缺點(diǎn)？
答：我個(gè)人做項(xiàng)目經(jīng)理很多年，PMP有它的價(jià)值，從PMP知識體系中我獲益不少。但PMP的知識體系是不敏捷的，即使今天有ACP也改變不了這個(gè)事實(shí)。因?yàn)?“項(xiàng)目”這兩個(gè)字就決定了它的屬性，項(xiàng)目創(chuàng)造了批量、創(chuàng)造的節(jié)點(diǎn)。批量本身就和敏捷交付是背道而馳的。敏捷交付需要更多的是產(chǎn)品思維，實(shí)現(xiàn)產(chǎn)品的持續(xù)交付、持續(xù)反饋、持續(xù)運(yùn)營和持續(xù)調(diào)整。
在敏捷交付中，我們需要弱化項(xiàng)目思維，而增加產(chǎn)品和價(jià)值思維。弱化批量化的階段實(shí)踐，而建設(shè)持續(xù)交付和反饋的能力。
另外，在需要大量同步、協(xié)調(diào)和決策評審的實(shí)施類項(xiàng)目中，PMP知識體系及實(shí)踐框架會繼續(xù)存在且發(fā)揮作用。
@大宇(大宇，聯(lián)想中國，PCSD高級架構(gòu)師)：請問，非互聯(lián)網(wǎng)團(tuán)隊(duì)如何轉(zhuǎn)型敏捷開發(fā)，團(tuán)隊(duì)成員應(yīng)該如何培養(yǎng)敏捷開發(fā)的能力，另外，如何讓產(chǎn)品->開發(fā)->QA->運(yùn)維能合理配合從而實(shí)現(xiàn)整體敏捷？另外產(chǎn)品如何拆分story，這是我們最頭疼的問題，有沒有什么最佳工程實(shí)踐。
答：這個(gè)問題非常大。我覺得從理清價(jià)值流，可視化價(jià)值流開始吧。關(guān)于故事拆分，我前面講過，還是要有好的需求實(shí)踐吧，比如故事地圖和實(shí)例化需求。
@大宇(吉巧云-日本IBM-IT specialist)：敏捷開始的結(jié)束時(shí)間是固定的、而開發(fā)對象可以允許變更和追加的、如何在遵守時(shí)間的前提下對待式樣變更。有沒有什么實(shí)踐經(jīng)驗(yàn)上的注意點(diǎn)可以分享。
答：固定時(shí)間盒不是敏捷的必然實(shí)踐，它只是Scrum的實(shí)踐，在Scrum框架中有它的道理。要注意的點(diǎn)是，
1. 拆分需求，但不要為了拆分而拆分，比如通過實(shí)例化需求把需求拆分成端到端的小需求。這樣才有安排和變更的靈活性。
2. 不要把Sprint做成小瀑布了，一旦做成小瀑布，所有的需求同時(shí)開始了，變更起來就不太可能了。而且最后往往會守不住時(shí)間，或因?yàn)闀r(shí)間而犧牲質(zhì)量。
@Howe(趙豪-愛客仕-項(xiàng)目)：如何讓團(tuán)隊(duì)自，主并且及時(shí)在看板上更新狀態(tài)
答：通常，這個(gè)首先是看板設(shè)計(jì)的問題，看板設(shè)計(jì)合理，運(yùn)作沒大毛病，更新狀態(tài)不應(yīng)該是問題。
@宏利(張宏利+競技世界+項(xiàng)目經(jīng)理)：我想問的是，如何能調(diào)動研發(fā)人員的敏捷積極性，每天晨會項(xiàng)目經(jīng)理對于未完成的內(nèi)容如何更好的處理
答：關(guān)于積極性，我在書中第22章有詳細(xì)的討論。
@ 陳嬌智????(陳嬌智＋金蝶＋部門經(jīng)理)：項(xiàng)目進(jìn)度推進(jìn)一拖再拖，每個(gè)階段都有無數(shù)不同問題，如果確保項(xiàng)目質(zhì)量和進(jìn)度并存問題？
關(guān)于質(zhì)量：以需求為粒度控制質(zhì)量，實(shí)現(xiàn)單個(gè)需求的持續(xù)流動，而不是以迭代或項(xiàng)目為粒度控制時(shí)間點(diǎn)。我在第21章有詳細(xì)的討論。進(jìn)度問題其實(shí)也是相關(guān)的，實(shí)現(xiàn)需求的持續(xù)流動，而弱化項(xiàng)目的階段，在需求上內(nèi)建質(zhì)量，就不存在每個(gè)階段無數(shù)問題這一說了。這一點(diǎn)招商銀行的項(xiàng)目管理是典范，做得非常好。
@琪琪(戰(zhàn)文琪-廣聯(lián)達(dá)-研發(fā)經(jīng)理)：大項(xiàng)目做敏捷、持續(xù)集成，過程中專項(xiàng)或集成的工作并行太多，導(dǎo)致團(tuán)隊(duì)同時(shí)在運(yùn)轉(zhuǎn)的事項(xiàng)比較多，狀態(tài)切換或?qū)ｍ?xiàng)轉(zhuǎn)換混輪，怎么處理解決這種狀態(tài)的混亂，或者怎么提高大項(xiàng)目管理中多項(xiàng)事情并行的效率
答：操作上兩個(gè)方面。第一：合理規(guī)劃，理清輸入。這是源頭。第二：在第一點(diǎn)的基礎(chǔ)上，限制在制品。我不了解你的上下文，但可能還有兩個(gè)更基礎(chǔ)的問題：第一：組織結(jié)構(gòu)的合理性，是否與交付的需要適配；第二：技術(shù)實(shí)踐的到位程度，比如有很多手工集成的工作，可能意味著需要?jiǎng)澐值暮侠硇?，或持續(xù)集成實(shí)踐的到位程度。
@Apricotone(林天金+翼支付+項(xiàng)目經(jīng)理)：作為精益敏捷項(xiàng)目經(jīng)理，在新立項(xiàng)目/項(xiàng)目中期兩個(gè)不同階段進(jìn)入項(xiàng)目，如何去推動在項(xiàng)目中實(shí)施精益敏捷。
答：立項(xiàng)階段，關(guān)鍵是理清需求，和需求規(guī)劃，這是一個(gè)很好的切入點(diǎn)，雖然不是唯一的。參見書的第20章。
項(xiàng)目中期，就不好回答了，要看具體情況。還是一解決和理清問題和交付為主。
@張麗華：互聯(lián)網(wǎng)醫(yī)療項(xiàng)目，包含軟件和硬件，按照傳統(tǒng)的項(xiàng)目管控，對需求和進(jìn)度的管控太死板，使用敏捷又避免不了需求變化帶來的返工或開發(fā)功能棄用。如何更好管控項(xiàng)目進(jìn)度和需求？如何提高團(tuán)隊(duì)效率？
答：需要太多的上下文，無法給出肯定的回答。一個(gè)可能的建議，嘗試家里故事地圖，來理清需求的關(guān)聯(lián)和規(guī)劃，包括硬件的計(jì)劃。再用看板來管理需求的流動。這只是可能嘗試的方向，具體問題需要具體對待。
@黃成東(黃成東、PM、麥子金服)：敏捷管理除了形式之外，在項(xiàng)目整個(gè)生命周期中，要注意哪些細(xì)節(jié)，如何實(shí)施？
答：敏捷的最終目標(biāo)是弱化項(xiàng)目生命周期，實(shí)現(xiàn)持續(xù)產(chǎn)品交付。
@滿江紅(江曉紅-隨行付-開發(fā)經(jīng)理): 梳理用戶故事地圖，如果即想按角色分類，又想按迭代劃分，如何呈現(xiàn)到地圖上，有沒有好的實(shí)例
答：看來你已經(jīng)實(shí)踐的比較深入了。這兩個(gè)本來就有一些沖突。我個(gè)人的觀點(diǎn)，按角色分是為了挖掘和過濾需求，到規(guī)劃的時(shí)候，就不要強(qiáng)求按角色來規(guī)劃迭代了。規(guī)劃的時(shí)候應(yīng)該按業(yè)務(wù)目標(biāo)（優(yōu)先）和場景來規(guī)劃，如果正好能匹配角色，那是件好事，匹配不上不要強(qiáng)求。
@Robin Lu（陸萍十中興通訊十過程改進(jìn)專家）在敏捷產(chǎn)品開發(fā)中如何發(fā)揮系統(tǒng)架構(gòu)師的作用?有哪些推薦書?
答：我不是架構(gòu)專家。只能從敏捷實(shí)施的角度來談一談。架構(gòu)有很多類型，比如應(yīng)用架構(gòu)，系統(tǒng)架構(gòu)和軟件架構(gòu)。我講的偏向系統(tǒng)和軟件架構(gòu)。
首先架構(gòu)是什么，這個(gè)就有就有很多說法，比如比較常見的定義是：軟件系統(tǒng)的高層結(jié)構(gòu)，以及決定這一結(jié)構(gòu)的相關(guān)原則。我個(gè)人比較喜歡采納的定義是：架構(gòu)是軟件設(shè)計(jì)中重要的決策，“重要”是根據(jù)后悔成本來衡量的。
根據(jù)這一定義，之所以頂層結(jié)構(gòu)屬于架構(gòu)，是因?yàn)樗坏┒ㄏ聛?，后面再發(fā)現(xiàn)問題要變更成本就會比較難（成本較高）。按照這一定義，同樣選取何種編程語言，對大部分系統(tǒng)就是架構(gòu)的一部分了，屬于架構(gòu)決策。
在敏捷開發(fā)中，架構(gòu)的一個(gè)重要目的是降低后面變更的成本，支持產(chǎn)品的演進(jìn)。在敏捷開發(fā)對架構(gòu)提出了更高的要求，架構(gòu)要更靈活，更具演進(jìn)能力，降低決策的后悔成本，支持演進(jìn)式的設(shè)計(jì)和交付。DDD和微服務(wù)都在解決這樣的問題，“演進(jìn)式設(shè)計(jì)”作為一個(gè)主題，也是在討論這個(gè)問題。這對架構(gòu)師的能力或團(tuán)隊(duì)的整體架構(gòu)能力要求肯定是提高了。
總體而言，架構(gòu)中所謂頂層結(jié)構(gòu)的部分在減少，架構(gòu)持續(xù)演進(jìn)的要求在增加。DDD應(yīng)該成為系統(tǒng)架構(gòu)師的基本能力，而在結(jié)合今天的云和運(yùn)維的生態(tài)，微服務(wù)方面的知識（包括運(yùn)維、部署）也變得必不可少。
書籍我就不做具體的推薦了，畢竟我不是專家。DDD和微服務(wù)架構(gòu)的能力肯定是要建立的，也有很多經(jīng)典的書籍。
