@SparkYu(喻志堅 招行 項目經(jīng)理)：敏捷怎燥、精益有什么區(qū)別？

@何紅旗[hktxcn.com]（何紅旗-匯科天下-產(chǎn)品）：講當敏捷和精益吧锯仪，看大家講的多是敏捷，有提精益的皮迟，但我不是太理解兩者之間的關系和區(qū)別

答：先說一個事實：敏捷早期受到了精益思想的一些影響，比如Scrum和XP的發(fā)明人都聲稱受到精益思想的啟發(fā)桑寨，但這些影響不是根本性的伏尼。早年提敏捷時，較少說到精益尉尾。不過最近3爆阶，5年情況變了，好像只說敏捷沙咏，不帶上精益就一點也不酷糊治。

兩者中柬讨，敏捷更容易理解芬失。敏捷就是敏捷（able to move quickly and easily）巍虫。具體到產(chǎn)品開發(fā)就是：“更早的交付價值，更靈活的應對變化”吆豹，這是一個目標鱼的，也是一個能力要求。至于各種實踐痘煤，其實都是為這一目標服務的凑阶。比如Scrum是管理迭代交付過程的一個框架，有人可能說不是衷快，說Scrum還是一個持續(xù)改進的框架宙橱，但持續(xù)改進不也是為了價值交付嗎？TDD蘸拔，持續(xù)集成等實踐都是服務于這個目標师郑。

精益的目標也不復雜，消除價值交付過程中的浪費都伪，交付更多有用的價值呕乎。它最核心的就是兩個字“價值”，體現(xiàn)到產(chǎn)品開發(fā)中就是要“順暢陨晶，高質(zhì)量地交付有用的價值”，就目標本身而言帝璧，如果順暢先誉，你自然就是敏捷的，精益是涵蓋了敏捷的的烁，但不能因此就說精益更牛褐耳，畢竟說大目標誰不會啊。精益的核心還是為了實現(xiàn)這一目標背后的方法學支持渴庆。方法學我沒辦法展開來講铃芦，好在雅镊，我有一篇完整的文章說了，也做過一次線上分享刃滓。大家可以參考仁烹。在我的公號（LeanAction）中回復“精益思想”可以找到這篇文章。

那為什么精益這兩年提得特別多呢咧虎，我看到三個原因卓缰。

第一： 產(chǎn)品交付的要求越來越高了。如果只是開發(fā)階段的迭代根本不能做到交付真正的價值砰诵。這時原先適應小團隊和交付階段的Scrum征唬，XP方法搞不定了。我們需要打通組織的整個價值鏈茁彭，做到所謂前后的真正拉通总寒，規(guī)模和關聯(lián)復雜時還要融合左右，目標只有一個——快速的交付價值或驗證設想理肺。今天幾乎所有的大規(guī)模敏捷框架（比如SAFe偿乖，LeSS）都會把精益思想和實踐作為基礎，背后就是這個道理哲嘲。順便說一句贪薪，我個人是不支持任何大規(guī)模敏捷框架的，包括眠副。

第二：創(chuàng)新的要求越來越高了画切。敏捷宣言里說，我們要響應變化囱怕。Scrum和XP的實踐也是這么做了霍弹。但今天互聯(lián)網(wǎng)時代，要求變得更高了娃弓。響應變化這個詞其實顯得有點被動典格，它暗含了一個假設，就是有人會告訴你改變了台丛，該怎么變耍缴。然而，今天這不是事實了挽霉。團隊需要刻意的有計劃的去探索防嗡、去尋求變化，甚至試錯這個詞都不能表達背后的意義侠坎，應該是目標驅動地蚁趁、系統(tǒng)和高效試錯。唯有這樣才能交付出有用的東西实胸。在這一背景先產(chǎn)生了精益創(chuàng)業(yè)的方法他嫡，精益創(chuàng)業(yè)事實上是精益思想番官，在產(chǎn)品創(chuàng)新（而不僅僅是創(chuàng)業(yè)）過程的應用。這個和精益思想有什么聯(lián)系我就不展開了钢属，Eric Ries在《精益創(chuàng)業(yè)》中有很好的闡述徘熔。

第三：敏捷的落地和變革非常困難。定義一個理想的模式是容易的署咽，了解現(xiàn)狀要難一些近顷，但也還好。最困難的是宁否，如何從現(xiàn)狀到達理想的目標窒升。精益方法為此提供了方法學和實踐的支持。我在書的第19章慕匠，就專門闡述了這一點饱须。我講了怎么化解資源效率和流動效率的悖論，并以流動效率為核心來組織團隊的改進過程台谊。這背后其實就是精益的改進思路和實踐蓉媳。

