轻松Scrum之旅--敏捷开发故事

2010年08月08日
《轻松Scrum之旅--敏捷开发故事》 丛书名：IBM中国开发中心系列
作者： 贾子河 段永刚 蒋博 段珊珊（2009年12月第1版第1次）
电子工业出版社 Publishing House of Electronics Industry
北京市海淀区万寿路173信箱（100036）

 

内容简介
本书是一本介绍Scrum和敏捷开发的入门读物。作者结合在大型跨国公司多年的软件开发经验，把Scrum敏捷开发实施经历进行巧妙的改编，以小说的形式将与敏捷开发相关的知识、经验和思考都融入到轻松、有趣的故事中，生动地展现给读者。
本书适合软件开发主管、IT项目经理、软件开发和测试人员、计算机相关专业的学生以及所有对软件工程和敏捷开发感兴趣的读者阅读。
  
贾子河，IBM中国开发中心高级软件工程师。2004年硕士毕业于北京工业大学计算机学院，清华大学经管学院工商管理硕士在读，曾在多家知名间公司从事过软件开发工作。2004年底加入IBM公司，从事过软件配置管理、测试及开发等工作。从2007年初在IBM中国开发中心领导一个Scrum团队开发Lotus Forms产品至今，具有丰富的敏捷项目开发和管理经验。

 

段永刚，IBM中国开发中心软件工程师。2005年硕士毕业于北京理工大学计算机系。毕业后曾在一家著名软件公司工作两年。2007年初加入旧M中国开发中心，从事Lotus Forms产品的开发工作，同时开始正式接触Scrum。通过两年的工作和生活，对Scrum有了不断深入的认识，对敏捷开发有了较为全面的了解，深刻感受到Scrum的魅力，由此希望能为Scrum的推广贡献自己的绵薄之力。

 

蒋博，IBM中国开发中心软件工程师。2007年硕士毕业于北京航空航天大学。毕业后加入IBM公司从事软件开发工作至今，目前在IBM中国开发中心参与开发Lotus Forms产品，具有丰富的敏捷项目开发经验和肝技能。

 

段珊珊，IBM中国开发中心软件工程师。2007年硕士毕业于北京交通大学计算机与信息技术学院，并于同年加入IBM。目前在IBM中国开发中心从事Lotus Forms系列产品的系统测试工作，具有较为丰富的软件测试经验。

 

媒体评论
敏捷方法是软件工程方法论和实践的新发展，相对于传统的开发方法和过程，它能够更快、成本更低、风险更少地开发质量更好的软件，团队的活力和成就感也更好。软件开发团队和企业应该学习和实践敏捷开发方法和过程。在IBM，敏捷方法、过程和相关的工具已经普及，大多数项目都是基于敏捷方法的。　　
本书作者是IBM开发中心的工程师，他们基于自己的实际经验，构造了一个虚拟的故事，生动活泼地解释了敏捷方法的最新实践，也就是Scrum方法。在这个故事中，我们会看到一个基于传统开发方法的团队是如何一步步地转变成一个敏捷团队的，内容涉及Scrum方法的各个阶段、各个方面。对于以前不太了解Scrum的朋友来说，这种讲述方法引人入胜，易于理解，非常值得一读。　　本书是一本很好的Scrum入门书籍，希望它能够带你进入敏捷的世界，开始敏捷软件工程的实践之路。　　　　　　　　　　　　　　
----IBM研发中心首席技术官 毛新生

 

