敏捷冲刺计划
概览
敏捷冲刺计划提供了一个结构化的方法，将工作组织成时间框定的迭代，使团队能够逐步交付价值，同时保持灵活性并响应变化。
何时使用
- 开始一个新的冲刺周期
- 定义冲刺目标和目标
- 估计用户故事和任务
- 管理冲刺待办事项优先级
- 处理冲刺中期变化或范围调整
- 准备冲刺评审和回顾
- 对团队成员进行敏捷实践培训
指令
1. 预冲刺计划
# 冲刺计划清单
## 1-2天前计划会议
- [ ] 梳理产品待办事项（确保顶部项详细）
- [ ] 更新用户故事验收标准
- [ ] 识别依赖和阻塞
- [ ] 准备前一个冲刺的估计
- [ ] 回顾团队速度（每个冲刺的平均故事点）
- [ ] 识别团队可用性/缺席
- [ ] 准备冲刺目标草案
## 收集信息
- 产品负责人优先级
- 团队容量（可用工作小时）
- 上一个冲刺的指标
- 即将到来的假期或中断
- 需要解决的技术债务项
2. 冲刺计划会议结构
// 示例冲刺计划议程和执行
class SprintPlanner {
constructor(team, sprintLength = 2) {
this.team = team;
this.sprintLength = sprintLength; // 周
this.userStories = [];
this.sprintGoal = '';
this.capacity = 0;
}
calculateTeamCapacity() {
// 容量 = 可用小时 - 会议 - 缓冲
const workHours = 40; // 每人每周
const meetingHours = 5; // 估计的站立会议，回顾等。
const bufferPercent = 0.2; // 20%缓冲用于中断
const capacityPerPerson = (workHours - meetingHours) * (1 - bufferPercent);
this.capacity = capacityPerPerson * this.team.length * this.sprintLength;
return this.capacity;
}
conductPlanningMeeting() {
return {
part1: {
duration: '15分钟',
activity: '产品负责人介绍冲刺目标',
deliverable: '团队理解业务目标'
},
part2: {
duration: '45-60分钟',
activity: '团队讨论和估计用户故事',
deliverable: '优先排序的冲刺待办事项和故事点'
},
part3: {
duration: '15分钟',
activity: '团队承诺冲刺目标',
deliverable: '正式承诺的冲刺待办事项'
}
};
}
createSprintBacklog(stories, capacity) {
let currentCapacity = capacity;
const sprintBacklog = [];
for (let story of stories) {
if (currentCapacity >= story.points) {
sprintBacklog.push({
...story,
status: 'planned',
sprint: this.currentSprint
});
currentCapacity -= story.points;
}
}
return {
goal: this.sprintGoal,
backlog: sprintBacklog,
remainingCapacity: currentCapacity,
utilization: ((capacity - currentCapacity) / capacity * 100).toFixed(1) + '%'
};
}
}
3. 故事点估计
# 使用规划扑克方法进行故事点估计
class StoryEstimation:
# 斐波那契序列用于估计
ESTIMATE_OPTIONS = [1, 2, 3, 5, 8, 13, 21, 34]
@staticmethod
def calculate_story_points(complexity, effort, risk):
"""
基于多个因素估计故事点
因素应评为1-5
"""
base_points = (complexity * effort) / 5
risk_multiplier = 1 + (risk * 0.1)
estimated_points = base_points * risk_multiplier
# 四舍五入到最近的斐波那契数
for estimate in StoryEstimation.ESTIMATE_OPTIONS:
if estimated_points <= estimate:
return estimate
return StoryEstimation.ESTIMATE_OPTIONS[-1]
@staticmethod
def conduct_planning_poker(team_estimates):
"""
处理规划扑克共识过程
"""
estimates = sorted(team_estimates)
median = estimates[len(estimates) // 2]
# 如果有显著分歧，讨论并重新估计
if estimates[-1] - estimates[0] > 5:
return {
'consensus': False,
'median': median,
'low': estimates[0],
'high': estimates[-1],
'action': '讨论并重新估计'
}
return {'consensus': True, 'estimate': median}
# 示例用法
print(StoryEstimation.calculate_story_points(
complexity=3, # 中等复杂性
effort=2, # 低努力
risk=1 # 低风险
)) # 输出：3点
4. 冲刺目标定义
冲刺目标模板：
冲刺：冲刺23（11月7日 - 11月20日）
目标声明： |
使用安全、直观的界面，让用户能够管理多种支付方式，减少结账时间40%
成功标准：
- 实现支付方式管理UI
- 支付逻辑测试覆盖率95%
- 性能：<200ms支付处理
- 零关键安全问题
- 向20%的用户发布功能进行A/B测试
团队承诺：89故事点
预期速度：85-95点
主要风险：
- 支付网关API变更
- 安全合规要求
- 集成复杂性
接受：
- 满足所有标准
- 功能部署到暂存环境
- 安全审查批准
- 团队和PO签字
5. 每日站立会管理
// 每日站立会结构和跟踪
class DailyStandup {
constructor(team) {
this.team = team;
this.standups = [];
}
conductStandup(date) {
const standup = {
date,
startTime: new Date(),
participants: [],
timeboxed: true,
durationMinutes: 15
};
for (let member of this.team) {
standup.participants.push({
name: member.name,
yesterday: member.getYesterdayWork(),
today: member.getPlanForToday(),
blockers: member.getBlockers(),
helpNeeded: member.getHelpNeeded()
});
}
return {
standup,
followUpActions: this.identifyFollowUps(standup),
blockerResolutionOwners: this.assignBlockerOwners(standup)
};
}
identifyFollowUps(standup) {
return standup.participants
.filter(p => p.blockers.length > 0)
.map(p => ({
owner: p.name,
blockers: p.blockers,
deadline: new Date(Date.now() + 24 * 60 * 60 * 1000)
}));
}
}
最佳实践
✅ 要做
- 基于过去冲刺中的实际团队速度来确定容量
- 包括中断和支持工作的时间缓冲
- 将冲刺目标集中在业务价值上，而不是技术任务
- 计划会议时间限制（2周冲刺最多2小时）
- 让整个团队参与计划讨论
- 将大型故事分解成更小、更易于管理的部分
- 跟踪故事点以进行速度趋势分析
- 根据实际完成情况审查和调整估计
- 保持一致的冲刺长度
- 在计划中包含回顾改进
❌ 不要做
- 计划100%容量利用率
- 跳过计划会议前的故事梳理
- 冲刺开始后添加故事（除非紧急情况）
- 让一个人为整个团队估计
- 使用故事点作为员工绩效指标
- 忽略团队速度趋势
- 没有明确冲刺目标的计划
- 为了匹配容量数字而强迫故事进入冲刺
- 为了节省时间而跳过冲刺计划
- 使用规划扑克结果作为最终估计而没有讨论
冲刺计划提示
- 保持故事在5-13点（将较大的故事分解）
- 保持85-90%的容量利用率（为中断留出缓冲）
- 将冲刺目标明显记录（物理看板或Jira）
- 跟踪5-10个冲刺的速度以识别趋势
- 使用历史数据进行更好的估计
- 在评审中庆祝冲刺成功
- 识别和解决估计偏见
- 根据回顾反馈调整流程