我们拒绝平庸,拒绝随波逐流,拒绝墨守成规,让梦想不再流浪。
敏捷
上一篇 /
下一篇 2014-05-28 10:36:23
/ 个人分类:总结
一、敏捷成熟度评估模型含义说明 | | | | | | | | | |
评估维度 | 评估等级 | 参照标准 | 评估项列表 | 评估项结果 | 评估等级结果 | 信息获取渠道 | 成熟度评估 | | 好的实践 | Top问题 | 改进建议 |
总体描述 |
每个页签是一个评估维度,敏捷成熟度从6个维度进行评估 | 每个评估维度有5个等级,每个等级由一个简要标题标识 | 参照标准是评估此等级的重要依据 | 评估项列表是对参照标准的细化 | 满足评估项描述的情况打勾,否则,打叉 | 如果评估等级中所有的评估项为勾,则模型自动给此等级打勾,表示符合此等级 | 访谈:通过访谈相关人员获得信息;客观数据:要求从CI中自动提取结果;观察:通过观察相关人员行为获取客观事实 | 敏捷成熟度在每个维度上的等级 | 评估时,对该评估项目的总体描述 | 评估时,团队哪些实践或活动能证明达到某评估等级(评估结果依据) | 评估时,团队存在哪些问题表明不能达到某评估等级(评估结果依据) | 评估时,该评估项目,本产品/版本具有哪些可改进建议 |
二、术语定义 | | | | | | | | | | |
敏捷(Agile) | 所谓敏捷,就是“以更短的周期交付可用的软件”的能力,敏捷不是一个固定的目标,而是一个不断进步的状态,这种能力最终的表现形式非常简短,但获得这种能力的过程实际是从各个不同方面改变整个系统 | | |
迭代(Iteration) | 以定长的短周期交付可工作的软件 | | |
故事(Story) | 它是敏捷软件开发中的一种轻量级的需求分析方法。User Story是一个对用户和客户有价值的功能点的简单描述 | | |
持续集成 (CI) | (缩写为CI),是一项软件开发实践,在这项实践中,团队的成员经常集成他们的工作,通常每人每天至少集成一次——这导致每天会集成多次。每次集成都是通过自动化的构建(包括测试)进行的,目的是尽快检查集成的错误,开发一致的软件。不断的、频繁的进行构建。此外,CI中的持续更强调坚持不懈。 | | |
构建(build) | 将各部分源代码、库文件、配置文件等结合到一起,确定它们是否能作为一个整体工作。生成、测试、审查、部署软件的一组活动。 | | |
自动化(automated) | 持续集成系统启动后,不需要用户的干预,无人值守。 | | |
提交构建(commit build) | 一种轻量级的集成构建,代码提交(commit)到版本配置库之后自动触发的第一个构建。提交构建应该是最快的构建,通常小于10分钟。提交构建可能仅仅包含编译和少量单元测试工作。 | | |
时间窗(Time Box) | 迭代以时间为准,不以某些功能是否完成为准 | | |
功能测试 | 对客户需求的验证 | | |
非功能测试 | 包括但不限于压力测试、性能测试、可用性测试等。 | | |
TDD | TDD以测试作为编程的中心,它要求在编写任何代码之前,首先编写定义代码功能的测试用例,编写的代码要通过用例,并不断进行重构优化 | | |
YAGNI | You Aren't Going to Need It,刚刚好的设计 | | |
三、成熟度等级定义 | | | | | | | | | | |
等级 | -1(阻碍) | 0(中立) | 1(协作) | 2(操作) | 3(适应) | |
含义 | 当前的过程限制了敏捷的实行 | 既不阻碍也不有利于敏捷软件开发 | 具备实施敏捷软件开发的基础 | 通过对相关技术的掌握和相应的纪律支持了敏捷软件开发的持续实施 | 1当前团队的过程已经足够成熟,能够良好地响应变化 | |
收藏
举报
TAG: