- Big visible charts
- 透明地展示团队的进度, 便于内部交流.
- 让利益相关者(stakeholder) 更容易获知项目组现在的进展.
- Burn down charts
- 以天位单位, 用以描述剩余的全部任务时间.
- x-axis代表天数, y-axis代表剩余人工量.
- 等同于物理的任务白板(physical task board).
- Burn up charts
- 描述已完成的story的数量.
- x-axis代表�点数(point), y-axis代表工作完成的上升趋势(upward trend), 会一直上升到100%.
- Scope提供了关于开发过程中story数量变更(增加,减少)的情况的更多信息.
�Burn down && Burn up
- Persons
- Chicken: 跟项目有利益关系, 但不负责具体的迭代工作.
- Pig: 在迭代工作中负责task的责任人.
- 全功能团队(Cross-Functional Team)
- 所有成员都具有从头到尾完成项目所需的所有技能的项目组.
- 完成的定义(Definition of Done)
- �敏捷的原则:
每个迭代都能交付可发布的软件 - 演化过程:
- 开发完成 ->
- 单元测试完成 ->
�有功能测试保证的�达到交付质量的完成(真正的完成).
- �敏捷的原则:
- 浮现(Emergence)
- 最好的设计和最好的方式来源于工作中日积月累的演化.
- 而不是能够事先定义和在详细项目计划中得.
- 经验主义(Empiricism)
- 知识通过经验获得.
- 估算(Estimation)
- �对backlog中的story/task的�大小的度量.
- 快速失败(Fail-fast)
- 让错误尽早被发现, 更易于修正和避免后果.
- 使用持续集成来完成.
- 持续生产(Flow)
- 持续给客户发布�有价值的功能.
- 与传统的�大批量发布相对应.
- 最小化的有价值的功能(Minimum Marketable Features)
- �每次的发布都是对客户有价值的最小的功能的集合.
- 计划会议(Planning Game)
- 每个迭代一次的会议.
- 而在XP中,分为迭代(sprint) 计划和发布计划.
- 发布(Release)
- 尽早地发布可用的MMF, 然后继续推进经常性的增量式发布.
-
每个迭代都要产出�可发布的软件, 即使代码还未被终端用户使用.
- Spike
- 目的是解决技术或者设计的问题, 而不是具体的实现story/task.
- Story
- 以业务术语描述.
- 使用story point 作为大小的度量.
- 每个story 都以验收测试来验证是否完成.
- Backlog
- Backlog 项目的工作量(effort)
- 是对工作量而不是持续时间(duration) 的估算.
- 估算(estimate) 是大致的猜测, 不等同于实际的工作耗时.
- sprint 的任务以时间为单位进行估算.
- Backlog 梳理(Grooming)
- 也被称为Backlog 细化(Refinement).
- 主要活动: 向Backlog中添加项目; 重排story的优先级; 创建工作量;分解大的story/task.
- 每次迭代中, 应该使用大概5%的时间�来管理backlog.
- Backlog 项目的工作量(effort)
