讀書筆記：分布式Scrum的實用指南 - A Practical Guide to Distributed Scrum

最近讀了這本IBM出的《A Practical Guide to Distributed Scrum》（分布式Scrum的實用指南），書中的章節結構比較清楚，是針對Scrum項目進行，一個階段一個階段來介紹的，既包含Scrum的做法，也包含了分布式團隊可能遇到的問題和一些建議。這裡我先根據書籍目錄，做個大緻的介紹和提要，最後做一個自己的總結。

一、提要

Chapter 1 The Evolution of Scrum

Core Principles of Scrum - 介紹Scrum架構和一些基礎知識

The Shift to Distributed Development Teams -羅列了很多分布式團隊（分布式團隊是指團隊不是一個地方工作的，跨國公司中一些成員在一個地方，另一些成員在另一個地方）的原因，成本、市場、遠端辦公、人員互補

Types of Distributed Teams That Have Emerged -分布式團隊類型，幾種類型的差別在于有沒有時間和地點重合及其重合程度

Ways of Handling Distributed Teams - 分布式團隊的組建方式，跟團隊人員地域配置設定、技能和任務依賴有關，人員分散，技能分散，任務依賴嚴重，分布式也越嚴重，帶來的問題越多

Chapter 2 Challenges Faced by Distributed Teams - 具體談到分布式的遇到的問題。高屋建瓴。

Time Zones and Working Hours - 在整個全球的情況，時區和不同工作時間為大家協作帶來困難

Cultural Differences - 國家不一樣，文化習慣，溝通習慣也不一樣

Language Differences - 口音和非母語，交流還是會不少的障礙。盡量簡單的語言；讓每個成員都發言；會議世使用群聊工具；配備翻譯人員；多和成員确認

Tools - 選擇合适工具，來幫助協作

File Sharing - 團隊共享檔案，如果成員對此不清楚，後果也挺嚴重的

Software Engineering Practices - 好的實踐，一定要用起來，比如TDD，CI，對分布式團隊更有用處

Schedule Differences - 越是分布的團隊，越是難選一個合适會議時間

Team Dynamics - 分布式的團隊，很難清楚團隊成員到底在幹嘛

Telephone Dynamics - 電話會議問題會很多，一些在會議室，一些是遠端參加，盡量都靠近麥克風說話，少一些背景噪音，少一些私下談話，最好在發言前報一下姓名，不說話的保持靜音；鼓勵大家都說話；雖然遠端參加的成員的肢體語言看不到，同樣這些成員可以在麥克風前做動作，進而聲音也收到動作，情緒而變化；專門人注意觀察會議的品質；實在不行，全部都通過遠端的方式參與會議；

Reminders - 經常需要提醒提醒，在分布式的環境中

Impact of Communication Problems - 溝通不暢，總得來說任務亂來，狀态不清晰

Chapter 3 Starting a Scrum Project - 介紹如何開始一個Scrum項目，了解項目，确認利益相關人、ROI

How to Identify the Problems Your Product Will Solve

Define the Vision

Create the Product Roadmap

Organize the Scrum Teams

Create and Prioritize the Backlog - 使用合适的工具；以團隊方式評估，包含所有的環節，開發、測試、等；最好評估引入有經驗的和沒有經驗的，一起評估；整個Backlog是根據不同distributed team的情況和feature, story優先、依賴關系組合而成；風險項、最佳實踐，考慮以Backlog進行管理和實踐

Create the Release Plan - 也是一個麻煩的地方，需要考慮不同團隊能力和任務的先後關系；各個不同地方的子團隊最好是使用同一個Sprint的長度，否則會議、任務依賴更加麻煩

Use Agile Project Management Tools - 保持資訊、狀态的透明度

Coordinating Agile and Non-Agile Teams - 如果需要和非靈活團隊配合，可以讓非靈活團隊了解優先級和依賴項以便配合；也需要考慮狀态如何報告

Important Note about Meeting Face-to-Face - 項目早期，最好來一段面對面的的工作時間

Chapter 4 Preparing for Sprint Planning - 本來原本的Scrum架構不包含的這個準備會議，在大型分布式團隊，在Planning會議前做一些準備，一來降低風險，二來使Planning更加高效

Sprint Preplanning Activities

Clarification of the User Stories - give time to answers / research

Breaking Down User Stories

Estimating User Stories

Dealing with Dependencies

Cleanup of the Product Backlog

Approaches for the Sprint Preplanning Meeting - 是具體情況，可以考慮每周進行這個會議，或者是一次性的全成員會議

Chapter 5 Sprint Planning - 介紹Planning會議怎麼開，分布式團隊怎樣去開這麼一個會議

Adequately Preparing for the Sprint Planning Meeting

Sprint Planning Meeting Logistics - 分布式團隊的會議會在非工作時間，可以派代表去參加；但盡量全部成員參加；獨立故事獨立團隊獨立開；共同選時間；提早準備