经过软件行业几十年的发展，软件系统变得越来越复杂，传统的软件工程理论使“软件危机”越来越严重。过长的开发周期、超出预算的开发成本、令人担忧的软件质量、频繁流动的开发人员、官僚的体系制度、迅速变化的市场环境等因素，让繁冗、笨重的软件开发过程越来越不能适应现实的需要，软件项目的失败率很高。敏捷开发就是在这种背景下应运而生的。敏捷（Agile）是一种关注价值、消除浪费、以人为核心、迭代、循序渐进的开发方法。
记得在2002年的时候，恰逢国内引进了一批XP（eXtreme Programming，极限编程）敏捷开发的图书，网络上和杂志中也出现了一些早期的相关文章和报道，于是笔者有机会认识了敏捷开发，觉得耳目一新，也很震撼。可惜当时很多讲解敏捷开发方法论的书籍内容比较抽象，也很理论化。那时笔者正在读研究生，所以没有经历过敏捷实践，也就很难有深刻的体会。当时笔者就在想：敏捷开发真的这么神奇吗？
笔者亲身经历过不同大小、不同类型的公司，也听许多朋友和同学谈起过自己的工作经历，可惜很多都是失败的教训，大家的抱怨大都集中在传统瀑布软件开发流程以及一些具有中国特色的企业管理制度和文化上。笔者一直在关注敏捷，也总是在思考这样一些问题：采用敏捷开发的软件公司和软件团队是怎样工作的？不同性质、不同文化的软件公司和软件团队对个人成长的影响又是怎样的？
如今，几年的时间过去了，以Scrum方法为代表的敏捷思想已经在全球范围内推广开来。Scrum一词来自英式橄榄球（Rugby）比赛。敏捷软件开发团队就好比一支橄榄球队：他们有明确的最高目标，而且每时每刻都朝着目标努力；他们熟悉最佳实践，高度自我管理，高度协作，高度灵活地面对各种挑战。大量的调查统计表明，敏捷开发确实大大提高了软件开发效率和软件质量，帮助软件企业提高了效益，并更有利于个人的成长。
在现在这个SOA和Web 2.0当道的时代，国内也迫切需要敏捷思想，然而这些年似乎依然是雷声大、雨点小。国内实施敏捷的阻力主要在于人。因为敏捷的核心就是“以人为本”，人的问题上升到了企业管理、企业价值观和文化的层面。片面地关注具体实践，而不去了解它背后的哲学思想，可想而知，是不会取得好结果的。所以说，敏捷决不是一个简单的软件过程。
最近两年，笔者有幸在IBM中国开发中心的一个Scrum敏捷开发团队担任Scrum Master，期间发生了很多有趣的故事。由于起步比较早，特殊的机遇让我们有机会给IBM的其他大大小小的开发团队进行敏捷培训，分享我们成功的经验和失败的教训。每次培训时，我们都会被同事们对敏捷的浓厚兴趣深深感染，也发现很多问题和困惑非常有代表性，于是就萌发了写作一本有关敏捷开发的图书的想法。
有一天，同事们在一起突发奇想——为什么不把我们的故事改编成小说，以小说的形式写一本书呢？大家说干就干。我们的开发小组在业余时间就变成了本书的创作小组。本书以敏捷思想为核心，以Scrum为重点，结合笔者所在的开发小组在IBM两年的Scrum项目实施经验，参考了大量资料，将近百个案例、问题、知识点融入我们的故事中。
本书讲述了某外企的一个新团队如何从零开始实施敏捷，经历挫折、失败、进步、成长，直到项目成功结束的故事。
为什么不直接写敏捷的最佳实践，而要写那么多曲折的经历呢？我们认为，这就像解题一样——了解、分析问题的过程比直接知道答案更有趣，也更有用。更何况其实并没有真正的所谓“最佳实践”。在实际工作中，软件开发团队、软件项目往往千差万别，书中讲到的实践不一定都是正确的和尽善尽美的，它们仅仅代表一些可能的敏捷开发实践。
本书的创作完全是由4位作者共同完成的，整个写作过程也是敏捷的：迭代、自我管理的团队、有条不紊的进度、期间收集潜在读者的反馈进而调整书中的内容。我们惊喜地发现：敏捷思想真的有效，而不仅仅是对软件开发项目而言。
本书的优势也许就是和大部头的经典著作相比更具有趣味性，和纯正的小说相比更具有知识性。本书的定位是介绍Scrum敏捷开发的入门书籍。如果您想了解什么是敏捷开发和Scrum，如果您对软件工程、软件开发流程有诸多困惑，如果您正准备采用敏捷开发但又缺乏实践经验，如果您想了解一些外企的工作模式和企业文化，如果您对自己的职业生涯感到迷茫……希望您能通过这本书得到一些帮助。如果这本轻松、有趣的敏捷开发故事书能在您忙碌的工作和生活中引发一点思考，带来一些价值，就是我们最大的欣慰了。
本书的完成首先要感谢IBM中国开发中心及各位同事的指导、支持和帮助，特别是我们的经理李斌的帮助。感谢IBM中国敏捷社区和项目管理社区的大力支持。特别鸣谢所有提前审阅过本书并对本书提供了大量宝贵意见的朋友，他们是：毛新生、谢明志、彭雷、岳治宇、汤宇松、钟朝晖、陈昊、窦文敏、唐威锋、郑曙旻、陈川、魏永超、马冀。他们中有的是IBM中国开发中心经验丰富的同事，有的是来自其他著名IT公司资深的软件工程师和项目经理。特别感谢本书的热心读者、IBM的项目经理杜程为本书绘制精美的阅读导引图，我们把这张图作为插页放在了本书的最后。我们同样要感谢家人们对我们在工作之外花费时间写作本书给予的理解和支持。本书能够顺利出版还有赖于IBM中国开发中心的高级经理闫小兵和电子工业出版社博文视点公司编辑潘昕的辛勤工作。
由于时间和能力有限，最后呈现给读者的内容依然有不少的遗憾。我们欢迎您任何形式的反馈，以促进我们不断改进——这也是敏捷所倡导的。
本书的故事场景、情节、人物纯属虚构，如有雷同，纯属巧合。本书观点仅代表笔者的个人观点，不代表IBM公司。
好了，我们的敏捷故事即将开始。

 

