2012-04-07 17:04:57 silkcity 阅读数 1099
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

Scrum为项目执行提供了可靠的、已被证实的基础。但是,在每个项目中,Scrum都必须根据具体需求和环境进行调整,这是项目成败的决定性因素。在这篇文章中,将会介绍如何成功地完成了一个大型的(20人年,超过十万行代码)、分布式(开发人员位于印度和荷兰)Scrum项目,而这个项目曾经在传统开发方式下被废弃过 。为了帮助读者顺利运作大规模项目,在这里我也会历数我们的经验教训,包括:项目启动、找到合适的产品负责人、估算的重要性、有效沟通、测试、文档。

  背景

  荷兰铁路可以跻身于世界上使用量最大的铁路系统之列,每天要运送120万乘客。该部门打造了一套全新的信息系统,为乘客提供更准确的列车信息,减少人为干预。作为该系统的一部分,我们做了这个PUB发布系统,对所有车站中的信息显示和音频广播做集中控制。

  有人之前试过完成这个PUB系统,但是他们当时用的是传统的瀑布方法。客户把详细的需求文档规范交给了开发商,然后放任自流,等着完整的系统成形交 付。三年之后,这个项目被取消掉了,因为开发商没能开发出一个可以工作的系统来。然后客户雇佣了我们公司从头做起,我们引入了敏捷开发方式,用上了 Scrum,跟客户紧密协作,开放交流,小步前进。

  起步

  项目开始的时候,我们在第一个sprint开始前安排了一个启动阶段,耗时三周,准备好了sprint中所需的一切。这个启动阶段由一个项目经理,一个架构师和一个Scrum_master参与完成。

  选择产品负责人是个很有难度的事情,我们找不到一个人能够有时间、具备领域知识、而且有权利设置需求优先级。我们提名了两个业务分析师来一起承担产 品负责人的职责。他们能抽出时间来,而且他们从前也参与过构建PUB的工作,所以业务知识很丰富,足以担当起产品负责人的角色,为多组客户充当优秀的代 理。有关优先级的和范围的高级决策,是由客户委任的项目经理负责,但是他时间不够用,对于需求的理解也有所欠缺。一般情况下大家的配合还可以,但偶尔项目 经理也会对(他所缺席的)计划会议上制定的优先级进行调整,于是这个会议就得重新来过。在理想状态中,对优先级有最终决策权的人应当每次都参加sprint计划会议。

  因为先前有人试着构建过PUB系统,所以有些部分的详细需求文档已经是现成的了。它们遵守了MIL标准[1],不过其形式不适于敏捷计划和估算 [2],因为在敏捷开发中,需求应当被组织成小块的段落,每一块都可以在一个sprint中进行实现、测试和演示,但是现有的文档与此要求不符。产品负责 人也没有多少编写用户故事的经验,为了解决这个问题,Scrum_master帮他们弄出了最原始的产品backlog,里面放着一些细粒度的、经过估算的用户故事,供前几个迭代使用。

  我们所构建的软件只是某个大型软件系统的一部分,它还包括很多相关的软件系统,那些系统负责显示信息,还要在车站内安装相关显示设备。我们得保证每 件事情都可以按时完成,才能把复杂的系统理顺。所以需要有一个整体的计划方案。经历了几次迭代,我们对系统的各个功能都按照自己的最大能力做出估算,这个 问题也解决掉了,而且也有了一个比较靠谱的生产率。于是就可以用发布版本燃尽图来记录和沟通进度了。这里我们学到的东西就是,即使是信息量很少的情况下, 有估算也比没估算好。

  扩展到分布式团队

  项目启动以后,一开始只有7个人,两星期一迭代。项目从一开始就计划着要用到印度的一些人力,所以从第一个sprint开始就有两个印度开发人员进入了团队。他们来到客户现场参与开发,用了六周时间熟悉领域知识、用户代表和团队其他成员。

  建立团队伊始,就要决定如何协作。我们跟所有团队成员一起——也包括印度同事——组织了一个“规范和章程 ”活动。我们定下来一些实践方式,如怎样做结对、用哪些工具、质量目标、每天的核心工作时间等等。然后在Wiki上记录下来。整个团队有了共识,事情就好 办多了。一旦这些共识需要修改,比如在回顾会议上提出改进,这些实践就要在wiki上更新,这样有新人加入的时候,他们看到的总是最新内容。

  在前几个迭代里面,团队成功地构建、测试、验证了组成系统核心的用户故事。这让客户很满意,尤其是跟过去相比,我们的进度更快,而且客户对项目的方向也有掌控权。

  几个迭代以后,我们就扩展了项目:印度的开发人员返回本国,然后我们在印度和荷兰都增加了资源,这样变成了两个Scrum团队,每个团队5个开发人 员,共享同一个测试人员。过后又变成了三个团队,一共三个测试人员。每个团队都既有印度员工,又有荷兰员工。这种方式让项目保持了很高的生产率和工作质量。

  那我们是怎样异地协同工作的呢?首先,我们频繁使用Skype。我们都有网络摄像头、耳机、麦克风,还有个大屏幕。所以我们既能一对一开会,也能全 体参会。这些都用的是现成的东西和免费软件。没多花多少钱,只是用UPS保证断电的时候也能继续开Skype会议,这样提高了印度那边的网络联系能力。其 次,只有在同一个地方的人才做结对。也就是说印度的人跟印度的人结对,荷兰的人跟荷兰的人结对。经验告诉我们,不管现在有了哪些工具,结对编程所需的交互 协作还是需要两个人坐在一起的。

  最后,我们用ScrumWorks记录谁在做什么事情,记录Sprint的进度。因为我们是分布式团队,所以这个比白板要好得多。在跟产品负责人讨论产品backlog的时候,ScrumWorks也起了很大作用。

  在实施这种分布式模型的时候,我们也战胜了很多困难。例如,产品负责人不习惯说英语。按照Scrum的说法,计划会议分成两部分,在第一部分中,产 品负责人给团队讲述用户故事,并且设置优先级。因为这种语言障碍的存在,这一部分的会就只让荷兰团队参加了。第二部分通常是大家讨论具体任务,做估算。这 部分是跟印度团队一起用Skype来完成的,说的是英语,产品负责人不参加。我们还多花一些时间来沟通第一部分会议的内容。Sprint演示也只在荷兰进 行。完成以后,荷兰团队再写封内部简报,告知印度团队——也包括公司其他人——演示的结果。事实证明,这个内部简报深受欢迎。

  拆出一个只关注架构的团队

  我们的项目只是整个应用链条中的一部分,必须要跟客户现有的IT基础架构无缝挂接。虽然我们的产品负责人对核心功能需求非常熟悉,但是在安全、日 志、可用性、性能等方面就所知甚少了。要从客户的组织中了解这些需求难度很大,因为这得跟不同部门中的许多人沟通讨论。这种调查工作给Scrum的迭代节 奏拖了后腿。为了解决这个问题,我们创建了一个独立团队,他们只关注架构方面的内容。他们的工作就是弄清楚非功能性需求,好让我们把它们转换成 backlog中的用户故事。我们用“Scrum of Scrum”会议来跟特征团队沟通。我们都喜欢这种方式,因为特征团队可以全速前进。而且有些员工也喜欢在“架构团队”中工作。

  文档

  客户要求大量的文档,而且还要符合MIL文档规范。还要用荷兰语写。很明显,这项工作只能由荷兰人来干。而且开发跟测试都不熟悉MIL规范,写用户 手册这样的文档也不是他们所擅长的。所以我们决定雇一个曾经写过MIL文档的技术文案。开发跟测试可以继续关注于各自职责。这个做法也很成功,不过我们发 现这也要求技术文案和其他团队成员之间也要有大量的沟通交流,这是需要引起注意的,因为开发人员只想“做他们该做的事情”。

  需求管理

  我们的产品负责人是一些业务分析师,他们习惯于用荷兰语写出大量的需求文档。而在我们的过程中,只要backlog中有用户故事,产品负责人也能在 计划会议上做解释,这就足够了。但是客户又要求有很多文档。所以我们打算和产品负责人一起把需求翻译成用户故事。结果就是需求被放在了两个地方:需求文档 和 backlog。当需求发生变化的时候就会导致问题。我们做了大量的辅导工作,确保产品负责人不仅仅是关注需求文档,也要负责backlog。

  有了一行文字表达的用户故事,再加上产品负责人的解释,我们的Scrum团队就可以构建和测试软件了。不过需求文档对外部的测试团队做测试还是很有价值的,虽然在好些迭代里面,我们很难把实现的用户故事跟需求文档中的某些部分“映射”起来。

  回顾从前,我们其实一直都没有一个理想的需求管理过程。我们只是尽了最大努力,来应对这相互冲突的需求:我们需要用户故事,客户需要详细的需求文档。

  Scrum为项目执行提供了可靠的、已被证实的基础。但是,在每个项目中,Scrum都必须根据具体需求和环境进行调整,这是项目成败的决定性因素。在这篇文章中,将会介绍如何成功地完成了一个大型的(20人年,超过十万行代码)、分布式(开发人员位于印度和荷兰)Scrum项目,而这个项目曾经在传统开发方式下被废弃过。为了帮助读者顺利运作大规模项目,在这里我也会历数我们的经验教训,包括:项目启动、找到合适的产品负责人、估算的重要性、有效沟通、测试、文档。

  测试

  我们在项目中做了自动化测试,保证在每个Sprint结尾的时候都可以交付经过测试的软件,不带有回归的bug。即使随着系统扩展,我们还是做到了在8人的Scrum团队中只安排一个测试人员,而且保证了高质量:外部测试团队最多也就是能在每千行代码中发现一个缺陷。

  我们的自动化测试包括两部分:单元测试和验收测试。在前者中,我们用的是JUnit,用Clover度量测试覆盖率,我们的目标是服务器端代码的测试覆盖率达到80%。验收测试用FitNesse作自动化。每个完成的用户故事,都会在FitNesse上有一套验收测试。有了庞大的测试套件,就能在Sprint中找到并修复回归的bug。这种做法还有另外一个好处,就是测试人员从一开始就可以积极参与,在用户故事实现之前编写测试用例。

  有一个地方让我们苦恼了很久。这个系统有一部分是一个用户界面很复杂的富客户端。对这东西做自动化测试要比对服务端做测试难得多。所以在UI方面的功能我们大部分还是依靠手工操作。随着系统的增长,回顾测试所花的时间就越来越长,更糟的是,外部团队只在这部分系统中会发现回归bug。如果有了自动化测试就能防止这一点。我们由此学到了一点,即便是自动化测试很困难,为它付出些努力,迟早会获得回报,尤其是在项目晚期。

  产出成果

  客户对我们的工作很满意。说点马后炮的话,跟大多数项目一样,功能、时间、预算都会随着项目进度发生变化,所以“按时按预算”完成只是个很模糊的完成标准而已。更为重要的是,我们在项目进程中常常跟客户讨论怎样把项目做好,他们都很满意。不幸的是,因为其他系统中的问题,产品在全国范围内部署的时候出了麻烦。

  客户找了外部的审核公司来审核这个软件。他们的结论是:

  1.系统的可维护性非常好。

  2.源码质量非常高。

  在审核公司的报告中,他们说他们从来没有给过一个项目这么多正面评价。

  总结

  下面是我们从这个项目中学到的最重要的几点:

  1.很难找到一个既有丰富的需求知识、又有权利设置优先级的产品负责人。所以人们往往都要用几个人一起扮演产品负责人的角色,尤其是在大型项目里面。

  2.如果一定要按期完成工作,那就得保证产品backlog的完整,也要做好估算。对需求而言,即便信息量很小,有估算也比没估算的好。把估算跟团队生产率合并以后,发布计划就有了必要的信息。

  3.Scrum对多个分布式团队很适用。我们每个Scrum团队都既有荷兰人又有印度人,这很好地发挥了团队精神,让我们注重有效沟通。在沟通中,利用现成的硬件和免费软件能节省成本。

  4.在启动分布式项目的时候,先把大家都聚到同一个地方,让大家对团队实践达成一致,这点效果很好。

  5.对于不适合放到Scrum Sprint中的工作(比如寻找关键人员,跟其他客户部门交流),可以让一个单独的团队去做,这样效率更高。特性团队可以集中精力开发软件。有一个专职的技术文案也很好,即便这会增加沟通成本。

  6.虽然软件开发过程不需要大量的需求文档,但客户可能需要。不过在Scrum项目中,需求文档代替不了用户故事。如果既有需求文档,又有用户故事,那就得在做计划的时候,就要考虑到在两个地方协调需求的额外开销。

  7.在增量式交付软件的过程中,自动化测试发挥着关键性作用,它可以排除回归bug的干扰。在项目结束之前,投资回报会高过成本的。

 

