scrum实践总结

The Art Of Agile

简述：请大家不要被标题吓着，也不要抱太大的期望，因为本文所述内容肯定没有那本《The Art Of Agile Development》写的那么给力。当然，如果你是敏捷的推崇爱好者，还是推荐先看一下这本英文书。本文之所以取这样的名字，只是想follow一下孙武《孙子兵法》的英文翻译“The art of war”,仅此而已，哈哈。如果你正打算在自己的团队中推广敏捷实践或者在为敏捷项目不知如何开始的话，或许本文对你会有些帮助。本文也是本人第一次敏捷项目实践中的遇到的问题和经验，如有可改善之处，望不吝赐教。

    如今scrum作为敏捷最简单最好执行的实践模式，在淘宝技术部门正如火如荼般展开。然最可怕也是我们最不想预见的的结果可能会是我们抛弃了传统,还打着敏捷的旗号,最后一只四不像出现了.我们敏捷了，但是依旧每天加班到晚上十点半；我们敏捷了，但是评审，会议还是那么多；我们敏捷了，但是我们还在等待别人发号施令；这些都不是敏捷！！！

作为社区团队第一个开始scrum实践的团队一员，在经历长达三个月之久(在淘宝，作为内部系统的开发，3个月似乎有点长久)的scrum实践后，本人可谓是身心俱疲，可值得总结的问题多多。希望能将它们分享给大家，避免一些不必要的弯路。

一．认同感：首先，关于认同感包括两个方面:第一重要的是你的团队成员是否都有了对敏捷式软件开发这种非传统模式的认可；第二，团队成员间互相认可。

对Scrum的认可：这种认可基于团队成员对敏捷要义的认同，对scrum模式的清晰理解；如果你的团队成员只是觉得新模式可以尝试，抱着可以做做看然后看效果的心态的话，那你的敏捷实践工作最好不要太急展开.我没有要求你的成员们都以“火的意志”来到这片战场，但是至少他们是对传统的”淘宝”式软件开发过程不够满意，而且要真正认可这个听起来很玄的东西---Agile；敏捷模式的知识普及推广工作显得如此重要；形式化的宣传可能起不到这样的效果，真正让大家参与起来，让自己去认知感悟，最后你告诉我你是否认可它，如果答案是否定的，请你“离开“（请不要误解，我指远离敏捷，远离scrum）；写到这里，我想起了第一次接触敏捷的时候，我也曾顽固过，仅仅只是结对编程，就花费了师兄云翼将近一天的思想工作，在此感谢云翼；所以，我想说的是，如果你们的敏捷正在起步，那scrum master你可能需要把自己的工作重点放在与团队成员的沟通上，你必须清楚他们对于敏捷的解释和想法；即便在技术上我们不能同一起跑线，在意识上所有成员都必须是统一的：作为团队一员,我必须“认可”scrum。

为什么这么说?因为敏捷倡导的是我们每个人的能动性,在刚开始的时候我们势必要尝试做一些改变和创新,也就不可避免会遇到一些困难和挫折,如果你没有真正认可敏捷,认同scrum,那么这只纸老虎可能会逼着你往后退,从哪来还滚回哪里去.

关于认同感第二重要的是团队成员之间的认同感：需求方要认可开发，测试同学的能力和效率；“PM”要认可你技术团队的编码/系分能力。这个是任何一个团队合作过程中都需要具备的因素，也没啥好多说。但是我们要清楚，敏捷中宣传的特性团队不可能在淘宝每个地方都能组建起来；团队成员能力/意思良莠不齐是很正常的现象；在敏捷初期，犯错误也在所难免，我们需要做的事情很简单，认可他，然后帮助他。

二．自主而积极的意识

这个大家都清楚，这是敏捷是否能够在你团队真正run起来的基石；也可作为他是否符合这个团队成员的门槛。在项目执行的每个环节，每个人都要像PM一样去推动每个细节的运作，所有的人都积极参与其中，否则，还是只有一台发动机在不停运转，一切都还是“外甥打灯笼”。

