Daniel Teng's Blog

Scrum中有一个“完成的定义”(Definition of Done)，其实就是对于Sprint待办事项列表(Sprint Backlog)中的每一个承诺的用户故事，都要达到的质量标准。通常包括：

• 代码签入到主线
• 代码审查
• 单元测试
• 功能测试
• 系统测试
• 。。。

教科书上的Scrum要求，每个sprint都能上线，也就是对于每个用户故事都需要达到所有的内部质量标准（也就是完成的定义）。因为功能上下，客户才会去使用，然后就会有反馈，从而指导产品演进的下一步方向。从而实现健康的关于产品演进发展的反馈环。如果功能不能达到上线的质量要求，与客户之间的反馈环就断了。那很有可能团队制造出很多sprint的垃圾。

但是不是所有的团队都有足够的能力去把功能推上线。很多团队不能在sprint内做系统测试，很多由于软硬件依赖的原因甚至不能做功能测试，不能把相关功能的所有bug都解决掉。因此在上线前，需要经过很长的stabilization阶段，不能在Sprint中完成，而只能在发布前的Stabilization阶段完成的工作叫“未完成工作”(Undone Work)，这其中也包括很多技术负债。“未完成工作”越多，债就越多，用来还债的stabilization阶段就越长。 而这直接后果就是拉长了客户之间的反馈环。在当前竞争激烈的市场中，这种缺陷可能是致命的。所以好的团队会花一部分精力去提高自身能力，“完成的定义”增强之后，从而减少“未完成工作”，

但是还有一个问题，既然“完成的定义”是不断发展、扩充的。那是否需要一个最小集合的“完成的定义”，而连这个最基本要求都没有达到的团队，连最起码的Scrum都不是呢？首先看一下Scrum，Scrum是一个基于反馈的框架，不断审视反馈中获得的数据，然后相应去调整。如果连反馈都没有的话，那就不是Scrum了。那软件开发中的反馈包括开发人员与测试人员、开发团队与产品负责人、团队与客户等等，那其中最小的反馈是什么呢？是开发人员和测试人员之间的反馈，从这个意义上说，最起码的“完成的定义”必须包括最基本的测试人员测试，哪怕是手动测试。如果连手动测试都没有的话，对团队正在做的功能来说，连最小的反馈都没有了。前一阵子网上看到一些公司的Scrum实际经验，其中很多公司提出了“具有XXXX特色的Scrum”，就是把未完成的工作放到下个Sprint去测试，对于这些团队来说，哪怕他们也有每日Scrum站会、各种各样的Scrum会议，由于连最基本的“完成的定义”都没有达到，违反了Scrum的最基本原则。

总结：

Scrum团队应该有一个“完成的定义”，哪怕是一个很弱的“完成的定义”，但是再弱也不能弱到连一点儿测试都没有。团队能力提高的过程就是不断强化“完成的定义”的过程。