Scrum中如何实现一个Sprint？
1、Scrum计划会议
在每个Sprint开始之前，需要召开Sprint计划会议，会议时间一般为4~8小时，参加人员有产品责任人、Scrum Master、Scrum团队和其他感兴趣的人，比如管理人员和客户代表。
Product Owner从产品Backlog中挑选高优先级的任务，并与Scrum团队一起决定在这个Sprint中需要完成多少功能。Scrum团队将这些任务分解成小的功能模块。Scrum团队成员详细讨论如何能按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间。

 

2、每日Scrum会议
每日Scrum会议（Daily Scrum），即团队每日例会，条件允许的话，每天都应该在同样的时间和地点，组织所有成员站立举行。由于是以站立的状态开会，因此时间比较短，一般为15分钟左右。这个会议最好是在每天的清晨开，有利于团队成员安排好当天的工作计划。只有团队成员可以在每日Scrum会议上发言，其他人员如果对项目进度有兴趣也可以参加，但只能旁听而不能发言。

 

3、Scrum评审会议
Sprint评审会议在Sprint结束时召开，由开发团队展示这个Sprint中完成的功能，长度为两个小时左右，不需要PPT，一般是已经完成功能的Demo，而客户、管理层、Product Owner以及其他开发人员等都可以参加。
在Sprint评审会议上，Scrum团队用Demo的形式展示产品的功能之后，与会人员依据在Sprint计划会议上确定的这个Sprint的目标来评审具备了这些新功能的产品。

 

4、Scrum回顾会议
Sprint回顾会议由产品责任人、Scrum团队和Scrum Master参见，会议中需要讨论：有哪些好的建议或方法应该被采纳；在Sprint中有什么做法不可取；有哪些做法效果很好，应该继续下去。
Sprint结束后，Scrum团队回顾刚结束的Sprint，对其进行总结和反思，使整个团队能持续成长。总之，Sprint回顾会议的宗旨就是：Scrum团队如何在下一个Sprint中做得更好！