A Practical Guide to Distributed Scrum - 分布式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
The Second Half of Sprint Planning: Deciding How to Get the Work DoneEngaging Stakeholders
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 - 有传递错误信息的风险，代理人需要在非工作时间参加会议，代理人或者可以轮换
Tips for Distributed Daily Scrums - 一些不错的小提示：集中注意力，保持成员心思放在会议上，积极参与，而不是在其他的任务上，分布式团队不能看到成员的具体表现，主持分布式会议的难度更大；或考虑备份，记录下每日会议的记录，一来是依据，二来减少语言障碍的影响；使用群聊工具更佳，可以通过打字辅助语音会议Alternating Meeting Times - 协调时候，全员参与，非工作时间会议不待见，可持续性差，如有成员不出现，缺失相应的信息
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 - 团队意识
Handling New Requests in the Middle of a Sprint - Sprint中间出现状况，肿么办？Transparency - 唯有透明，才能更少的发现问题
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
Test Automation - 测试自动化Builds Can Run at Different Frequencies
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的问题；演示时录像）。准备越是充分，会议会越是顺利。
在会议之中
由于是远程参与，如何提高成员的参与度，并把心思放在会议上，也是一大难题。提问，确认。鼓励开口，鼓励参与。了解成员个性、习惯、网络环境，引导会议，说来简单，做起来都是需要很多技巧，知易行难。
在会议之后
