项目管理：敏捷开发方法论

可视化演示

展示Scrum Sprint迭代循环（计划→开发→评审→回顾）、看板流动管理（WIP限制）及敏捷度量指标（速率/燃尽/缺陷率），动态演示敏捷开发全流程。

敏捷起源：从“瀑布之痛”到“四项宣言”

老陈以前在大饭店后厨干过，那里的规矩是“一锤子买卖”：菜谱年初定死，从备料到摆盘一条流水线走到底，中间谁也不能改单。结果辛苦忙活大半年，端上桌的菜早不是客人想吃的了。这种“一次性走完”的流程，在软件行业里就是瀑布模型——需求、设计、开发、测试、交付五个阶段串行推进，每个阶段都要等上一个阶段彻底结束才开始。最大的痛点是：需求冻结得早，反馈来得晚，等到验收时才发现全盘跑偏，返工成本高得吓人。

2001 年，17 位软件行业的老手聚在一起，提出了敏捷宣言。他们给出的解药不是更厚的文档、更严格的流程，而是四个价值取舍：个体和互动高于流程和工具；可工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。注意，宣言没有否定流程和文档，只是说当两者冲突时，前者优先。就像老陈的食堂，菜单、账本都还在，但客人的实时反馈永远是第一位的。

这套思想孵化出了一系列具体框架：Scrum 负责节奏和角色，看板负责可视化流动，极限编程（XP）强调工程实践。它们共同的特点是“短周期、快反馈、勤调整”。敏捷不是没有纪律，相反，它用更轻的流程约束换来了更频繁的纠偏机会。

框架角色：餐厅里的铁三角

深夜食堂能运转，靠的是三个角色各司其职。老板老陈决定卖什么：他观察客人口味、维护一份“候选菜单”、拍板哪道菜下周上——这是对菜品价值的最终裁决。主厨阿忠不碰菜单，他管节奏：催菜、协调、扫清障碍，保证后厨不崩盘。至于每道菜具体怎么炒、谁来炒，阿忠不插手，由厨师们自己商量着来。

在 Scrum 里，这三个角色有一个标准名称。产品负责人（PO）是唯一的“价值决策者”，他负责维护产品待办列表（Product Backlog），把需求按商业价值排序，回答“做什么、先做什么”。敏捷教练（Scrum Master）不是经理，是流程的守护者：他确保会议按时开、规则被遵守、障碍被移除——就像阿忠在后厨四处灭火，但从不替厨师颠勺。开发团队则是自组织的，他们自己拆任务、认领任务、决定技术方案，回答“怎么做”。

自组织不等于没人管。恰恰相反，成熟的团队需要更强的责任感：任务认领靠自觉、进度透明靠自律、跨职能补位靠默契。老陈的食堂里，切配的师傅偶尔也会去盯一眼蒸锅，这叫“团队整体对交付负责”。一个 AI 项目团队同样如此——算法工程师、数据工程师、产品经理之间没有森严的等级，只有清晰的角色边界的共同目标。

冲刺迭代：一周一桌新菜

老陈现在的经营节奏很有规律：周五闭店后试菜，定下下周菜单（计划会）；每天早上开工前，前厅后厨对一遍单子，谁卡住了当场说（站会）；周日晚上请几位老客人来试新菜，听反馈（评审会）；全部收拾停当，大伙儿围一桌复盘这周哪里手忙脚乱（回顾会）。这一整套循环，就是一次“冲刺”（Sprint）。

冲刺是一个固定时间盒，通常 1 到 4 周，目标是产出“可以端上桌”的交付增量。冲刺计划会从产品待办列表里挑选本迭代要做的用户故事，并拆成具体任务；每日站会严格限时 15 分钟，只同步三件事——昨天做了什么、今天做什么、遇到什么障碍，不展开讨论；评审会向干系人演示可工作的产品，收集反馈；回顾会则聚焦流程改进，找出一个下个迭代要改的点。四场会议形成一个闭环：计划 → 执行 → 反馈 → 改进。

团队能持续稳定地规划冲刺，靠的是一个关键指标——速度（Velocity）。它的计算很简单：

用户故事：客人的一张点菜单

有客人进店说：“来点热乎的。”老陈若真端上一碗热汤，客人可能皱眉说“我想要的是热粥”。需求说不清，后厨再忙也是白忙。在敏捷里，“用户故事”就是解决这个问题的翻译器。它的标准格式只有一句话：“作为〈某个角色〉，我希望〈做某件事〉，以便〈达成某个价值〉。”三个要素缺一不可：角色回答“谁要”，功能回答“要什么”，价值回答“为什么”。

