敏捷开发

目录

背景

敏捷开发的真正内涵

敏捷开发不仅是方法论，更是一种价值观和思维方式，其核心体现在《敏捷宣言》的四大价值观中：

  1. 个体与互动 高于流程与工具
    • 强调团队成员间的直接沟通，而非依赖文档或流程。例如，通过每日站会（Daily Standup）同步进展，而非通过邮件汇报。
  2. 可工作的软件 高于详尽的文档
    • 目标是通过迭代持续交付可用功能，而非追求完美的设计文档。例如，用户故事（User Story）仅描述需求核心，细节在开发中逐步澄清。
  3. 客户合作 高于合同谈判
    • 业务方（客户）作为团队成员深度参与开发，而非仅通过合同约束。例如，产品负责人（Product Owner）全程参与迭代计划会和评审会。
  4. 响应变化 高于遵循计划
    • 接受需求变化是常态，通过短周期迭代快速调整方向。例如，在迭代评审会后根据反馈重新排定优先级。

敏捷开发的深层原则

  1. 以用户为中心
    • 通过持续交付用户价值驱动开发，而非单纯完成技术任务。
  2. 渐进明细
    • 需求在开发过程中逐步细化，而非初期追求完美。例如，用户故事从“模糊的需求”逐步拆解为具体任务。
  3. 自组织团队
    • 团队自主分配任务、解决问题，管理者角色弱化（如Scrum Master仅负责移除障碍）。
  4. 快速试错与学习
    • 通过MVP（最小可行产品）快速验证假设，失败成本低，学习速度快。
  5. 持续改进
    • 每个迭代结束后通过回顾会（Retrospective）优化流程，而非“一次性完成”。

如何建立自组织团队

一、建立自组织团队的基础条件

  1. 信任与心理安全

    • 团队成员需要彼此信任，敢于表达不同意见，无需担心被指责。
    • 实践：通过团队建设活动（如信任游戏、开放讨论）打破隔阂，鼓励透明沟通。

  2. 明确的共同目标

    • 团队需对齐一个清晰的愿景（如“3个月内交付用户注册功能”），而非各自为战。
    • 实践：通过冲刺目标（Sprint Goal）和用户故事地图（User Story Mapping）明确优先级。

  3. 跨职能能力

    • 团队成员需具备互补技能（开发、测试、设计等），减少对外部依赖。
    • 实践：通过“T型人才”培养计划（如开发人员学习测试技能）。

二、赋予团队自主权的关键动作

  1. 减少微观管理

    • 管理者（如Scrum Master）角色从“指挥者”转变为“服务型领导”，负责移除障碍而非分配任务。
    • 实践：管理者仅提出业务目标（如“提升支付成功率”），由团队自行拆解任务。

  2. 任务自分配

    • 团队成员根据能力和兴趣主动认领任务，而非被动接受指派。
    • 实践：在迭代计划会上，成员通过“任务集市”选择任务（如看板上贴出任务卡片，自行领取）。

  3. 自主决策权

    • 团队有权决定如何实现目标（如技术选型、任务顺序）。
    • 实践：技术方案由团队投票或讨论决定，而非上级强制要求。

敏捷开发 vs. 瀑布式开发的核心区别

特性 敏捷开发 瀑布式开发
开发流程 迭代式、增量式开发，以短周期（如双周迭代）交付可用的功能。 线性、顺序式开发，按照需求、设计、实现、测试、维护等阶段依次进行。
需求管理 需求动态调整，允许在开发过程中根据反馈和变化修改需求。 需求在项目初期完全定义，开发过程中需求变更困难。
交付方式 频繁交付小版本，逐步完善产品。 项目完成后一次性交付完整产品。
灵活性 高度灵活，能够快速响应变化。 灵活性低，难以应对需求变化。
沟通与协作 强调团队协作和持续沟通，业务方与开发团队紧密合作。 阶段之间沟通较少，通常由文档驱动。
风险管理 通过迭代开发和持续反馈，能够早期发现和解决问题。 风险集中在后期，问题可能在项目结束时才暴露。
适用项目规模 适合中小型项目或复杂、不确定性高的项目。 适合大型、需求明确且稳定的项目。
文档要求 轻量级文档，注重可工作的软件。 需要详细的文档，每个阶段都需要完整的文档记录。

