我们真的在敏捷吗？
“敏捷”这个词在互联网行业并不陌生，早在我刚入行的第二年，我就有幸加入一家以敏捷开发著称的公司，并且在那里得到了较早的一些敏捷的熏陶，比如每天开站会，脑暴，迭代计划会，项目回顾会等等；那时候并没有系统的去学习如何敏捷以及什么是敏捷，只是针对如雷贯耳的敏捷，每天，每周，每个季度在执行一些相关的活动。
来到xx以后，我以一个QA人员的身份投入到项目测试里面，随着时间和经验的增长，也越发的明白，项目质量和时间的控制需要一些项目管理的方法从源头去把控，从团队成员各个角度去思考，以结果导向去随时调整我们的步伐。
在过去的三个月里面，我经历过2次比较失败的迭代，以项目结果来说，非常让人沮丧，项目延期现象不说，而且项目上线以后出现过一些较为严重的Bug。
不如意的迭代结果给团队的自信心带来很大的打击，痛定思痛，项目成员针对在迭代过程中的问题也进行了相关的列举和总结：
QA同学总结如下：
1. 项目延期提测，导致上线延迟的风险
2. 需求蔓延，导致测试用例覆盖不到位
3. 开发提测质量较差，不断返工
开发同学总结如下：
1. 需求蔓延，导致开发时间紧张
2. 对老系统不熟悉，工作超出预期判断
3. 对于业务流程没有很好的理解和把握
4. 前后端联调经常阻塞
产品同学总结如下：
1. 整个开发和测试阶段，对她来说都是盲点，并不能真正的去了解风险和进度
2. 没有从任何一方提早预知到风险
在那之后的很长一段时间内，其实我都非常的困惑，我们是在敏捷，一样的开着着Sprint的迭代计划，一样每天早上站在一起开站会，讨论着昨天干了什么，今天要干什么；一样的组织着Sprint的评审会；开发测试也都非常努力在做自己的事情，但是面对项目中的各种暴露出来的问题，面对项目中最基础的铁三角的结果展示，我一直反问自己我们真的在敏捷吗？
初识互联网敏捷的三大支柱
带着我所经历的项目痛点，我报了云课堂的项目管理微专业，带着困惑和疑问，希望从项目管理专业的角度去发现团队到底哪里出现问题；
在敏捷的课程中，我得到了非常大的启发，结合我们项目的特点，我发现其实我们团队只是copy了敏捷的身形而没有领会他的神；当讲到互联网敏捷的三大支柱的时候，我如获至宝，感觉找到了我想要的答案。
敏捷中Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应，如下：
第一：透明性（Transparency）
透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
第二：检验（Inspection）
开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。
第三：适应（Adaptation）
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。
敏捷的调整
在系统的学习和理解了自适应敏捷以后，领悟到了敏捷所传达的一些持续改进的精神，于是重振旗鼓，围绕着敏捷的三个核心的思想，以优化项目时间和质量为前提，针对项目做了一些流程和制度上的调整：
1.过程透明化
我们首要面临的问题是如何让开发过程透明化，这样做的好处是能够提早预知到开发过程中的风险，把控项目范围和时间的风险；
在以往的过程中，我们团队每天早会的时候，只是站在一起，讲讲今天干了什么，明天干什么，但是我们没有针对开发过程进行相关的任务记录；以及在项目结束的时候，其实并不知道各个开发的预估和实际时间的排期是否有偏差；
基于透明性这个原则，我们利用Jira白板，进行开发任务和新功能需求的跟踪，每天早会进行跟踪，并且让开发自己去记录相关的预估和实际开发时间，这样对于开发自身而说是可以提高自己对任务的评估能力和对自己承诺时间的一个自觉性的提高。
其次，针对测试的同学，需要将测试计划以及测试过程透明化。在用例评审的时候，需要着重的将测试策略和测试用例过一遍；其次项目提测后至上线前，针对每日的测试进度和风险，进行邮件全员抄送，这样做的目的是便于让大家一起了解整个产品的进度和质量。
2.交付可检验
我们面临的第二个问题是如何提高开发的交付质量。在以往的过程中，主要突出的核心矛盾有2个：
1.在前后端联调的时候，后端同学交付出去的联调接口质量较差，联调时交付的接口50%以上仍然处于500的状态，所以联调时间较耽误大家的时间。
2.开发提测的质量版本较差，导致Bug较多，不断返工。
针对这两点，我们做了一些改进，希望在每一次提测之前，都可以有一个检验的标准，可以确保任务及时的完成：
1.联调前：利用接口测试平台，要求在后端用统一用平台自测成功后才可开始联调。
2.提测前：细化冒烟用例，统计每个版本的冒烟通过率进行版本迭代的跟踪，制定冒烟通过率的标准。
总结
随着不断的调整和改进，团队在质量和时间把控上有了各种改善和提高。
同时也让我明白，一个项目里面，我们遇到的问题大多是我们所看到的问题，可能问题的呈现方式会是各种各样的，在这个过程中，我们很容易被问题的表相所迷惑而是采取出现一个窟窿填一个窟窿的方式去解决问题;尤其在互联网企业中，敏捷开发的一些模式和方法能帮助我们很好的把控项目的进度和质量，但是团队如果仅仅走了敏捷的形式而没有领悟到敏捷的灵魂，仍然会暴露出非常多的问题。深刻理解敏捷背后的一些核心的支柱，核心的思想理念，敏捷的目的和价值以及团队所执行活动的背后的原则给我们提供了一些解决问题的思路，可以帮助我们从源头去找到问题和方法，给予团队不断去挑战困难和变化的信心！