敏捷开发实践的感悟

工作中采用敏捷开发已经好几年了,在实际采用这个开发模式遇到了较多问题,使我不得不重新反思敏捷开发。个人认为现如今，多数公司采取敏捷开发，失败的风险反而会几何倍数提升。

首先，请允许我简单的介绍一下敏捷开发，很多人并不想看这个，但基于知识的连贯性，我依旧不得不说这点。敏捷开发的概念如下：

• 什么是敏捷开发？敏捷开发是一种迭代式的软件开发流程，强调快速反应、快速迭代、价值驱动。
• 为什么要使用敏捷开发？敏捷开发能够快速响应客户需求，通过短增量完成工作来缩短DevOps生命周期。
• 谁使用敏捷开发？许多大型公司为了提高产品的开发效率，已经渐渐在开始运用敏捷开发。
• 在哪里使用敏捷开发？敏捷开发起源于美国，但现在已经在世界范围内被广泛采用。
• 何时使用敏捷开发？当需要快速响应客户需求并缩短DevOps生命周期时，可以采用敏捷开发。
• 如何进行敏捷开发？敏捷开发通过在短增量完成工作（通常称为冲刺）来缩短DevOps生命周期。冲刺通常长达一到四周。
• 敏捷开发的成本是多少？这个问题的答案会因公司而异，在部分公司是无穷。

其次，我想说一下敏捷的优缺点。如下：

敏捷开发的优点包括：

• 更快地交付价值
• 更低的风险
• 拥抱变化
• 更好的质量
• 持续改进
• 更高的客户满意度
• 更高的团队满意度
• 更大的灵活性

敏捷开发的缺点包括：

• 很难进行准确的资源规划
• 很难准确地定义“轻量级”或必要的文档
• 很难把握整体产品的一致性
• 很难预测有限的终点

然后，这里我着重说一下其缺点。各个公司在推行敏捷开发的时候，都遭遇了一系列的困难，所以往往在各公司都在不停宣传敏捷的好处。这里我先列一下目前已知，不适合使用敏捷开发的情况，

• 需求极其明确的项目，可能没有必要使用敏捷开发。
• 项目成员众多时，敏捷开发并不适用，这往往会导致团队成员不清楚自己要做什么事、为什么这么做、这样做解决了什么问题都不清楚。
• 项目团队人员不能实时快速沟通交流的时候敏捷开发不适用。敏捷开发原本就缺少很多的文档，如果团队成员沟通不畅，或者没有明确负责的功能点，经常交叉开发，而产品和项目经理不能很好管理组织各处的业务，就会导致没有人清楚系统的实际逻辑。
• 集中的命令式管理方式，并不适合敏捷开发。而这在现如今大多数采取敏捷开发的公司，这是很常见的，这些公司由产品、项目经理主导，经常只下达一系列的命令，下面的人蒙着头开发，当决策失误，就让研发人员加班解决，因为在他们看来，是开发人员不够“敏捷”，不能跟上需求的变化。

产品研发是企业构思、设计实现产品的过程，企业需要依据市场需求、行业环境和企业战略等多方面来设计产品开发流程。产品研发需要遵守一些基本原则，例如MVP原则，简洁原则，核心体验原则，数据导向原则，统一需求原则和系统效应原则等。

MVP原则指的是通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。简洁原则指的是专注于核心功能，简化用户体验。核心体验原则指的是在核心功能上做得足够好，再去延伸其他功能。数据导向原则指的是依据数据来降低错误概率。统一需求原则指的是统一需求出入口，避免需求满天飞。系统效应原则指的不仅仅是在产品设计和技术选型的系统性，还包括围绕产品上构想到售前、售中、售后的全链路的问题。

最后说一下我最近遇到的问题。

• 命令式管理方式：在开发过程中，对于存在疑问的点，产品和项目经理往往表现的很不耐烦，不能清晰明确地给出需求，只想下达一个命令，我们执行。之后的一切问题，以bug形式输出到研发团队。
• 产品和项目经理并不关心需求：不关心不在乎需求，让客户和用户来试错，并不在乎产品是否合理。即使让研发在车轱辘上放上方向盘，将车轮放在车里也没关系，毕竟对于产品和项目经理而言，敏捷要拥护变化嘛，有什么问题让研发改就行了。
• 产品和项目经理限制研发对需求的了解：当研发质疑需求时，给出的答复有时是以现场有，以现场为主，有时和现场不符了，又说以我为主，当研发人员觉得需要明确的时候，有时回怼：你说，去问谁？你自己去问。有时回怼：我们看过现场，你们没看过，照着做就行了。有时说：这些是要保密的，你们照做就行了。
• 开发大半年了，底层模型仍旧没有确定，系统的分类规则，各对象的关联关系依旧不能确定，回复是：后面实际落地还是会大改的。
• 需求无法把控，产品自己也只管输出客户用户提出的需求，人员都是谁有空谁改，有时改了一半，又被调去做其他需求。没有人能说清楚某一块的需求，设计逻辑，实现逻辑等等。
• 研发无法规避这种管理造成的种种问题：在每个需求变更的过程，及变更后，研发仍需解答产品和测试提出的各种问题，仍需按照当前给出的逻辑，调整修改代码，仍然要在极短时间内分析，开发，配合测试并修复提出的问题。整个系统不是PPT，仍然有很多逻辑，推翻重做带来的工作量似乎理应研发买单。
• 产品和项目经理的输出以下达命令，给领导写各种材料为主，而这些并不面向开发，对于系统的研发毫无建树。
• 经典问答： 研发：你这明显不合理啊？ 产品：不合理你先做，后面变了，你可以指着这个骂我，说这是我说的吧？ 研发：骂你是不是就不用改了？ 产品：那不行。

• 产品什么都想要：产品没有定位，没有亮点，但是什么都做，处处展现着我们的无知......

我们这家餐厅,大堂的经理不能明确说出来客户想吃什么就算了,还夹杂着许多自己的口味,还不停地换食材,换搭配,满汉全席都快做完了,还没搞明白客户用户的需求和痛点......甚至端出一盘盘在极短时间内开发出来的新菜,还要大厨保证每道菜的质量,为每个他们的错误决策买单......阿门,刚刚那道九转大肠,产品要求保留大肠原始的味道......这真的不能怪大厨呀,希望客户和用户不会被恶心到......不停研发新菜,也许凑巧就成功了,不是吗?然后就可以当做经典案例大肆宣传了~~~加油吧,chatGPT,你适合这种忽悠产品的场景,快快发展起来吧,让他们自己恶心自己去。