说起来似乎很简单，master也会告诉你们：“大家都要发动起来啊”。但是要从“我命令你去做什么”转变成“我现在应该主动去为团队做什么”，这种反差极大的思维模式转变，绝对不是那么容易做到的（记得上次在北京agile会议上，一位XXX公司的敏捷爱好者说出了自己的亲身体会：越是工作时间长的员工，越难让他接受敏捷；由此可见“习惯”(不太好的)可能会是影响我们走向成功最困难的绊脚石）；所以scrum框架中要求我们把约定/规则做起来，通过这种带有惩罚性质的约定来慢慢改变我们传统的思维模式，由此可见，约定，何其重要。

以上两点，尽管描述的不是很详细，但是如果你是敏捷的实践者，请你起行前先检验好这两个条件。不要人云亦云，不要以为“别人似乎可以做，那我们也来试试吧”，敏捷不是银弹，不是谁都可以做的！况且，传统模式也并非一无是处，“抛弃我，请给我充足的理由”。

(待续)……

三．约定

前面已经提到约定在敏捷中的重要性：它可以约束我们，将自己从传统的软件开发思维中转变过来，只有按照约定走，scrum才有可能；好的约定条款不需要在这里一一罗列出来，但是这必须是所有团队成员的一起做的约定；此外做约定的时候需要注意几点：

文档化：约定必须要记录下来，而且所有团队成员都能快速的看到；

范围：整个scrum迭代过程中所有涉及到的步骤都必须要约定好，包括每个sprint的周期，需求会议时间点，回顾会议时间点，开发同学的编码规范，单元测试覆盖情况，集成测试执行等；刚开始的时候，约定可能就几个：晨会开始时间和迟到惩罚，代码规范，sprint周期等；每次回顾总结会议上，我们肯定能得到一些规范化的东西，这些也需要一点一点加入到约定中去；所以，约定也是需要及时管理，更新；

执行：你的团队做了很多约定，但是只是简单的文档化，没有被真正执行起来，约定也就没有了意义。前期的时候，所谓的“腐败专员”我想是必不可少的，master必须在这个时候确保将我们的约定执行到底。

之所以要做好团队约定，还有另外的原因：团队效率提升，减少不太“河蟹”的情况发生；做开发的应该比较清楚，约定甚于配置的好处，否则ROR也不会这么火，一旦很多东西按照约定来做，我们就可以避免一些没有必要的沟通和争执，至少减少了因为团队成员行动行为不一致产生的内部损耗；另外，整个团队都遵守同一个约定，比如统一的代码规范，会减少开发团队彼此的摩擦，更利于打造良好的团队氛围；

四．需求讲解会议

      我不清楚现在其他团队是如何展开需求讲解会议的，一开始做的时候确实会比较迷茫，如何做好需求讲解。这对于项目的PD来说也是一个很大的挑战；我的建议是在每个迭代的末尾，PD们就要准备好下一个迭代需要完成的User Story需求列表；这个过程中会遇到很多问题：

首先，PD应该为下一个迭代准备多少个需求才是合理正常的？太多或者太少都不是我们想要的；刚开始的时候，pd对整个团队的开发效率肯定不熟悉，所以也需要不停的尝试和调整，要时刻关注整个团队的效率，质量情况；所以作为scrum中最重要的角色之一，你的投入时间肯定不能再如同传统模式那样，呈现开口向上的抛物线趋势，我们需要的是持久和坚挺～～

其次是UserStory的粒度问题。分两块：时间上和需求详细程度上。

在时间上，我们刚开始的时候一个UserStory可以3天，5天，这么做导致的结果是我们无法跟踪每个用户故事当前的进度情况，而且太大的US会疏忽很多可能是致命的细节问题；当然，如果用户故事分的太小，那你可能需要多租用几个白板，意义不大；所以个人建议的用户故事时间是0.5d~2d之前，太大的用户故事就要进行拆分，太小的用户故事也要合并起来。

当然，如果你觉得还是没有办法跟踪到详细的项目进度的话，就需要对每个用户故事拆分成多个任务来做，比如某个用户故事可能涉及demo制作时间，dao层实现时间，screen编码时间，单元测试时间等；这边要强调一点，我们的UED，测试，开发的US最好都要分开来做，这样才能真正统计出我们每个人的效率和真个团队的合作效率；