原文出处:

http://tech.it168.com/a2009/0818/629/000000629869_4.shtml

http://www.searchsoa.com.cn/Print_23898.htm

2007-11-06 23:01:00 szjerrywangyong 阅读数 308
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师
http://www.itpub.net/868217.html
2008-09-14 22:49:00 scrumcn 阅读数 670
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

 

内容简介

在这本书中,享誉全球的软件开发专家和软件工程大师Robert C.Martin将向您展示如何解决软件开发人员、项目经理及软件项目领导们所面临的最棘手的问题。这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。
  ·讲述在预算和实践要求下,软件开发人员和项目经理如何使用敏捷开发完成项目。
  ·使用真实案例讲解如何用极限编程来设计、测试、重构和结对编程。
  ·包含了极具价值的可多次使用的C++和JAVA源代码
  ·重点讲述了如何使用UML和设计模式解决面向客户系统的问题

目录

第Ⅰ部分 敏捷开发
第一章 敏捷实践
第二章 极限编程概述
第三章 计划
第四章 测试
第五章 重构
第六章 一次编程实践

第Ⅱ部分 敏捷设计
第七章 什么是敏捷设计
第八章 单一责任原则(SRP)
第九章 开放—封闭原则(OCP)
第十章 Liskov替换原则(LSP)
第十一章 依赖倒置原则(DIP)
第十二章 接口隔离原则(ISP)

