PART 1
答：製造業部分首先我前面提到了，如果是已經設計好的東西，那麼這部分精益製造有更好的方法，如果是蓋樓，那麼傳統的建築學有更好的方法。那麼它能夠發揮在什麼地方呢？它是發揮在設計階段，剛纔我舉的例子是水泵設計，那麼也就是說製造業的前部分設計的部分，我們現在已經清晰的看到很多的公司是試用實用敏捷，我們最新有個江生自控，是一個世界五百強公司，發佈了相應的報告。他們在江生自控的很多設計環節採用了敏捷方法論，所以這個製造業設計部分是可以的，但製造業本身製造部分用傳統的精益生產更加好。
PART 2
答：不是的，他要求跟最終能夠展現的產物相關，如果是軟件開發的話恰恰不需要文檔產出，恰恰需要可運行的軟件。那麼如果不是軟件開發的話，就跟你自身的工作要出的產物一樣，敏捷不要求額外的產物。敏捷只需要求在每個迭代你原來要做什麼產物就做什麼產物，所以它不會因爲敏捷有額外任何文檔的增加，所以這個文檔整理的工作量不會更大，只會更少。
當然這裏面我要多說一句，就剛纔我已經說到了極限編程這方面是早年犯錯誤的，那麼所以在現在的話呢，在這個文檔處理方面，我們目前非常清晰地看到採用Wiki這樣的工具來使得我們的文檔能夠得到自動的累積效果。人員能夠編輯，然後自動的有版本控制，這樣的話雖然你可以寫的非常的馬虎，但是他們這個文檔會自然而然的累積下來。所以現在大規模敏捷的建設Wiki工具是離不開的，比如說comforence、Sharepoint 、微軟的Azure DevOps等等都有內嵌這樣的工具。那麼反過來說，Word、PowerPoint、Excel這些工具，都是屬於過時的工具，這些工具的整個的效率都不夠高。所以的話就是我們鼓勵各個規模化敏捷實施的組織都要換線上的協同工具。國產的石墨工具，國產的磨刀啊等等，線上多人協作的這種工具確實是好很多，這樣的話文檔的工作更加高效。
PART 3
答：其實整個敏捷團隊跟傳統的團隊建設最大的區別用一個詞就是僕人式領導，僕人式領導更多的傳遞能夠創建良好的條件，支撐我們團隊的開發，信任我們團隊，授權我們團隊，能夠使得團隊形成一個自組織自管理的氛圍來推進。那這裏面有一個敏捷方面的陷阱，或者說是大的臺階，大家要注意，就是我剛纔提到的Scrum。
Scrum在團隊模型當中是一個極端的團隊模型，它取消了項目經理，它直接任命了Scrum Master和產品負責人，所以它是一個非常高效的團隊模型，但是跟各個團隊當前或者說起點的形態是有點距離的。所以業界出現了爲了敏捷直接跳躍到Scrum團隊模型，反而是出現負面影響的情況，所以我這裏面有一個告誡就是說，“start from where you are”,從你當前的形態開始，然後尋求怎麼一個小步的改變完了之後來推進敏捷的團隊建設，不要一上來無視自身團隊的實際情況強行套用所謂的最敏捷的團隊模型，所以這是一個注意的地方。
PART 4
答：事實上敏捷和PMP是接在一起的，我剛纔提到它最大的衝突點恰恰就是它最大的融合點，它最大的衝突點就是整個生命週期模型。
原先的PMP對於生命週期模型方面沒有強制引入短迭代的要求，敏捷方面是有強制短迭代的要求，那麼及時衝突的地方也是融合的地方。只要解決這個要點，就能夠融會貫通的把PMP當中的其他所有的知識全部給用進去，包括WBS、時間管理、範圍管理等等都可以用。
掌握了PMP再去做敏捷會更加的紮實，沒有任何基礎去考敏捷反而是有些薄弱，PMP和敏捷完全兼容，只要是在關鍵的融合點上把它融合好。
PART 5
答：測試報告在敏捷開發當中是一個很大的問題，事實上傳統的測試策略在敏捷當中需要修改，簡單說，基於覆蓋率的傳統策略是無法在敏捷當中長期使用的，因爲敏捷每個迭代都會有新東西，也就意味着在迭代迭代走下去的時候，迴歸測試所謂的量就在不斷的增加。
所以這裏面有兩個選擇方案，第一個用自動化測試能夠跟代碼開發配套，這樣的話手工測試就少。再一個是探索性測試，要用新的探索性測試策略來改變原先的手工迴歸測試。需求的文檔這個量確實也要交代清楚，最新的一個情況剛纔我強調了，確實要積累文檔，它就絕對的字數而言，不排除是會多一些的。但是我可以樂觀的告訴大家，雖然字數會多但寫的速度反而會快。
敏捷採用了用戶故事這樣的直觀表達方式，能夠使得我們腦袋當中想到的東西快速的表達出來，這是它的優勢。那麼這也是我們敏捷項目管理現場培訓的一個焦點，我們在現場培訓的時候會花大量時間來闡述如何進行條目化管理，如何把指示工作切分成一條一條。那麼這裏面一個核心的工具和手段就是用戶故事和敏捷故事。我們通過敏捷故事能夠自然而然的把各種各樣的工作進行包裝進行管理，使得成爲WBS的基石，它所要表達的內容和承載的項目管理的抓手能夠合二爲一，也就是說原先的WBS跟原先項目管理當中做的事情它不是合二爲一的，而在敏捷當中是合二爲一的。不過今天我們先給大家介紹這麼些。
PART 6
答：這個部分是測試數據如何建設的問題，這個不同公司有不同策略。那麼生產數據是一個很好的測試數據的源頭，有些地方要進行脫敏，所以如果你是金融企業的話那是快不了的。所以他就是要有一定的策略，比如說每季度拉一次還是每半年拉一次，不需要每個迭代都來拉，所以這是測試數據的建設部分，想辦法把它加快也確實是能夠提升我們的敏捷速度。
PART 7
答：這個問題在早年間的小敏捷時代沒有得到回答，在規模化的敏捷時代得到了清晰的回答。在SAFe框架當中，軟件設計師是團隊之團隊上面的一個固定角色。比如說當有五六個、七八個敏捷團隊的時候，它就建議有專門的架構師這樣的角色。
這個架構師不屬於特定的一線敏捷團隊，他屬於二線，一個架構師支撐幾個敏捷團隊。那麼從介入角度講，那就是一開始去介入。不僅是一開始介入，每個迭代都要介入。每個迭代都要問一下我們這次的功能變化對架構是不是產生了影響。是架構推進要求我們的功能做相應的變化還是說功能推進需要架構有什麼樣的變化。
所以這個是架構在新的規模化敏捷當中非常重要，不可或缺的。原先在小敏捷時代，在極限編程也好，在Scrum也好，都缺失了這個角色。
PART 8
答：這幾乎是必須的。
我們敏捷建設有專門的敏捷建設金字塔，只有塔尖部分是手工測試，塔身和塔基都是自動化測試。這裏面有突出的一個實踐來自於極限編程，就叫做持續集成。
PART 9
答：這個看屬於哪個傳統金融企業，最新我們中原銀行行長和董事長都發表了長篇的敏捷銀行的報告，平安銀行蔡興發副行長接受的麥肯錫的採訪，也發佈了平安銀行的敏捷戰略。
麥肯錫本身敏捷銀行的報告寫了很多份，所以我們看到現在的傳統金融都是紛紛的擁抱敏捷，這裏面還有一個非常典型的例子是匯豐銀行。匯豐銀行就是一頭大奔向，匯豐銀行在2016年就啓動了DevOps & Agile的transformation，他們爲什麼把DevOps放在前面呢？
他們取了一個D字，&是&字，Agile是A字，所以它縮寫是D&A。匯豐的口號是要把DevOps & Agile成爲匯豐21世紀的新基因。現在匯豐整體上面轉型仍在進行當中，但是已經取得了明顯的效果，16年到19年。所以這是傳統金融企業我們看到都在往這個方向去，工行也好，建行也好，農行也好，中國的都有相應的報道。