在需求讲解的时候，需求讲解的详细程度也很重要。因为这个涉及后面团队成员对需求工作量的评估。我们肯定不能按照“我需要XXX功能来完成XXX效果”这么简单的模式来做；个人的建议是尽量详细最好；至少PD在讲完一个需求之后，所有成员对这个功能前后的交互过程要非常清楚；如果有成员不清楚的，请你立马抬起你高贵的手～～～。

最后，PD一定要对一个迭代中的需求需要设置优先级，然后将其反应在你的白板上，如果可以，尽量参入几个重要不紧急的小需求进来，用于缓冲；

建议：所有的详细需求列表还是要有一份电子文档保存下来。可以是prd形式，uc形式，tc形式，或者其他形式，一定要有，因为我们不能完全肯定我们的代码就是pd要的需求。如果你的团队需要长期使用scrum模式来完成项目开发的话，可以参考使用以下scrum管理相关的开源软件（类似Mingle），省时省力。

另外一个问题也可能被一些团队忽略：US详细的验证标准。这个是在需求会议上或者会议后开始coding之前必须先弄清楚的。

五．时间评估

时间评估的时候，如果多个开发同学对于同一个us的评估时间相差太远，那我们需要PD重新对需求进行讲解；当然如果发现评估出来的时间大于2d，那最好将这个需求再做一下拆分。

如果你是master或者开发人员，可能你会比较头疼于需求讲解完后的时间评估和每一天晨会后的燃烧图绘制。到底是按照绝对时间来评估每个US的工作量还是要加入其他工作，沟通和被打扰的时间？有一种做法是采用相对速度来做时间评估；这个速度是团队的平均速度，不是具体每个成员的速度。假设一个US需要5个相对时间来做完；刚开始可以将相对速度设置为0.3，那么这个US大概需要1.5天来完成；这么做的好处是在迭代结束，我们可以统计实际的工作时间，依此可以对下一个迭代的团队速率做调整，以便我们更好的做项目计划和改进。Scrum是否真正提高了你团队的效率，从这里就可以看出来。所以必要的时间统一是要的。

 困扰我们的还是燃烧图。燃烧图的横轴是迭代的时间范围；纵坐标是本迭代的总工作量。这个工作量是所有US的总和。所以这个时间肯定是完成一个US的绝对时间，当然这个绝对时间除了系统设计/编码时间，还有单测，自测，沟通时间。

一天结束或者新一天开始的时候，我们要更新燃烧图。这就需要对所有团队成员一天内的工作做一个统计，我们统计的是每个团队成员对这一天内他在做的UserStory剩余工作量的总和再加上那些没有做的US工作量得到一个值。

六.站立会议

站立对于大家再熟悉不过了。主题：“昨天做了什么”，“今天要做什么”，“有什么问题”。每个人的谈话内容不能涉及太细节的问题，时间不能太长。这里我只想提几个自己的想法：

1.Master：请你“躲到角落里”；非常必要时刻才站出来；

2.站立会议前准备工作1：可以把自己昨天的工作内容先记录成小纸条，尤其是问题，在站立会议上要将它贴到白板上让大家都知道；如果是亟待解决的问题，晨会结束后master要将其安排给相关人员去解决；如果是已经解决的问题，可以作为总结分享，让其他成员从你的问题和错误中学习成长；

3.站立会议前准备工作2：每个人统计好自己前一天正在做的US需要完成的工作量，或者是已经完成的US的实际工作量，将这个结果主动交给master或者贴出来，以便接下来的燃烧图绘制工作；

我们不希望等到晨会上你再去回想昨天做了什么，统计工作量等。这样才能提高晨会效率。

七．关于测试人员

      首先，淘宝的敏捷必须要测试人员作为敏捷一员，至少目前是。其原因大家也很清楚，我们的dev们质量意识还有待提高，单测意识还相当弱化；产品的线上质量必须要QA的XDJM们来做保证；我们目前可以做的是更多的跟测试同学学习测试的思维和逻辑，提高自测能力；

     个人理解测试这个角色在敏捷中可能做的事情会非常多，要求也就更高。

测试人员在需求会议上必须要和PD明确每一个US的验证标准是什么。比如一个列表页面：按什么排序，显示哪些字段，列表上可能会有哪些操作，查询操作是按照哪个字段是否做模糊查询等等。

demo产出的时候，QA需要对demo做相关的确认以便于接下来立马要着手编写的自动化脚本；