第Ⅲ部分 薪水支付案例研究

第十三章 COMMAND模式和ACTIVE OBJECT模式
第十四章 TEMPLATE METHOD模式和STRATEGY模式:继承与委托
第十五章 FACADE模式和MEDIATOR模式
第十六章 SINGLETON模式和MONOSTATE模式
第十七章 NULL OBJECT模式
第十八章 薪水支付案例研究:第一次迭代开始
第十九章 薪水支付案例研究:实现

第Ⅳ部分 打包薪水支付系统
第二十章 包的设计原则
第二十一章 FACTORY模式
第二十二章 薪水支付案例研究(第2部分)

第Ⅴ部分 气象站案例研究

第二十三章 COMPOSITE模式
第二十四章 OBSERVER模式——回归为模式
第二十五章 ABSTRACT SERVER模式、ADAPTER模式和BRIDGE模式
第二十六章 PROXY模式和STAIRWAY TO HEAVEN模式:管理第三方API
第二十七章 案例研究:气象站

第Ⅵ部分 ETS案例研究

第二十八章 VISITOR模式
第二十九章 STATE模式
第三十章 ETS框架

  下载

2013-07-26 10:19:48 iteye_15786 阅读数 28
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

敏捷开发一千零一夜(国内首部以真实敏捷实施案例为主线的案例集)

王立杰 主编

ISBN 978-7-121-20818-8

2013年8月出版

定价:49.00元

244页

16开


编辑推荐

覆盖组织转型、产品管理、团队建设、工程实践,解析精彩过程,分享经验教训,揭示敏捷背后的奥秘。

汇集IBM、淘宝、京东、暴风影音等IT名企的敏捷专家经验分享。

内容提要

本书以多位作者的亲身经历,再现真实的敏捷实施过程,描述各个企业在实施敏捷的过程中,遇到的种种问题、解决的思路及最终得到的经验与教训。这本案例集从不同的视角,为读者展示从大型互联网企业到初创公司、从大型国企到独资外企、从典型的甲方到第三方咨询公司的敏捷历程。这里面既有大的组织的敏捷转型,也有一个小团队或个人的敏捷历程,还涵盖某个敏捷实践或工具的应用描述。

本书的特色在于由真实实践提炼,对正在实施敏捷的读者具有很高的参考价值。

目录

第一篇  组  织  篇

第1章  暴风敏捷项目管理实践          2

一、暴风的项目危机     2

二、组织级的敏捷初体验     3

三、再次组织级探索     12

四、持续优化的力量     18

五、组织改进中人的因素     27

第2章  淘宝的敏捷实践与过程改进          35

一、背景介绍         35

二、不同背景下的解决方案         36

三、ScrumMaster心得 50

四、敏捷与过程改进     51

五、工具的支持     54

第3章  从CMMI5到敏捷   57

一、案例背景         57

二、敏捷导入过程         60

三、敏捷优化改进过程         70

四、整体回顾         81

第4章  从装甲兵团到特种部队          83

一、引子         83

二、实施过程         88

三、反思         95

第二篇  产  品  篇

第5章  火星人一千零一夜          98

一、第一个月:一个产品的诞生         98