Joe Little在Scrum联盟认证讲师和认证教练讨论组里面发起了一个有意思的关于常见Scrum问题的讨论，不少讲师和教练都提出了问题，整个列表越来越长。具体如下：
1 No SM
2 Lack of courage
3 Lack of persistence
4 No SM worth a dang
5 SM who has not been to a CSM class
6 SM allocated too low
7 SM not allocated 100%，对于初始团队，100%的SM是很重要的。
8 SM with zero people skills
9 A PO with zero understanding of technology
10 A PO who has never met a customer
11 A PO with no support from ‘the business’ (depends on context what ‘bus’ means)
12 A PO who does not understand the 80-20 rule
13 A PO with no nose for business value
14 Product Owner not empowered. 很少见到真正的PO，尽管很多人的Title都叫PO
15 Focus on “get all this done” rather than true Agile project. 关注于Output而不是Outcome
16 Asking team to “meet their commitments”, meaning make their estimates come true.很多的manager都很关心承诺
17 Estimates, period. [SG]
18 Failure to work as a team. [!!!!!] 95%以上的团队都不是真正的团队
19 Failure to use the necessary technical practices.
20 Failure to be anywhere near Done at Sprint end [and with no decent explanation]。不少团队在做这种具有XXXX特色的Scrum
21 Stretch goals.
22 no Backlog Refinement done with the Dev Team, so Sprint Planning gets long, boring and risky; 绝大多数团队都没有产品代办事项梳理(Backlog Refinement)
23 Dev Team committing to the Sprint Backlog items during Sprint Planning, instead of committing to a Sprint Goal…这显然是更高层次的要求
24 …therefore, Sprint gets labeled as “failure” because Dev Team didn’t complete all the items (they didn’t work towards a Sprint Goal);
25 The Team members working over night and weekends trying to complete all Sprint Backlog items (or even trying to reach the Sprint Goal), so no sustainable pace nor room for learning from mistakes;
26 ScrumMaster is the technical leader and has the final word on technical decisions; 十分常见
27 Every Dev Team member working on a different item, in any order (not from the most important one);绝大多数Scrum团队都是这个样子
28 High specialization on the Dev Team, so some people only work on some determined kinds of tasks or items;很多这样团队里面的成员都认为自己的东西别人学不会，只能自己碰。
29 Technical or business discussions during Daily Scrum, so meeting could take longer than expected and not create the desired visibility;
30 No impediment list
31 Best impediments not aggressively identified [too short a phrase]
32 All impediments found in only a few categories
33 Inability to make a business case for an impediment fix to a manager
No investment to fix impediments
34 Dev Team members reporting to the ScrumMaster on Daily Scrum; 绝大多数都是这样。
35 No stakeholders at Sprint Review, so Dev Team is presenting to the Product Owner;大多数团队还是离客户太远
36 Items [PBIs] left on a Sprint automatically going to the next Sprint; 或者到下个sprint去测试！！！
37 No action plans from Retrospectives, so almost no improvements are made; 绝大多数团队连Retrospective都没有
38 Stressful, finger pointing Retrospectives;
39 Tasks in the Product Backlog
40 ScrumMasters doing coordination work in a Scrum of Scrums meeting (actually recommended by the black book, then unrecommended by everyone I know, but still persists for some reason) 这明显是PM的做法
41 Deciding which team member will do which work during the Sprint Planning Meeting (an early mistake we made, led to team members working by themselves, not sharing when getting behind, etc.)，我见到过很多在”实践Scrum”团队中都是这个样子。
42 Deciding what will happen in Sprint 2, Sprint 3, Sprint 4, and Sprint 5 before Sprint 1 has been completed
43 Managers talking and interrogating team during the daily
44 Team reporting during daily [unclear]
45 Changing Sprint length
46 Changing team members during a Sprint
47 ScrumMaster who is PO too
48 PO who is the boss of the SM
49 Daily Scrum in the team room with screens turned on [unclear, I guess screens are distracting]
50 Lack of a PO…
51 A Prod Bklog that shows no understanding of BV
52 ScrumMaster delegating and sometimes imposing stuff to the Team.
53 A PITA manager pushing the Team
54 PO not collaborating with the team, not available to the team.
55 Lack of an initial PBL.
56 Scrum Master spread across 4 teams…
57 SM spread across 2 teams
58 Development Team members spread across 4 teams…
59 Dev Team members not 100% dedicated to one Team
60 A Development Manager.
61 A Development Manager insisting that all teams document their Retrospectives using the same document template
62 A Development Manager sending all teams their Definition of Done
63 Checking in code and immediately going home without checking that the build worked, leaving the build broken for others to fix? Even worse, done 3 times by the same person 

64 A product owner not invited to the retrospective 

65 No shared definition of done 
No Def of Done at all

66 A pause between sprints

67 More than one product owner
68 
A daily scrum only twice a week

69 No testing in the sprint
，我们经常会见到，如果做不完了，我们就把这个sprint的工作，放到下个sprint去测试
70 No professional testers in the Team

71 Unfixed bugs on (so-called) done stories