總結一下：

第一：敏捷作為一個目標，就是更早交付和靈活的響應變化锅铅。它特別重要酪呻，但不代表產(chǎn)品交付的全部。

第二：精益強調(diào)是順暢和高質(zhì)量的交付盐须，以及交付的是真正的價值玩荠。

第三：精益作為一個工具，應該主導精益和敏捷的實施贼邓。畢竟創(chuàng)新和價值交付是產(chǎn)品開發(fā)組織存在的理由阶冈。我們應該回到這個根本上來。

不過塑径，很多時候精益和敏捷一般是混著用的女坑，這沒關系。重要的是统舀，你應該合理應用敏捷的實踐匆骗，并掌握精益這個強大的工具，實現(xiàn)真正的精益和敏捷的目標——順暢（包含靈活）和高質(zhì)量的交付真正的價值绑咱，有力支持業(yè)務的成功绰筛。

@Charles(charles+我愛卡+ 技術經(jīng)理)敏捷和持續(xù)交付的關系講講

敏捷是一個目標，也是一個能力要求描融，而持續(xù)交付是這個能力的最核心部分，是集成和標志衡蚂，具備持續(xù)交付能力窿克，其它能力估計問題也不大骏庸。

Jez Humble 給持續(xù)交付的定義是：以可持續(xù)的方式將各類變更（包括新功能、缺陷修復年叮、配置變化具被、實驗等）安全、快速地落實到生產(chǎn)環(huán)境或用戶手中的能力只损。

按這個定義一姿，持續(xù)交付不就是敏捷響應的能力嗎？不過跃惫，持續(xù)交付從字面意義上叮叹，偏向工程實踐，特別是軟件構建和部署的Pipeline爆存，但它也應該包含組織和管理實踐蛉顽。

其實今天，敏捷先较、持續(xù)交付携冤、DevOps、精益（產(chǎn)品開發(fā)）是近義詞闲勺，每個社區(qū)也都在努力擴展自己的外延曾棕，都在拉近自己和業(yè)務以及創(chuàng)新的關系，最后也就殊途同歸了菜循。

另外翘地，持續(xù)交付這個詞，我蠻喜歡的债朵，它指向明確子眶，又有撬動作用。DevOps就不那么明確序芦。但模糊性反而DevOps有更大的想象空間臭杰，搞得朋友多多的，誰都為它站臺谚中，特別是云計算廠商渴杆，都號稱自己是DevOps 的enabler。這樣也不錯宪塔，眾人拾柴火焰高嗎磁奖。

@飛翔的心(楊亮+尚科+sm): 進行scrum開發(fā)，如果提升團隊的需求拆解能力某筐？

@梅（梅寶強+北森+架構師）：產(chǎn)品大特性如果需要跨sprint時比搭，是否需要拆分成小故事？如何評估和衡量

答：大特性的分解是必要的南誊，因為這樣才能1）更早和更靈活地交付身诺；2）更早的發(fā)現(xiàn)風險蜜托；3）方便計劃安排

拆分有三個基本要求，1）要足夠小霉赡，從迭代的角度橄务，至少要能很容易的放入一個迭代，理想情況下一個迭代要能做多個需求穴亏；2）拆完的要端到端（有價值蜂挪，能測試，能交付）嗓化；3）拆完后還要能看到整體棠涮。

為了拆而拆而拆，把拆分當成單獨的工作是常見的誤區(qū)蟆湖。拆分應該是需求組織故爵、分析和澄清的副產(chǎn)品，而不是單獨的任務隅津。

具體到實踐诬垂，故事地圖和實例化需求這兩個實踐很有用。其中故事地圖是為了按業(yè)務場景來組織和規(guī)劃需求伦仍。實例化需求的目的是有效地分析和澄清需求结窘，過去OOA(面向對象分析)所解決的問題，實例化需求當中也會體現(xiàn)充蓝，只不過更適合迭代或持續(xù)的交付隧枫。實例化需求，我實施的時候覺得是個比較容易的實踐谓苟，也能解決上面的問題官脓。但是現(xiàn)實中做好的團隊的確不多，等我有時間應該好好總結一下才對涝焙。