二、第二个月:框架优先,还是故事群优先     101

三、第三个月:故事树         103

四、第四个月:用户故事的颗粒度(上)         105

五、第五个月:用户故事的颗粒度(下)         108

六、第六个月:用户故事的分类         110

七、第七个月:分类语法     114

八、后记         115

第6章  从敏捷到精益          117

一、背景         117

三、破窗理论         121

四、敏捷宣言错了吗     125

五、南辕北辙         127

六、MVP才是王道         129

七、跨越鸿沟         135

八、小结         136

第三篇  团  队  篇

第7章  敏捷英雄传之火烧赤壁          140

一、人物介绍         140

二、故事梗概         141

三、引子         142

四、CEO孙权的故事:计划永远赶不上变化     144

五、CTO周瑜的故事:究竟是变好,还是变得更烂          148

六、产品经理太史慈的故事:一个大版本经理的困惑     152

七、编码狂人凌统的故事:主刀,就是能上得天堂,下得地狱的主儿         157

八、测试经理陆逊的故事:敏捷测试,就是明知不可为而为之     161

九、产品集成主管甘宁的故事:持续集成的烦恼     162

十、臭皮匠的话     167

第8章  打造学习型自适应团队          168

一、背景介绍         168

二、团队实践过程         169

三、回顾与反思     181

第9章  从传统软件开发到敏捷的初体验          183

一、背景         183

二、迈出第一步     187

三、对第一次迭代的改进     192

四、关键的第三次迭代         196

五、第四次迭代:低耦合软件设计     197

六、总结         199

第10章  敏捷在传统软件与互联网中的应用   200

一、背景介绍         200

二、敏捷实施过程         201

三、回顾与反思     207

第四篇  实  践  篇

第11章  敏捷无它,唯持续改进       210

一、背景介绍         210

二、我与敏捷的第一次亲密接触         210

三、敏捷原来是这样的         211

四、第一个挑战     213

五、团队的好奇心         213

六、更多挑战         214

七、团队的惯性     215

八、镜子         215

九、从一开始就要高标准     216

十、TDD的争议     216

十一、“道”与“术”  217

十二、程序员文化         217

十三、程序员与建筑工人     218

十四、TDD不是目的,“拉”与“推”       218

十五、Coding Dojo 219

十六、让实践落地         219

十七、程序员的产出     220

十八、权威     220

十九、认同权的建立:无私,勇于说不知道     221

二十、成就感:点燃程序员的热情     221

二十一、PDD:痛苦驱动开发      222

二十二、排除障碍,创建舒适的技术环境         223

二十三、投资回报率     223

二十四、让领域模型裸奔     224

二十五、架构         224

二十六、你做什么就是什么(You are what you do)         225

二十七、Scrum是不行的,如果只有Scrum       225

二十八、做正确的事情 vs 正确地做事情 226

二十九、问题和解决方案,5-whys     226

三十、“为什么”  227

三十一、估算(动词)很有帮助,但估算(名词)往往没有         228

三十二、守破离     228

三十三、测试优先         228

三十四、QA vs QC 229

三十五、分享:Wiki、博客、书籍、技术讨论、编程练习      229

三十六、没有银弹,只有持续改进     230

三十七、敏捷宣言         230

第12章  网龙持续集成实践       231

一、案例背景         231

二、案例分享         232

精彩节摘

1.展示板和信息系统的巧妙结合

敏捷例会的展示板每个团队都会实施得不一样。对于进度跟踪,可以采用观察燃尽图的趋势,也可以融合信息系统的做法。

只要不苛刻地挑剔,很多工具都支持Scrum敏捷项目管理,从最简单的白板加Excel,到ScrumWiki、Xplanner、GNATS都能支持Scrum的实施。暴风的团队开始就尝试了Redmine这个缺陷管理工具来配合展示板实施敏捷项目管理。没有好不好用的系统,只要运用合理,抱着极简的思维去使用工具,就能最低成本地发挥工具的作用,至于使用信息系统遇到的各种缺陷或者不能满足管理的功能,还是应该报以宽容的态度。但理想和现实往往经常事与愿违,将就用了一段时间后团队终于不能忍受系统功能的不足,于是开发自己的信息系统的呼声愈演愈烈,最终还是决定开发自己的系统。

还是本着极简的思维方式,系统只围绕包括Sprint任务导入、任务完成更新(工时填报)、燃尽图自动生成、问题的生命周期管理这样几个核心功能进行开发。这样也使得任务板和信息系统的信息完全一致,障碍(问题)也得到了有效的跟踪和管理。

2.配置管理的敏捷实践活动

对于暴风影音的官网版本来说,每个月会有多个官网版本发布,一种是提供给用户新特性验证的β版本,根据用户体验后真实的反馈信息,进行后续产品的优化和完善,另外一种是将已经完成验证的功能和新特性合并到稳定的官网版本中。基本每两周就要交付一个版本,每个项目都感觉时间紧、任务重。配置管理在敏捷实践中起到怎样的作用呢?

暴风转码的敏捷团队在版本V2.1刚刚完成用户故事的开发工作,也就是说,产品已经能运行,系统测试工作还未开展。按照估计测试和修改Bug的周期为一周计算,此一周的时间研发人员会很不饱和,按照公司对人员使用率的要求,通常会启动V2.2版本的开发工作。这样会提高研发人员的利用率,但也会带来两个甚至多个版本同时开发的问题,如果没有好的配置管理,代码会混乱不堪,很多人同时并行两个版本的代码开发工作,一方面改V2.1版本的Bug,另一方面开发V2.2版本的新功能。我们通过配置管理工具的代码分支、代码合并来解决代码管理问题。为V2.1开出代码分支,这样两个版本的代码相互隔离,不会彼此干扰。V2.1版本上的Bug修复工作,对于V2.2的开发同样也适用。这样实现了版本的交替开发,提升了开发人员的使用率。通过代码的分支与合并也能处理好“新特性开发”与“产品稳定”的关系。两种版本经常存在交叠。用分支支持交叠,即防止了前者干扰后者,也防止了后者阻滞前者,这样维持了开发效率和产品质量的平衡关系。

