PB SB 燃尽图--跟进累计剩余工作量
3. 五种仪式/事件
每日站会的重点包括:
- 同辈压力——因为团队靠大家,所以同辈的期望可带动进步;
- 密切配合——团队应当理解专注的必要性并独立工作;
- 细在专注——团队应当理解每日站立会议中简洁的必要性,由此团队才有效益;
- 每日承诺——团队应当理解对每人每日承诺的价值所在,并兑现这些承诺;
- 辨别障碍——团队应当集体意识到每个人的困难,由此团队可尝试集体解决。
可以把开发工作流程分为以下几个阶段:编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署
正如你在上图中看到,「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期。
7.1 持续集成CI(Continuous Integration)持续集成(Continuous Integration)简称CI,持续集成强调开发人员提交了新代码之后,立刻自动的进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。
持续集成过程中很重视自动化测试验证结果,对可能出现的一些问题进行预警,以保障最终合并的代码没有问题。
7.2 持续交付CD(Continuous Delivery) 持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。
持续交付并不是指软件每一个改动都要尽快部署到产品环境中,它指的是任何的代码修改都可以在任何时候实施部署。
这里强调的是
- 手动部署
- 有部署的能力,但不一定部署
持续部署是指当交付的代码通过评审之后,自动部署到生产环境中。持续部署是持续交付的最高阶段。
这里强调
- 持续部署是自动的
- 持续部署是持续交付的最高阶段
持续部署意味着所有的变更都会被自动部署到生产环境中。
持续交付意味着所有的变更都可以被部署到生产环境中,但是出于业务考虑,可以选择不部署。如果要实施持续部署,必须先实施持续交付。
- 持续交付表示的是一种能力
- 而持续部署则是一种方式
「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」提供了一个优秀的 DevOps 环境,对于整个团队来说,好处与挑战并行。无论如何,频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。
整体而言,Jenkins 过去一直是大部分公司的选择,但这个现象正在发生改变,随着公有云服务、Docker,SaaS 的普及,越来越多的企业开始选择在线托管型持续集成系统。
8. 相关术语 osmotic communication渗透式沟通;通过联合驻扎的方式,敏捷团队成员在同一个视觉与听觉空间中工作,团队内部就彼此的问题或工作能够产生快速的反馈,从而形成“渗透式沟通”。
Colocation集中办公;渗透沟通和集中办公有助于确保在敏捷项目团队内部进行问题、想法和信息的自然流动。速度速度是指对每一次迭代完成的用户故事点或故事数量的衡量。一个敏捷团队可根据当前迭代速度记录来估算下一个迭代可完成的用户故事点数量。relative ranking/prioritization相对级别/优先级是指根据团队对优先级的定义,对一列用户故事进行排序weighted shortest job first,WSJF加权最短作业优先(weighted shortest job first,WSJF)
计算方式:将工作的延迟成本(cost of delay,CoD)除以工期,在最短时间内能提供最大价值(或CoD)的工作,通常被优先选择实施
用于计算WSJF的表格
features and benefits--FAB
特征和收益矩阵,