08按任务单元组织工作.pptVIP

软件项目组织、配置与管理 李 林 第八讲 按任务单元组织工作 为什么要使用任务单元 从创建到提交 适时更新工作空间 保证任务单元完成的质量 第八讲 按任务单元组织工作 为什么要使用任务单元 从创建到提交 适时更新工作空间 保证任务单元完成的质量 为什么要使用任务单元 通常，我们应该干完一件事情，再交活儿。干到一半的工作，对别人意义不大，甚至会有负面影响 张大侠为了添加一个新功能，需要修改源文件A、B、C 若只修改了A，就签入到了版本库 测试人员进行构建测试时，可能编译都通不过 即使编译通过了，可能很多测试用例都跑不通 应该在完成一整件事（A、B、C都修改了）——任务单元——之后，再交活儿 任务单元 任务单元Task 又称活动Activity 任务单元通常有个标题，用来说明这个任务单元的目标 任务单元的粒度没有划分的标准：可以是修复一个bug，实现一个小功能………. 任务单元是指一个明确的工作单元，带有明确的目的，可以和其他工作单元区分开 变更集（Change Set） 要完成一个任务单元，可能需要对一个或多个文件的一处或多处进行修改，或新增/删除文件。这些改动组合在一起，被称为变更集或变更包 显然，一个任务单元对应了一个变更集 变更集（Change Set） 一个一个任务单元，累加在一起，实现了整个软件的从无到有，直到开发完成 任务单元的好处 利用任务单元，可以明确要做哪些工作（标题、变更集）、谁来做、什么时候开始做、最晚什么时候做完 便于交流和管理 可以利用工具自动查看每个人完成任务单元的列表 当程序交给测试团队时，测试人员会问，这一版改动了什么内容，增加了什么功能，修复了什么bug——任务单元的标题及说明 源代码层面回顾时，也很方便——变更集 Bug怎么修复的 新增功能改动了哪些文件 追踪版本问题时，可以查看改动了哪些部分 Subversion的任务单元 任务单元的划分 如何划分任务单元？ 每个任务单元对应的工作量不能太大 应对变化的能力变小 短期构建无望 任务单元也不能过于琐碎 根据实际经验调整——参考敏捷开发中用户故事 第八讲 按任务单元组织工作 为什么要使用任务单元 从创建到提交 适时更新工作空间 保证任务单元完成的质量 从创建到提交 开始一个任务单元时，需要创建它 告诉版本控制工具，你要开始一个新任务单元的开发了 此时，还需要大致描述一下这个任务单元，版本控制工具会进行记录 任务单元的创建者，不一定就是开发者 老板 其他人，例如测试经理 ………… 从创建到提交 任务单元创建完毕后，通常需要进行签出操作 签出需要修改的内容 可能签出多次，以便签出多个文件；可能签出一次，以便签出整个模块/目录 从创建到提交 当任务单元完成的时候，通常需要进行签入操作 但也不一定。有时虽然任务单元没有完成，但是希望在安全的地方（版本库），保留一个中间版本（checkpoint） 并不意味着任务单元完成，别人可以看到中间版本代码 都是用签入，中间版本的签入和任务单元完成的签入就混淆了 提交Commit 任务单元完成后，交活儿，别人可以看了 提交时，还可以对任务单元进行补充说明 从创建到提交 从创建到提交 Subversion觉得中间版本、区分签入和提交，太麻烦了 简化：提交就是签入 中间版本由用户自己保存 任务单元也有标题，只是在提交的时候通过注释输入。即，提交时才创建任务单元 工作空间中只能有一个未完成的工作单元（同一个目录） 从创建到提交 ClearCase用相对完备的方法支持任务单元 任务单元被称为活动Activity 活动有标题，在活动创建时输入 支持中间版本 工作空间中可以有多个活动（目录） 支持相关活动 支持多个彼此相关的活动一起提交 而不是每完成一个活动就提交 活动完成和提交是两回事 第八讲 按任务单元组织工作 为什么要使用任务单元 从创建到提交 适时更新工作空间 保证任务单元完成的质量 适时更新工作空间 在完成任务单元的过程中，别人可能已经向版本库提交了代码，版本库发生了变化。可能会出现什么样的情况： 自己手上的代码会不会过时 自己的代码能不能和别人代码共同工作 Timer故事再次发生 即使使用了版本控制工具，若不及时更新，上述事情也会发生 适时更新工作空间 更新Update： 从版本库中获取最新的版本，以更新本地的工作空间 更新和签出的区别（在Subversion中） 签出：从版本库下载，并在本地工作空间创建；对于工作空间而言，是从无到有的过程；往往只在工作空间创建时使用 更新：本地工作空间已有，从版本库获取新的版本；当然也会创建，版本库中新增的文件或目录；往往在工作空间创建之后使用 更新演示 适时更新工作空间 Subversion中，更新就叫更新 ClearCase将更新称作变基（Rebase） 变基是指用一个