在敏捷开发过程中,变更是被鼓励的。而变更一定会体现在代码中,因此在SVN里,加一些控制以保证开发人员做且只做该做的事。方法是让变更集不由开发人员创建,而是由专门的配置管理员创建,然后指定给相应的开发人员完成。配置管理员会和产品经理、开发负责人和测试负责人沟通达成一致,然后在SVN中完成相应的设置。对于一些比较大的任务,需要多个人协同完成,可以为此开分支,分支也由配置管理人员创建,然后要求开发人员在分支上工作,完成相应任务,同时控制修改代码之后的提交。对于分支版本,只有符合本次版本要求的分支才允许合并到主干。这个工作是配置管理员和敏捷团队协作完成的。配置管理实践中最重要的是要摒弃原来所有的控制思想,让配置管理员作为敏捷项目团队中的一员,和团队共同协商如何管理代码、管理变更,而不像实施CMMI过程中有各种控制和审批环节。

3.敏捷中实施Code Review(代码走查)

技术评审活动是不管是否实施敏捷项目管理都需要进行的一种活动,很多人从来没有搞清楚什么是技术评审、什么是管理评审。技术评审包括需求评审、设计评审、代码Review、测试用例评审等和项目直接结果相关的工程活动的评审。管理评审指的是敏捷项目管理的三个仪式:Sprint规划会、每日例会和Sprint评审会。传统项目管理中的项目立项评审、里程碑评审和验收评审也属于管理评审。简单地总结,技术评审是针对软件工程活动的评审,其目的是通过缺陷预防提升软件的质量,管理评审是针对阶段活动是否可认定为结束、下阶段如何开始,其目的是项目管理活动是否有效,交付的成果是否可接受。

如果借助敏捷项目管理的思想“交付可用的软件”,技术评审在敏捷活动中显得尤为重要,从评审的正式程度上划分,技术评审分为正式评审、技术审查和代码走查三种类型,如下表所示。

评审种类

计划

准备

会议

修正

确认

Inspection(正式评审)

Technical Reviews(技术审查)

Walkthrough(代码走查)

正式评审通常由项目经理主持,邀请项目的核心成员和外部有经验的专家参加,目的在于定位并消除软件中的缺陷。技术审查或称内部评审,通常由技术负责人召集相关人员参加,一般是在模块或功能完成时进行,目的在于通过对交付模块或功能的技术审查,提出改进意见。代码走查又称代码走读,由代码作者来组织,主要是代码质量分析和编程规则检查。一般是在模块或功能完成的早期进行,作者有一定的想法时,希望从其他开发者那里获得一些帮助或补充。由作者主持,目的是进行缺陷预防,提高代码的质量,很多公司已经成功地实施了Code Review和结对编程。

总结第一轮实施敏捷的试点项目,并没有要求实施代码走查活动,项目负责人和开发人员也没有意识进行Code Review。要么是找借口说进度太紧张时间不够用,要么是不知道如何进行代码走查。第一种纯粹是意识问题,要回答不知道怎么进行代码走查的问题则从代码走查的种类开始着手。代码走查分为两种:一种是交叉代码审查,自己的代码由他人来检查,就像检查作业一样;另一种是代码会审,就是以会议的形式,大家共同审核代码的质量。代码走查主要审查的内容包括:是否符合代码规范,确保所有人写的代码基本一致并符合代码规范;代码满足基本用户故事的要求,检查代码的逻辑实现,确认能实现用户故事;代码满足性能等非功能性需求,非功能性需求一般需要借助一定的工具和Code Review人员的能力,针对编码中对于性能影响的瓶颈给出解决方案;代码简化,提高代码的可读性,能够用公用的方法和公用API实现,则无须每人定义自己的实现代码。

随便抽出某开发人员的1000行代码检查的结果是:代码注释不充分,很多实现逻辑的类和方法没有注释;有些代码性能差,频繁地读/写磁盘I/O;有些代码虽然实现了功能需求,但从逻辑上写得太死,不便于扩展;在约定使用统一代码的写日志功能代码作者定义了自己的代码来实现。看来为了提高质量,代码走查是实施敏捷项目管理一定要执行的工作。

4.被修订的测试报告

测试报告是集成测试阶段每天都需要测试工程师编写的一份重要的信息沟通工具,它的目的是让团队所有成员了解当前Sprint交付软件的质量情况,每个开发人员身上有多少未解决的Bug,以及交付模块的质量情况。回顾试点项目的项目测试报告,大概是从百度上搜索的模板,冗长而不知所云。报告中什么编写目的、背景、测试对象、测试概要、测试用例、测试环境等,光标题就会让人眼花缭乱。从正规性上讲,这样的测试报告提交给最终用户无可厚非,但是给团队内部看就没必要这样讲求全面性和规范性了。再引用敏捷思想“可用的软件重于完备的文档”。所以修订测试报告应该是为团队减轻负担、提高沟通效率的一项优先级非常高的优化活动。

问问团队需要什么样的报告。产品团队回答需要了解当前软件的质量来决策是否可发版,以及有些不好解决的缺陷拿出来让团队共同来决策Bug的处理策略。研发团队回答需要了解每个人身上有多少个未解决的缺陷,Bug整体解决情况和各模块的质量。测试团队关注的是Bug整体解决情况及分解下的按模块、按人员缺陷情况。统一思想后的测试报告包括一个测试情况的基本总结和三个部分。