@小魚（匯合發(fā)展-余曉蒨（軟件開發(fā)部門經(jīng)理））：如何讓非IT人員理解敏捷卑笨，然后可以一起參與推動敏捷的實施和改善？

答：敏捷作為一個目標（快速仑撞、靈活的交付）本來就是業(yè)務的目標赤兴，而IT人員要做的是建立起實現(xiàn)這一目標的能力，我們稱之為IT的敏捷交付能力隧哮。

這是前提桶良，那怎么讓非IT的人員理解敏捷呢。那就是要回到業(yè)務本省沮翔，談靈活交付陨帆，談端到端的價值交付，談交付真實的價值。這些背后往往包含精益的思想歧譬，這部分解釋了為什么最近兩年岸浑，突然談敏捷時搏存，必有精益瑰步。

@天外來客（金毅，光環(huán)國際璧眠，敏捷咨詢顧問）：WIP經(jīng)驗值與案例

答：我在書中用了三個章節(jié)和大量的案例談WIP這件事缩焦，也給出了相應的經(jīng)驗和方法。

對這個問題责静，我在實施中很少會糾結袁滥。而那些糾結WIP應該是幾的團隊，往往還有更基礎的問題需要解決灾螃。那就是要圍繞價值組織團隊的協(xié)作和交付题翻，打通和可視化端到端的價值交付流程。有了這個基礎腰鬼，你會發(fā)現(xiàn)WIP的設置和貫徹難度會極大的降低嵌赠。專注于已經(jīng)開始的價值，快速完成它們熄赡，難道不是很自然的事嗎姜挺？

如果團隊看到的只是任務，這時要求設置WIP限制彼硫，就會很不容易接受炊豪，達到的實際業(yè)務效果也不直接，推廣起來當然難拧篮。

@追夢(追夢 聯(lián)想 研發(fā))：我想了解的是：敏捷開發(fā)流程的前提是團隊都需要具備敏捷思維词渤，那么如何帶動團隊快速敏捷起來呢？

答：什么是敏捷思維串绩？憑什么你的思維是敏捷的缺虐，而我的不是呢？這是我們應該思考的赏参。

我不認為敏捷思維的說法是錯的志笼，但現(xiàn)實中鼓吹敏捷思維，效果的確不好把篓。這你也看到了纫溃。作為個人應該有敏捷思維（不管這種思維是尊重人也好，適應性或成長思維也罷）韧掩，但回到執(zhí)行層面卻不能要求別人有自己所為的“敏捷思維”紊浩，更不能以此占據(jù)道德高點。

我們需要的價值思維和目標思維，而把敏捷看成實現(xiàn)目標的方法坊谁。所以费彼，第一步應該達成共識的是，我們作為一個組織應該如何交付價值口芍，我們對外的目標是什么箍铲，需要什么樣的能力。而后才是需要是是什么樣的敏捷方法鬓椭，來幫助我們建設這一能力颠猴，和實現(xiàn)目標。

組織存在一定是對外交付價值小染，靈活的交付價值翘瓮，這一點是沒有異議的。從這個基礎出發(fā)裤翩，我們就有機會構建好基本的共識和選擇正確的方法资盅。這也是為什么我在書中，強調(diào)最多的兩個字是“價值”踊赠，而后再強調(diào)“價值的流動”呵扛。我強調(diào)的還不夠的是“有用的價值”，這是我后面要做的臼疫。

@小樓聽雨(段智鋒-品騰貿(mào)易-產(chǎn)品總監(jiān))：我想問一下择份，PMP項目管理和敏捷管理有啥區(qū)別？敏捷方法迭代速度快烫堤，在有限的時間和資源下荣赶，如何快速實現(xiàn)功能開發(fā)交付？用PMP方法管理團隊和利用敏捷管理項目團隊鸽斟，各有啥優(yōu)缺點拔创？

答：我個人做項目經(jīng)理很多年，PMP有它的價值富蓄，從PMP知識體系中我獲益不少剩燥。但PMP的知識體系是不敏捷的，即使今天有ACP也改變不了這個事實立倍。因為 “項目”這兩個字就決定了它的屬性灭红，項目創(chuàng)造了批量、創(chuàng)造的節(jié)點口注。批量本身就和敏捷交付是背道而馳的变擒。敏捷交付需要更多的是產(chǎn)品思維，實現(xiàn)產(chǎn)品的持續(xù)交付寝志、持續(xù)反饋娇斑、持續(xù)運營和持續(xù)調(diào)整策添。

