敏捷开发的初始理解

Posted 2022-12-01 壹叁零壹

一，什么是敏捷开发

1，敏捷开发的概念

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。 把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

2，遵循的基本原则

个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 虽然右项也有价值，但是我们认为左项具有更大的价值。

3，实际有效的建议

快速迭代 让测试人员和开发者参与需求讨论 编写可测试的需求文档 多沟通，尽量减少文档 做好产品原型 及早考虑测试

二，敏捷开发的具体实现形式

1，站会

每天工作开始前，小团队聚一起少时沟通。 确定每个人工作的大致情况，是否在预期的进度内；发现是否有异常情况，对异常情况进行管理，整理备用方案。一切都是为了按照预定进度进行，在适当的时间提供可用的版本。

2，看板

应用泳道图的样式，将任务的进度明显的展示出来。 应用及时的状态反馈，能够看到整体情况，也能够看到自己任务所处的状态，便于团队进度管控，以及适当的促进个人的工作效率。

三，敏捷开发的个人理解

1，敏捷开发的意义

敏捷开发通过各个形式，在不断的迭代，快速的提交可用软件的情况下，能够较好的适应用户需求，且整体进度的管控相对比较合理何时。 看板的应用也确实能够促进个人用户的工作激情，也能够便于管理人员掌控全体。

2，敏捷开发实现的误区规避

敏捷开发是一个理念，在具体执行时不能生搬硬套 （1）沟通因为参与人员多少，所消耗的成本区别，造成大团队不适用； 沟通进度及问题反馈，需要相关人员或者通才，或者更高层次的人才能理解与产生有效沟通，对于精于一个小方向或者一线执行人员，意义并不明确； （2）在软件规模较小的时候，版本之间的修改影响面较广，而在软件较大的时候，版本升级次数过多，对于用户很不好，对于测试人员，为了保证产品质量的回归测试资源浪费明显；且版本修改内容过少时，版本更新的意义就失去； （3）客户合作不合作不是最大的问题，最大的问题在于协同办公，甚至是异地协同办公，所以在没有有些数据收集与反馈渠道，客户合作再好也仍是解决不了新修改版本具体承载意义的反馈；在现在时时变化的社会潮流中，客户也很难把我自己真实的需求。若是你能够做好需求规划，满足客户，客户也是很满意的；若是客户自己定义需求，那就开始随着客户需求的变更整个团队无限轮转吧！若是用户能够很好的定义需求，那自己家的产品干嘛呢？！ 不是不要求变化，而是在变化中，需要遵循自己的规则，有自己的重心。
看过一篇文章，描述传统的瀑布研发流程是火炮，敏捷开发是导弹。这个从某种意义上已经阐明了瀑布研发和敏捷研发的特点。在个人的认知中，应该结合两种方式，各取其长，构建属于每个公司自己的工作模式。 火炮的造价低，火力猛，在快速定位目标后，集火干掉目标；这里的关键在于目标的瞄准 和 弹道发射的速度。大目标的确定，这是最关键的问题，及时研发最初是导弹，直接瞄准目标，也比胡乱开一个目标，不断调整到目标来的更快，成本更低。若是发现目标发生重大偏离不管是什么模式，都是需要新投入，进行调整的。 市场的表现即是，若是新一项突破性的技术形成，整体的产品方向必须调整。

个人建议，在传统的瀑布模型上，增加产品的管控；在研发的过程中使用敏捷模式，快速的交付产品，验证产品的效益，及时调整。形成良性的循环，不断反思，不断试错，进行成长。

参考资料：

为什么我不推荐敏捷开发？

你大概走了假敏捷

敏捷开发
要是在第一个产品版本中，只能有3个功能，你要选哪一个？书中给出的建议是，一定要有用户反馈和留言功能。因为，在一个产品的验证阶段和不成熟期时，用户的反馈永远是让产品朝正确方向迭代的重要决策依据。