交互效果网站,网站建设 工作职责,中文域名查询官网,wordpress 通过电子邮件发布一、引言
1 中国式软件过程的坏味道 RUP#xff0c;CMM/CMMI到了中国就变了味。。。。。。
2 Team Foundation Server TFS是软件开发的协作平台#xff0c;它要解决的首要问题是团队成员的协作问题。比如说#xff1a; 研发团队内部怎么协作#xff0c;产品经理#x…一、引言
1 中国式软件过程的坏味道 RUPCMM/CMMI到了中国就变了味。。。。。。
2 Team Foundation Server TFS是软件开发的协作平台它要解决的首要问题是团队成员的协作问题。比如说 研发团队内部怎么协作产品经理架构师设计师开发人员测试人员怎么进行协作并行工作 研发团队之间怎么协作开发人员怎么共享重用技术加强横向的联系 研发团队与运营团队怎么协作 之前我一直在实践着Rational系列软件产品总觉得Rational系列易用性不好。一直到2006年我才发现有TFS但安装部署Team Foundation Server 2005没有成功所以到2007年Team Foundation Server 2008(beta1)发布后我们才开始试用期间经历了TFS的多次发布。在4年的实践过程当中我们越来越深刻认识到只要协作的问题解决了管理的诸多问题将迎刃而解。 软件过程没有银弹但可以有核弹TFS就是这样的核弹它的威力足以支持超大型的软件团队研发优秀的软件产品。当然它的威力大小取决于你运用的功力。
3 敏捷过程 作为软件全生命周期的工具TFS支持CMM等重量型软件过程也支持敏捷过程。CMM等重量型软件过程受管理人员的欢迎敏捷过程更受开发人员的欢迎。重量型软件过程过于粗放敏捷过程更细致灵活。从管理思想上来看重量型软件过程强调管理执行力纪律制度等有兵家和法家思想的特点。敏捷过程强调协作创造性自由等无为而治有道家思想的特点。 君子性非异也善假于物也。再先进的思想也离不开工具。扎根在TFS的平台上敏捷思想必能开出更加炫丽的花朵。4 持续改进 中国文化创造了中国式软件过程的坏味道西方文化创造了TFS也创造了敏捷思想并且指明了软件过程持续改进的原则。从蹒跚学步到腾云驾雾绝非一日之功需要十年磨一剑的执着。而分享成功的经验改变中国式软件过程的坏味道不要让TFS也变了味为千千万万的程序员创造良好的生态环境则是更大的挑战需要更多人的努力更需要持续改进。 最近我一直在思索新手怎么学习TFS和敏捷过程。对于刚刚工作的程序员虽然经验不足但恶习未养成可塑性最好。从一开始就应该持续的学习和实践始终走在正确的道路上。千里之行始于足下。从一下篇开始我们将把起点定位新手的水平来学习TFS
二、源代码管理
重量型过程改进通常会先拿出一个文件夹里面有各种规范和文档模板琳琅满目ISO9000如此RUP也是如此CMM更是如此。一般人看到这么多东西非吓晕过去不可但咨询师会鼓励你告诉你这是培训的框架都是必须品等你把这些东西掌握了就如何神通广大了然后开始漫长的学习过程。新手这是for高级岗位的。
敏捷开发认为代码是最精确的文档一个软件什么都可以省唯独代码是必不可少。一个项目团队可以没有项目经理测试人员哪怕只有一个人那一定是个程序员。现在只要会写代码马上就可以开始敏捷开发了门槛不高吧这才是最贴近我们程序员的软件过程。
1 TFS 2010入门
TFS 2010的安装已经很容易了安装完后点下面的链接先入个门Visual Studio Application Lifecycle Management 入门
1.1 连接到 Team Foundation Server
1.2 新建团队项目
1.3 将解决方案添加到源代码管理
1.4 签入
简单练习一下上面列出的4条你就已经入门了。 2 源代码管理资源管理器
接下来请打开源代码管理这才是众妙之门CMM的文档模板集只是个笨重的大包裹。练练签入签出就可以用TFS来工作了。好像有的人用TFS只是来做源代码管理有点儿可惜了。 3 管理工作区
3.1 编辑工作区
接下来打开工作区添加或编辑工作区把TFS服务器映射到本地文件夹D:\Projects确定后系统会提示你工作区已修改是否要更新本地工作区选是。 3.2 本地工作区 下图是本地工作区D:\Projects的目录结构每个文件夹映射到一个团队项目与服务器的团队项目完全相同。这样把各个不同的项目区分开不同项目的成果和过程文件等各自放到各个项目文件夹里不要再放到桌面我的文档逻辑驱动盘的根目录等。另外不要把不相关的文件签入到团队项目里来。敏捷的秘诀之一就是力求简单。 3.3 团队项目目录结构
团队项目的根目录都包含三个主要目录 序号 目录 说明 1 Data 数据 2 Documents 文档 3 Source 源代码 软件程序数据文档这不正是我们软件工程师理解的软件吗让那些高高在上的理论落地成为我们实践中的一部分。 4 变更集
4.1 历史记录
在源代码管理资源管理器里选中Source然后点击工具条上的历史记录我们将看到Source目录下所有的变更集。这些变更集是我们日常签入在TFS上自动化的结果这不需要CMM过程填这样那样的表格不会增加我们的负担。即使写个简要的注释慢慢的我们也习惯得了。要知道我们的目的是给程序员减压而不是加压。 4.2 变更集详细信息
现在我们看看70号变更集的详细信息我们看到这次变更是添加了一个文件LoadLayerCommand.cs。 右键查看一下这个文件里写了什么 4.3 查找变更集
打开查找变更集界面我们可以按用户文件日期等条件进行组合查询。下图是查文件LoadLayerCommand.cs的变更历史以了解它的开发以及重构等。 4.4 签入原则
变更集是由签入产生的所以正确对待每一次签入。乱糟糟的代码肯定会导致乱糟糟的变更集关于如何写简洁的代码请参考《敏捷软件开发原则、模式与实践》《重构-改善既有代码的设计》等书。对于新手签入的时候尽量用小的变更不要把多个单一职责的文件一起签入比如说ImportTxtFileCommand.cs和ExportTxtFileCommand.cs要分开签入即使你写在同一个文件里MainForm.cs的两个方法ImportTxtFile() 和ImportTxtFile()也分开签入。为什么呢是因为我们将归纳变更集来产生工作项你签入耦合度非常大的变更集我们就没办法归纳了。正向的工作计划不容易逆向的工作总结要容易的多。好了今天先说到这至少工作项已经很近了下一篇探讨怎么通过工作总结来提高工作计划的能力。
三、定制敏捷过程模板
Team Foundation Server 2010内置两个过程模板虽然有TFS过程帮助文档但微软并没有提供我们最需要的实践指南示例等。我们一直用MSF for Agile Software Development v5.0长期以来我们尽量适应这个模板把它当成标准来用。但是渐渐的我们发现这个过程模板跟我们实际的开发工作并不吻合一方面这个模板毕竟是舶来之品跟中国式的软件特点有很大的差异另一方面软件过程持续改进是恒定的规律现阶段的工作特点需要跟现状相符的过程模板而不是一步到位。
首先启动Visual Studio 2010打开团队\团队项目集合设置\过程模板管理器下载MSF for Agile Software Development v5.0到本地文件夹。 然后下载Team Foundation Server Power Tools 安装完成后在visual studio里执行工具\Process Editor\Process Templates\Open Process Template打开刚下载的MSF for Agile Software Development v5.0进行修改。 1 迭代(Iterations) 团队项目的第一个阶段是迭代 1迭代 n等随项目的进展动态添加。另外这里增加一个特殊的迭代积压(Backlog)未计划的不明确不紧急的工作项暂时放到积压里随着项目的进展情况以及客户的要求积压里的工作项才会安排到迭代n里。 2 组成员资格(Group) 新增三个组Developers (开发者)Support (技术支持)Testers (测试员) 3 团队查询(Team Queries)
敏捷过程模板默认生成的团队查询如下图所示看起来比较复杂我们一边用一边定制新的查询来来回回用了两年最后总结了最常用的查询那些不常用的查询狠狠心都删除了。
图 1 修改前 图 2 修改后 3.1修改查询 3.2 我的所有工作
这个查询体现的是个人关注是项目成员工作的入口把所有项目中指派给他的用户情景任务问题Bug显示在一个表格里使得他可以快速简便的查看自己的任务情况比如新任务未完成的任务优先级高的任务等等。实践发现这种方式比让他去各个项目里去查找我的任务我的Bug等要有效的多特别是对于多项目并行开发以及跨部门协作的情况。 3.3 所有工作
这个查询体现的是项目关注关注项目的全部工作项以及工作项之间的父子关系。 4 工作项(Work Item)
4.1 默认工作项(Default Work Items)
TFS2010支持工作项的层次结构这样当工作项特别多的时候就不像TFS2008那么乱了。于是每一个新的团队项目里都要手工创建完全相同的顶层摘要任务重复工作又来了消灭重复劳动提高自动化水平是我们义不容辞的责任那就直接在默认工作项里添加吧。一点小遗憾是不能建立父子关系只能在创建团队项目后手工完成。 4.2 工作项类型(Work Item Type)
本来不想定制工作项类型无奈敏捷过程模板不支持开始日期和完成日期如果想要设置工作项的完成日期还要用Office Project打开tfs才能修改完成日期。这也太不敏捷了打开Type Definitions编辑任务添加上开始日期和完成日期。 预览一下看看效果看起来还挺合适的嘛自从把这两个字段放出来舒适度提高20%。 最后把修改完的过程模板改名为MSF for Agile Software Development v5.1再次打开过程模板管理器上载到服务器。 代码下载
四、工作项跟踪1
可跟踪性是软件过程的重要能力TFS主要是以工作项来实现过程的可跟踪性。曾有人问你们实际项目里的工作项是怎么样的能不能让我们看看我也一直很好奇别的公司TFS里的工作项是怎样的网上这方面的资料很少。我就以三年前的三维管线项目为例说一说我们的工作项跟踪欢迎大家批评指正。 1 需求
敏捷宣言认为响应变化 重于 遵循计划需求的变化尤其是在中国经常是无休无止。我们要做的就是要在TFS上做好需求管理 从而达到响应变化的目的。 1.1 需求管理
我们先新建一个用户情景标题写上爆管分析然后指定区域迭代堆栈级别需求说明写到详细信息里。情景点是跟工作量相关的我们没有估算工作量也没有安排时间进度。 用户情景是需求管理的基本单元跟文档化需求管理有很大的不同我们没有强调需求基线评审也没有正式的需求变更审批。需求发生变化时只管更新到用户情景的详细信息。需求往往会经过反反复复的修改历史记录里会保存着更改的时间人内容。这比跟踪需求规格说明书这样的大文档的版本历史要容易的多。 1.2 用户故事
用户故事是需求建模的一种方式也是敏捷开发的重要实践。功能点的建模我推荐采用用户故事可以比可视化建模表达详细的信息。转到上图里的实现这时我们看到当前的子项为空接下来新建一个子任务编写爆管分析用户故事经过反反复复的修改最终结果如下
1 启动爆管分析命令系统显示爆管分析界面
2 指定一条管段三维窗口里显示这条管段的选中状态
3 输入缓冲区半径后执行分析系统显示出阀门井列表
4 双击列表中的一条记录三维窗口定位到当前的阀门
5 点击[导出]按钮列表里的数据导出到excel里了 用户故事完成后合并到用户情景的详细信息里跟需求规格并列 2 设计
软件的设计涉及到方方面面同时还有各种各样的设计方法。我认为实际的工作中我们应该只做必要的设计敏捷宣言认为工作的软件 重于 详尽的文档。工作的软件就是可以运行的程序和运行所必须的数据。基于代码和数据一样可以作出好的设计在没有必要写文档时尽量不要长篇大论。 2.1 爆管分析输出设计
转到用户情景的实现创建一个新的子任务写上标题爆管分析输出设计并链接编写爆管分析用户故事作为前置任务。 接下来我们看看这个任务的结果变更集的注释是爆管分析输出设计.fly下载打开发现是用skyline软件制作的三维数据如图所示。 2.2 爆管分析用户界面视觉设计
再创建一个子任务写上标题爆管分析用户界面视觉设计指派给界面设计师转到所有链接链接类型选择已进行版本管理的项指定项$\Pipe2012A1\Documents\设计\输出设计\爆管分析\爆管分析输出设计1.png写上注释工作输入。即爆管分析输出设计任务的工作输出是这个任务的工作输入。 工作完成后我们打开变更集5702并查看其中的图片$\Pipe2012A1\Documents\设计\界面设计\爆管分析\爆管分析界面设计1.png 2.3 爆管分析面向对象设计
再创建一个子任务写上标题爆管分析面向对象设计并链接编写爆管分析用户故事作为前置任务。这里的面向对象设计已经是详细设计了我们的做法是直接到代码需要设计类名输入数据输出数据方法命名空间等。代码是最精确的文档不要在文档上绕来绕去没有程序员有兴趣看那些华而不实的设计文档。 我们打开变更集5143查看BoomPipeCommand.cs。 3 构建
构建最主要的活动是编码由于敏捷开发反对过度的详细设计所以这里的编码所涉及到不仅仅是实现还包括算法设计设计模式代码重构代码调整等等。用代码承载那些精妙的设计而不是笨重的文档。
3.1 爆管分析编码
再创建一个子任务写上标题爆管分析面向对象设计并链接爆管分析用户界面视觉设计和爆管分析面向对象设计作为前置任务。这样就不用给该任务链接工作输入了执行任务的程序员可以直接找到前置任务的工作输出即变更集。 任务完成后我们看到变更集5115的链接注释BoomPipeCommand.cs变更集5160的链接注释BoomPipeControl.cs。代码大家都很熟悉了这里就不再详述。
4 测试
TFS的测试涉及非常多的内容本文我只谈测试用例和Bug。
4.1 测试用例
转到用户情景的测试用例创建一个新的测试用例标题写上手工输入管段ID进行碰撞分析然后使用Microsoft测试管理器进行编辑在步骤里写上 操作 预期结果 点击[爆管分析]按钮 左边栏显示爆管分析界面窗口 从文本框输入J-A229回车 三维窗口高亮显示ID为J-A229的管段并闪烁爆管的图标。 输入缓冲区半径200点击[开始分析]按钮 阀门井列表显示2条记录 双击列表中的第一条记录 三维窗口定位到控制阀门FA-331并闪烁 点击[导出]按钮选择路径d:\1.xls 系统提示导出成功。 在excel里打开d:\1.xls 显示2条记录ID分别是FA-331FA-334
测试用例完成后结果如下 4.2 Bug
测试工程师在测试中发现了Bug这时候应该转到用户情景的所有链接新建一个Bug标题写上Bug阀门记录与操作有误严重级别为中然后写上说明指派给某个程序员。程序员调试Bug之后会把状态改为已解决原因改为已修复。指派给测试工程师测试工程师验证后如果没有问题就将状态改为已关闭。 5 小结
现在让我们回到用户情景的所有链接我们将看到如下图所示 在TFS上需求管理项目管理测试管理缺陷跟踪等融为一体。无论是从需求到设计编码测试Bug的正向跟踪还是从Bug向编码设计需求的逆向回溯都不成问题。取得了可跟踪的能力响应变化也就不再是一句空话了。