在敏捷交付中，我們需要弱化項目思維毫缆，而增加產(chǎn)品和價值思維唯竹。弱化批量化的階段實踐，而建設持續(xù)交付和反饋的能力苦丁。

另外浸颓，在需要大量同步、協(xié)調(diào)和決策評審的實施類項目中芬骄，PMP知識體系及實踐框架會繼續(xù)存在且發(fā)揮作用猾愿。

@大宇(大宇，聯(lián)想中國账阻，PCSD高級架構師)：請問，非互聯(lián)網(wǎng)團隊如何轉型敏捷開發(fā)泽本，團隊成員應該如何培養(yǎng)敏捷開發(fā)的能力淘太，另外，如何讓產(chǎn)品->開發(fā)->QA->運維能合理配合從而實現(xiàn)整體敏捷规丽？另外產(chǎn)品如何拆分story蒲牧，這是我們最頭疼的問題，有沒有什么最佳工程實踐赌莺。

答：這個問題非常大冰抢。我覺得從理清價值流，可視化價值流開始吧艘狭。關于故事拆分挎扰，我前面講過，還是要有好的需求實踐吧巢音，比如故事地圖和實例化需求遵倦。

@大宇(吉巧云-日本IBM-IT specialist)：敏捷開始的結束時間是固定的、而開發(fā)對象可以允許變更和追加的官撼、如何在遵守時間的前提下對待式樣變更梧躺。有沒有什么實踐經(jīng)驗上的注意點可以分享。

答：固定時間盒不是敏捷的必然實踐傲绣，它只是Scrum的實踐掠哥，在Scrum框架中有它的道理。要注意的點是秃诵，

1. 拆分需求续搀，但不要為了拆分而拆分，比如通過實例化需求把需求拆分成端到端的小需求顷链。這樣才有安排和變更的靈活性目代。

2. 不要把Sprint做成小瀑布了屈梁，一旦做成小瀑布，所有的需求同時開始了榛了，變更起來就不太可能了在讶。而且最后往往會守不住時間，或因為時間而犧牲質(zhì)量霜大。

@Howe(趙豪-愛客仕-項目)：如何讓團隊自构哺，主并且及時在看板上更新狀態(tài)

答：通常，這個首先是看板設計的問題战坤，看板設計合理曙强，運作沒大毛病，更新狀態(tài)不應該是問題途茫。

@宏利(張宏利+競技世界+項目經(jīng)理)：我想問的是碟嘴，如何能調(diào)動研發(fā)人員的敏捷積極性，每天晨會項目經(jīng)理對于未完成的內(nèi)容如何更好的處理

答：關于積極性囊卜，我在書中第22章有詳細的討論娜扇。

@ 陳嬌智????(陳嬌智＋金蝶＋部門經(jīng)理)：項目進度推進一拖再拖，每個階段都有無數(shù)不同問題栅组，如果確保項目質(zhì)量和進度并存問題雀瓢？

關于質(zhì)量：以需求為粒度控制質(zhì)量，實現(xiàn)單個需求的持續(xù)流動玉掸，而不是以迭代或項目為粒度控制時間點刃麸。我在第21章有詳細的討論。進度問題其實也是相關的司浪，實現(xiàn)需求的持續(xù)流動泊业，而弱化項目的階段，在需求上內(nèi)建質(zhì)量断傲，就不存在每個階段無數(shù)問題這一說了脱吱。這一點招商銀行的項目管理是典范，做得非常好认罩。

@琪琪(戰(zhàn)文琪-廣聯(lián)達-研發(fā)經(jīng)理)：大項目做敏捷箱蝠、持續(xù)集成，過程中專項或集成的工作并行太多垦垂，導致團隊同時在運轉的事項比較多宦搬，狀態(tài)切換或專項轉換混輪，怎么處理解決這種狀態(tài)的混亂劫拗，或者怎么提高大項目管理中多項事情并行的效率

答：操作上兩個方面间校。第一：合理規(guī)劃，理清輸入页慷。這是源頭憔足。第二：在第一點的基礎上胁附，限制在制品。我不了解你的上下文滓彰，但可能還有兩個更基礎的問題：第一：組織結構的合理性控妻，是否與交付的需要適配；第二：技術實踐的到位程度揭绑，比如有很多手工集成的工作弓候，可能意味著需要劃分的合理性，或持續(xù)集成實踐的到位程度他匪。

