来!聊聊用 Al+Agile敏捷 进行软件开发的这些事

敏捷开发的核心实践大多建立在关于人类行为和团队生产力的假设之上。其中最基础的假设之一就是：我们需要跨职能团队。传统敏捷团队通常由5-7人组成，每个人拥有不同的技能，这些技能相互补充，形成一个完整的知识网络。这种设计背后的逻辑很简单：团队需要混合互补的技能，否则就无法构建他们应该构建的产品。

但生成式AI的出现改变了这一切。现在，每个人实际上都拥有一个AI同事，这个同事速度惊人，精通所有编程语言、所有流行框架、所有设计模式，并且拥有比任何人都多的知识。在同样的视觉隐喻中，添加一个AI团队成员意味着添加一个比任何人类圆圈都要大得多的知识圆圈。

AI模型虽然还不够完美，仍然需要人类的监督，但一两个拥有强大提示工程技能和顶级生成式AI模型的人，无论是在速度还是质量上，都会超过传统的敏捷跨职能团队。有了AI同事，开发效率会大幅提升——几小时内完成过去需要几天的工作，几天内完成过去需要几周的工作。

这意味着跨职能团队仍然很重要，但不像过去那么关键了，因为知识不再是真正的瓶颈。一个1-2人的团队加上AI，就能获得他们需要的大部分知识。为什么不是1个人而是2个人？因为有另一个人可以交谈总是一件好事，而且更容易处理休假和病假等情况。

当团队规模缩减到2个人时会发生什么？是否需要解雇团队里的其他人？聪明的公司会选择为所有人赋能，而不是只赋能少数人然后解雇其余的人。因为这个原因而解雇一批人，可能会创造一种恐惧文化并扼杀创新——人们将没有动力进一步探索这项技术，因为效率提升意味着更多人被解雇。

相反，假设最初有2个各5人的跨职能团队。现在这可能被拆分为5个各2人的团队加上AI。这些小团队做什么工作呢？这取决于具体的情境。这是一个"奢侈的问题"：开发能力增加了，我们用这些能力做什么？

如果原来的两个大团队正在一起做一个产品，专注于不同的功能区域，那么现在有5个小团队，每个团队都比之前的大团队更高效。可以让所有5个团队都在同一个产品上工作，就像以前一样专注于不同的功能区域，结果是在该产品上完成更多的工作。或者让3个团队专注于现有产品，2个团队开始一个新产品，从而放大公司整体的生产力。

这带来了一个必然结果：AI赋能的团队将导致团队更小，团队数量更多。

小团队意味着更少的会议和其他内部协调仪式。如果他们坐在一起，无论是物理上还是数字上，并且根据需要随时交谈，那么他们在团队内部几乎不需要任何正式会议——例如，当他们可以随时交谈时，就不再需要每日站会。当然，他们可能仍然会为了社交原因这样做。

但另一方面，现在有比以前更多的团队。因此，跨团队协调的需求会增加，至少当这些团队在同一个产品上工作并且有依赖关系时是这样。事实上，如果他们在同一个产品上工作，也许每个团队都可以被视为一个更大的"超级团队"的单一团队成员，然后在团队之团队的层面上进行回顾和冲刺规划会议等仪式。

大多数公司最终可能会有某种形式的每日同步会议，以及每隔几周一次的某种规划会议。但这些会议的结构将与传统的敏捷实践不同，例如它们很可能是跨团队会议而不是团队内部会议，规划会议可能会更关注大局而不是具体的待办事项。

软件工程师不再主要写代码，这是一个清晰的趋势。AI模型在编写代码方面变得越来越好。虽然还不完美，但已经足够好，让AI同事编写大部分代码变得有意义。这从根本上改变了这个角色。

作为软件工程师，仍然需要负责，思考架构，编写提示词，审查结果，并对代码质量负责。但实际编写代码的工艺——AI在大多数情况下会更快更好地完成。这在今天已经部分真实了，在一年内很可能在90%的情况下都成立。在AI时代坚持手动编写所有代码的软件开发者，很可能成为瓶颈和错误的来源。

冲刺会逐渐变得更短，或者完全消失。也许是一天冲刺。在一天开始时，与AI同事快速同步，决定今天关注什么，然后在一天结束前完成并发布，回家前进行快速回顾。每日站会和冲刺规划基本上变成了同一件事。

当多个团队一起工作时，仍然需要更高层次的同步会议，也许每周一次，以确保它们保持一致。无论有没有AI，这都是真的，但当我们朝着更多小团队而不是少数大团队发展时，这种需求会增加。

人类仍然需要每隔几周进行某种同步和规划会议。但这种会议的目的和结构会发生变化，因为我们转向了更快更短的开发周期，不再需要因为编码需要时间而将工作批量处理成多周的工作。