The First Half of Sprint Planning: Deciding What to Do

Reviewing Product Vision and Sprint Goal

Reviewing the Product Backlog

Engaging Stakeholders

The Second Half of Sprint Planning: Deciding How to Get the Work Done

Creating the Sprint Backlog

Gaining Commitment

Updating the Release Plan

Chapter 6 Distributed Daily Scrum Meetings - 每日Scrum會議

Using the Three Questions Effectively - 重視每日會議上的3個問題，千萬使其不能流于形式，喪失其作用

Answering the Three Questions

Coordinating the Team on a Daily Basis

Committing to the Team

Verifying Progress

Resolving Blockers

Daily Scrum Logistics

Ways of Communicating During the Daily Scrum - 每日會議的幾種方式

Face-to-Face Meeting - 分布式團隊中，能面對面談，過于理想，跟現實差距大

Teleconference Meeting - 電話會議，沒有肢體語言，較難保證大家的參與度

Videoconference Meeting - 視訊會議，較難看到所有人，對軟體，硬體，帶寬都有要求

Group Instant Messaging Approach - 可以提前準備；保留證據；互動差，對項目的關注度、參與度低

Approaches to Handling Time Zone Issues - 遇到時區問題，怎麼辦？

Daily Scrums Through Documentation - 可跟蹤，可持續性不錯，但是沒有互動；

The Liaison Approach - 有傳遞錯誤資訊的風險，代理人需要在非工作時間參加會議，代理人或者可以輪換

Alternating Meeting Times - 協調時候，全員參與，非工作時間會議不待見，可持續性差，如有成員不出現，缺失相應的資訊

Tips for Distributed Daily Scrums - 一些不錯的小提示：集中注意力，保持成員心思放在會議上，積極參與，而不是在其他的任務上，分布式團隊不能看到成員的具體表現，主持分布式會議的難度更大；或考慮備份，記錄下每日會議的記錄，一來是依據，二來減少語言障礙的影響；使用群聊工具更佳，可以通過打字輔助語音會議

Scrum of Scrums - 上面的一些建議，都可以用在這種結構的會議上

Chapter 7 Effective Collaboration During a Sprint

Communicating During the Sprint -Sprint 過程的溝通

Documentation to Overcome Distance - 分布式團隊的情況下，文檔較友善準确的傳遞

Using the Right Tools

Valuing the Whole Team - 團隊意識

Transparency - 唯有透明，才能更少的發現問題

Handling New Requests in the Middle of a Sprint - Sprint中間出現狀況，腫麼辦？

Single Point of Entry - 最好團隊裡有一個專門的人，來處理這些狀況，而不是有了新的變動，直接到開發人員

Value of the Well-Groomed Backlog - 新出現的狀況，也需要判斷其價值，判斷在backlog的中優先級 

Shortening the Sprint - 縮短Sprint的周期，讓利益相關人的來Review

Dealing with Defects - 下個Sprint解決；算為一個有一定優先級的任務項；子團隊處理；由支援團隊處理并在特殊版本上修改

Disruptions at the Team Member Level - 團員級别的一些中斷

Handling Stories the Team Cannot Complete During the Sprint -沒有完成的故事，拆開掉到下一個Sprint；保持記錄；總結

Handling Blockers During the Sprint

Responding to Questions During the Sprint - 快速決策；代理利益相關人 

Sustainable Pace - 盡量平滑，可持續發展

Sharing Time Zone Challenges - 開會；共同選一個不是最好的，最好的是子團隊能自己搞定所有事情

Avoiding Double Workdays - 分布式團隊常常容易增加工作量，工作時間變長。

Continuous Integration - 可持續內建

Reports Any Build Failures to the Team

Reduces the Risk of Integrating Code

Establishes Greater Confidence in the Product

Reduces the Time to Find Integration Issues

Improves the Efficiency of the Team

Builds Can Run at Different Frequencies

Test Automation - 測試自動化

Dedicated Automation Teams

Identify High-Value Automated Tests

Automate What Is Stable

Automated Tests Can Run at Any Time

Automation Helps Improve Software Quality

Test-Driven Development - 測試驅動開發

Provides Documentation and Working Examples of Code

Helps Reduce the Time to Fix Defects

Helps Improve Code Quality and Provides a Safety Net for Changes

Helps Team Members Work Together and Collaborate

Helps Teams Move Away from Big Upfront Designs

Unit Tests and Continuous Integration

Handling Infrastructure Projects - 環境,基礎設施搭建,可以考慮加成backlog；專門團隊做自動化

Chapter 8 End of Sprint Reviews - Review會議

Who Participates in the Reviews

Enterprise Stakeholders - 利益相關人不參加的話，風險會增加

Who Should Present - 了解相關故事的，溝通交流不錯的，或者錄像；最好不要直接的開發，因為他也許會避開潛在有問題的路徑

