个月回顾一下敏捷开发的得失

　　其实人脑远没有我们自认为的那么强大，我们的系统1（可以简单理解为直觉系统）可以同时做几件事情，但是我们的系统2（可以简单理解为思维系统），它在一个时间内其实只能做一件事情，而且它很懒。
　　敏捷开发在今年已经经历了9个月的风雨。在部门内，敏捷开发已基本成型，在公司内，也有进一步发展推广的趋势，在世界上，好像人人都在谈论敏捷。因此，有必要在这个时候回顾一下这9个月的得失，毕竟方向比努力更重要。
　　1。收获
　　1。1。全功能型团队
　　一个团队，拥有策划、交互、视觉、软件、测试、运营各个领域的人员，有足够的能力实施任何软件功能从无到有，从有到优的过程。他们是一个整体，有着共同的目标，能够充分的交流，互相信任。他们是一只能真正打仗的团队。
　　1。2。有条不紊的流程
　　没有红绿灯，交通会堵塞，会出事故。同样，没有敏捷流程，项目进度会堵塞，项目下单会出事故。敏捷项目中的每一个人就是行驶在公路上的一辆辆车辆，他们既有自主的意识，也受制于交通规则的约束，他们合二为一成为一个整体，相铺相成。敏捷流程，将大家串在了一起，使大家步调一致，更高效的工作。
　　1。3。更快的发布与反馈
　　在敏捷的世界，发布速度更快那是基本，不能快速发布就谈不上什么敏捷了。目前，我们做到了每半个月对外发布一个版本，相比于之前的一个月甚至几个月，在发布效率上有了成倍的提升。这样，我们能更快速的验证我们的功能，更快速的修复问题，结合大数据和线上问题反馈，形成闭环，不断迭代，这才是敏捷的意义。
　　1。4。稳定的开发节奏
　　在今天，需求再也不是像以前那样一波一波的来，软件一波一波的忙。需求池不再是一个名词，它起到了应有的作用，需求也不在是高，很高，没有低，而是一个合理的高中低分布。就这样，稳定的需求决定了后端稳定的开发节奏，持续的功能迭代已经步入正轨。
　　1。5。可控的项目进度
　　在以前，我们会定一个某个不靠谱的月份下单，然后延后一个月，甚至两个月。渐渐的，大家习以为常，大家觉得项目延期理所当然。而现在，迭代的功能的项目进度完全可控，说哪天下单，基本上就在哪天下单。这样，项目组成员更有目标，也更有成就感，对功能进度关注的非项目组成员也能提前心里有数。
　　2。损失
　　2。1。满载的会议
　　为了有效的促进团队信息的流通，保障信息对称，敏捷采用晨会、需求评审会、用例评审会、迭代总结与计划会、版本发布会议等会议，在敏捷的世界里，他们都有其存在的必要性，甚至可以说，没有了他们敏捷寸步难行，但是带了一系列副作用，会议占用了团队成员的较多时间，如果某个成员不幸身处于多个项目中，那简直是一个噩梦。有得必有失，我们只能直面敏捷的会议消耗，因此，提高会议效率，是一项十分重要的工作。
　　2。2。超过强度的迭代
　　持续迭代，十分美好，但是长时间超过正常强度的迭代，对于团队来说那就是一种伤害。在这样的迭代环境中，团队成员因为疲惫，更容易暴躁，更难以沟通，大家疲于奔命，没有时间停下来思考，大家总日忙碌，渐渐的忘记了为什么要做这些事情，渐渐的，团队少了几分思想，只剩下执行。既然敏捷是持续迭代，那它就属于长跑，我们不能让一个人总是以短跑的速度去完成长跑。
　　2。3。误解带来的失落
　　当大家看到版本每半个月发布一次时，觉得我们任何一个新功能都能快速的上线，这往往是大家一厢情愿，大家的错觉。也因为有了这种错觉，对敏捷团队产生了很多误解，带来了打击，而不是肯定。
　　一个软件正常的生命周期包括以下：需求提出、交互设计、视觉设计、测试用例，软件开发、测试、发布上线、线上维护。
　　这里客观的举一个需要开发一周的功能：从需求提出到交互完成一周，软件开发一周，单模块测试一周，集成测试两周，因此在一切顺利的情况下，一个需要开发一周的功能，至少需要5周左右的时间才能上线。这就是我们目前的实际开发能力，我们要客观面对事实。
　　这里很多人会说，测试花了三周时间，太长了，交互也许也用不了一周，但是这就是我们的能力，或许这里有提升空间，但是这大半年的实际经验告诉我们，这是目前保持稳定的节奏的最佳方式，鼓励大家提供更好的方案，但不要仅仅只看到问题的一部分，我们是要解决的是产品整个生命周期的问题。
　　2。4。缺乏激情的目标
　　敏捷的持续进行，也是对团队成员的持续打击，时间越长，打击越强，因为随着时间的推移，按照现有的评价体系，大家会越来越没有成就感，缺乏创业般的动力。
　　为什么？人都是有思想的，不是机器，工作总会有点追求，工资是最基础的，一个有梦想有追求的人，或许是追求自身技术的进步，或许是追求自己做的产品的成功，或许追求事业的发展，或许追求家庭的幸福，但是绝不是追求没有任何成就感的迭代。这样的工作，我们有什么理由要求大家时刻保持创业的精神工作？
　　2。5。弱凝聚力的团队
　　虽然我们拥有了一个全功能型团队，但是这个团队的凝聚力却很弱，但是身处于这个团队不是为了创造激动人心的产品，而是为了完成迭代任务，因为只有这样才能较好的协作，如果可以，也许他们更愿意自娱自乐，而不是围着这个团队打转。因此，当有别的地方需要他们时，他们不会对现在这个团队有任何留念，因为哪里都一样。
　　3。敏捷接下来怎么走？
　　这个问题很复杂，因为我自身也在这个漩涡中难以自拔。但是我还是希望能解决这个问题，因为从长远来看，大家总会在这个漩涡中筋疲力尽。大胆假设，小心求证，我们需要有这样的勇气，就像很多人说传统行业转型是找死，不转是等死一样，找死至少还有一线生机。以下是我的一些方向和设想：
　　3。1。优化会议效率
　　会议多难以避免，但是优化会议效率却是我们能做到的事情，这个问题目前普遍存在，但是却没有引起重视，会议效率的提高不是简单的一句话，需要会议主持人和参与人都做好充分的准备，以及具备相应的能力，所以它不是简单的一两个流程和制度，更重要的是对人员的培养以及团队文化的建设，这些都需要时间、资源和精力。过多低效的会议，会让大家更低效的工作，甚至每天一起床就想着各种会议，就等着开会吧，反正中间间隔时间也做不了什么事情。
　　3。2。长跑式的迭代
　　有一个理论，当一个人按照正常步伐行走时，我们的大脑还能干点别的事情，如果让一个人保持一个比平时更快的速度行走，大脑就无法干别的事情了，《思考，快与慢》一书中提到的系统2需要持续保持快速的行走这个事情，因此如果让一个团队已一个不正常的速度保持迭代时，那么你就别想他们还能干点出乎你意料之外的事情来，因为他们只有能力完成你交代的事情。
　　其实人脑远没有我们自认为的那么强大，我们的系统1（可以简单理解为直觉系统）可以同时做几件事情，但是我们的系统2（可以简单理解为思维系统），它在一个时间内其实只能做一件事情，而且它很懒。
　　这里还有一个简单的实验，大家不妨自己试一试：
　　一个手保持1秒一下的固定节拍，每隔两个节拍周期性的完成4785每位加1的计算结果，并说出来，例如：4785的计算结果是5896。
　　3。3。明确敏捷团队的核心业绩
　　问题由小到大，这是目前面临的最大的问题，也是最难解决的问题，因此，我自身也对此疑惑不解。现在的敏捷团队缺乏明确的目标，一层不变的迭代，周期性的发布在一定意义上更让人感觉自己所做的工作按部就班，缺乏意义，严重缺乏成就感。
　　如何让团队成员身处于一个敏捷项目组中有所成就，实际操作中确实没有探索到有效的方法，如何明确敏捷团队的核心业绩，也是难以评估和量化，正因为如此，在这个问题上，目前只有方向，没有方法。
　　个人觉得以上三个方向，是下一阶段值得探索改善的方向，也许我们现在只做到了60分的成绩，但是一个一个问题的解决我们会做到70分、80分，有一天，我们的项目管理能正规化，能与这方面的佼佼者并肩，而不是一直处于这种纯工作经验式的直觉式管理和补丁式管理。