“Software development using scrum”读书笔记
Part I. Overview
敏捷(Agile)对于中国的软件开发团队和个人来说，一直是一个比较新鲜的概念，虽然很多优秀的中国公司也有几年的敏捷实践经验了，但同国外的积累相比，仍然属于比较初级的阶段。最近阅读了敏捷实践的一部非常经典的书籍，结合自己从业这些年和现在所在公司、团队实践敏捷的经验，写下一些心得和读书笔记，以供自己和他人参考。
首先明确概念：Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球。在书中有一段话非常准确的描述了刚接触Scrum的人需要铭记于心的：”Scrum转型意味着一场变革，在转型的过程中，人们的思维方式和行为方式都必须随之发生改变，它不仅是指技术层面的转型，更意味着理念的革新。人们需要学会在没有大而全的计划的情况下开始工作；人们要学会在没有详细需求文档的情况下，通过用户故事和交流分析和理解需求，开始设计和编程；人们要习惯于频繁递交代码和持续的集成……”
回想起大学时代所接触的正统软件课程，特别是在软件工程中提到的软件生命周期模型，从需求分析到概要设计、详细设计在到开发实现和集成测试等阶段。那里所提到的都是被称之为”顺序式”软件开发的流程，如果习惯了顺序式开发，要转型为Scrum，确实需要在观念上首先接受思维的变革。
那么到底Scrum式的敏捷开发到底是什么样子？笔者个人的理解仍然是一堆零散的碎片：持续改进，保持高效的沟通，通过测试驱动开发和尽早的引入自动化测试，保持在每一个短暂的周期里都能交付甚至发布一部分稳定的可以使用的功能，然后及时的得到用户和相关人员的宝贵反馈，让需求在整个软件周期中可以随着开发和客户的反馈同步得到不断细化。在这个过程中，团队成员彼此协同共同建立对产品质量的责任制，每个人也可以不断的感受到开发出客户满意功能的成就感，并且把个人的意见和灵感持续灵活的集成进软件产品中，保持产品一直在市场上具备一定的竞争力甚至走在领域的前端。这就是笔者所理解的Scrum，简而言之就是一句话：通过永不止尽的迭代式改进使得软件产品能迅速的响应市场的任何变化。
Scrum以及敏捷的出现来自一些必然的原因驱使。其中来自企业外部的原因是非常公共的：市场瞬息万变，客户当下提出的需求，在6个月甚至3个月之内有可能变得面目全非；而竞争对手的动作也可能让你当初的设计不得不堆到重来，最有价值的信息，也不可能在项目的初期就凭空想象出来。毕竟，当今世界，变化来得比以往更快了！另外，来自企业内部的原因，可能稍显复杂，因为每个企业都有自己的特性，其中常见的向敏捷改革的动力包括：坚持传统的方式，员工在高强度的工作下，无法感受到成就感和实现自我价值，团队之间的沟通过于依赖冷冰冰的文档，大伙总是默认了经理和老板才是应该对产品负责的人，多团队共同协同时，也经常因为各自掌握的信息都是片面的而产生诸多误会，以至于最后共同开发出来的产品，以质量的缺失甚至需求的误解来还这笔债。
Part II. What’s Scrum
实施Scrum又包括哪些方面呢？首先要接触几个Scrum和敏捷中新的概念：在Scrum式的软件开发中，整个开发周期被划分成一个个短暂的时期，通常叫做一个个Sprint。每个Sprint的长度可以因公司和产品而异，但一般是2周到4周，且不宜过长。Sprint的意义在于，在每个短暂的周期里，团队的责任是交付一些可以使用但并不一定完美的功能，而目的是能及时的得到客户、产品负责人的反馈，也可以尽早的得到整个系统集成这些功能所带来的隐患反馈。在Scrum式的理念里，Scrum团队应当具有自组织的特性，大家都有着公开一致的愿景，并且根据个人的特长通过结对编程等方式，自由的提出改进产品质量的想法，共同对产品来负责，这里也许弱化了以往所谓的项目经理的权威和实施的管理工作，由整个团队来承担责任。这里会产生一个新的角色叫做ScrumMaster，他的作用并不是做任何决定发布任何命令，而是帮助团队、引导团队始终在坚持着Scrum的原则，做最正确的事。即使他将实行任何的权力，这种权力也应该是团队一直通过授予他去做的。
关于一个优秀的ScrumMaster应该具有的品质，书中提到了这样几点：能够并且愿意承担责任，这种责任是指最大化团队的产出并支持团队成员实施Scrum；不会以自我为中心，能理解全体团队成员的价值，并以身作则促成其他人也达成这样的共识；确保团队成员能够把问题拿出来公开讨论，鼓励团队用共赢的方式来思考；对项目以及目标具有高度的奉献精神；最好具有较广的知识面和交际能力，能够高效正确的传达来自市场、客户甚至销售人员对产品的反馈信息给整个团队。
在Scrum式的软件开发过程中，团队不再死盯着需求文档(当然并非说完全抛弃需求文档)，而是借用一种有序队列来分析和掌控整个开发过程的重心导向，这样的队列叫做Backlog。产品Backlog包括所有有待添加功能的列表，它由产品负责人维护并根据优先级从高到低顺序保存。它具有很高的动态性，随着Sprint的功能交付和反馈信息，Backlog中的事项会被增加或者减少，其中将要被实现的事项也可能得到进一步的细化和修改，当然这些事项也会因为有了更多的反馈和团队对产品的了解而重新排列优先级。
Part III. How to Scrum
在笔者工作过的几家公司，大家似乎都意识到了要想Scrum的一些概念靠拢，产生了一些与Scrum不谋而合的想法。即使那个时候大家甚至都没有听说过敏捷或者Scrum。比如团队营造一个彼此分享持续学习的氛围；互相review代码提出不同的看法；更频繁的check in代码，做到每天的产品集成中并且迅速的检验整个系统的健康；弱化早起需求的神话效果，让用户的反馈和市场的竞争来引导功能发布的优先级…诸如此类等等。
尽管如此，由于没有系统的了解过Scrum，仍然有做得不到位的方面。这里笔者不得不提的一点就是：为了让Scrum最宣称的一点，团队产出最大化，非常重要的一步就是在整个开发流程中尽早的引入自动化测试。无数事实证明，最后再测试是没有多少效果的，因为到那个时候，往往有些错误为了顾全产品架构的大局而不得不放弃或者延缓修改，你已经错过了最佳的反馈时机。在Scrum所倡导的每个Sprint中，当稳定的功能被按时交付了之后，持续的集成会产生新的build或者installer，这时都应该对整个系统所全面的集成测试，而且在开发coding的过程中，单元测试也应该尽早的发挥作用，整个Sprint的核心都是为了保证交付的功能稳定健康而且尽量不会对系统的其他部分造成影响。试想一下，如果这些测试都交给手工来做，我想无论任何一家公司，都承受不起这个成本。如果能让自动化测试更早的发挥作用，包括自动化的单元测试和集成测试，无论是开发人员还是测试人员，都可以迅速的得到反馈并把大部分的精力投入到改善和迭代、重构，专注于实现每一个Sprint的目标中去。书中提到的一句话很有道理：”在Sprint的第一天和最后一天都应该有同样多的测试活动”，直至最后一个Sprint产品顺利发布。相比之下，手工测试应该主要作为”探索式测试”，以短为特色，它产生的周期类似于测试驱动开发应该具有的测试->写代码->重构的短周期风格。
Scrum中非常重要的一点就是保持信息的透明化和高效的沟通。笔者现在的项目团队会按照Scrum的思想坚持一系列的碰头，包括两周一次的Sprint Planning Meeting(因为我们的Sprint长度是两周)，还有每天团队的Standup Meeting(大概15分钟)。在Sprint Planning Meeting上，大家着重讨论的是产品Backlog中靠前(优先级较高)的事项，对上一个Sprint交付功能的评审，以及一些持续改进的建议。在这里我们做的并不好的是，团队的每个成员并不会时刻都有机会看到Backlog的变化，这样就错过了很多一闪而过的好的想法和不错的质疑。而在Standup
Meeting上，大家只是简短的描述一下每个人的进度和模块之间协作的疑问，保证大家都能对整个Sprint产品的变化保持全局的了解。
这里值得借鉴的一点是书中提到：有经验的Scrum团队必须始终保持深度协作，跨职能团队一起工作，而不是讲工作从一个组交接给另外一个组。摒弃一个任务必须在下一个任何开始前完成的概念，用”完成-完成”的关系取代”完成-开始”的关系。
另外，许多企业在实施Scrum的时候也会引入一些工具。在笔者的公司，我们使用的是传统的JIRA来管理项目，通过购买JIRA的一个插件叫GreenHoper，来构建我们的Backlog、燃尽图以及管理每一个Sprint。笔者一直认为JIRA是个出色的顺序式项目管理软件，但是它并不能很好的传达Scrum思想。一个无法改变的概念是JIRA分配任务是以issue的形式，每个issue只能有一个assignee，这在笔者看来似乎有违敏捷中倡导的团队责任制。理想的状态是：代码是团队的代码，任何人只要提出足够的理由来，都有义务去让代码的质量变得更好。结对编程说的也是这个概念，两个人面对同一份代码，各自操作一个键盘，互相轮流写一段，融合各自对产品、对技术的经验，最终产出质量更高更稳定的代码。
Part IV. Guide of Scrum
笔者阅读完这本书，反思了许多过往的经验教训，也记录了书中对实施Scrum所给出的指导性意见。这里把它们零散的罗列出来，希望其中的某一点或者某几点能在将来持续的给自己或者他人带来启发：
最好用Scrum自身来管理Scrum实施过程，由于它的迭代本质、固定的时间箱(Sprint)以及对团队协作与实际行动的重视，使其看上去特别适合实施Scrum而实现敏捷的大型项目。
有许多对Scrum和敏捷的误区极易出现：”Scrum要求每个人都是通才，Scrum团队不做计划，Scrum忽略系统全局架构，Scrum不适用于过于复杂的系统。” 这些误区有时是因为对瀑布式和顺序式的流程深信不疑，或者对变革充满恐惧，其实这些误解只要做到：合理的任务划分、共同责任制的建立、每个Sprint都交付有价值的成果、持续的集成以及通过结对编程和TDD(测试驱动开发)等手段提高代码质量，这些问题和误区都会不攻自破。
优秀的团队需要两个角色才能取得成功：产品负责人为团队指出正确的目标，ScrumMaster帮助团队尽可能有效的达到目标。产品负责人应该分享诱人的愿景而创造激情洋溢的氛围，优秀的产品负责人应当具有的品质是：始终Available、熟知业务、善于沟通、行事果断。
Scrum团队的自组织性消除了团队技术领导这个角色。个体需要跨越他们本身的专业而尽可能的帮助团队其他成员 (这有力的反驳了Scrum要求团队成员都都是通才)；团队也从强调编写需求文档转变到广泛讨论需求；团队需要在每个Sprint结束时产生一些切实的交付物。个人选择任务是团队成员能做到自组织最根本的因素，必须留给团队自己做决定。
在Scrum团队中，程序员很大的变化之一就是他们将不能呆在自己的隔间里等待有人来告诉他们具体改写什么程序，他们需要积极主动的理解产品需求。在敏捷团队中，测试工程师会对开发过程有着更多影响，更重要的是对最终产品本身的影响。
坚持TDD(测试驱动开发)，你将得到一个巨大的好处是：系统中所有的代码都可以被测试。它能帮助程序员通盘思考他们的设计。重构是指改变代码的结构，而不是代码的行为，重构不仅对TDD的成功至关重要，也有助于防止代码腐烂。越是复杂的代码模块，越是应该考虑使用结对编程的方式来完成它。这些都属于敏捷编程的概念，敏捷编程为变更而做设计，它的目标是设计出能接受变更、甚至期望变更的程序。理想情况下，敏捷编程允许以简单的、局部的方式来适应变更，以避免或大大减少重大重构、重新测试和系统构建。
Scrum团队的两个关键因素：保持小团队和定位每个团队基本上可以交付端到端的、用户可见的功能。团队规模越大，沟通的开销就越大，个人的力量发挥的空间就越小。所以，一个Scrum团队基本应该保持5~9人。Scrum团队一成俱成，一败俱败，这里没有我的工作和你的工作，而只有我们的工作。
每日站会在团队成员以及可能的其他参与人员中传播信息，Wiki和大的可视图表给出了Sprint和项目进展状况的一个概览，团队成员或者其他的人可以很容易的了解项目状况。在团队中对新的想法应该持开放态度，鼓励犯错误，然后用改进的方式继续做。敏捷转型其实就是想方设法取得预见性和适应性之间合理的平衡。敏捷开发的目标是找到文档和讨论之间的合理的平衡。例如，用户故事是将团队焦点从编写功能需求转移谈论它们的最佳方式。好的用户故事，应该详略得当，能涌现出用户真实的需求，并且随时适应外界因素的变化而更新(包括它的优先级)。
对Sprint产生的可交付的定义是通过了测试可运行，并不一定完整，但能成功的集成进整个系统的功能。快速的提供可工作的软件胜于全面的文档，用户能够更加直观的感受到这是不是他们想要的东西。不要轻易改变Sprint的长度，保持一个比较固定的节奏，尽管不同团队特别是跨区域的团队共同开发一个项目时，各自Sprint的起始时间可以有2~3天的不同。无论何时，都不要延长Sprint的长度，因为这会给出计划内的工作可以完不成这种迹象。除非有非常特殊的理由，否则不要轻易改变Sprint的目标，尽管它的外部世界可能正在变化，Sprint的短暂正式为了适应外界的变化，但它本身对目标是非常强调保持贯彻始终的。
比起加班，更好的做法是给团队增加能源。增加能源最好方法之一是增加热情。为此，产品负责人需要传达一个引人注目的愿景，让开发这个产品的团队满腔热情的工作。每天坚持两次长一些的精神放松，每天两次符合人类的亚节律。人的身体逐渐从精力旺盛状态过度到生理的低谷期大概是90~120分钟。
保持产品Backlog大小的合理，一位人类学家说人脑对于自己维持正常社会关系的人有一个大概150人的上限。我们大概最多只能记住150人。同理，太过于细化和庞大的产品Backlog会变得不可管理，也不可能让团队成员都熟悉。在一些很庞大的功能描述上可以借助史诗故事(Epic)或者主题故事(Theme)来做代表，总之使得Backlog的size不超过100~150。另外针对不同的模块或者组件团队可以从Backlog衍生出多个不同的视图，来保持每个团队都在清晰的关注这自己正在开发的功能。
CMMI标准与Scrum并不冲突，在追求某个特别的CMMI级别时，很多企业忘记了最终的目标是改进他们的软件以及交付的产品，相反，它们关注于填写按照CMMI文档描述的假想的缺陷，却不关心这些变化是否能改进过程或者产品。但当CMMI目标与Scrum与生俱来的关注价值以及”最近你为我完成了什么”的意识结合时，这个问题就会被消除。
ScrumMaster作为团队的传道者和保护者，应该紧挨这团队区域的主要入口就坐。充分保证团队能免受干扰的继续这Scrum的正确行为。同时在工作空间，Scrum团队成员应该能明显看见的东西包括：大的、可见的图表，额外的反馈设备(如果可以的话，自己开发出来)，团队里的每一个人，还有就是最重要的Sprint List和产品Backlog。一个好的建议是有一块大白板，鼓励任何范围团队成员间突发的会议和讨论，使用这个白板来记录创意和发现的问题。至于食物和饮料什么的，这就要看各个公司的文化了。(在笔者的团队里，笔者鼓励购买一些大家爱吃的零食，在大家注意力都开始下降的时候停下来，吃点东西，聊一聊工作之外的话题来帮助每个人放松)
Part V. End
终于总结完了，到了尾声笔者想说的是，Scrum和敏捷的理念是在这个瞬息万变的世界中应运而生的。其实它并非是IT行业特有的，每个学习和实施Scrum的人都应该牢牢记住的是：Scrum的持续改进是没有终点的！今时今日的理论和经验，可能随着世界的变化继续进化和演变，世界上也没有任何一套理论和流程是足够完美的，我们都必须根据所在的公司文化、团队现状、项目情况来反思总结出最适合自己团队的Scrum版本来，最终无论我们给它一个什么样的名字都无所谓，最重要的是它能让团队成员深度协作、快乐的工作，让团队共同肩负起对项目和产品的责任，高效而高质量的开发出在市场上具有竞争力的产品。