Preparing Stakeholders - 提前計劃會議；設立示範的目的和期望；子團隊也可能有自己的Review會議

Reviewing the Strategic Vision of the Product

Approaches to Help Focus the Review

Using Themes and a Script - 來一段劇本串起所有故事

Having the Product Owner Introduce Each Presentation

Scheduling for Teams with Overlapping Work Hours

Scheduling for Teams with No Overlapping Work Hours

Alternating Meeting Times

Multiple Sprint Review Meetings

Sharing the Pain

Feeling the Pain

Recording the Entire Sprint Review Meeting

Challenges Teams Face - 挑戰

Not Keeping Track of the Stakeholder Comments - 沒有記錄儲存下利益相關人的意見

Demos May Provide a False Sense of Completion - 沒有說哪些是假資料，是模拟出來，可能會對項目狀态産生錯誤的認識

The Team Has Nothing to Present - 如果不能示範，還是需要跟利益相關人一些過一遍故事，分析原因

Added Challenges of Distributed Teams - 分布團隊還有更多的挑戰

Neglecting to Demo the Work of Part of the Team - 分布式團隊，可能某些功能，某些成員被忽略，記錄哪些人講解了，哪些人沒有；可以考慮用recording的方式；

Coordinate with Teams on Different Sprint Lengths - 子團隊的周期不一樣，會議時間也不一樣，如果重合時，多個子團隊一起開

Remote Demonstrations - 遠端示範

Network Delays and Poor Performance - 網絡環境也需要考慮

Services May Vary by Location - 不同地方，會議環境不一樣，需要提前準備

Demos Outside of Office Hours - 也存在不是正常工作時候進行示範

Chapter 9 Retrospectives - 回顧會議

Sprint Retrospectives

What Should Come Out of a Retrospective? - 不要變成抱怨的會議；産出是可行動項；子團隊關注自己團隊内部的情況

Retrospective Timing - 如果有多個團隊，先各自開，再開統一的會議

Hold Joint Retrospective as Needed

Hold Regular Joint Retrospectives

Joint Retrospectives for Teams on Different Sprint Lengths

Retrospectives for Teams in the Same Product Family

Conducting Retrospectives After Reviews

Larger Retrospectives

Building Trust -  回顧會議需要建立信任，提供一個安全的或者匿名的，能暢所欲言的環境

Effects of Distance - 遠端會議的通用影響，更難建立信任，更難讓成員參與進來

Preparing for the Retrospective - 準備回顧會議，設立目标期望；了解成員的個性；尊重地域文化；提供匿名機制

Asking for Comments Before the Retrospective Meeting - 提前準備經典的問題；附帶自我評定

What Went Well and What Can We Improve?

Providing Questions to Focus the Discussion - self check question

Consolidating Comments Is Extra Work - 整理意見也是一項工作，需要額外的時間

Conducting the Retrospective - 主持回顧會議，遠端會議的注意事項和經驗，一樣适用

Discussing Reported Issues

Giving Everyone a Chance to Engage

Using Common Terminology

State the Obvious

Keep the Conversation on Track - 保留會議記錄

Managing Time Effectively 

Release Retrospectives - 更大級别的回顧會議，關注裡程碑的情況

二、總結

分布式團隊，就是不同地方工作，不同時間工作，帶來的問題，就是溝通問題，會議問題。

總得來說，這些經驗還是有些虛，分享一些更為具體的問題，提供一些解決思路和方向。

溝通

分布式的情況，用一些看得見的東西來輔助口頭溝通是非常有必要，有幫助的。例如，必要的文檔，通過code溝通。一定程度上排除語言障礙，更為準确，也是後續的依據。

另外需要，更加透明，更加快速響應，由于大家不在一起工作，很容易在等待，在不健康的狀态中，對整個項目而言，是有害的。

會議

會議的要素有人物，時間，地點，主題。

人物，時間，地點，幾個要素，都是根據自己團隊的分布情況來協調，考慮讓什麼時間點怎樣才能讓更多人參加，考慮什麼時候需要團隊代理人、代表的方式參加會議，什麼時候需要全員參加，什麼時候需要聯合會議。會議的可持續性比較重要。

在會議之前

最好需要準備，準備軟體，硬體，網絡；準備會議内容（不管Backlog的Review，Research；Daily Scrum/Retrospective的問題；示範時錄像）。準備越是充分，會議會越是順利。

在會議之中

由于是遠端參與，如何提高成員的參與度，并把心思放在會議上，也是一大難題。提問，确認。鼓勵開口，鼓勵參與。了解成員個性、習慣、網絡環境，引導會議，說來簡單，做起來都是需要很多技巧，知易行難。

在會議之後

會議記錄，也是必要的。一來共享資訊給未能參加會議的成員，二來避免會議上的了解不一緻，三來呈堂證供。