敏捷开发实践记录

该文档是一个翻译版本，里面涉及的内容都是作者的团队在实施敏捷开发的过程中的真实写照.对已经开发实施敏捷开发或准备实施敏捷开发的团队有非常重要的指导意义.硝烟中的 Scrum和XP我们如何实施 Scrum作者: Henrik Kniberg译者:李剑审校:郑柯C 2008 C4 Media Inc版权所有C4 Media是 nfoQ. com这一企业软件开发社区的出版商本书属于 Infor企业软件开发丛书如果您打算订购INfoq的图书,请联系books@c4media.com未经出版者预先的书面许可,不得以任何方式复制或者抄袭本书的任何部分,本书任何部分不得用于再印刷,存储于可重复使用的系统,或者以任何方式进行电子、机械、复印和录制等形式传播。本书提到的公司产品或者使用到的商标为产品公司所有如果读者要了解具体的商标和注册信息,应该联系相应的公司英文版责任编辑: Diana plesa英文版封面设计: Dixie Press英文版美术编辑: Dixie Press中文版翻译:李剑中文版审校:郑柯中文版责任编辑:霍泰稳中文版美术编辑:吴志民欢迎共同参与 Infor中文站的内容建设工作,包括原创投稿和翻译等,请联系editors@cn.infog.com。1098765321目录译者序致谢序 JEFF SUTHERLAND序— MIKE COHN前言—嘿, SCRUM成了!简介免责声明撰写本书的原因ScRUM到底是什么?我们怎样编写产品 BACKLOG额外的故事字段我们如何让产品 BACKLOG停留在业务层次上2234678我们怎样准备 SPRINT计划我们怎样制定SPR|NT计划10为什么产品负责人必须参加.为什么不能在质量上让步12无休止的 SPRINT计划会议13SPRINT计划会议日程.………………14确定 SPRINT长度15确定 SPRINT目标决定 SPRINT要包含的故事17产品负责人如何对 SPRINT放哪些故事产生影响?18团队怎样决定把哪些故事放到 SPRINT里面?20我们为何使用索引卡,26定义“完成30使用计划纸牌做时间估算...30明确故事内容….32把故事拆分成更小的故事33把故事拆分成任务34定下每日例会的时间地点36最后界限在哪里………………36技术故事…37BUG跟踪系统VS.产品 BACKLOG40SPRINT计划会议终于结束了!我们怎样让别人了解我们的SPR|NT42我们怎样编写 SPRINT BACKLOG…45SPR| NT BACKLOG的形式45任务板怎样发挥作用····..·.··.·······47例1—首次每日 SCRUM之后47例2—几天以后49任务板警示标记52嘿,该怎样进行跟踪呢?...55天数估算VsS.小时估算55我们怎样布置团队房间.56设计角.56我们怎样进行每日例会我们怎样更新任务板…….61处理迟到的家伙62处理“我不知道今天干什么”的情况……63我们怎样进行 SPRINT演示65为什么我们坚持所有的 SPRINT都结束于演示….65SPRINT演示检查列表..66处理“无法演示”的工作.....…….67我们怎样做 SPRINT回顾.68为什么我们坚持所有的团队都要做回顾……68我们如何组织回顾69在团队间传播经验71变,还是不变71SPRINTS之间的休整时刻………........74我们怎样制定发布计划,处理固定价格的合同.…..17定义你的验收标准77对最重要的条目进行时间估算78估算生产率80统计一切因素,生成发布计划81调整发布计划82结对编程.………...…………83测试驱动开发(TDD).84增量设计87代码集体所有权88充满信息的工作空间88代码标准音音音音音音音音音音音音音音音·音音音音音8可持续的开发速度/精力充沛的工作.…89我们怎样做测试…….….….……………90你大概没法取消验收测试阶段.90把验收测试阶段缩到最短把测试人员放到 SCRUM团队来提高质量92在每个 SPRINT中少做工作来提高质量94验收测试应该作为 SPRINT的一部分么?……94SPRINT周期vs.验收测试周期95别把最慢的一环逼得太紧.回到现实.100我们怎样管理多个 SCRUM团队…,101创建多少个团队.....….….….101为什么我们引入“团队领导”的角色106我们怎样在团队中分配人手....107是否使用特定的团队?…:108是否在 SPRINT之间重新组织团队?112兼职团队成员……………13我们怎样进行 SCRUM-OF- SCRUMS.113交错的每日例会116救火团队…117是否拆分产品 BACKLOG?8代码分支123多团队回顾.124我们怎样管理地理位置上分布的团队125离岸126在家工作的团队成员128SCRUM MASTER检查列表129SPRINT开始阶段……129每一天129在 SPRINT结束时………….…….……130额外的话131推荐阅读……132有关作者133译者序孙子兵法有云:兵无常势,水无常形,能因敌变化而取胜者谓之神。很多人都向往用兵如神的境界,想必也知道读万卷书不如行万里路,纸上谈兵的故事更是耳熟能详;但偏偏不能举一反」且看风清扬的一段话:“……你将这华山派的三四十招融合贯通,设想如何一气呵成,然后全部将它忘了,忘得干干净净,一招也不可留在心中。待会便以甚么招数也没有的华山剑法,去跟田伯光对打”。如果有人说,既然“无招胜有招”是武学的最高境界,那干脆什么招数都不要学,拿把剑乱挥乱舞,处处破绽,也就处处无破绽,便是天下第一了。听到这话的人肯定会笑他太缺心眼。我在这里不想解释为什么上面那种说法缺心眼,因为只要不是缺心眼的读者就肯定能够理解说他缺心眼的理由。但有句话叫做“不识庐山真面目,只缘身在此山中”。对待离自身尚远的事物时,人们可以把它分析的淋漓尽致;但到了自己身上,就往往成了当局者迷,旁观者清。譬如青春、譬如爱情、譬如敏捷软件开发。我想,这本书的读者大概都知道,现如今敏捷开发是何等炙手可热的程度,但潮流一起,跟风者势必有之。虽然没法在这篇短短的序中逐一批驳,大家也可以仔细思索一下,在周边是否存在缺心眼的做法。比如,把 bad smells背下来以后就大谈重构的好处;版本控制、缺陷跟踪、配置管理等一无所有,便一味追求持续集成;单元测试还不会写,就疯狂宣传测试驱动开发……这些都还好,只要没有把敏捷等同于迭代,等同于又敏又捷,又快又爽;这也无所谓,只要没有在实际上对敏捷一无所知、对想要达到的目标不甚了了对项目中存在的问题视若无睹的情况下宣传敏捷、推行敏捷就可以了。但如果前面那些条件都吻合,最后这一点还能不满足么?其实,敏捷不是说出来的,是干出来的。是为序。李剑于小女出生43天之际致谢本书初稿完成仅用了一个周末,但很显然:那是一个超高强度工作的周末!投入程度高达150%:0)感谢我的妻子 Sophia和两个孩子Dave与 Jenny,我那个周末扔下她们独自工作,她们对此表示了宽容;还应该感谢 Sophia的父母Bva和J6rgen,在我忙碌的时候,他们过来一起照看了整个家庭同时,还应该感谢在斯德哥尔摩 Crisp工作的同事,还有scrumdevelopment yahoo讨论组的成员,他们一起校稿,提出了很多改进意见最后,我要深深感谢所有的读者,从你们长期的反馈中我收获颇丰尤其要指出,能够通过本书点燃许多人尝试敏捷软件开发的热情,这让我感到特别开心!