基本情况总结是整个测试报告中最重要的部分,应该用粗体和红色来描述。要求尽量用一两句话描述清楚当前测试的总体情况。例如,当前测试遇到未解决的严重级别缺陷大于3个,不符合发版需求,其中组件下载功能如果点击取消,必崩。第一部分是Bug移除率的统计,其中累计移除率是了解当前Bug整体解决情况的最好的说明,如下表所示为2010年9月23日某项目测试统计数据。

日期

当前

遗留

本日

新增

本日

移除

本日新增未解

累计

新增

累计

移除

本日

移除率

累计

移除率

9/14

120

87

80

58

314

194

92.0%

61.8%

9/15

136

83

67

58

397

261

80.7%

65.7%

9/16

135

81

83

38

478

343

102.5%

71.8%

9/17

105

47

76

29

525

420

161.7%

80.0%

9/18

107

87

84

45

612

505

96.6%

82.5%

9/21

139

73

41

45

685

546

56.2%

79.7%

9/22

137

67

69

50

752

615

103.0%

81.8%

9/23

152

71

49

58

823

671

69.0%

81.5%

成功实施敏捷项目管理的团队一定有疑问,为什么实施敏捷后还有集成测试阶段,看上面的数据为什么质量会那么差,似乎和敏捷倡导的交付可用的软件有冲突。带着这些“十万个为什么”不妨思考一下。

没有实施代码走查导致了大量缺陷,造成的直接结果是必须有个集中测试的阶段来把Bug找出来,每个功能和功能之间并不是独立的,开发人员在开发过程中并没有及时沟通导致了接口不一致等诸多Bug,产品人员没有及时确认交付的功能或模块是否可用甚至提出一些变更也导致了一些缺陷。如此多的原因导致这么多缺陷已经解释了上面的为什么,结论是如果敏捷项目管理实施成这样,基本上可以界定为是一场“形似而神不似”的失败的敏捷尝试了。但也可以肯定的是,这份测试数据总结对团队了解项目当前的总体质量起到了一目了然的作用。

第二部分为Bug人员分布,第三部分为Bug模块分布,分别是按人员和按功能模块的缺陷数据总结。按人员的分布可以看出每个人当日解决的Bug数和剩余Bug数,便于提醒团队及时地解决Bug或者相互协助。按模块的Bug数总结便于提醒团队哪个模块的Bug多,除了了解模块的质量外还有助于提示团队及时进行代码走查来彻底解决质量问题。

5.发布规则,绝不让步

经过再一轮的组织级探索,让团队对于敏捷项目管理的基本原则有了更深入的认识。软件开发的残酷现实告诉我们,即使在敏捷项目管理框架下,没有规则的软件开发过程带来的只可能是无法预料的结果。不管是多么有经验的项目团队,在“响应变化胜于遵循计划”一项上都难以做到。一次次失败的教训告诉我们,我们需要在敏捷框架下设定一些基本规则,而在这些基本规则面前,在保证敏捷思想的前提下不能向规则让步。

软件可用规则:上述的代码走查和测试数据告诉我们,在很多情况下我们交付的用户故事可用实际上是带有很多缺陷的,即使强调了PCT原则,团队交付的功能模块还是不完全可用,所以严格的方法是在燃尽图统计时,所有未完成的(即使是P和C状态都完成了的功能)都不进行统计,这和传统的“0-100”进度统计法则一致。让任何一个团队成员都知道积极参与,因为每一个功能交付如果说可用就一定要可用。

目标导向原则:目标导向是充分调动员工工作积极性的最有效的方法,每个目标都设定卓越和及格的标准,在制订敏捷计划时,就需要明确项目如何做到卓越,并让指标认领到个人。例如,手机端每个滑屏操作的卓越标准是任意滑动的展现在0.6秒以下全部完成。对于开发者来说,近期的Sprint目标总是比远期目标来说更容易看到和达到,这会使每一个Sprint员工的工作效率维持在一个较高的水平。

代码提交原则:很多开发人员在提交代码到配置管理系统时往往不注意是否通过了单元测试和自己代码的质量,这样会给其他人员带来或多或少的麻烦。所以为了提升团队效率,代码的提交必须满足两个硬条件,其一是提交的代码必须经过自己的单元测试,其二是确保提交代码后整体代码可编译通过。在这个原则的基础上,如果能自动化完成的工作绝对要减少人工干预,例如,持续集成和自动化测试尽量按策略自动完成。

有话好好说原则:项目成员理解和赞同用户故事的范围、项目目标吗?开发人员大多数时间都不喜欢发表自己的看法和言论,大家不发表言论意味着他们认同项目范围和目标吗?这一点在项目沟通中极为重要,敏捷教练一定要问每个人,让每个人表达自己的观点,让大家有话好好说,有话桌面上说,不可认为不发言就认为是同意。在对项目目标没有一个共同认识的前提下,团队是不可能成功的。

文档极简原则:敏捷思想并不鼓励书写文档。敏捷宣言也宣告“可用的软件重于完备的文档”,但如果一个软件是长期更新和维护的,还是需要必要的文档来将所有有价值的历史信息记录下来的。你如果刚加入一个敏捷团队来接手一个已经迭代了9个Sprint的软件,如果什么都没有你从哪里下手?但是不希望文档过于庞大,能把用户故事的关键点、设计的关键点记录下来就够了,特别是代码每次变更必须用注释描述清楚。

精英团队原则:众所周知国内软件的成熟度偏低,一个公司能数出几个好的产品经理?又有多少技术高手?其实资源很有限。如果实施敏捷项目管理,必须抱着精英团队的原则,不鼓励团队规模过大。团队规模过大,按照n(n-1)/2的沟通渠道计算公式,沟通成本增加,效率极大降低。特别是很多需要技术难点公关比较多的项目,人数多根本解决不了任何问题。

总之,在不违背敏捷思想的前提下,一些必要的规则是保证项目目标能够达到卓越的必要约束,也是促进团队建设和高效协作的基础。