好故事要符合 INVEST 准则：独立的（Independent）、可协商的（Negotiable）、有价值的（Valuable）、可估算的（Estimable）、小的（Small）、可测试的（Testable）。就像一张合格的点菜单，不能含糊其辞，必须具体到“少盐、不放香菜”这种可验证的程度。估算时，团队用故事点而非小时——故事点衡量相对复杂度，常用斐波那契数列（1、2、3、5、8、13），因为人对复杂度的判断天然是模糊的、非线性的，就像给菜分“家常菜、功夫菜、硬菜”三档比精确到分钟更靠谱。

优先级排序常用 MoSCoW 法：必须有（Must）、应该有（Should）、可以有（Could）、不会有（Won't）。老陈上新菜也会先问：这菜没有会砸招牌吗？有它会加分吗？没有它客人会介意吗？最后还要配上验收标准，AI 团队最常用 Given-When-Then 格式：“给定模型已训练完成，当我提交一份新样本时，那么系统应在 1 秒内返回预测结果。”这让“做完”有了客观证据，而不是凭感觉。

看板实践：出菜口的任务墙

深夜食堂的墙上贴着一排任务卡：备料、切配、下锅、上桌。每张卡代表一份订单。老陈立了条铁规矩：每个厨师手里最多同时捏两张单子，做完一张才能从线上再抽一张。这条规矩让后厨从没乱过——没人闲得发慌，也没人忙得四脚朝天，菜品的等待时间大大缩短。这就是看板方法：把工作流可视化，然后限制在制品（WIP），让工作“拉动式”地流动。

看板的核心有三个：第一，可视化工作流——把流程分成若干列（如待办、分析、开发、测试、完成），所有任务以卡片形式贴在对应列里，谁在做什么一眼可知；第二，限制在制品——每列有 WIP 上限，比如“开发中最多 3 张卡”，堵住的列不再进新卡；第三，拉动式生产——上游只在下游有空位时才补充新任务，而不是一股脑往下推。这套逻辑和食堂后厨一模一样。

为什么限制在制品能加快交付？利特尔法则给出了数学解释。它描述的是排队系统里三个量的关系：

瀑布对比：大饭店和深夜食堂

大饭店接婚宴订单，菜单提前半年定死，流程照本宣科，好处是计划性强、文档齐全、责任清晰——这是瀑布模型。深夜食堂的客人随来随点，菜谱周周更新，边做边改——这是敏捷。两者没有高下之分，只看场合。瀑布模型适合需求明确、变更极少、合规要求高的项目，比如银行核心系统、航天控制软件；而敏捷适合需求不确定、需要快速试错、市场变化快的项目。

AI 项目有个鲜明的特点：大部分时间花在“探索”上——模型效果好不好要训练了才知道，数据够不够要标了才清楚，用户买不买账要上线了才见分晓。这种高度不确定性让瀑布模型举步维艰：你可能花三个月把“需求文档”写到完美，却发现算法在真实数据上根本不 work。敏捷的“小步快跑、每步可验证”正好对症：先做一个能跑的最小版本，让数据和用户说话，再决定下一步往哪走。

选择方法论时可以问三个问题：需求是确定的还是探索的？交付是低频合规还是高频试错？团队是职能竖井还是跨职能小团队？答案偏向前者选瀑布，偏向后者选敏捷。但现实中很少有“纯瀑布”或“纯敏捷”，更多是混合形态——比如整体框架用瀑布做里程碑，每个里程碑内部用敏捷迭代。老陈的食堂也接宴席订单，只不过他会把宴席拆成“前菜、主菜、甜品”三个小迭代来准备。

质量保障：不能等上桌才发现咸了

老陈定过一条死规矩：任何菜出锅前必须试味，不合格直接重做，绝不让客人当小白鼠。这条规矩的成本看似增加了，实际上省下了更大的代价——一盘菜被退回重做，浪费的食材和客人差评的口碑，远比试味那几秒钟昂贵得多。敏捷里的质量保障也是这样：质量不是最后阶段“大检查”查出来的，而是每个迭代里“内建”进去的。

具体到工程实践，三件事最重要。第一是持续集成（CI）：代码每天合并到主干、自动构建、自动跑测试，让“集成地狱”消失——就像老陈每天开张前先试一遍所有灶台的火焰，而不是月底才检查煤气管道。第二是自动化测试：单元测试、接口测试、端到端测试组成一张“安全网”，回归测试不用靠人肉记忆——就像后厨有一套标准化的口味检查清单，新手也能照着试味。第三是结对编程：两个人一起写同一段代码，等于“双人四手、两双眼睛”，它本质上是实时的代码评审。