@Apricotone(林天金+翼支付+項目經(jīng)理)：作為精益敏捷項目經(jīng)理菇存，在新立項目/項目中期兩個不同階段進入項目，如何去推動在項目中實施精益敏捷邦蜜。

答：立項階段依鸥，關鍵是理清需求，和需求規(guī)劃畦徘，這是一個很好的切入點毕籽，雖然不是唯一的。參見書的第20章井辆。

項目中期，就不好回答了溶握，要看具體情況杯缺。還是一解決和理清問題和交付為主。

@張麗華：互聯(lián)網(wǎng)醫(yī)療項目睡榆，包含軟件和硬件萍肆，按照傳統(tǒng)的項目管控，對需求和進度的管控太死板胀屿，使用敏捷又避免不了需求變化帶來的返工或開發(fā)功能棄用塘揣。如何更好管控項目進度和需求？如何提高團隊效率宿崭？

答：需要太多的上下文亲铡，無法給出肯定的回答。一個可能的建議葡兑，嘗試家里故事地圖奖蔓，來理清需求的關聯(lián)和規(guī)劃，包括硬件的計劃讹堤。再用看板來管理需求的流動吆鹤。這只是可能嘗試的方向，具體問題需要具體對待洲守。

@黃成東(黃成東疑务、PM沾凄、麥子金服)：敏捷管理除了形式之外，在項目整個生命周期中知允，要注意哪些細節(jié)撒蟀，如何實施？

答：敏捷的最終目標是弱化項目生命周期廊镜，實現(xiàn)持續(xù)產(chǎn)品交付牙肝。

@滿江紅(江曉紅-隨行付-開發(fā)經(jīng)理): 梳理用戶故事地圖，如果即想按角色分類嗤朴，又想按迭代劃分配椭，如何呈現(xiàn)到地圖上，有沒有好的實例

答：看來你已經(jīng)實踐的比較深入了雹姊。這兩個本來就有一些沖突股缸。我個人的觀點，按角色分是為了挖掘和過濾需求吱雏，到規(guī)劃的時候敦姻，就不要強求按角色來規(guī)劃迭代了。規(guī)劃的時候應該按業(yè)務目標（優(yōu)先）和場景來規(guī)劃歧杏，如果正好能匹配角色镰惦，那是件好事，匹配不上不要強求犬绒。

@Robin Lu（陸萍十中興通訊十過程改進專家）在敏捷產(chǎn)品開發(fā)中如何發(fā)揮系統(tǒng)架構師的作用?有哪些推薦書?

答：我不是架構專家旺入。只能從敏捷實施的角度來談一談。架構有很多類型凯力，比如應用架構茵瘾，系統(tǒng)架構和軟件架構。我講的偏向系統(tǒng)和軟件架構咐鹤。

首先架構是什么拗秘，這個就有就有很多說法，比如比較常見的定義是：軟件系統(tǒng)的高層結構祈惶，以及決定這一結構的相關原則雕旨。我個人比較喜歡采納的定義是：架構是軟件設計中重要的決策，“重要”是根據(jù)后悔成本來衡量的行瑞。

根據(jù)這一定義奸腺，之所以頂層結構屬于架構，是因為它一旦定下來血久，后面再發(fā)現(xiàn)問題要變更成本就會比較難（成本較高）突照。按照這一定義，同樣選取何種編程語言氧吐，對大部分系統(tǒng)就是架構的一部分了讹蘑，屬于架構決策末盔。

在敏捷開發(fā)中，架構的一個重要目的是降低后面變更的成本座慰，支持產(chǎn)品的演進陨舱。在敏捷開發(fā)對架構提出了更高的要求，架構要更靈活版仔，更具演進能力游盲，降低決策的后悔成本，支持演進式的設計和交付蛮粮。DDD和微服務都在解決這樣的問題益缎，“演進式設計”作為一個主題，也是在討論這個問題然想。這對架構師的能力或團隊的整體架構能力要求肯定是提高了莺奔。

總體而言，架構中所謂頂層結構的部分在減少变泄，架構持續(xù)演進的要求在增加令哟。DDD應該成為系統(tǒng)架構師的基本能力，而在結合今天的云和運維的生態(tài)妨蛹，微服務方面的知識（包括運維屏富、部署）也變得必不可少。

書籍我就不做具體的推薦了蛙卤，畢竟我不是專家役听。DDD和微服務架構的能力肯定是要建立的，也有很多經(jīng)典的書籍表窘。