亞馬遜買的電子版，2天看完。

有時間再慢慢來談感悟，下面分享俺的Kindle讀書筆記：

第1-3章　?

ThoughtWorks全球團隊怎么做敏捷，我們商定了一個“60%Scrum+40% XP”的經典答案。

ThoughtWorks敏捷開發的核心原則：價值驅動與技術卓越。

Scrum的燃盡圖并不推薦，原因是很容易營造一種遵循計劃的假象。

ThoughtWorks持續集成紀律有兩個核心：第一是必須每次提交觸發構建；第二是每次提交必須基于上次的成功構建。這兩條紀律是底線。

評審會，Sprint Review Meeting —>Showcase展示會

ThoughtWorks敏捷開發實踐方面特別注意不會聚焦到個體，比如我們說到的Story估點和Velocity統計都是團隊為單位，不會指定或統計到個人。 迭代過程中的缺陷也不會追溯到某個特定開發人員。

該項目經理是個高人，他在項目開始的時候，問清楚每個人擅長的部分，然后讓每個人去做自己不擅長的部分，不會？去找擅長的人幫忙。

在ThoughtWorks，我們認為，軟件開發中的一切問題，根本上都是人的能力問題。如何發展每個成員才是問題的關鍵。如果成員沒有進步，始終是治標不治本的。所以我們采用的一切實踐，不管是以前曾采用的還是以后會采用的，核心目的都只有一個：發展人的能力。因此才有了那個聽起來很聳動的口號：“把項目成功交付當成能力建設副產品。”

把交付過程中的一切活動都看作能力建設，把整個團隊構造成促進每個成員成長的生態系統。

因為大部分的IT項目都可能失敗，成功對于IT項目而言很可能是“不失敗”。

而“控制需求”成為了“控制風險”中最重要的一環，換言之，對于一個失敗的項目而言，需求未得到有效的控制，往往是最重要的原因。

“沒有這個功能，我們不能上線。” 必須據理力爭，請堅信，沒有阻止上線的功能，只有阻止上線的、不理智的、缺乏安全的客戶。

第4章　基于用戶故事的需求及范圍實時管理?

“控制需求”成為了“控制風險”中最重要的一環，換言之，對于一個失敗的項目而言，需求未得到有效的控制，往往是最重要的原因。

業務分析師常常被形容為產品和交付之間的橋梁，產品經理把握產品走向，聚焦產品成長；業務分析師則往返于產品經理和程序員之間，專注如何迅速有效地讓產品落地。

在拆分完成進行復檢時，敏捷團隊（而不僅僅是 BA），可以問自己下面這幾個問題。

1. 客戶所處的行業是什么？

2. 本行業有沒有固定的業務領域模型？

3. 客戶想做的是哪個模型的擴展？

4. 有沒有類似的競品可以參考？

5. 有沒有考慮系統交互的全部的用戶角色？

6. 有沒有系統自動推進、不需要用戶交互的任務？

7. 有沒有考慮全部的業務場景？

8. 正常的場景和異常的場景？

9. 每個場景的每一步是如何對接的？

10. 具體的詳情是什么？

11. 是否可以進行進一步拆分？

12. 每個環節使用的用戶數量是多少，會有性能要求么（精確到每個指標）？

13. 系統邊界是什么？

14. 待開發系統和待集成系統各自完成的業務功能是什么？

15. 是全新的系統，還是需要與舊有系統做數據遷移，逐步替代？

16. 是否有逐步替代的計劃和方案？

第7章　組建人人深度參與的統一團隊?

對于“坐在一起”的敏捷團隊，溝通會在工作和相處中自然而然地發生。

遠程協作編輯軟件市面上的遠程協作軟件

1. Keynote- Collaborate Mode： Keynote算得上我們目前使用最為頻繁的演示軟件，而它的 Collaborate Mode這項高能技巧好像并不是那么知名。

2. RealtimeBoard

3.即時通訊工具：常見的主要有 Skype， Lync（ Skype for business）， Slack， HipChat， Hangouts等。目前我們項目正在用的是 Hipchat，比較突出的亮點是不用翻墻，可以與 Jira， Github集成，缺點主要是記錄保存時間較短。

第8章　為什么你的Scrum會失敗？

換句話講， PO通常是資方而不是勞方的人， PO要么是給項目提供資金的人，要么是他的代言人。通常出錢的人是老板，很忙，在大的組織里不太可能直接出任 PO，但他必須把他的職責代理給某個人，而這個人是要對產品的成敗負責的，出了事之后他要負主要責任。

在我見過的運行比較好的 Scrum團隊中，擔任 PO的人都滿足上述任職資格，包括客戶本人，包括從頭到尾負責一個產品很多年的人等。而運行的不好 Scrum團隊中， PO通常由原先開發團隊中的業務分析師擔任，僅具備一定的業務能力，而沒有商業上的資格和權威。

