??xml version="1.0" encoding="utf-8" standalone="yes"?>
我不仅发挥了自己的全部能力,q将我所C的h的能力发挥到极致?/em>
——伍d|?#183;威尔逊,国W?8LȝQ?865—1924Q?/em>
只要是具备一定规模的目Q就必然需要一个团队。靠单打独斗在自家R库里面开发出一个完整品的时代早已不再。然而,在团队中工作与单兵作战,二者是完全不同的。Q何一个h的行为都会对团队以及整个目的生产效率和q度产生影响?/p>
目的成功与否,依赖于团队中的成员如何一h效地工作Q如何互动,如何理他们的活动。全体成员的行动必须要与目相关Q反q来每个人的行ؓ又会影响目的环境?/p>
高效的协作是敏捷开发的基石Q面寚w的会议是最有效的沟通的方式。每日例会(Daily ScrumQ是最早引入ƈ被极限编E所的一个实c它是将团队召集hQƈ让每个h了解当前目q展状况的一U会议。它是一个快速的会议Q每个参与者只能被l予很少的发a旉Q大U两分钟Q来介绍自己的项目进展概要。ؓ了保证会议议题不会发散,每个人都应该只回{三个问题:
Daily Scrum 有诸多好处:
MQDaily Scrum 能帮助所有的团队成员全心投入到项目中Qƈ且一起向着正确的方向努力。IBM® Rational® Team Concert QRTCQ对于团队来_已经被证明是一U在软g开发过E中q行协作的高效方式。RTC 实现了源代码理与工作项理的完集成。它能够帮助q行敏捷计划、ƈ生成报告Q方便管理工作项Qƈ且它q提供了一U有效的框架来支持每日例会(Daily ScrumQ。下面,本文介l三U?RTC q行 Daily Scrum 的方式?/p>
?RTC 里用默认的 sprint backlog q行 Daily Scrum
双击打开目当前所处于?sprint backlogQsprint ?scrum 中的术语Q指敏捷开发周期中的一个P代计划)Q如?1 所C,在窗口底部选择“Planned Item”标签Q在H口右侧选中 Schedule Risk 单选按钮,H口呈现将列出当前 sprint 中的所有工作Q务项 story ?task。在q行 Daily Scrum Ӟ团队成员可以Ҏq个H口Q逐一更新q些d的状态?/p>
?1. 默认?sprint backlog H口
用户可以展开dҎ昄其各个子dQ了解子d是由谁负责,q展{详l信息。如?2 所C?/p>
?2. 展开的默?sprint backlog H口
q种召开 daily scrum 的方式非常简ѝ它能够展示整个目的进展和最q的变化Q但是Q务项不是按照团队成员分组的,不太适应于了解各个团队成员状态。ؓ了解册个问题,本文下一章介l另一U用 RTC q行 daily scrum 的方式?/p>
?RTC 里定?sprint backlog q行 Daily Scrum
定制?sprint backlog 又称?#8220;开发者Q务一览表”。一览表按照团队成员展示dQ每一行表CZ个正被开发的d。Q务显C在W一列,其余几列昄其子d的开发状态:ToDoQ将要做Q,In ProgressQ正在做Q和 DoneQ完成)。ƈ且,各Q务根据其当前状态,分别用不同的颜色昄Q一目了然。定?sprint backlog 的具体步骤如下:
当工作Q务项不是很多的时候,q种方式非常适合q行 daily scrum。但是,如果当P代计划中的工作Q务项很多Ӟq种方式׃再适合了。ؓ了解册个问题,下一章将介绍最后一U用 RTC q行 daily scrum 的方式?/p>
一般在q行 daily scrum Ӟ目理者需要查询出最q正在被修改的Q务,q包括状态是“New”?#8220;In progress”的Q务。创U自定义的查询具体步骤如下:
在打开的窗口中点击“start from scratch”Q如?9 所C:
Ҏ需要选择一些查询条Ӟ个查询取一个名字,保存。如?11 所C:
在弹出的H口中选择׃nq个查询l哪个团队,如图 13 所C,然后点击 OKQ保存?/p>
?13. 选择׃n团队
q种召开 daily scrum 的方式能够列出在最后一天工作Q务项的变化,以及哪些工作d还没有完成。但是它们都是以列表的方式显C出来,界面友好性和可读性不是很好?/p>
本文介绍?daily scrum 在团队项目开发中的重要性,以及三种?IBM Rational Team Concert q行 daily scrum 的方式:默认?sprint backlogQ定?sprint backlogQ和创徏自定义查询。这三种方式各有其优~点:
Lh据自q需要选择不同的方式进?daily scrumQ进行高效的团队目开发?/p>
@import url(http://www.aygfsteel.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);
Rational Team Concert 是徏立在 Jazz 技术^CQ支持若q种 Agile 开发模型。Jazz 技术^C软g开发更加灵z,支持团队成员分布在不同地理位|,提供从小型团队到大型企业的可扩展的Y件开发解x案。Rational Team ConcertQ有时简U?RTCQ具有如下特?:
使用 Rational Team ConcertQ在软g开发中Q能够实C息的交换和信息集成,如果某个需求变化了Q团队成员就会自动收到通知Q团队成员也可以通过多种方式了解q种变化。Rational Team Concert 中的各种视图可以让你更详l地了解信息Q跟q团队的开发进度和zd?/p>
Rational Team Concert 使开发团队能够轻村֒有效地执行和定制程Q这个流E是角色、实跉|动、规则、权限的集合?/p>
Rational Team Concert 中,变更理的主要特Ҏ用工作项跟踪和协调各UQ务,q些d包括故事QstoryQ、缺PdefectQ、计划项Qplan itemQ、以及普通Q务(taskQ等。工作项和工作流E是灉|可定制的Q工作项也可以与其他的变更管理系l进行整合和集成?/p>
Rational Team Concert 中提供了工具来保证计划管理能力,对于目团队Q这些工兯够计划、跟t、^衡项目的工作量,以反映团队的实际状态。对?ScrumQ可以创建和理q代计划?/p>
Rational Team Concert 内置的源代码控制理pȝ是基于组件的和徏立在 Jazz q_上的Q它支持q行和敏捷开发,支持分布在不同地理位|的团队开发,同时它紧密地集成了缺陯t、构建、和以流Eؓ中心的自动化?/p>
对于开发和试团队QRational Team Concert 提供了自动地构徏识别、构建控制和构徏可追溯性。团队成员可以跟t构建的q度Q查看构建的警告信息和结果,提交构徏hQƈ跟踪构徏q程?/p>
Rational Team Concert 的报告组件能够显C项目的q展和项目状态,可以Ҏ地分析某些可能被隐藏的趋势;软g开发过E中的可视化数据和各U分析报告,能够支持有效的决{?/p>
q些客户端界面ؓ开发者提供了一个灵zȝ集成开发环境?/p>
2 Rational Team Concert ?Scrum
Scrum 是一个典型的q代式增量的敏捷软g开发过E。整个开发过E由很多ơP代组成,每一ơP代是一?SprintQ每?Sprint 的周期一般是 2 周到 4 周。在 Scrum 中,?Product Backlog 来管理品功能或目的需求,?Sprint backlog 理每个 Sprint 的Q务。在每个 Sprint 中,Scrum 产品负责Z Product Backlog 中挑选最高优先的需求,?Sprint planning 会议上由团队成员讨论Q估工作量Q确?Sprint backlog d列表。在目q行中,每天要D?Scrum 例会QDaily Scrum meetingQ。在每个 Sprint l束ӞScrum 团队提交增量的可交付物。每?Sprint l束Ӟ团队成员q行ȝ和回,吸取本次 Sprint 的经验教训,Z一?Sprint 做准备。请参考图 1 Scrum 模型?/p>
Scrum ׃下几个部分组成:
?Scrum 中,产品功能或项目的需求会列在 Product Backlog 中。Product Backlog 是一个项目所需的所有需求或功能的优先列表Q这个列表条目常总用户故事Quser storyQ的形式体现。品负责hQproduct ownerQ维护这个列表,Ҏ目的进展和商业环境的变化修改优先列表。品负责h对品的成功负责Q定义品特性和产品发布旉表,负责定各种功能的商业h|不断完善和优?Product Backlog?/p>
Scrum 负责人(Scrum masterQ管?Scrum q程Q确?Scrum 的做法是正确的,q且让团队成员理?Scrum 的h|消除目q展中遇到的障碍Qƈ保护团队成员不受外界q扰?/p>
在每?Sprint 开始的时候,组举行 Sprint Planning 会议。在 Sprint Planning 会议上,产品负责Zؓ卛_到来?Sprint 展示最惌实现的品功能或目需求,让团队成员把握和分析需要实现的功能Q品负责h和团队成员在本次 Sprint 中的目标达成一_定未来 2 周到 4 周的工作重点。然后团队成员决定如何完成这?Sprint 的目标,q分解成所需的Q务,q些dq成了 Sprint Backlog 的Q务列表。在 Sprint Backlog 中,每个d按小旉估完成时_团队成员定是否可以按时完成开发Q务,如果没有_的时间完成某个功能,可以该功能从当前的 Sprint Backlog 中返回到 Product Backlog。Sprint Backlog 中列Z团队成员已经承诺在本?Sprint 期间完成的工作。根据团队经验来评估工作量,而不是由 Scrum 负责人或产品负责人决定,q是 Scrum 的一个特炏V?/p>
在每?Sprint l束Q需要召开 Sprint Review 会议Q评审已l完成的工作。Sprint Review 会议是一个简短和非正式的会议QQ何感兴趣的h都可以参加,q从参与者得C些反馈?/p>
团队成员可以举行 Sprint 回顾会议Q?strong>Sprint RetrospectiveQ,分析目的经验。通过本次 Sprint 回顾会议Q不断改q团队工作方式和不断提高工作效率Qؓ下一?Sprint 做好准备?/p>
Rational Team Concert 中提供了 Product Backlog ?Sprint Backlog 的功能,它们?Scrum 敏捷开发中的重要工?Product Backlog ?Sprint Backlog 一致?/p>
?Rational Team Concert 1.0 中,如果创徏 Product BacklogQ切换至 Team Artifacts 视图Qƈ在项目区域中Q选择 Release 1.0Q然后选择 New > Plan。在 New Plan H口中,输入 Product Backlog 作ؓ名字。选择 Product Backlog 作ؓ Plan Type?/p>
?Rational Team Concert 3.0 中,?PlansAll plansMain DevelopmentBacklog 下,有默认的 Product Backlog。打开 Product BacklogQ点?Planned Items ,可以?Product Backlog d工作,q些工作的cd?Epic ?storyQ对?ScrumQ类型ؓ story ?epics 的工作项Q描qC Agile 中的用户故事Q包括项目需求或产品功能?/p>
在添加所有的工作之后,产品负责为工作项讄优先U,优先U属性有 High、Medium ?LowQ这可以定义实现工作的优先U顺序?/p>
?2. Product Backlog
?Rational Team Concert 中,Sprint Backlog 中包含了来自?Product Backlog 相关的具体工作项。RTC3.0 含有默认?SprintQ例?Sprint1QSprint2Qƈ且有默认?Sprint BacklogQ对于有多个 Sprint 的项目,如果要创建新?Sprint BacklogQ首先需要创?SprintQ然后才能ؓ?Sprint 创徏 Sprint Backlog。打开 Sprint BacklogQ在 Sprint Backlog ?Notes 面上,能够填写 Sprint 的目标,?Planned Items 面上,可以?Sprint d工作,然后Q详l分解工作项Q定义Q务?/p>
?3. Sprint Backlog
q有另外一U方法ؓ Sprint d工作,?RTC 中,打开 Product Backlog H口Q选择相关的工作项Q然后右dƈ选择 Plan ForQ把q个工作Ҏ定给某个 Sprint?/p>
?4. l?Sprint d工作?/strong>
?Sprint Planning 会议中,团队成员分析需要完成的dQؓ每个d估计旉Q?/p>
当估计完所有的工作之后,可以看到每一个故事的M估计|以及整个 Sprint 阶段的M旉估计倹{?/p>
一般来_Scrum 负责人分配Q务给团队成员Q团队成员也可以d领取Q在 Sprint Backlog 的列表内Q可以实现将d分配l团队成员?/p>
?5. l工作项分配所有?/strong>
在每?SprintQ团队成员要每天更新 Sprint Backlog 中的工作状态和旉估计Q这PҎ更新后的工作,RTC 便可以生一?Sprint Burndown 图表Q这?Sprint Burndown 图表以图形方式显C剩余的工作和工作量,昄目的进展,预测目的未来情c?/p>
3 使用 Rational Team Concert 有效地进行每天的 Scrum 会议
Agile 敏捷开发实践中Q强调团队的自我理。在 Scrum 中,自我团队理体现在每天的 Scrum 会议中和日常的协同工作,在每天的 Scrum 例会中,团队成员一般回{一下几个问?:
整个会议应该于 15 分钟。这U经常性的沟通,让团队成员能够了解每个h都在做什么,他们正面临着什么问题,有什么事情需要其他团队成员帮助解冻I提高团队成员的协作?/p>
?Scrum 中,要坚持D?strong>每天?Scrum 会议 , 了解团队成员的工作进展和遇到的问题,Scrum 负责l护一个障列表(Impediments ListQ?/strong>Q帮助解军_队成员遇到的ȝ和问题,保证目利q行?/p>
每天?Scrum 会议可以增加团队成员之间的沟通,q帮助团队成员更有效地工作?/p>
?Rational Team Concert 中,通过集成的视图,团队成员能够了解各种d、计划、工作项Q也可以查看当天需要完成的工作,当团队成员更新每日的工作ҎQ其他成员也可以看到?/p>
?Rational Team Concert 中,通过持箋跟进工作,团队成员可以更好C解工作项的优先Q集中精力在优先U高的工作项上,保证目的正常进展。团队成员还可以规划自己的工作内容和更新剩下的工作项。例如,?Rational Team Concert 的P代计划编辑器中,团队成员可以直接看到今天或本周的工作V这些都有助于每天的 Scrum 会议Q了解每天的 Scrum 会议中的问题?/p>
Team Central 视图中的 Team Load 部分也可以显C团队工作负P在每天的 Scrum 会议之前QScrum 负责人可以监控团队成员工作负荗?/p>
Rational Team Concert 提供?My Work 视图以帮助每一位团队成员查看和跟踪自己的工作项状态。在 Sprint 阶段Q团队开发h员可以在 My Work 视图中看CQ务和工作V?/p>
Planned Time 视图可以查看工作的剩余旉Q支?Daily Scrum 会议Q团队成员可以根?Planned Time 视图讨论哪些已经完成和哪些还没有完成。ؓ了帮助跟q每个工作项的工作量Q团队成员应该在 RTC 中每一天更新每个Q务的剩余旉?/p>
开发员的Q务面板也可以分配和监视工作项Q它昄了每个团队成员的d?/p>
团队成员可以使用查询来监视工作的q展状况QRational Team Concert 已经有很多可用的预定义查询,q可以轻村ֈ建新的查询。预定义的查询,预定义了一些查询条Ӟ可以直接用来查询工作,比如Q?Open assigned to me'Q?Recently modified'{,q些预定义的查询可以用于每天?Scrum 会议Q团队成员和 Scrum 负责人可以快速了解每个工作项的进展?/p>
对于地理位置上分散的团队Q每天的 Scrum 会议有时通过电话或视频会议进行。Rational Team Concert 可以更好地辅助管理每天的 Scrum 会议Q可以很快捕捉和处理ȝ目的事情,然后Q通过团队成员的协作,完成q些工作Ҏ重新分配q些工作V?/p>
4 ?Scrum 中,?Rational Team Concert q行软g源代码控制管?/span> ?Agile 敏捷开发最佛_践中Q持l集成和自动化构建可以保证高质量的Y件开发,持箋C付有价值的软g产品来提高客L满意度。作Y件开发项目,需要一个高效和协作的Y件源代码控制理pȝ。Rational Team Concert 是q种源代码控制管理系l,可以q行变更理和配|管理,帮助开发团队管理源代码、管理文档、跟t代码和׃n代码的各U变化,q保持整个开发团队的高效协同工作Q同ӞRational Team Concert 提供了自动地构徏增量可交付物的功能,实现了Y件开发的持箋集成和自动化构徏Q实现高效的敏捷开发?/p>
下图昄了在 Rational Team Concert 中源代码控制{q程Q开发h员把变更的源代码入到存储库工作空_然后提交到共享的开发流中,其他开发h员接受这些变更的源代码,q且装蝲到存储库工作I间中?/p>
?Rational Team Concert 中进行源代码入(check inQ和出(check outQ,需要连接存储库和项目区域,下蝲源代码到本地存储库工作空间中。首先把源代码从开发流装蝲到本地存储库工作I间Q然后,在本地存储库工作I间修改源代码,提交变更的源代码到开发流中。开发h员在 Pending Changes 视图中,展开 Unresolved 节点Q检入源代码Q加上一些注解,然后Q在 Outgoing 节点下,通过提交QDeliverQ的功能Q就可以把变更的源代码提交到开发流中?/p>
当开发h员提交了变更的源代码到开发流中,团队中其他成员就可以接受q些变更Q把变更的源代码同步到自q本地存储库工作空间中。开发h员在 Pending Changes 视图中的 Incoming 节点下,选择变更集,然后Q接受(AcceptQ这些变_q些变更的源代码p入了自己的存储库工作区?/p>
5 ?Scrum 中,灉|使用 Rational Team Concert 的工作项 ?Agile 敏捷开发中Q以用户故事Quser storyQ的形式定义各种需求,Rational Team Concert ?Agile 敏捷开发提供了cd为故事(storyQ和历史QEpicQ的工作,可以定义用户故事Q定义的工作会昄?Product Backlog 中。在每个 SprintQSprint Backlog 中的d也是一U类型的工作,同时Q工作项也是跟踪、协调开发Q务和工作{的基本机Ӟ它是各种部g和元素之间的联系枢纽?/p>
?Scrum q程中,Rational Team Concert 提供了一些常用的预定义工作项cdQ这些类型的工作全面支?Scrum 敏捷开发?/p>
?Rational Team Concert 中,Product Backlog 中的用户需求或产品需求是通过工作Ҏ描述Q在 Scrum 的每ơP代中Q用户需求或产品需求会被分解成够小的类型ؓd的工作项Q放?Sprint Backlog 里,q且每一个Q务是被赋予了优先U?/p>
在工作项中有很多属性,充分和准用这些属性,Rational Team Concert 可以?Scrum 敏捷开发更有效率?/p>
摘要QSummaryQ字D|一个工作项的简短ȝ和标题,可以?Scrum 成员?Scrum 负责人快速理解工作项内容?/p>
工作的cdQTypeQ定义了工作的Ҏ,包括~陷QdefectQ,dQTaskQ,故事QStoryQ等Q不同的cd有不同的属性和不同的状态变化。类型ؓ故事QstoryQ的工作,可以描述 Scrum ?Product backlog 中的用户需求或产品需求。类型ؓdQtaskQ的工作可以定?Scrum 中每一ơP代(SprintQ的d。类型ؓ~陷QdefectQ的工作可以记录每?Sprint 中测试验证阶D늚~陷Q跟t缺L修复状态和q展?/p>
严重U别QSeverityQ定义了工作的严重{?/p>
描述QDescriptionQ字D详l描qC工作的目标和相关信息,描述 Scrum 中的需求和d?/p>
所有者(ownerQ,昄q个工作当前的拥有者或执行者。在 Scrum 中,团队成员可以通过q个字段知道自己负责的Q务,Scrum 负责人可以分配Q务和了解团队成员的Q务情况,在每天的 Scrum meeting Ӟ可以监控 Sprint 的进展?/p>
优先U(PriorityQ属性指定这个工作项的重要性和优先序。高优先U的工作将会被优先开发ƈ保完成。低优先U的d有可能被转入下一个P代(SprintQ周期l开发?/p>
计划目标QPlanned forQ属性指定这个工作项属于某个 Sprint?/p>
状?/ 解决Q?strong>State/Resolution
?6. My work 视图
?7. Planned Time 视图
?8. 创徏一个新查询
?9. 源代码控制流转过E?/strong>
?10. 工作属?/strong>
?RTC 中,灉|使用工作,可以提高 Scrum 的执行效率,下面介绍一些用工作项的技巧:
在摘要(SummaryQ,描述QDescriptionQ和讨论QDiscussionQ字D中Q支持粗体("bold"Q和斜体Q?italic"Q,也可以创Z其他工作的链接。在工作中Q可以选择一些文本,使用上下文菜单中提取工作的功能QExtract Work ItemQ,提取相关的工作项内容?/p>
在讨论(DiscussionQ字D中Q添加评论,也可以和评论的作者进行聊天会话或发送邮件?/p>
在快速信息(Quick InformationQ部?, 可以通过上下文菜单添加订阅者、附件、链接到其他工作,也可以附加屏q截图?/p>
可以使用"查找"对话框,搜烦包括摘要QSummaryQ,描述QDescriptionQ和讨论QDiscussionQ部分的内容?/p>
在编辑器的工h中,可以使用'L潜在的重复工作项'QFind Potential DuplicatesQ,发现可能重复定义的工作项?/p>
Rational Team Concert 是一个徏立在可~和可扩展^C的团队协作开发工P整合了Y件开发项目生命周期的所有Q务,包括计划、P代、流E定义、变更管理、缺陯t、源代码控制和源代码理、品构动化Q和各种各样的分析报告等。Rational Team Concert 有力地支持了一?Agile 敏捷开发方法,利用 Rational Team Concert q行 Scrum 敏捷开发,能够开发出高质量的产品和项目,能够q行高效率的协同工作Q持l的集成和自动化构徏交付物?/p>
@import url(http://www.aygfsteel.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);
StreamQ流Q是 Jazz 源代码管理系l中的重要成员,体现目开发中的一个版本,׃个或者多?componentQ?lgQ构成。流的徏立得团队成员在不同的版本之间进行代码的׃n与管理,满目q代开发中代码理的需要,促进团队成员之间更好的协作。组件是代码׃n与管理的基本单位Q由一个文件或者文件夹所构成Q团队成员可以通过使用中的组件进行代码的׃n?/p>
目前QY件开发中q代开发非常普遍,目的开发经常涉及两个或多个版本。即在一个版本尚未发布就需要进入下一个Y件版本的开发,q样使得目开发h员需要同时维护多个Y件版本。特别是一个缺陷需要在多个版本上解冻Iq样在这些不同的软g版本上进行代码同步就成ؓ团队开发h员日常的工作内容。如何简化代码同步的程Q提高多个Y件版本代码同步的效率以及减少在多个Y件版本中׃代码同步引v的缺hQ对于降低Y件开发成本和提高软g质量h重要的意义?/p>
源代码管理与׃n是项目开发中的重要内容,?RTC 作ؓL的源代码理工具Q对目的源代码的管理与׃n提供了很好的机制。在实际的项目开发过E中Q项目拥有者需要在q程 Jazz 服务器上创徏 streamQ项目开发h员在q程 Jazz 服务器上Z?stream 创徏自己的版本库工作I间。除此之外,开发h员还需要在本地的机器上创徏自己的本地工作空间。开发h员通过 Check-in 操作本地工作空间的改动同步到远E?Jazz 服务器上的自q版本库工作空_通过 Deliver 操作远E版本库工作I间的代码同步到团队׃n?stream 上。其他团队h员则通过 Accept 操作代码从 stream 同步到自pE的版本库工作空_q过 Load 操作版本库工作I间的源代码下蝲到本地的工作I间。依此类推,RTC 可以同时管理多?stream q进行有效的׃nQ其具体的源代码理与共享机制如?1 所C:
通过 RTC 中对源代码的理与共享机制可以看出,如果不进行Q何修改与配置Q在多个 stream 上,开发h员只能通过单独l护每个 stream 上的源代码,q在q些 stream 上进行代码的来回复制辑ֈ?stream 上的源代码同步,q样无疑增加了维护和同步多个 stream 上的源代码成本。事实上 RTC 可以通过更改相应?flow targetQ目标流指向Q来化多 stream 上的源代码同步,有效的提高项目开发的效率?/p>
ȝ来说QRTC 对多 stream 上源代码的同步提供了三种方式Q各 stream 单独同步Qstream ׃版本向高版本同步?stream 由高版本向低版本同步Q具体操作如下图所C(图中以两?stream ZQ多?stream 可以依此q行cLQ:
从图 2 可以看出Q同?stream1 ?stream2 上的源代码需要在每个 Local workspace ?Check-in 相应的代码,在同步第二个 stream 旉要从一?Local workspace 上拷贝源代码到另一?Local workspace 上,q样加大了开发h员的工作量,q且增加了一些由拯源代码所造成的缺陗图 3 与图 4 的同步机制没有多大差别,?3 所C的为源代码从低版本Qstream1Q向高版本(stream2Q同步,开发h员先代码提交到 stream1Q然后改?stream2 的目标流指向Q接受之前提交到 stream1 上的变更集,最后通过 Jazz Server 上的 Repository workspace 变更集提交?stream2 上。图 4 所CZؓ源代码从高版本(stream2Q低高版本(stream1Q同步,具体q程与低版本Qstream1Q向高版本(stream2Q同步相反。由于高版本往往会包含低版本没有实现的功能,所以对于多 stream 的源代码同步Q采用从低版本向高版本同步的方式遇到的潜在的源代码冲H相对较,开发h员解册些冲Hƈ合ƈ变更集所付出的成本也随之降低。因此,在实际项目开发中Q对于多 stream 的源代码同步Q采用低版本Qstream1Q向高版本(stream2Q同步的方式最佟?/p>
׃?stream 从低版本中向高版本同步时潜在的冲H最,因此本文以q种同步方式作ؓCZ说明如何在两?stream 实现源代码的同步。对于三个或三个以上 stream 的代码同步,读者可以依此类推。在CZ中,我们拥有两个 streamQ?.3.1.1 ?6.3.2。ƈ且我们已l创建好两个 stream 上对应的两个我们自己的版本库工作I间?/p>
打开 Pending Changes 视图Q在 6.3.1.1 版本库工作空间上有个新的可交付变更集Q右击选择 deliver 对其q行交付Q具体操作如?5 所C:
打开更新版本?6.3.2 版本库工作空_更改?Flow Targets ?6.3.1.1 stream。如?6 所C,?6.3.1.1 stream |成当前 flow target 且是默认 flow targetQ然后确认保存?/p>
?6. 版本库工作空间界?/strong>
保存后结果如?7 所C?/p>
?7. 更改 Flow Target 界面
如图 8 所C,此时再次查看 Pending ChangesQ?.3.2 版本库工作空间已l指?6.3.1.1 streamQ刚才在 6.3.1.1 版本库工作空间中交付的变更集出现?6.3.2 版本库工作空间的可接受变更集中。此时该变更集与 6.3.2 版本库工作空间中代码不存在冲H,可以直接选择接受?/p>
?8. 接受 Incoming 变更集界?/strong>
接受后,?6.3.2 版本库工作空间的 flow target 改回 6.3.2 stream Q如?9 所C:
从图 10 中可以看出,?Pending Changes 中,6.3.2 版本库工作空间中有了新的可交付变更集Q该变更集正?6.3.1.1 版本库工作空间之前交付的变更集。由于不存在冲突Q我们可以直接将该变更集交付?6.3.2 stream 中,从而实C?stream 上针对该变更集的源代码同步。在下一节中我们给出存在代码冲H的同步CZQؓ了模拟这U情况,我们暂且不交付此变更集?/p>
?10. 交付 Outgoing 变更集界?/strong>
同样Q打开 Pending Changes 视图Q在 6.3.1.1 版本库工作空间提交一个新的变更集模拟代码冲突Q右击选择 deliver 对其q行交付Q具体操作如?11 所C:
更改 6.3.2 版本库工作空?flow target ?6.3.1.1 stream。从 Pending Changes 视图中可以看?6.3.1.1 版本库工作空间中新提交的变更集。该变更集前出现色高亮Q说明该变更集和 6.3.2 版本库工作空间中可交付的变更集存在代码冲H。具体操作如?12 所C:
选择接受该变更集Q此时会弹出是否自动解决冲突的对话框如图 13Q我们这里徏议选择 Resolve LaterQ以防止出现代码合ƈ错误的情况发生。下面我会给出具体的情况说明在接受冲H变更集后如?Resolve。Resolve 有两U方法:自动合ƈ和手动合q。什么时候选择自动合ƈQ什么时候需要手动合qӞq对于维护代码的同步和准性十分重要?/p>
?13. 冲突提示界面
选择 Resolve Later 后,?6.3.2 版本库工作空间的 flow target 改回 6.3.2 stream。如?14 所C,出现未解决代码冲H。双L开冲突比较视图?/p>
?14. 未解军_H界?/strong>
如果视图中仅有蓝色标识,说明没有严重冲突。如?15 所C,可以选择 Auto Merge 自动合ƈ代码?/p>
?15. 自动解决冲突操作
如果视图中有U色标识Q说明存在严重冲H,自动合ƈ代码导致代码错乱。如?16 所C,红色部分右侧代码拷贝覆盖到左侧Q手工完成覆盖后Q选择 Resolve As Merge 完成合ƈ?/p>
?16. 手动解决冲突界面
在弹出的对话框中选择 OK 定手动合ƈ操作Q如?17 所C:
q样合ƈ完成后,6.3.2 版本库工作空间可交付变更集如?18 所C。此时可看到被合q的原变更集后出?1 merged 字样Q合q操作完成。对其交付后Q?.3.1.1 stream ?6.3.2 stream 在该变更集存在冲H的情况下实C代码同步?/p>
?18. 交付合ƈ后变更集界面
在同步两个或多个 stream 的时候,很可能误不属于?stream 的代?deliver ?stream 上。如果错误交付的代码q多的话Q手动去删除错误交付的代码将会需要花费很大的工作量来代码还原到原来的状态。而且Q还会带来代码被错误修改的风险。?RTC 提供了一U回退QReverseQ的功能Q将错误交付的代码自动清除掉Qƈ恢复到原来的状态?/p>
回退QReverseQ功能的具体操作步骤如下Q?/p>
如果代码错误提交到 stream 后,有其他开发h员提交了自己的代码,q个时候要q行回退的时候,需要查看需要回退的文件是否和其他开发h员修改的文g有冲H。如果有冲突Q可以通过前面提过的方法进行代码冲H的整合Q或者把错误提交代码以后其他开发h员提交的代码先回退回去Q在把错误提交的代码?stream 上删除以后,重新其他开发h员提交的代码 deliver ?stream 上?/p>
衷心的感谢钱巧能工程师在本文大纲斚w的讨论所提供的意见和支持?/p>
本文详细介绍?RTC 代码同步的原理,q且比较了目?RTC 中多 stream 上代码同步的几种ҎQ最后以具体CZ说明了如何在 RTC 中进行多 stream 的代码同步,解决代码同步中出现的冲突及如何撤销错误的代码同步。读者可以通过阅读本文Q掌握各U在 RTC 中多 stream 代码同步的方法,q根据项目实际情况选择Q灵z运用,提高目开发的整体效率?/p>
本文介绍?IBM Rational Team ConcertQRTCQ的代码评审功能QCode ReviewQ。这一功能可以使代码评审流E变得更加规范,完善代码提交程Q对于不同区域的成员可以更高效的协同工作Q在代码提交前发现到潜在的问题,快修复Q提高代码质量,有效减少~陷数?/p>
多数情况下,评审者能够发现开发h员自w不能发现的问题或潜在问题,毕竟思维方式和考虑的点{会有差?/p>
作ؓ目前L的代码管理工PRTC 对代码评审的功能已经有了很好的支持,比如利用邮g作ؓ代码提交者与评审者通信的工P代码评审q程中各个角色的划分Q代码提交的权限讄{等Q本节将具体介绍 RTC 在代码评审过E中所涉及的概念及详细配置?/p>
在整个代码评审过E中Q邮件是作ؓ代码提交者及其他相关人员之间的重要通信工具Q比如在代码评审前提交、对代码d修改意见Q团队相关h员都应收到相应的邮g提醒Q用户可以通过如下配置是否启用邮g支持Q?/p>
在整个代码评审过E中QRTC 会涉及到如下几U角?/p>
事实上对于以上这些角ԌSubmitterQReviewer ?Approver 是必,Verifier 是可选的Q用户可以根据团队实际情况决定在代码评审q程中是否需?Verifier?/p>
RTC 在代码提交时有了较好权限配置的支持,用户Q一般由 Project owner 或团队的 tech lead 配置此权限)可以Ҏ如下步骤q行配置Q?/p>
l过上述一pd配置后,代码提交者必d取得相应?Approval 之后才能提交代码Q从而达C码提交时的权限控Ӟ保证代码的质量?/p>
?RTC 中,代码评审的流E大致如下,各个团队可以Ҏ实际情况q行优化?/p>
?10. 代码评审时序?/strong>
下面我将以一个简单的实例来说明在 RTC 中是如何q行代码评审的:
修改源代码,?RTC 客户端中扑ֈ Pending Changes 视图Qƈ这些变更集 check in 到在 Jazz repository 上的 workspaceQ如?11 所C:
?Pending Changes 视图中,?check in 的变更集兌到相应的 work item(story 上的 task work item 或者是 issue cd?work item) 上?/p>
?12. 兌 work item 界面
?Pending Changes 视图中,扑ֈ相应?Outgoing 变更集,点击右键菜单中的 Submit for Review... 选项?/p>
?13. Submit for Review 界面
在弹出的 submit for review 的对话框中添加相应的注释及添加相应的 Approver cdQ具体类型请参?RTC 中对代码评审章节Q?/p>
?14. d注释?Approver 对话?/strong>
Approver 会Ҏ RTC 中关于代码评审的邮g扑ֈ相应?work itemQƈ?work item 中找到链接页面?/p>
?15. work item 链接界面
Approver 从链接页面中扑ֈ需要评审的变更集,双击此变更集Q变更集会?RTC 客户端的变更视图中显C?/p>
?16. 查看变更集界?/strong>
每个 Approver Ҏ代码评审的实际情늻出相应的修改意见和评审意见,如对于哪一行代码需要修Ҏ者同意提交等{,具体操作如图 17 所C:
如果l出的评审结果ؓ同意提交Q则 submitter 直接q入代码提交阶段。如在此阶段l出的评审结果ؓ拒绝Q则 submitter 需要从 work item ?overview 视图?RTC 邮g中查?Approver d的修Ҏ见,q根据意见进行代码修改,重新提交代码评审?/p>
代码 Submitter ?Pending Changes 视图中找到相应的 Outgoing 变更集ƈ提交?/p>
一ơ代码评审和所提交的一个变更集是一一对应的关p,当对一个变更集提交代码评审后,q个变更集就被冻l,此后对其中Q何文件的修改都将通过另一新的变更集来跟踪。所以,对于新的修改Q需要再ơ提交代码评审?/p>
评审者在应用被评审者的变更集进行代码评审时Q有时会和评审者本地的变更集生冲H,此时只要生冲H的本地变更集暂停(SuspendQ,p暂时避免冲突从而l进行评审?/p>
虽然 RTC 已经能够支持完整的代码评审功能,但在实际使用中还有一些改q之处。比如无法动态嵌入或链接到评论所涉及的代码中的指定行Q方便被评审者阅MҎ见。而且评审的粒度较大,Z每个评审者的修改意见无法针对每条评论q行接收或拒l。此外,如果加入代码静态分析功能,p更快的找到问题,避免Zؓ的疏漏?/p>