日常运营对敏捷开发的借鉴

说实话，一开始想借鉴敏捷开发到日常运营里，我是拒绝的。敏捷的特点是封闭式项目，无外界干扰。首先这两点日常运营就不可能做到。但就像逆境中求生存一样，说着不行，还是会努力争取一下。

对于这个不晓得是美妆号还是心理建设号，还是百度普及下敏捷开发（AGILE）：

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

那么我们再看下日常运营的几个特点：

多个项目并行——可能一个运营小组要管理多个项目，且互相之间有实质性的交叉影响；

非封闭式——没有一个专门的周期，供成员专心对一个具体项目需求进行研究和开发，日常运营提供的是长期的需求保障，bug响应；

干扰性强——除了维护外，还有许多公司事务需要操心，服务、改进某个小需求、修正某个bug、测试、团队管理等等。

更不要说每个阶段循序渐进，随时处于可使用状态了，开发、测试、发版一步到位后才可使用。

于是在一次项目小组分享敏捷开发的优点后，没加入该项目的成员纷纷表示，要么加入，要么佛系运营。当敏捷中的开发成员，尤其是刚毕业就被分配玩敏捷的，很开心很幸福地表示敏捷真的很好很棒啊，增强了团队感情，觉得人生有目标有希望！其他人的表情，我基本都观察了，表面呵呵呵，心理mmp，你们小孩子真的不懂事，是运营团队在用生命保证你们不受一切干扰好嘛，然而理论上和实际上都会都归功于scrum master（scrum master表示我也很惨呀）。

我是正文分割线，而且正文非常短

首先，运营的需求多数是线上某一个流程的改进或新增，因此需求文档一般不庞大，只要理清流程顺序和其他流程所受影响，基本问题不大，因此我推荐结对需求。需求提出人理好框架，和开发一起review这个流程，切记，一定要开发打开程序一起看，因为可能是前辈写的代码，该开发并不知道隐藏多少问题。由该开发复述他看到的程序流程，需求人核对与现有需求有何冲突，是否需要更改某部分或编程方法是否需要修改。

其次，要求开发在需求下备注测试要点，若有方法变更的也必须备注。这样的好处是，第一，以后有疑惑，直接翻看需求文档；第二，提醒需求人特别测试某一点。当然，需求人在流程中也应写清每个流程，无需变更的需备注，因为开发会根据整体代码或方法进行调整，确保一致性，这里便是：流程无需变更，代码需变更。这要非常注意。

最后，需求人一定程度上也充当了PO和scrum master的角色，需求提出人不一定是项目经理，可以是小组中任何成员。把握自己的心理健康是很重要的，因为要求开发理解你的心情是不太可能，也不要对此做出期待。能理解需求的开发是很少的，当然也不是没有，我有遇到，这就是天使程序员。

又一条分割线，说在最后

标题所谓的对敏捷的借鉴，其实理论上少之又少，但仍然要从中获取有效方法，作为2~4人小团队的敏捷变种。没有完全的不适合，也没有完美契合，敏捷的特点就是拥抱需求变化，随时调整方法，尝试各种可能，我想这种精神对我们的人生都很有借鉴。

这篇文字主要提供给外行或非互联网人士茶余饭后看的，并不专业，但有些用处。