作者简介

陈勇:在工作的17年间,曾任其程序员、项目经理、事业部总监、副总经理、咨询师等各种技术与管理岗位。开发中获得的一线工程经验和CMMI/FPA功能点估算/敏捷开发等跨领域知识,令其可以更广的视角来理解敏捷开发。

   当前他作为产品经理、架构师带领一个小型团队,从事“火星人敏捷开发在线平台”的研发工作。很多课程与咨询中的最佳实践,均来自于其之前及当前参与的实际项目的一线实践。本书收录的文章就是他们在实际开发过程中,同时应用敏捷开发的用户故事和功能点估算中的功能点时的实际经验总结。

   日常工作与培训之余,陈勇在其博客http://blog.csdn.net/cheny_com上总结编写了300多篇系列文章,点击量150万次,其中200篇以上是敏捷开发相关的文章,力求逐一解决敏捷开发中的一些似是而非的问题,为一线工作人员及敏捷推广者提供完整透彻的应用思路和方法。

 

杜伟忠:中国人民大学管理学硕士,京东商城敏捷教练,精通Scrum、Kanban、XP等敏捷实践。10年电信软件开发经验,6年敏捷实践经验,其中有3年教练经历。作为教练指导团队超过200人,目前专注于互联网公司敏捷的推广和实施。

 

冯国馨:网名“谷雨霖”。天津大学工学博士、PMP  联合永道高级副总裁兼CTO

PMBar IT项目管理实践公益社区创始人、天津大学北京校友会秘书长

曾任神州数码网络研发中心副总经理、质量管理部总经理,现任联合永道高级副总裁兼CTO、联合创始人。美国项目管理学会协会PMI会员、中国国家外专局资深专家、中国系统与软件过程改进协会主任专家会员、中国计算机学会软件工程师工作委员会专家组成员、国家应用软件产品质量监督检验中心特聘专家。长期从事项目管理、产品研发、持续改进与团队管理,对教育信息化建设有一定见解。创办IT项目管理实践公益社区www.pmbar.net,长期积极活跃在CSPI、CSDN CTO俱乐部、IT168等IT管理社区,与用友集团、阿里巴巴集团、盛拓传媒、搜狐集团、安博教育集团、神州数码集团等多家IT单位多次开展沙龙交流活动。

 

王立杰:敏捷爱好者、实践者,独立培训师,专注Scrum与XP。2006年开始探索敏捷,应用敏捷,于2009年与许舟平合作出版国内第一本小说体敏捷项目管理图书《敏捷无敌》;2010年进入敏捷咨询培训领域,为诺基亚、北电、爱立信、VMWare、阿尔卡特-朗讯等多家公司提供服务,曾在AgileChina、ScrumGathering、AgileTour等行业会议发表多次主题演讲。

 

许舟平:本一北国布衣,求学于西,工作于都,躬耕于代码十余载,苟全技术于IT间,不求闻达于海内。

亲实践,远空谈,此敏捷之所以兴隆也;实践者,敏捷之本。盖闻流程者莫高于Scrum,实践者莫高于XP,皆因敏捷而成名。今天下贤者智能,岂特西洋者乎?好友立杰,邀士十余,原始察终,见盛观衰,论考之行,历经春秋,终成此集。

敏捷者,其行虽不轨于瀑布、CMMI等,然其言必信,其行必果,已诺必诚。周易曰:天下一致而百虑,同归而殊途。窃以为,敏捷之事,内立法度,务实践,修研发之具;外连横而协客户,则事可成已。至于XP、Scrum、Lean、Crystal等,各有所用,若欲循观其大旨,可阅此书。

布衣之人,不害于政,不妨百姓,取与以时而行敏捷,仅愿读者有采焉。

 

杨立东:PMP,美国加州州立大学富尔顿分校硕士,中欧国际工商学院EMBA,华中科技大学特聘教授。北京暴风科技股份有限公司董事、首席技术官。2011年第二批“中关村高端领军人才聚集工程” 科技创新人才。发表学术论文4篇。曾从事过6年一线Java开发工作,作为项目经理带领过多个大型软件项目,2006年开始从事CMMI咨询和评估工作,服务过的软件企业超过30家,多次举办项目管理,软件度量,敏捷项目管理的公开课,培训人数超过15000人。2008年开始专注于公司级管理工作,2010年开始总结自己多年的研发管理经验,专注于互联网公司敏捷项目管理的推广和实施。

 

杨瑞:个人简介:厦门英睿信息科技有限公司联合创始人,目前致力于敏捷的推广,研发管理咨询、培训及移动开发。

10年软件工程管理经验,在基于传统和敏捷的开发管理方面具有丰富经验。曾任三五互联产品技术中心总监、福州网龙程序中心高级经理等职位,擅长软件研发管理、过程改进咨询、培训及实施,精通CMM、CMMI及Scrum。

2011、2012年ScrumGathering分享嘉宾,2011、2012年AgileTour厦门站&福州站组织者、分享嘉宾,Agile China2013程序委员会专家,厦门敏捷社区发起人、技术社区积极分子。

 

张克强:思碧睿inspearit高级顾问,高级程序员、系统分析员、IPMP、CSM。

本硕毕业于清华大学。曾在宝信软件担任过测试经理、EPG组长、项目总监,曾在Intel担任过QA Manager,曾在DNV担任过资深咨询师。

在软件工程/系统工程方面拥有10年多经验,主要经历在组织过程改进、质量保证和测试方面,帮助组织参照CMM/CMMI/Agile/Scrum等进行改进,在软件开发技术方法论和流程管理两方面都积累了丰富的经验,熟悉OOAD,UML,TDD, 测试等等。

媒体评论

敏捷是一种方法,更是一种组织能力。那些不懂得敏捷不利用敏捷方法的研发团队,最终将在快速变化、竞争激烈的互联网环境中落败。拥抱敏捷吧,从现在开始!

