我的“伪敏捷开发”：重视期限与核心点、监控质量与频率
以前有看过敏捷开发相关的内容，被说不懂敏捷开发被人带着做敏捷开发，到后来我自己结合瀑布流与敏捷开发建立出一套比较能提高项目效率的“伪敏捷”模式。
一、敏捷开发是什么
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。——来源百度百科
其实从上面的描述里面，敏捷开发的核心理念是“以用户需求进化”、“迭代、循序渐进”、“持续可用”，相比起瀑布式开发，敏捷开发更加强调团队合作、快速响应、持续产出。两种模式各有优缺，其实现在很少纯粹的敏捷，也很少纯粹的瀑布式开发，更多是将两者结合。
二、我的“伪敏捷开发”
纯粹的敏捷开发，是基于用户需求，然后团队分析团队建模，快速开发，快速上线。但是这种做法非常考验团队及对工作的把控，因为大部分公司一个产品都不是纯粹的产品，除了负责某个产品线外，还需要很大量的其他工作，而且团队素质能力也未必很高。所以纯粹的敏捷开发比较少见到。
大部分的公司团队都是用瀑布式，我做了一堆需求，然后批量一个团队开发，批量上线，每次上线都是生死大关一样，通宵是常态化的情况。我一开始也是这种做法，但是后来发现太累了，将需求拆解得更细，将功能点之间的耦合降低到最低，逐步搭建，持续产出，这样随时可以叫停项目，又可以持续满足用户需求，同时也不会出现对实施团队高要求的问题。
这就是上面说的，以瀑布式为核心，但是附以敏捷开发的设计理念，结合产生的“伪敏捷开发”。这种追求的是在明确大部分的需求情况下，发挥团队的能力去推动完善，做完即上线不需等大版本更新，降低团队压力。
我的一些做法：
1、产品深度参与功能测试，把控每个细节质量
后来我带的团队，都要求产品人员亲自去测试每一个功能、细节，细致到按钮文案是否容易理解，这个交互是否容易理解。因为发现很多产品人员只是设计，然后丢给交互设计师去设计，然后实施，最后直接给用户，让用户来体验反馈问题。但是过程里面，产品对质量的要求很低，导致产品不知道自己设计多渣，用户体验了渣设计更反感这个产品。
2、过程中监控实施质量的频率与周期
A、前期：周一五各一次周例会，周一为本周工作及需求讨论，周五为进度更新，下周计划。在这阶段让开发专心设计底层架构，让测试专心研究需求，产品还得做其他项目，只要大功能方向没有偏离就好（这里只是说整个团队集中沟通的会议，常规、日常讨论还是会每天进行）；
B、中期：周一三五各一次晨会，目的是营造进度压力推进项目，在中期最容易出现问题就是团队感觉时间很多，可以慢慢磨设计、需求。加强产品对实施过程、细节的参与。很多时候开发遇到问题，卡在某个环节，不会懂得寻求帮助，在这时候需要产品去推动；
C、后期：每天晨会更新进度，共同测试快速修复问题，提高产品完成的质量。单纯依靠开发、测试人员去把控质量其实是很有问题，大部分的开发、测试人员，只是对功能测试，而不会站在用户的角度“测试”（如果遇到在乎用户体验的团队，那就好好把握住，别放手）。
3、需求会议及回顾会
A、需求讨论会议：这种会议其实不是开一次就足够，基本第一次开，全世界懵逼只有产品自己爽。一般我第一次需求会议，只是告知各位，我们要干这个事情，大概目的，虽然也会说下需求细节，但是不深。然后每周一左右，会对当前准备做的需求，进行深入讨论。每天会鼓励开发、测试聊需求，细节处调整需求，保持需求文档更新。
这种做法好处是持续灌输需求，并且推动整个团队一起参与到需求的设计里面。每次我都很直白，我的设计是垃圾，你们做的时候要注意，别被我坑了，觉得设计有问题，请找我一起聊聊，改完通知全员。这样开发、测试会相对更愿意去分析业务设计是否合理，团队参与感才会强烈。
B、回顾会：每周回顾会的时候，我都会先赞扬谁对需求有疑问，让我们的设计更完善。谁做完功能，好牛逼、有质量。就是在平时观察、留意团队人员的工作，挑有价值出来赞扬下，让各位融入到团队里面，为这个产品或者项目贡献自己全部能力。
在做完一次迭代之后，会举行一次小小的回顾会，先是说下做了什么，结果是如何，赞扬下过程的一些好的做法。然后每个人自己写做的好，做的不好，可以改善。最后一起聊聊。但是发现有更高一级人员在的时候很流于形式，各位还不如平时放得开的态度。
4、将目标、用户画像放在看板上
会将项目目标、用户的一些画像、流程图等放在看板上，看板上不仅仅只是需求卡片，这样聊起来某个需求的时候，也比较容易有针对性聊。我们是要为这些用户提供服务，这流程有问题，那看下怎么搞搞，是不？
我的一些经验：
1、重视期限与核心点，而不是追求所有都要满足
虽然用的是瀑布流的核心，在事前有立项有需求文档，要做这么一堆功能点，但是在实施过程中，我更加关注核心功能点的完成情况、整个项目的期限问题，而细节、伴生需求，或者那些优先级低、与核心流程无关的需求点，我有可能直接放弃掉
每个版本都有目的，围绕目的会有一些核心需求和非核心需求，只需要核心需求的质量、完成度可以，那这个版本，这个项目就完成，而不是追求所有写的，所有细节，都要百分百完美。因为这种百分百的完美需要付出很大的成本代价，而资源并不是可以随便挥霍。
2、敏捷开发不是晨会、看板这些东西
当时那上级带着我们团队开始敏捷开发，组织需求评审会议，组织工作量评估（卡片、需求规模大小评估）、项目看板（便利贴、需求流动）、晨会/周回顾会、需求过程讨论/变更等等这些东西。第一次接触的时候，感觉很新奇，但是接触第一天就心里面有疑惑，这些就是敏捷莫？跟看到的文章的敏捷开发的核心不一样。
经历了一次完整开发之后，发现更多事情，然后反思得出一个结论：这些晨会、看板，只是手段、方法、工具，这些的目的是促进沟通，这些根本不是敏捷开发的核心！讨论脱离用户、最后产出还是以大版本产出、过程中软件一直不可用。
3、团队不参与，等于不敏捷
说个当时常见的场景：晨会的时候每个人说一下昨日做了什么、今日计划、有什么问题/协助，然后大部分人都说没问题！这场景是不是在晨会或者周例会里面很常见，然后一般主持人也不觉得有问题，然后就结束。然而一转身，开发第一口就说：“傻逼，浪费时间”。
敏捷开发是要求整个团队一起建模发挥各自领域的能力去共同完成这项任务，让产品或者功能尽可能满足用户需求。而一般情况下，都是做好需求，然后开发、测试过来听，听完之后就干。而且一般情况下实施团队不是没问题，而是问题都是技术上的问题，就没有拿出来聊。最后就会演变成上面场景，流于形式的晨会及团队每个人都没真正参与到产品设计里面。
怎么引导团队多沟通并融入团队里面，这个才是敏捷开发的核心点之一。敏捷开发在我看来，更多是利用团队的力量在短的时间内，产出高质量的服务，满足用户的需求。
4、不要用“拥抱变化”来不停折腾“皮肤”
再说一个很常见的场景：当时产品拿需求跟交互设计师聊，然后讨论出A方案，我就屁颠屁颠写画原型写需求（当时我就是做小的~~后面戏肉来了）。第二天交互设计师找产品，聊那设计，感觉不是很好，然后沟通后，改成B方案，好，我再改文档。然后第三天产品找交互设计师，聊那设计好像还是很满足情况，不是很好，沟通后改回A方案！！！这时候我就内心一万个草泥马，于是我开始介入讨论过程，我提出，先做出来再看用户使用反馈，其实两个方案从根本上，没有什么差异。
为什么我会说这个，因为我从一开始就发现他们讨论的，都是一些“皮肤”交互问题，两套方案从本质上都没有影响用户的需求，而且这个需求点并不是这个功能的核心需求，只是一个伴生需求而已。而且更加重要的是，他们两个只是在那臆想用户，但是我发现两个交互设计水平都不强，所以就在那不断折腾。
为什么说上面这个场景很常见，就是因为很多时候产品自身水平或者性格问题导致设计犹豫不决，不断在这种没涉及到核心需求改变的点上面折腾“皮肤”，然后还美名为敏捷开发就是要拥抱变化，敏捷开发就是不冻结需求。
这里不是说需求不可变更，但是要分析到，这个变更是否对用户的核心业务、是否对整个功能的核心有正面还是负面的影响？这个才是真正判断变化的标准。
最后，虽然几乎全是项目管理的内容，但是作为一个产品经理，还是需要能够发挥团队的能力，调配响应的资源。而且方法只是“术”而已，核心是改善工作、提高效率、解决问题，这些是产品经理核心的“道”。模式没有好坏，而且在不断实践中不断完善升级，每个人都可以去思考一下，怎样才能让这事做得更好？相信很快，就会找到属于你自己的“术”与“道”。
有兴趣可以继续查看我的其他文章：