Scrum Master的使命就是把自己做沒，不是做媒，是做沒。

如果團隊在眾多內部關于流程／活動／角色／職責等事情上需要 Scrum Master的干預，則離自組織還很遠。

那為什么球隊永遠都需要一位教練？答案很簡單，因為球隊教練的職責是贏球，而不是教會球員自組織。如果他通過讓球員在場上自組織來贏球，那球隊確實對他的依賴會減少。

?PO自己搞定規劃， PO和團隊一起開工，團隊自己搞定怎么做。 IPM不占開發團隊時間， IKM兩個小時足夠，其他的討論分散在開發過程中。

站會／回顧／評審會議，都涉及調整。開完會后沒什么調整，這個會就白開了。

第9章　技術領導者即服務?

技術領導者需要扮演三種重要的角色：技術決策者、流程監督人和干擾過濾器。一支團隊能否有效采用架構最佳實踐、交付流程最佳實踐和項目運作最佳實踐，很大程度上取決于技術領導者把自己的工作完成得多好。

第10章　項目管理中的敏捷實踐?

唐僧師徒可以被看作敏捷中的全功能團隊：團隊有共同的目標“取到真經”；他們歷經了九九八十一難，好比九九八十一個迭代，每次打怪成功都是完成了一次交付；在不斷迭代的過程中，這個團隊不斷地收集反饋、持續改進，一步步地完成了最后的目標。取到真經，意味著完成了項目的交付，同時使得團隊能力得到質的提升。這是一個美妙的結果。

-----大強評：唐僧師徒這段是印象最深刻的描述-----

ThoughtWorks，有一個非常有名的活動叫 Inception。 Inception是啟動軟件設計和交付項目的方法，通過集中式、互動式的設計工作坊，幫助客戶在最短時間內對項目范圍達成一致，快速進入項目交付。而 Inception的一個產出就是溝通計劃（ Communication Plan）。比如在這個溝通計劃中會討論：以什么頻率、什么形式作項目的更新，比如說每周五以周報的形式作一些主要信息的更新；站會和迭代會議什么時候召開，需要邀請哪些人，比如業務負責人和技術負責人等。

第12章　團隊敏捷轉型的三個階段

有些人說為什么不從技術實踐開始？設想一下在瀑布式開發中，開發團隊幾周甚至一個月才交一次版本給測試團隊，在這種情況下，開發怎么會有動力寫自動化測試？運維怎么會有動力做自動部署？需求沒有妥協的空間，設計沒有妥協的空間，導致團隊的痛點永遠是按時交付，質量一定會被犧牲掉的。因此只有先強制縮短交付周期，讓團隊痛點轉移，才能改變開發人員對質量的觀念。至于這個過程中導致的交付速率降低，我們的觀點如下。在敏捷轉型前期一定是有所付出的，然而你投入越多，進展就會越快，收益就會來的越早。沒有質量的交付不能稱為完成，只能叫半成品或者次品。

很多財大氣粗的企業一定想知道有沒有什么捷徑，我的答案是有：敏捷轉型的過程就是培養大家能力的過程，既然終點是所有人都擁有很強的能力，那為什么不在一開始就找這樣的人來工作呢？

第13章　績效考核，敏捷轉型的鴻溝?

傳統管理方式跟敏捷價值觀之間的沖突，其表現如下。經理：敏捷追求的是打造自組織團隊和成員能力多樣化，那么我如何考核某個員工做得好還是不好？有哪些新的 KPI？經理：是不是可以按照一個員工完成的用戶故事點數來考核他的年終績效？經理：怎么樣才能促進團隊成員之間多協作？一個團隊成員請假，這部分工作就擱置在那里了，要是能多協作，就可以替補一下。經理：小李，你看這個任務你來吧，這周五能不能完成？（殊不知，小李心里想的是本周五休假陪老婆過生日） Scrum Master：為什么站會的時候大家都各自更新各自的，沒有任何“相互關心”的交流，站會沒啥用啊！團隊成員：我在迭代開始已經認領卡，我這周快做不完了，為什么要幫他啊？而且我的確不懂他那一塊啊！團隊成員：今年的績效考核我的目標已經定好了，如果達不到，我的工資就加不了多少，我還是多關注自己的事情吧。以上表現，究其本質原因，就是傳統的績效考核方式跟敏捷價值觀和原則的沖突。

為了打造高績效敏捷團隊，結合傳統公司的管理方式，作為啟動，管理者需要把握三個關鍵“考核”思想的轉變。?

1.從考核個人績效轉移為考核團隊成效；以產品的好壞來評價團隊表現。?

2.從橫向比較員工績效轉移為縱向比較個人成長；對于個人的成長，企業應該定義清楚每個角色的勝任力模型，從而幫助員工設定自我提升計劃，而不進行員工之間的橫向比較。

