轻松Scrum之旅:敏捷开发故事
基本信息
- 作者: 贾子河 段永刚 蒋博 段珊珊
- 丛书名: IBM中国开发中心系列
- 出版社:电子工业出版社
- ISBN:9787121099847
- 上架时间:2010-1-22
- 出版日期:2009 年12月
- 开本:16开
- 页码:281
- 版次:1-1
- 所属分类:
计算机 > 软件工程及软件方法学 > 软件方法/软件工程
编辑推荐
抛开繁冗笨重的瀑布软件开发过程,SOA和Web 2.0的时代迫切需要敏捷开发。
推荐阅读
内容简介回到顶部↑
本书是一本介绍scrum和敏捷开发的入门读物。作者结合在大型跨国公司多年的软件开发经验,把scrum敏捷开发实施经历进行巧妙的改编,以小说的形式将与敏捷开发相关的知识、经验和思考都融入到轻松、有趣的故事中,生动地展现给读者。
本书适合软件开发主管、it项目经理、软件开发和测试人员、计算机相关专业的学生以及所有对软件工程和敏捷开发感兴趣的读者阅读。
本书适合软件开发主管、it项目经理、软件开发和测试人员、计算机相关专业的学生以及所有对软件工程和敏捷开发感兴趣的读者阅读。
作译者回到顶部↑
目录回到顶部↑
1重获新生
痛苦的挣扎
全新的开始
找工作
面试e公司
焦急的等待
e公司报到
2回首往事
回忆x公司
欢迎午宴聊开发
关于软件开发流程的争论
来自经理的帮助
3准备scrum之旅
敏捷开发培训——什么是敏捷开发?
敏捷动员大会
招兵买马——打造敏捷开发团队
hello,温哥华
初遇scrum——xp、rup和scrum的比较
产品backlog的制定
scrum管理工具
痛苦的挣扎
全新的开始
找工作
面试e公司
焦急的等待
e公司报到
2回首往事
回忆x公司
欢迎午宴聊开发
关于软件开发流程的争论
来自经理的帮助
3准备scrum之旅
敏捷开发培训——什么是敏捷开发?
敏捷动员大会
招兵买马——打造敏捷开发团队
hello,温哥华
初遇scrum——xp、rup和scrum的比较
产品backlog的制定
scrum管理工具
前言回到顶部↑
经过软件行业几十年的发展,软件系统变得越来越复杂,传统的软件工程理论使“软件危机”越来越严重。过长的开发周期、超出预算的开发成本、令人担忧的软件质量、频繁流动的开发人员、官僚的体系制度、迅速变化的市场环境等因素,让繁冗、笨重的软件开发过程越来越不能适应现实的需要,软件项目的失败率很高。敏捷开发就是在这种背景下应运而生的。敏捷(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公司。
好了,我们的敏捷故事即将开始。
记得在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公司。
好了,我们的敏捷故事即将开始。
序言回到顶部↑
序
答应了作者为本书写序已是两星期前的事情了,对此托付我诚惶诚恐。近来工作忙碌,虽未提笔,但心中一直惦念不忘仔细斟酌如何才能将本书作者对于敏捷的理解和著述浓缩成文,写出一篇精彩的序而不负期望。
本书写得有生趣。大概是有很多共通之处吧,所以读主人公的故事就回忆起了许多和敏捷团队一起奋斗的日日夜夜,也自然而然地联想到我在敏捷咨询服务中遇到的一个个活生生的案例。公司做敏捷似乎来自一股强劲的“西北风”,头头脑脑们开始铺天盖地地学习和宣传敏捷。敏捷确实那么神奇吗?敏捷真的能让偌大一个公司的项目运营变得像其所提倡的那样快速、灵敏吗?敏捷的确可以让公司的业绩大幅提高、缩短产品的上市周期吗?即使这些问题能够在敏捷开发中得到很好的解决,那么参与敏捷开发的人需要有哪些变化,而他们又将会有哪些变化呢?带着这些问题,我接手了几乎是公司启动最早的敏捷项目之一,开始边接受边思考。
没想到,短短的两年时间,工作几乎让我着了迷。虽忙,但亦快乐。仿佛是触动了我的某处神经,不对,应该说是着了魔,我不仅每天忙得不亦乐乎,还逢人便说,敏捷给我带来了更多的满足。大概我是个天生的工作狂吧,接受挑战总能让我兴奋。而且,在敏捷项目里工作不再是被设定既定的目标,终日朝着固定的要求努力,而是自己同样需要了解为什么要达到这个目标,由自己决定如何达到目标,由自己计划何时达到目标。敏捷开发项目超级锻炼人,让我有“人民当家作主”的感觉。
这些大概就是敏捷让我感受到的不同于以往项目的最大区别吧!
在传统项目中,层次森严的等级管理制度让我们疲于奔命,但很少有机会想想对错。而现在的敏捷项目给我们的不仅仅是责任和要求,更多的是信任和鼓励。
说到这里,我想讲一个题外的故事。
我和太太认真地装修了自己的第一套房子。在装修期间,爸妈扮演了“伪监工”的角色,对工人的工作大加赞扬不说,看到问题竟然还说“比起当年好多了”,而我和太太自始自终就没放心过。当然,本应自己更多地去和工人们沟通,让父母闲些。所以,后来爸妈也就退居二线给我们做后勤了。因为是自己的房子,而且是要结婚的新房,我和太太特别细心。我详细量了房间的尺寸,但凡去和设计师聊设计,或者去家具城淘货,拿出来就能比划。太太更牛,把买来的冠军砖在我绘制的图纸上横排竖排。当时我超级怀疑她的能力。几面墙如何做到排列得最好,也就是说,整砖要用在看得见的地方,碎砖应该用到角落看不见的地方,这可是一门学问。而且,还要考虑砖的排列方向产生的美感:哪种排列方式会有延伸空间的效果,哪种没有。最后,还要充分利用切剩的砖,不能造成浪费。这简直是最让我头疼的奥数嘛!没想到,太太用两个小加班就搞定了。当工人贴完砖,厂家来拉退回的砖时,居然立刻打电话到店面,说:“你们怎么给客户估计的面积?怎么整整多了两箱!”而我们家的砖贴得相当的漂亮。
下面还有一个故事。
一天,我和太太照常去工地。进门一看到新贴好的砖,太太顿住了,然后径直走到跟前,拿起工人的水平尺,像模像样地比划起来:“老公,我觉得这块砖低了0.1厘米!”听了这话,工人差点从梯子上跌下来,我也受到很大的冲击。这眼力,没说的。而工人是个很不错的老师傅,听见我们这么说,就拿来专业的工具帮着仔细测量起来。结果太太说得一点儿没错,就是低了。我和老师傅当时那叫一个诧异和佩服!最关键的是,连老爸也感觉在这之后工人们干活更认真了——让我们将敏捷项目进行到底!
其实,无论是开发、设计还是测试,甚至包括产品开发过程中的一切细微活动,当我们可以把它们当作义务而不是责任后,效率和质量会有惊人的飞跃,而且在管理和过程中耗费的其他成本也将显著减少。这也是我想通过上面两个故事与读者分享的。
在之后的敏捷咨询生涯中,我也屡次用实验证明了这一事实。当团队将项目当成自己的分内事时,无论你们是在从事敏捷开发还是传统开发,你们团队的工作成绩都将非常亮眼。
敏捷开发,特别是Scrum的模式,我最喜欢,因为它提倡以人为本、平等对待团队中的每一个成员、相信队友,它简单而直接的沟通平台能让人有更多的主人翁意识。在这样的环境里工作会很容易被大家看到成绩并获得认可。如果Scrum Master很专业,那么大家就能加倍感受到“相互依存”的氛围。
所以,我们常说,敏捷开发能让我们读懂“没有一个人的成功,也没有一个人的失败”这个道理。一种主人翁和集体意识,一种宽容的待人态度,一群乐于积极自我学习和相互分享的伙计(包括女伙计),铸就的就是一支优秀的团队。
敏捷开发伴随的是突破和挑战,从外面看到的是市场决定一切,在里面酝酿的是对新技术和新想法的勇敢尝试。曾经有位高人讲过:如果你的工作不是经常遇到困难,就说明你的工作还缺乏挑战。想想看,无论是硬的技能还是软的技能,不都需要在有挑战的环境里来培养吗?所以,正如我们感受到的,我们的实践也说明敏捷不仅能够开发和培育人,而且能促使人更快地成长。成就感是个好东西。
说到本书的另一个精彩的地方,就是潜移默化地让人体会到E公司是如何将一支普通的开发团队从传统团队转变为成熟的敏捷团队的。值得注意的是,没有人可以一蹴而就,这支团队也是在不断地寻找局限和不敏捷之处,步步为营地改善,最后才终于成为一支经验丰富的敏捷团队。总结其精华,我感觉:首先,这个组织找到了正确的人,他勇于负责、敢拼敢扛,同时,他不刚愎自用,他相信协作总是大于“一”的道理;然后,就是遇有“贵人”,无论是在团队的起步阶段还是发展阶段,基于信任和指导,“贵人”让这支团队顺利地从各种陷阱里走了出来;最后,就是团队通过良好的沟通达到一心一体,无论是理解市场动向还是上传下达,团队总能在共同目标上达成一致。这三点缺一不可。做好一件事也要“一个好汉三个帮”,不是吗?但是,在实际工作中,我们往往会遇到很多阻碍和问题,许多团队在实践过程中真的没有办法像故事中描述的那样,虽有波折但仍能达到目的。比如,如何在跨时区、跨地区的多团队合作项目中进行良好的沟通和进度协调,如何在文档和话语的沟通中作出折中的选择,如何将TDD做得更有效率并减小转变的风险和成本等。希望作者能够在本书出版后有第二步的出书计划。
最后,我要感谢作者的邀请。为本书写序的过程仿佛也打通了我的奇经八脉,又好像打了场痛快的球赛,让我兴奋不已。同时,也希望本书能得到读者您的喜欢。对于本序的内容如有疑义,本人愿与探讨。
谢明志
IBM全球敏捷社区中国区主席
IBM注册敏捷培训讲师
答应了作者为本书写序已是两星期前的事情了,对此托付我诚惶诚恐。近来工作忙碌,虽未提笔,但心中一直惦念不忘仔细斟酌如何才能将本书作者对于敏捷的理解和著述浓缩成文,写出一篇精彩的序而不负期望。
本书写得有生趣。大概是有很多共通之处吧,所以读主人公的故事就回忆起了许多和敏捷团队一起奋斗的日日夜夜,也自然而然地联想到我在敏捷咨询服务中遇到的一个个活生生的案例。公司做敏捷似乎来自一股强劲的“西北风”,头头脑脑们开始铺天盖地地学习和宣传敏捷。敏捷确实那么神奇吗?敏捷真的能让偌大一个公司的项目运营变得像其所提倡的那样快速、灵敏吗?敏捷的确可以让公司的业绩大幅提高、缩短产品的上市周期吗?即使这些问题能够在敏捷开发中得到很好的解决,那么参与敏捷开发的人需要有哪些变化,而他们又将会有哪些变化呢?带着这些问题,我接手了几乎是公司启动最早的敏捷项目之一,开始边接受边思考。
没想到,短短的两年时间,工作几乎让我着了迷。虽忙,但亦快乐。仿佛是触动了我的某处神经,不对,应该说是着了魔,我不仅每天忙得不亦乐乎,还逢人便说,敏捷给我带来了更多的满足。大概我是个天生的工作狂吧,接受挑战总能让我兴奋。而且,在敏捷项目里工作不再是被设定既定的目标,终日朝着固定的要求努力,而是自己同样需要了解为什么要达到这个目标,由自己决定如何达到目标,由自己计划何时达到目标。敏捷开发项目超级锻炼人,让我有“人民当家作主”的感觉。
这些大概就是敏捷让我感受到的不同于以往项目的最大区别吧!
在传统项目中,层次森严的等级管理制度让我们疲于奔命,但很少有机会想想对错。而现在的敏捷项目给我们的不仅仅是责任和要求,更多的是信任和鼓励。
说到这里,我想讲一个题外的故事。
我和太太认真地装修了自己的第一套房子。在装修期间,爸妈扮演了“伪监工”的角色,对工人的工作大加赞扬不说,看到问题竟然还说“比起当年好多了”,而我和太太自始自终就没放心过。当然,本应自己更多地去和工人们沟通,让父母闲些。所以,后来爸妈也就退居二线给我们做后勤了。因为是自己的房子,而且是要结婚的新房,我和太太特别细心。我详细量了房间的尺寸,但凡去和设计师聊设计,或者去家具城淘货,拿出来就能比划。太太更牛,把买来的冠军砖在我绘制的图纸上横排竖排。当时我超级怀疑她的能力。几面墙如何做到排列得最好,也就是说,整砖要用在看得见的地方,碎砖应该用到角落看不见的地方,这可是一门学问。而且,还要考虑砖的排列方向产生的美感:哪种排列方式会有延伸空间的效果,哪种没有。最后,还要充分利用切剩的砖,不能造成浪费。这简直是最让我头疼的奥数嘛!没想到,太太用两个小加班就搞定了。当工人贴完砖,厂家来拉退回的砖时,居然立刻打电话到店面,说:“你们怎么给客户估计的面积?怎么整整多了两箱!”而我们家的砖贴得相当的漂亮。
下面还有一个故事。
一天,我和太太照常去工地。进门一看到新贴好的砖,太太顿住了,然后径直走到跟前,拿起工人的水平尺,像模像样地比划起来:“老公,我觉得这块砖低了0.1厘米!”听了这话,工人差点从梯子上跌下来,我也受到很大的冲击。这眼力,没说的。而工人是个很不错的老师傅,听见我们这么说,就拿来专业的工具帮着仔细测量起来。结果太太说得一点儿没错,就是低了。我和老师傅当时那叫一个诧异和佩服!最关键的是,连老爸也感觉在这之后工人们干活更认真了——让我们将敏捷项目进行到底!
其实,无论是开发、设计还是测试,甚至包括产品开发过程中的一切细微活动,当我们可以把它们当作义务而不是责任后,效率和质量会有惊人的飞跃,而且在管理和过程中耗费的其他成本也将显著减少。这也是我想通过上面两个故事与读者分享的。
在之后的敏捷咨询生涯中,我也屡次用实验证明了这一事实。当团队将项目当成自己的分内事时,无论你们是在从事敏捷开发还是传统开发,你们团队的工作成绩都将非常亮眼。
敏捷开发,特别是Scrum的模式,我最喜欢,因为它提倡以人为本、平等对待团队中的每一个成员、相信队友,它简单而直接的沟通平台能让人有更多的主人翁意识。在这样的环境里工作会很容易被大家看到成绩并获得认可。如果Scrum Master很专业,那么大家就能加倍感受到“相互依存”的氛围。
所以,我们常说,敏捷开发能让我们读懂“没有一个人的成功,也没有一个人的失败”这个道理。一种主人翁和集体意识,一种宽容的待人态度,一群乐于积极自我学习和相互分享的伙计(包括女伙计),铸就的就是一支优秀的团队。
敏捷开发伴随的是突破和挑战,从外面看到的是市场决定一切,在里面酝酿的是对新技术和新想法的勇敢尝试。曾经有位高人讲过:如果你的工作不是经常遇到困难,就说明你的工作还缺乏挑战。想想看,无论是硬的技能还是软的技能,不都需要在有挑战的环境里来培养吗?所以,正如我们感受到的,我们的实践也说明敏捷不仅能够开发和培育人,而且能促使人更快地成长。成就感是个好东西。
说到本书的另一个精彩的地方,就是潜移默化地让人体会到E公司是如何将一支普通的开发团队从传统团队转变为成熟的敏捷团队的。值得注意的是,没有人可以一蹴而就,这支团队也是在不断地寻找局限和不敏捷之处,步步为营地改善,最后才终于成为一支经验丰富的敏捷团队。总结其精华,我感觉:首先,这个组织找到了正确的人,他勇于负责、敢拼敢扛,同时,他不刚愎自用,他相信协作总是大于“一”的道理;然后,就是遇有“贵人”,无论是在团队的起步阶段还是发展阶段,基于信任和指导,“贵人”让这支团队顺利地从各种陷阱里走了出来;最后,就是团队通过良好的沟通达到一心一体,无论是理解市场动向还是上传下达,团队总能在共同目标上达成一致。这三点缺一不可。做好一件事也要“一个好汉三个帮”,不是吗?但是,在实际工作中,我们往往会遇到很多阻碍和问题,许多团队在实践过程中真的没有办法像故事中描述的那样,虽有波折但仍能达到目的。比如,如何在跨时区、跨地区的多团队合作项目中进行良好的沟通和进度协调,如何在文档和话语的沟通中作出折中的选择,如何将TDD做得更有效率并减小转变的风险和成本等。希望作者能够在本书出版后有第二步的出书计划。
最后,我要感谢作者的邀请。为本书写序的过程仿佛也打通了我的奇经八脉,又好像打了场痛快的球赛,让我兴奋不已。同时,也希望本书能得到读者您的喜欢。对于本序的内容如有疑义,本人愿与探讨。
谢明志
IBM全球敏捷社区中国区主席
IBM注册敏捷培训讲师
媒体评论回到顶部↑
敏捷方法是软件工程方法论和实践的新发展,相对于传统的开发方法和过程,它能够更快、成本更低、风险更少地开发质量更好的软件,团队的活力和成就感也更好。软件开发团队和企业应该学习和实践敏捷开发方法和过程。在IBM,敏捷方法、过程和相关的工具已经普及,大多数项目都是基于敏捷方法的。
本书作者是IBM开发中心的工程师,他们基于自己的实际经验,构造了一个虚拟的故事,生动活泼地解释了敏捷方法的最新实践,也就是Scrum方法。在这个故事中,我们会看到一个基于传统开发方法的团队是如何一步步地转变成一个敏捷团队的,内容涉及Scrum方法的各个阶段、各个方面。对于以前不太了解Scrum的朋友来说,这种讲述方法引人入胜,易于理解,非常值得一读。
本书是一本很好的Scrum入门书籍,希望它能够带你进入敏捷的世界,开始敏捷软件工程的实践之路。
IBM研发中心首席技术官 毛新生
本书作者是IBM开发中心的工程师,他们基于自己的实际经验,构造了一个虚拟的故事,生动活泼地解释了敏捷方法的最新实践,也就是Scrum方法。在这个故事中,我们会看到一个基于传统开发方法的团队是如何一步步地转变成一个敏捷团队的,内容涉及Scrum方法的各个阶段、各个方面。对于以前不太了解Scrum的朋友来说,这种讲述方法引人入胜,易于理解,非常值得一读。
本书是一本很好的Scrum入门书籍,希望它能够带你进入敏捷的世界,开始敏捷软件工程的实践之路。
IBM研发中心首席技术官 毛新生








点击看大图










加载中...