专家角色的定位也在发生变化。假设团队需要处理数据库和持久性，并且需要专业知识。传统上，会确保每个跨职能团队至少有一个具有数据库技能的人。在一个2人AI赋能的团队中，人类将缺乏某些技能，需要依赖他们的AI同事。这会足够吗？对于常规任务，可能足够。但有时对于更高级的任务，可能需要人类专家，例如制定提示词或评估结果，或者构建工具。人类专家还可以帮助确定哪些AI模型和工具适合当前任务，甚至微调模型使其在该专业知识上表现更好。

我们会有流动的或共享的专家。这不是一种新方法，一些敏捷团队无论如何都这样做。但这会变得更常见。

例如在上面提到的5个团队中，假设它们都使用数据库。也许一两个团队实际上有数据库专家，因为它们是做最多数据库工作的团队。但它们是共享专家，有时也会帮助其他团队。另一种替代方案是拥有不属于任何特定团队的流动专家，而是去最需要他们的团队。AI模型应该拥有所需的大部分专业知识，但人类专家在那里作为补充，当我们达到AI的极限，或者需要额外的人类专家眼睛来评估结果时。

对产品待办事项和优先级排序的影响：随着AI赋能的团队更快交付，产品待办事项需要更频繁地更新。产品负责人的角色会演变为更专注于战略优先级和利益相关者管理。

估算和规划的变化：传统的估算技术，如故事点或理想人天，会变得不那么相关，因为AI可以显着加速开发。团队需要采用新的规划预测方法。

敏捷框架的适应：流行的敏捷框架，如Scrum、Kanban或SAFe，需要调整以适应AI带来的变化。例如，像冲刺规划、每日站会和冲刺审查这样的事件的持续时间和频率需要调整。

对团队动态和协作的影响：虽然AI可以提高生产力，但重要的是考虑它对团队动态和协作的影响。团队需要找到新的方式在AI驱动的环境中培养人类连接、创造力和创新。

持续学习和技能发展：随着AI接管某些任务，团队成员需要专注于发展新技能，如提示工程、AI模型选择和结果评估。持续学习和技能提升在AI时代变得更加关键。

伦理考虑和透明度：团队需要应对围绕AI的伦理考虑，如偏见、公平性和透明度。敏捷实践需要演变为确保负责任的AI开发和部署。

"重新校准——我们花时间的事情需要改变。"这句话完美地捕捉了我们现在在所有角色和职业中面临的本质。需要重新校准在所有角色和职业上花费时间的方式。作为工程师、ScrumMaster、产品负责人、工程经理等意味着什么？

这对敏捷也是如此：需要重新校准敏捷实践。这始于自我反思。把时间花在什么上？仪式、角色、工件是什么？随着进入AI时代，什么需要被挑战、改变或重新评估？

不知道最终会如何。但很确定事情会发生变化，需要保持开放的心态，准备好迎接这个智能作为一种服务的新世界带来的所有可能性。

以上文章给予我们每位从业者一个全新的思考维度，变化正以难以想象的速度进行，如文章所说，“需要保持开放心态，准备好迎接所有可能性”。

个人针对上述3种开发模型做下讲解：

1. Waterfall瀑布模式

瀑布模式的特征是：“大家并肩子上，直接做出成品！”。 适合有明确开发目标，资金充实的项目。 参考图例，打个比方就是，想做一个汽车，那么直接进军汽车行业，把各零部件都做起来。 全部做好后，车也就好了。 所有部件相关需求都铺上人力或者按部就班一个个做。 反正目标明确， 我就是要汽车。如果资金很充裕，各部件该买买，该收购收购，该挖人挖人。开发速度也不慢，不能说不好的。

2. Agile敏捷模式

这是当前很流行的敏捷开发模式。图例中也非常形象。还是以制作一台汽车为例。在敏捷开发下，我们可以先完成一个最小可行产品：滑板。 然后逐步根据用户反馈迭代升级成品，逐步做出 滑板车， 自行车，摩托车，最后达成完整的技术链生产出汽车。

3. AI模式

这个模式就很灵性了。 不过它应该只是一个“趣图”，现实中应该没有人真的用这种AI模式来指导开发。 不过就好比作图一眼，我们需要让AI 必须画一幅图汽车的创想图，可能就会存在反复的微调过程。 图例表示的重点感觉就在于AI模式的微调处理。想让 AI 产出理想汽车图，得不断调整关键词、参数，从奇奇怪怪的初始稿，一步步迭代，把歪扭造型、奇怪细节慢慢修正，让结果贴合需求，像一场和 AI 的 “创意拉扯”，在反复微调里找最终答案 。