-999% 火龙果·整理 uml.org.cn 第1章 敏捷开发和Scrum 敏捷软件开发越来越流行了，而且基本深入人心。技术水平高的人尤其推崇。 当我们学习编程时，本性都是敏捷的，谁都不想浪费时间。只是进入企业（不管大小） 后，由于管理的需要，产生了不必要的浪费，也就显得不太敏捷了。 瀑布V模型在早期开发周期长，需求变化少的情况下还是很不错的，只是互联网时代软 件开发技术日新月异，更新越来越快，这又不得不回到原来的思想，精简管理来降低浪费。 由此不要抱怨敏捷，它只是揭开了软件开发的遮羞布而已。 敏捷是由很多技术实践结合在一起的，依靠有经验的开发者去实施。 1.1工作环境 不需要电脑，积极回答问题，并多多提问。 1.2简单历史 敏捷这个术语早期有人叫轻量级(1 ightweight)软件过程，来区别于CM、RUP等重量 级软件过程。后来又觉得本质不是轻重的问题，所以又改成敏捷(Agi1e)。 Manifesto for Agile Software Development We are uncovering better ways of developing Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is,while there is value in the items on the right.we value the items on the left more 图1.1：敏捷宜言 敏捷的技术实践在敏捷出现前就出现了，如持续集成，代码共享，结对编程。甚至是那 些敏捷流派，如XP、Scrum、DD都早就有了。只是这些技术先驱们觉得单打独斗太累，因此
第 1 章 敏捷开发和Scrum 敏捷软件开发越来越流行了，而且基本深入人心。技术水平高的人尤其推崇。 当我们学习编程时，本性都是敏捷的，谁都不想浪费时间。只是进入企业（不管大小） 后，由于管理的需要，产生了不必要的浪费，也就显得不太敏捷了。 瀑布V模型在早期开发周期长，需求变化少的情况下还是很不错的，只是互联网时代软 件开发技术日新月异，更新越来越快，这又不得不回到原来的思想，精简管理来降低浪费。 由此不要抱怨敏捷，它只是揭开了软件开发的遮羞布而已。 敏捷是由很多技术实践结合在一起的，依靠有经验的开发者去实施。 1.1 工作环境 不需要电脑，积极回答问题，并多多提问。 1.2 简单历史 敏捷这个术语早期有人叫轻量级（lightweight）软件过程，来区别于CMM、RUP等重量 级软件过程。后来又觉得本质不是轻重的问题，所以又改成敏捷（Agile）。 图 1.1: 敏捷宣言 敏捷的技术实践在敏捷出现前就出现了，如持续集成，代码共享，结对编程。甚至是那 些敏捷流派，如XP、Scrum、FDD都早就有了。只是这些技术先驱们觉得单打独斗太累，因此
火龙果·整理 uml.org.cn 2第1章敏捷开发和Scrum 在一次聚会中一起创建了敏捷宣言。 1.2.1敏捷流派 从2004年起，敏捷开始展露锋芒，主要原因是恰好互联网企业需要快速开发，快速交 付。他们就顺理成章地采用了敏捷的方式。 同时传统企业开始感受到了压力，碰到了问题，需要改进了，看看别人都敏捷了，开始 跟风（褒义）了，这就碰到了选择的问题。记住，只有等你到了一定的水准后，才能无招胜 有招。早期还是要学些固定套路的，这些套路就是不同的敏捷开发过程。 *邓（极限编程）较早出现在中国的原因，得益于当初翻译的几本书(2001年)，不过 有点极端了，很多传统企业都不能适应。 *Scru是一个框架，概念清晰，比较容易上手（狡猾），当然它还是得和其他实践同步 开展。不管怎么样，Scrum越来越流行了；当然骂声也不少，认为它什么都没讲，太虚 了。实际上他们大多数人把自身的问题归结于Scrum了。 幸FDD(Feature Driven Development)等还有一些其他的过程，声音慢慢就越来越少 了。猜想商业是一方面，推动者的能力或兴趣也是一方面。 这里，我们主要以Scrumi来讲解敏捷，但千万别以为Scrum就是敏捷。可以阅读相关知识来了 解更多的敏捷。 1.3 Scrum基本知识 Scrum是迭代式增量软件开发过程，也是一种敏捷软件开发的框架，通常用于敏捷软件 开发。Scrum在英语的意思是橄榄球里的争球。 1.3.1基本角色 Scrumj是一个包括了一系列实践和预定义角色的过程框架。Scrum中的主要角色包括： *Scrum Master是来确保团队合理的运作Scrum,.并帮助团队移除实施中的障碍。 ◆产品负责人(PO:Product Owner),确定产品的方向和愿景，定义产品发布的内容、优 先级及交付时间，为产品负责。 ◆开发团队(Team),一个跨职能的小团队，人数5-9人，团队拥有交付可用软件需要的各 种技能。 WEEK 图1.2：Scrum框架 Ihttp://agilemanifesto.org/iso/zhchs/ 2http://zh.wikipedia.org/wiki/Scrum
2 第1章 敏捷开发和Scrum 在一次聚会中一起创建了敏捷宣言1。 1.2.1 敏捷流派 从2004年起，敏捷开始展露锋芒，主要原因是恰好互联网企业需要快速开发，快速交 付。他们就顺理成章地采用了敏捷的方式。 同时传统企业开始感受到了压力，碰到了问题，需要改进了，看看别人都敏捷了，开始 跟风（褒义）了，这就碰到了选择的问题。记住，只有等你到了一定的水准后，才能无招胜 有招。早期还是要学些固定套路的，这些套路就是不同的敏捷开发过程。 * XP（极限编程）较早出现在中国的原因，得益于当初翻译的几本书（2001年），不过 有点极端了，很多传统企业都不能适应。 * Scrum是一个框架，概念清晰，比较容易上手（狡猾），当然它还是得和其他实践同步 开展。不管怎么样，Scrum越来越流行了；当然骂声也不少，认为它什么都没讲，太虚 了。实际上他们大多数人把自身的问题归结于Scrum了。 * FDD（Feature Driven Development）等还有一些其他的过程，声音慢慢就越来越少 了。猜想商业是一方面，推动者的能力或兴趣也是一方面。 这里，我们主要以Scrum来讲解敏捷，但千万别以为Scrum就是敏捷。可以阅读相关知识来了 解更多的敏捷。 1.3 Scrum 基本知识 Scrum2是迭代式增量软件开发过程，也是一种敏捷软件开发的框架，通常用于敏捷软件 开发。Scrum在英语的意思是橄榄球里的争球。 1.3.1 基本角色 Scrum是一个包括了一系列实践和预定义角色的过程框架。Scrum中的主要角色包括： * Scrum Master是来确保团队合理的运作Scrum，并帮助团队移除实施中的障碍。 * 产品负责人(PO: Product Owner)，确定产品的方向和愿景，定义产品发布的内容、优 先级及交付时间，为产品负责。 * 开发团队(Team)，一个跨职能的小团队，人数5-9人，团队拥有交付可用软件需要的各 种技能。 图 1.2: Scrum框架 1http://agilemanifesto.org/iso/zhchs/ 2http://zh.wikipedia.org/wiki/Scrum
火龙果·整理 uml.org.cn 1.4节相关知识 3 1.3.2框架过程 在每一个Sprint(两到四周的周期，其长度由开发团队决定)当中，开发团队创建可用 的（可以随时推出）软件的一个增量。每一个Sprint所要实现的功能来自产品待办事项列表 (Product backlog)。 产品待办事项列表是按照优先级排列的要完成的工作的概要需求，在团队的计划会议 (Planning meeting)中，Po给出各个功能的优先级，开发团队一起决定在下一次Sprint中 他们能够承诺完成多少功能，这就形成了Sprint待办事项列表(Sprint backlog) 在Sprinti过程中，没有人能够变更Sprint待办事项列表，这意味着在Sprint中需求是被 冻结的(o Change)。 每日站立会议(Daily standup meeting)一般定在早上，持续10分钟左右，每个团队成 员需要回答三个问题来了解整个的运行情况和潜在的风险： 幸昨天你完成了哪些工作？ 幸今天你打算做什么？ *完成你的目标是否存在什么障碍？ 在Sprint结束时，会有一个评审会议(Review meeting)来检查一下功能是否按照产品负责 人要求地完成了，质量应该是由团队保证的，而不是产品负责人或其他人负责。 评审会议后的回顾会议(Retrospective meeting)是团队自己帮助自己发现问题，并提 出行之有效的方式进行提高，所以这不是由其他人来组织的。 1.3.3常用的实践 管理Scrumi过程有很多实施方法，如即时贴(yel1 ow stick)、燃尽图(burndown chart )、白板(whiteboard)。Scrum:最大的好处之一是它非常容易学习，而且启动Scruml应用并不 需要太多的投入。 NoT CHECKED OUT DONE! SPRINT GOAL:SETA-REAOY RELEASE! CHECKED OUT UNPLANNED ITEMS 图1.3：每日例会中的任务白板（图来自《硝烟中的Scrumi和XP》一书） 1.4相关知识 敏捷这个范畴很大，在过程这个方面，建议看看XP和Lean、看板等内容
1.4节 相关知识 3 1.3.2 框架过程 在每一个Sprint（两到四周的周期，其长度由开发团队决定）当中，开发团队创建可用 的（可以随时推出）软件的一个增量。每一个Sprint所要实现的功能来自产品待办事项列表 （Product backlog）。 产品待办事项列表是按照优先级排列的要完成的工作的概要需求，在团队的计划会议 （Planning meeting）中，PO给出各个功能的优先级，开发团队一起决定在下一次Sprint中 他们能够承诺完成多少功能，这就形成了Sprint待办事项列表（Sprint backlog)。 在Sprint过程中，没有人能够变更Sprint待办事项列表，这意味着在Sprint中需求是被 冻结的(No Change)。 每日站立会议（Daily standup meeting）一般定在早上，持续10分钟左右，每个团队成 员需要回答三个问题来了解整个的运行情况和潜在的风险： * 昨天你完成了哪些工作？ * 今天你打算做什么？ * 完成你的目标是否存在什么障碍？ 在Sprint结束时，会有一个评审会议（Review meeting）来检查一下功能是否按照产品负责 人要求地完成了，质量应该是由团队保证的，而不是产品负责人或其他人负责。 评审会议后的回顾会议（Retrospective meeting）是团队自己帮助自己发现问题，并提 出行之有效的方式进行提高，所以这不是由其他人来组织的。 1.3.3 常用的实践 管理Scrum过程有很多实施方法，如即时贴(yellow stick)、燃尽图（burndown chart )、白板(whiteboard)。Scrum最大的好处之一是它非常容易学习，而且启动Scrum应用并不 需要太多的投入。 图 1.3: 每日例会中的任务白板（图来自《硝烟中的Scrum和XP》一书） 1.4 相关知识 敏捷这个范畴很大，在过程这个方面，建议看看XP和Lean、看板等内容
火龙果·整理 uml.org.cn 4 第1章敏捷开发和Scrum 1.5 课后练习 学会使用白板来做团队任务的分配，并且开始体会团队合作和企业中的工作任务和以前 的不同。 ◆在Wiki系统中，各自创建自己的个人主页。 ◆敏捷团队到底要不要团队组长(Team leader),简单阐述想法，记录在Wiki中。 *一个敏捷团队几个人是最适合的，简单阐述想法，记录在Wki中。 ◆Scrum/周期多长是最合适的，简单阐述想法，记录在iki中。 1.6小结 敏捷听起来很虚，但是实际上回归了软件开发的本质，关注需求，团队合作，不断进 步。 1.7参考阅读 幸硝烟中的Scrumz和XP:http:/ww.infoq.com/cn/minibooks//scrum-xp-from-the-trenches 幸看板和Scrum-一一相得益彰：http:/www.infoq.com/cn/minibooks/,kanban-scrum- minibook-cn 幸你的Scrumt检查列表：http:/www.infoq.com/cn/minibooks/scrum-checklists-cn What is scrum?http://www.scrumalliance.org/pages/what_is_scrum
4 第1章 敏捷开发和Scrum 1.5 课后练习 学会使用白板来做团队任务的分配，并且开始体会团队合作和企业中的工作任务和以前 的不同。 * 在Wiki系统中，各自创建自己的个人主页。 * 敏捷团队到底要不要团队组长（Team leader），简单阐述想法，记录在Wiki中。 * 一个敏捷团队几个人是最适合的，简单阐述想法，记录在Wiki中。 * Scrum周期多长是最合适的，简单阐述想法，记录在Wiki中。 1.6 小结 敏捷听起来很虚，但是实际上回归了软件开发的本质，关注需求，团队合作，不断进 步。 1.7 参考阅读 * 硝烟中的Scrum和XP: http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches * 看板和 Scrum——相得益彰： http:// www.infoq.com/ cn/ minibooks/ kanban-scrumminibook-cn * 你的Scrum检查列表：http://www.infoq.com/cn/minibooks/scrum-checklists-cn * What is scrum? http://www.scrumalliance.org/pages/what_is_scrum
火龙果·整理 uml.org.cn 第2章 版本控制Git和代码审阅Gerrit 如果你还停留在SN阶段，或者从没有玩过Git,那太落伍了。Git是版本控制的一个飞 跃，它极大的提高了软件开发的效率。 代码审阅有好几种方式，走读式效果不佳（有点事后诸葛亮的味道），结对编程(Pir Programming)一直是蛮多人推荐的方式，但真正在企业中实施成功的不是很多，不过还是 值得推荐的。 基于Gerrit方式的代码审阅有很多的优点，能很好得满足企业的需要。 2.1工作环境 *服务器端推荐用Gerrit http:/code.google.com/p/gerrit/ *客户端用Windowsh版的Git:http:/code.google.com/p/msysgit/, 2.2什么是Git Git最早是Linus用于Linuxf内核开发的版本控制工具。与常用的版本控制工具CVS、Subversion 等不同，它采用了分布式版本库的方式，不需服务器端软件支持，使源代码的发布和交流 极其方便。 Git的速度很快，既然它能应付Linux kerneli这样的大项目，那么相信对大多数的企业 软件的协作开发和代码量，它也是能胜任的。 Git最为出色的是它的合并跟踪(Merge tracing)能力和强大的社区支持。 2.2.1集中式和分布式 企业常用的SVN和ClearCase是集中式版本控制系统，服务器架在IT环境中，本地只是签 出代码的一个快照。很多操作如历史记录查询都必须要连接到服务器才行。只要依赖网络， 就会带来不必要的麻烦，比如在家办公。 分布式顾名思议就是代码仓库是可以分布在各处的，那样你就可以做很多以前必须要配 置管理员参与的事情，如分支。当然它也带来一定的复杂性，早期可能还不太适应。有兴趣 的朋友可以在附录B看看我的一些推广经验：“企业版本控制的改革：走向Gt
第 2 章 版本控制Git和代码审阅Gerrit 如果你还停留在SVN阶段，或者从没有玩过Git，那太落伍了。Git是版本控制的一个飞 跃，它极大的提高了软件开发的效率。 代码审阅有好几种方式，走读式效果不佳（有点事后诸葛亮的味道），结对编程（Pair Programming）一直是蛮多人推荐的方式，但真正在企业中实施成功的不是很多，不过还是 值得推荐的。 基于Gerrit方式的代码审阅有很多的优点，能很好得满足企业的需要。 2.1 工作环境 * 服务器端推荐用 Gerrit http://code.google.com/p/gerrit/ * 客户端用Windows版的Git：http://code.google.com/p/msysgit/ 2.2 什么是Git Git最早是Linus用于Linux内核开发的版本控制工具。与常用的版本控制工具 CVS、Subversion 等不同， 它采用了分布式版本库的方式，不需服务器端软件支持，使源代码的发布和交流 极其方便。 Git的速度很快，既然它能应付Linux kernel这样的大项目，那么相信对大多数的企业 软件的协作开发和代码量，它也是能胜任的。 Git最为出色的是它的合并跟踪（Merge tracing）能力和强大的社区支持。 2.2.1 集中式和分布式 企业常用的SVN和ClearCase是集中式版本控制系统，服务器架在IT环境中，本地只是签 出代码的一个快照。很多操作如历史记录查询都必须要连接到服务器才行。只要依赖网络， 就会带来不必要的麻烦，比如在家办公。 分布式顾名思议就是代码仓库是可以分布在各处的，那样你就可以做很多以前必须要配 置管理员参与的事情，如分支。当然它也带来一定的复杂性，早期可能还不太适应。有兴趣 的朋友可以在附录B看看我的一些推广经验：“企业版本控制的改革：走向Git