——京东商城高级副总裁  李大学

 

这是一本很好的讲敏捷的书,本书的作者们并没有生硬地罗列令人费解的理论,而是结合亲身的经历,给读者生动展现了敏捷在IT行业的各种应用场景,令人受益匪浅,非常值得一看。我们也可以从中了解到,任何一种工具或者方法应用到实际工作中时,都不能生搬硬套,而是需要根据具体所在的行业、公司的企业文化以及研发团队的状况进行适当调整,亦可以称之为“本土化”——通过在实践中不断的解决问题,持续优化,使其更适用,更实用,真正的帮助到团队。

——汽车之家CTO  廖志强

前言

前些日子,有人在微博上发文说,现在IT界有三大俗:云计算、大数据、敏捷,这从一个侧面反映出了敏捷的热度!如果你最近一年内参加过各类IT过程改进大会、测试大会、研发管理大会、案例研讨大会,一定会发现有很多人在讲敏捷、谈敏捷,而且占据的场次越来越多。以前是我们这些所谓的敏捷狂热分子在讲,现在连一些CMMI/PMP死硬分子也加入进来讲。敏捷让以前的CMMI/PMP阵营不得不做出调整,PMP搞了敏捷的认证,CMMI新出了1.3版,据说里面有97处提到了敏捷……这从另外的角度说明敏捷的确已经入“俗”。

中国人素来讲究雅俗共赏,在这个越来越“俗”的过程中,我们该怎么保持那份“雅”呢?希望大家在看热闹、参与热闹的同时,能够冷静地思考,敏捷到底能为我们带来什么?我们该如何变得敏捷?敏捷又将何去何从?

大师们也在思考,2011年,敏捷10年回顾的时候,将“追求技术卓越”放在了第一的位置;10年之后,敏捷又将如何呢?著名敏捷大师MikeCohn认为:“在接下来的10年,面向对象世界中发生的事情会再次出现,即我们将不再讨论敏捷。不久前我们不再讨论对象了,因为它们已经胜出,没有人再会参加针对面向对象的大型辩论。当然,还有一些应用我们不使用对象,比如有严格性能要求的应用,也有些项目是用非OO语言开发的。但即使在这些案例中,我也怀疑开发的代码仍然受到对象的影响。我希望敏捷也能达到这一点,我们不再讨论敏捷,不再说‘敏捷软件开发’,我们仅仅说‘软件开发’,当然一定是敏捷的。没有人会问我编写的Ruby代码是否面向对象,因为这毋庸置疑;我希望某一天也没有人问我项目中是否使用了敏捷,这也将会毋庸置疑。”

在过去几年中,我们给客户做敏捷培训时,收集到的最多的反馈之一,莫过于学员想听到更多的敏捷实施案例。于是,慢慢地就有了收集各类敏捷实施案例的想法,并日渐强烈起来。毕竟,每个人都有偷窥别人隐私的好奇心,不然Twitter、微博也就不会这么火了。同理,正在实施敏捷的人,无论自己做得好的,做得不好的,其实都希望看到同行是怎么做的。

冯国馨,作为PMBar IT项目管理公益实践社区发起人,在社区内外的各种敏捷分享和交流过程中,看到大家也非常希望了解、学习和探讨国内不同IT行业、不同特点IT企业敏捷开发的真实案例。加之,2011年8月PMBar社区推出的第一部实践案例书籍《IT项目管理那些事儿》在社会上反响热烈,至今图书热卖万余册。这些极大地增强了我们进一步开展敏捷实践案例书籍撰写的信心!

于是,在王立杰的协调下,PMBar社区内外的十几位敏捷专家决定共同分享自己的敏捷实践案例,希望通过出书使行业内的敏捷实践者或敏捷观望者有所借鉴和体悟。

本书采用的是叙事的风格,通过分享每个敏捷实践者自身的实践案例,为读者展现一个个鲜活的敏捷实施过程,展示敏捷团队的成长烦恼和喜悦,从而和读者达到共鸣。这是一个百花齐放、精彩纷呈的故事集,就像《一千零一夜》一样,有十几位作者,他们中有来自国际著名IT公司的敏捷专家、有来自国内著名电商的敏捷教练、有来自大型国有企业的IT总监、有民营高科技企业技术管理者,有纯粹的敏捷实践者、也有CMMI/敏捷融合实践者等,他们以不同的经历、用不同风格的言语,为我们描述一个又一个精彩的敏捷开发故事。

感谢本书编委会全体成员(王立杰、冯国馨、许舟平、陈勇、杨立东、张克强、杨瑞、杜伟忠、郑贺宸、蔡阿彬、胡峰、范佳莹、马越、史昀)的共同努力,因为他们的努力才有了这本书的诞生。感谢电子工业出版社博文视点的张月萍,她的“博文视点除了盈利的任务外,还承担着教育用户、传播思想的重任!”一句话为《敏捷开发一千零一夜》这本书画龙点睛。我们希望这本书能启迪正在或者准备开展敏捷实践的读者,如果它帮助你加快了敏捷步伐,那就是我们最大的欣慰。

再次,真心感谢曾经为此书劳心劳力的各位朋友,愿天下人幸福安康。

2012-04-16 20:56:23 gsfw2010 阅读数 380
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

前段时间进许了设计模式的学习,收获挺多的。

接下来学习敏捷软件开发(原则、模式与实践),继续加强设计模式的学习,了解软件设计原则,并通过一个案例将

设计原则和设计模式运用到真实的项目当中去。

备注:

(1)参考书籍《敏捷软件开发--原则、模式与实践C#版》Bob大师所著

(2)博客中的设计和案例都来自于参考书籍,主要是为了加强理解和记忆。

奋斗奋斗奋斗

努力,努力,再努力!

没有更多推荐了,返回首页