3.從長周期考核轉移到及時反饋與調整；縮短反饋周期有利于及時改進，相互反饋有利于增進成員之間信任和理解。

最后，績效考核的未來有不少探索者認為是沒有績效考核。

第14章　一個交付故事?

“平臺風險”（ The Risk of Platform）這樣的概念，每個成功的互聯網公司都有一個基礎平臺來更好支撐和實施自己的業務戰略，這正是現在 A記想要前去的方向。而平臺思維的關鍵并不是如何吸引開發人員，更多的是把開發者當作平臺的客戶，專注在如何提升開發團隊的體驗、關注在如何打造一個平臺來為開發團隊提供更多的自治，從而釋放出更大的生產力。

第15章 又一個交付故事

我們建議客戶能夠更多的分享上下文，而不是做決策，決策由團隊來出，但是客戶保留否決的權力。

第16章　一個遺留系統自動化測試的七年之癢?

UI測試不是著重去測試某個功能是否工作，更關注的是用戶在使用系統時能否順利實現某個業務目標。

第17章　如何在團隊建設工程師文化？阿里資深技術專家這么做 >?

如果沒有技術 KPI，技術就會總被放在次優先級。

一個軟件技術團隊的最終產出物是可交付的軟件本身，所以不管什么花里胡哨的管理方式都沒有一份安全和穩定運行的代碼來得給力。

好的代碼應該要有設計的痕跡：簡單粗暴地還原業務或多或少給未來埋坑。

IDE永遠不能忽略 IDE對編程效率帶來的影響。 IDE是工程師每天面對的工作環境，任何跟工程效率相關的思想都應該以 IDE PLUGIN的方式讓工程師們每天可用，每天受益。 IntelliJ作為 Java神器存在有其必要的原因是因為它把能幫到工程師的每一個操作都簡化和方便到極致。團隊使用 IDE的技能是否出神入化一定程度反映了這個團隊的編程效率是否高。這是結對編程的另一個重要好處：一個團隊使用同一套快捷鍵寫代碼，而這套快捷鍵是整個團隊每個成員快捷鍵使用心得的合集。

?第18章　敏捷轉型下的團隊管理：來自一線管理者的思考?

首要的就是要培養團隊成員間的協作意識，進而形成自組織，而站立會議是促成這種成員間協作的主要形式之一。可是我又不知道該如何處理，因為，僅僅告知團隊成員說話的時候不要看你或者當你不存在是虛偽的，這種所謂的建議在實際操作層面毫無意義。敏捷教練給我的建議是，你不妨缺席幾天站立會議。

管理者是有“神光”的，特別是相對于你直接考核和管理的成員。這種所謂“神光”有的時候是有用的，它可以讓懶散、推諉和各種組織里的不良風氣見光而散。同時，它也是有害的，它讓團隊成員不自覺的產生依賴和等待指示的心態。

作為團隊管理者，不能僅僅關注團隊這一次把事情做對了，關鍵是，團隊通過自己的成長持續的把事情做對，以致做得更好。

團隊管理者要打造敏捷的自組織團隊，必須給予團隊足夠的屬于團隊自己的空間。因為既然是“生命體”，就是有隱私的，就不像“時鐘”一樣，隨時都可以打開看看里面的齒輪轉得怎么樣。需要一些不同的溝通方式和管理方法。

受訪者來自不同行業，其中來自互聯網企業的 26%、信息科技 21%、通信 16%、金融 17%。

企業敏捷實施的團隊規模大部分（ 79%）在 100人以內。其實，這是一個趨勢，隨著技術和工具的發達，一個人能做的事越來越多，所以團隊規模也自然變小。更重要的是，自主小團隊和網絡式組織結構，更靈活、更能夠產出成績。這也符合敏捷理念。只有特別復雜的系統，才需要大規模 100人以上的團隊。我們仔細分析了 500人以上的敏捷實施團隊，他們大部分實際上是多個獨立產品線并行交付。單產品的交付，大部分還是 100人以內。

敏捷實施周期與效果：堅持 6個月，必有效果

敏捷雖然可以提供快速驗證產品的機制，但是并不能指定產品方向。這還是依賴于有智慧、有眼光的產品負責人。有能力的產品經理，加上一個有效的敏捷運作機制是一個完美的組合。

實施敏捷的時候，首先要先從一批意愿比較強的成員入手，同時也要考慮當前的績效管理體系是否會促進或阻礙協作。

如果一個團隊說他們很敏捷，但是沒有站會，沒有工作跟蹤，沒有自動化測試，更沒有持續集成，你覺得他們能夠敏捷起來嗎？

我們發現企業采用的步伐通常都是先實施團隊級的敏捷，然后端到端交付敏捷，最終實現企業級敏捷。