在每个US完成需要验证之前，QA可以就一些关键测试点先和相关开发同学做确认，ok后方可开始验证，做功能测试；

此外，因为我们是迭代式的需求开发，测试可能做的最多的事情就是回归测试。实现自动化回归最好不过，但是这对自动化工具的要求很高，因为会涉及很多一般自动化不能覆盖到的测试用例；重复的迭代开发相关模块，这些自动化的脚本也要同步更新维护才能确保正确性；

当然，我们还会建议你团队的QA做更多的事情，比如写单测用力，或者更好的方式：和开发同学结对来编写单元测试。Pair总是会快速让彼此学习彼此的优点，发现各自的问题。

QA还可以做更多……

但是QA也是人，一天8小时，那么多事情来得及做吗？所以，刚开始我们必须先做好取舍，哪些必须做，哪些可以尝试着去做；绝对不能什么都去尝试，因为这么做的结果很可能是质量没了，效率也下去了。所以，新的开发模式对测试人员的能力要求更高。敏捷对所有的团队成员要求都很高，敏捷了不代表轻松，敏捷的过程会很痛苦。

九．文档

       的确，敏捷不要求详细的文档，但是不代表我们丢弃了文档；比如约定，我们需要记录，比如需求列表，比如那些不太好记的需求细节，比如一个让人头疼的设计方案；请不要可笑的说：我们的代码就是文档。

十．   回顾会议

       个人认为敏捷过程中的最重要一个环节就在这里。每个人在过去的一个sprint里面肯定会有所收获，肯定会遇到一些技术或者合作上的问题，肯定会和你的团队成员有摩擦或矛盾产生；回顾会议就是用于解决这些问题的；一方面，我们总结 做的好的方面，并在以后的工作中继续将其保持下去；另一方面，在下一个迭代开始前，我们一定要做到将前一个迭代的问题提出并给出一个可行的解决方案，以避免类似问题在下一个迭代中再次发生；当然，你也可以对你团队某些成员提出他的问题或要求；通过这种反复的总结回顾，持续的去改进，团队才能一步一步成长起来，效率才能有所提升；往往越是持续要去完成的事情就越难办到。敏捷的成功与否便在于此-------你够持久吗？

十一．   单元测试

      关于单测，我不想在这里告诉你要如何去写单元测试；我们可能需要考虑以下几个方面：

首先，意识最重要；单测，一方面确实能够帮助你发现一些容易或不容易犯的错误，减少低bug率的发生；写单测也是一门学问，一种很高的技术，你会发现有些单元单测实在不好写，可能需要处理脏数据带来的问题，可能需要构造非常复杂的数据对象，你会发现原来单测还可以这么写；另外，通过单测你会发现你的代码是不是耦合太多，是否有更好的方法来完成一个单元的代码编写？

可见，单测的好处多多，但同时也需要花费你更多的精力来完成和维护你的测试代码；因为我们的代码可能会被不停的重构或修改，重构过程中不可避免会随之修改你的测试代码，

修改过后的代码是否正确，单测能立马发现；但是如果你的修改确实是要修改原来的功能，那单测代码也要随之更新；可见，单测的维护成本也很高；但是对于开发童鞋而言，这是不可或缺的一项工作。所以，我们在做单测的时候要学会平衡，其实没有必要把一个单元的所有逻辑都测通；我个人的原则是：越是简单，越是固定的模块(除了DAO层，它是一定要做的)，做单测的必要性越低，比如我们现在的BO层；相反，对于那些逻辑相对复杂的，可能需要经常修改，bad smell越多的单元，单测力度越要加强；越是经常修改，就越容易出现错误。保证我们最少的去犯错误的方法就是单元测试这块试金石。金子在最重要的时候总是会发光的。

十二．持续

当你发现团队的效率差到比瀑布式开发还慢的时候，告诉自己，告诉团队：我们要持久；当你天天疲于编写代码，被单元测试压的喘不过气的时候，告诉自己：我要持久；当你发现自己只是一个前端或者测试，却被当成baby sister一样忙碌的时候，告诉自己，我很持久，我要更持久； 我们的终极目标就是所有的项目成员都是baby sister。

持久，持久，再持久，敏捷的曙光就在前方。 

（以下待续…） 

十三．自动化测试

十四．成长