团队还需要一个共同的质量底线——完成的定义（DoD，Definition of Done）。一个用户故事要算“做完”，必须同时满足：代码评审通过、自动化测试通过、文档已更新、产品可部署。DoD 是全组共识，不是某个人说了算。它像后厨的“上岗证”：一道菜从“炒完”到“可以上桌”，中间隔着一整套试味和装盘标准，谁也不能跳过。

风险管控：主厨的冰箱清点

每天晚上打烊前，主厨阿忠都会清点冰箱：牛腩还够明天两桌，青菜只够一桌半，得马上通知老陈调整菜单。这个朴素的动作，在项目管理里就是风险管控——风险不可怕，可怕的是风险没被看见。敏捷最常用的“看见”工具是燃尽图：把剩余工作量画成一条随时间下降的曲线，和理想线对比，偏离了就能立刻预警。前面可视化演示里的那张图，就是一次典型的“第 4 天突增需求”引发的燃尽线反弹。

需求变更是 AI 项目里最频繁的风险。模型效果不达标，突然要加数据；业务方看了 demo，临时要调交互。敏捷处理变更不是“来者不拒”，而是有秩序的变更管理：新需求先记录下来，评估它的故事点和优先级，然后用等价的故事点“交换”掉待办列表里优先级较低的任务，而不是简单塞进当前迭代。这样既尊重变化，又保护了冲刺承诺。就像老陈遇到客人临时加菜，他会说“这道菜要 40 分钟，您看是等，还是换一道同样费时的炖菜？”

风险燃尽图是燃尽图的变体：纵轴换成风险等级（发生概率 × 影响程度），跟踪高风险项是否随迭代推进而下降。进度可视化（看板 + 燃尽图）让所有人都能看到“车在哪、往哪开、油还够不够”。冲刺回顾会则是风险管控的最后一环：把本周踩过的坑、堵过的车写进改进清单，下个迭代必须落实一项。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""敏捷冲刺规划模拟器: 按 WSJF 优先级挑选用户故事进入冲刺"""  class UserStory:    def __init__(self, title, points, value):        self.title = title          # 故事名称        self.points = points        # 故事点 (工作量)        self.value = value          # 商业价值     def wsjf(self):        # 加权最短作业优先: 价值/点数, 越大越优先做        return self.value / float(max(self.points, 1))  class SprintPlanner:    def __init__(self, velocity_history):        self.stories = []                    # 所有待排期故事        self.velocity_history = velocity_history  # 历史冲刺速度     def add_story(self, story):        self.stories.append(story)     def avg_velocity(self):        if not self.velocity_history:            return 0.0        return sum(self.velocity_history) / float(len(self.velocity_history))     def plan_sprint(self):        capacity = self.avg_velocity()        used = 0.0        plan = []        # 按 WSJF 降序挑选, 容量超 20% 则不再加入        for st in sorted(self.stories, key=lambda s: s.wsjf(), reverse=True):            if used + st.points <= capacity * 1.2:                plan.append(st)                used += st.points        return plan, used  def main():    planner = SprintPlanner([34, 40, 38, 42])    planner.add_story(UserStory("数据标注流水线", 5, 20))    planner.add_story(UserStory("训练监控看板", 8, 30))    planner.add_story(UserStory("Prompt 调优工具", 3, 15))    planner.add_story(UserStory("模型灰度发布", 13, 50))    plan, used = planner.plan_sprint()    print("选中故事数:", len(plan))    print("占用故事点:", used)    for st in plan:        print("-", st.title)  if __name__ == "__main__":    main()

1. class UserStory:定义用户故事类，包含标题、故事点（工作量）和商业价值三个字段，对应正文里用户故事的三要素。
2. def wsjf(self):计算加权最短作业优先得分，价值除以点数，得分越高越优先，像老陈判断“哪道菜最值得先上”。
3. self.velocity_history = velocity_history保存团队历史冲刺速度列表，用于估算当前迭代容量。
4. def avg_velocity(self):计算历史速度平均值，对应正文中的速度公式 V = ΣP/N。
5. for st in sorted(self.stories, key=lambda s: s.wsjf(), reverse=True):把所有故事按 WSJF 降序排列，逐个尝试放入冲刺计划。
6. if used + st.points <= capacity * 1.2:容量校验，允许 20% 的弹性空间，防止硬塞导致迭代承诺落空。
7. if __name__ == "__main__":可执行入口，运行后输出本迭代最终选中的故事清单。

常见误区

面试题