敏捷开发模式强调团队协作和持续沟通，业务方与开发团队紧密合作，具体体现在：

  1. 业务方通过产品负责人、需求澄清和反馈机制，深度参与开发过程。
  2. 跨职能团队通过自组织、每日站会和结对工作，紧密协作。
  3. 通过迭代计划会、评审会和回顾会，确保信息透明和持续改进。
  4. 通过优先级管理、增量交付和MVP，持续交付业务价值。
  5. 通过问题快速暴露、风险共担和持续改进，优化协作流程。
  6. 通过客户参与、用户测试和快速响应变化，确保产品符合用户需求。

问题

敏捷是双周一个迭代，我们可能需要知道全年的项目计划。因为要做人力资源的预算，招聘准备什么的

交付件

迭代日历

以2周为迭代为例子。

流程

敏捷开发分 “需求功能管理”和“迭代开发管理”子流程。最低标准，需求功能管理做一个迭代的需求功能设计，好的敏捷团队可以做1个月甚至更长时间的提前需求设计。

有些团队仍然会提前规划未来1个月甚至2个月的需求设计。这种做法有以下几个好处：

1. 确保需求一致性和完整性

  • 减少需求变更：提前规划可以帮助团队更全面地理解业务需求，减少后期需求变更的可能性。
  • 避免遗漏：通过提前设计，团队可以更好地识别潜在的需求遗漏或逻辑漏洞，避免在开发过程中发现问题。

2. 提高开发效率

  • 减少返工：提前设计可以减少开发过程中因需求不明确或设计不合理导致的返工。
  • 并行工作：开发团队可以提前了解未来的需求，开始相关的技术调研或准备工作，提高开发效率。

迭代开发管理流程

需求澄清（活动）

【任务】审视设计

【任务说明】
通盘审视所有待澄清需求的设计成果，评估：
1、迭代容量与工作量是否匹配，如果不匹配（工作量过多或过少），则需要与设计小组沟通调整迭代规划（迭代的次数、起止时间和需求排期），或者协调资源。
2、设计成果是否符合相关规范，拒绝质量低下的设计成果对应的需求。
【执行角色】研发组长
（1）评估迭代容量与工作量是否匹配，并根据评估结果，调整迭代规划或者协调资源
【参与角色】
1、产品经理/业务分析师
（1）参与评估
（2）根据评估结果，支持研发组长执行
2、技术架构师
（1）参与评估

【★关键任务】澄清需求

【任务说明】
产品经理在此阶段，必须正式发起一场需求澄清会议，提前在团队内公示需求相关材料，需求澄清会议上，设计小组需把版本价值、功能需求、概要设计讲解清楚。
研发组长需要识别每个需求的交付小组相关人，以侧重对该需求的理解。
交付小组对需求及方案有全面而清晰的认知，如果有异议，需要尽快与设计小组沟通直至达成一致。
【主导角色】
产品经理/业务分析师
（1）组织需求澄清会议的召开
（2）把版本价值、功能需求讲解清楚
（3）对于参会人的疑问进行答疑
【参与角色】
1、技术架构师
（1）对概要设计做讲解
（2）主导完成功能需求粒度的最终确认
2、研发组长
（1）熟知需求及方案
（2）对需求疑问点进行确认并达成一致
（3）识别每个需求的交付小组相关人
2、开发工程师
（1）熟知需求及方案
（2）对需求疑问点进行确认并达成一致
（3）按需开展需求反串讲
3、测试工程师
（1）熟知需求及方案
（2）对需求疑问点进行确认并达成一致
（3）按需开展需求反串讲
（4）判断是否需要测试方案
【准入】
本迭代的功能需求均已进入待澄清状态并通过审视

产品原型（终版）
产品需求说明书
概要设计说明书
高保真设计稿（按需）
【准出】
1、交付小组对需求无异议
2、确定需要做详设的需求清单

研发计划

【任务】制定研发计划

【任务说明】
研发组长组织交付小组基于诺亚平台完成迭代容量设置、分配需求处理人、任务拆分及任务工时评估、迭代阶段设置（交付侧），平衡成员饱和度，确保组内成员对任务、时间阶段安排无异议。

【★关键任务】召开研发启动会

【任务说明】
研发组长正式向交付小组同步迭代研发时间阶段，需求分配情况，成员任务清单，并锁定迭代。

DOD （关键）

每天站会跟DOD会议合并，下班之前开DOD，没有完成任务的开发需要留下来完成。

XXX 迭代
一、当前迭代
需求总数 X，已全部澄清完毕，开发进度9%，缺陷总数8，剩余4个未关闭

迭代风险项：（风险，应对措施）

生产问题项：

二、下迭代下迭代需求扭转进展(是否有风险)

参考资料

posted @ 2025-03-12 17:16  向着朝阳  阅读(45)  评论(0)    收藏  举报