前言
说到为什么想把敏捷的转型的历程写出来，一方面是为了把自己的经历整理下来，另一方面是为了可以分享给大家自己走过的坑，本人并非敏捷相关认证讲师，但是，是一个在敏捷项目上前行的实践者。以一个技术管理者的角度，不断优化项目管理和技术实践。
因为涉及敏捷，持续集成，持续交付等内容，暂且说整体风格，不会是一篇教材，或重理论的文章，更希望是简单项目日记。关于细节我也会分成几次来说明。
简单介绍一下目前团队
目前作为管理者，分管4个子项目，其中一个为全栈的产品团队，我们姑且称为项目A，有一点必须声明一下，我们是乙方，就是帮甲方完成实现商业价值的产品，换句话，我们负责的是交付任务。而接下来的描述就会以这个项目A，和这个交付背景为前提，展开说明我们在敏捷上的实践。
项目A从2018年开始，起初因为是面向2个产品线的开发团队，所以我们打算以敏捷的方式进行管理，虽然在此之前，我们没有进行过真的敏捷实践，有的只是和目前大多数团队一样，敏捷的流程，瀑布的思想。这种形式就是我们开始时候，项目管理模式，暂且称为敏捷初期。
如果你也刚开始做敏捷
我刚开始接触敏捷的时候，就是以Scrum为主，开始了解以下问题：
1. 敏捷的体制是怎样的，都有哪些角色？
2. 敏捷的流程是什么样的？
3. 支撑敏捷管理的工具的有哪些？
总之，通过各种途径，我会照猫画虎的来做，没有思想，没有文化的硬来，我开始在组内划分角色，召开会议，但结果可想而知，我们发现为什么一点不敏捷，而且更难以控制。你们是不是也遇到同样的问题呢？虽然这样，我们也不断的优化流程，找出影响推进的问题点，最后是我们扛不动了，中间也有一段时间，我们放弃了，团队一盘散沙。
我本身是向往拥抱变化，看到全世界好多团队在做敏捷，在做持续交付，比如传说中的aws，甚至秒级的持续集成和发布，是我一直向往的一种团队状态。当然我也希望自己团队，在自动化测试到部署的流程能更加前进一步。所以，我不能放弃。我开始寻找这背后发生问题的根本原因是什么。这也是我们在敏捷初期所遇到各种问题的原因。
请用以下问题来审视自己
1.团队是否有敏捷文化？
首先提出三个问题，来改造我们的团队，文化建设是一个很难解决的问题，更不用说放在一个组织结构较为复杂的大公司里的小团队。我想把办公室改造成咖啡厅，车库等产品氛围很强的环境，但我们毕竟是乙方，我们毕竟是工厂，盈利是第一目的。工位是按人头算钱的，办公间能放多少位置，会直接影响公司的生产力。这岂不是和传统手工制造行业一样，固定着装，固定时间，人越多，企业规模越大。这个背景下文化建设有多难，你们可想而知。
在思想上能做的事情还很多，我会经常和大家分享敏捷的价值观和原则，精益的思想以及成功的产品团队，怎么做到快速且品质高的团队。小到我们希望做个小灯泡来监视我们CI运行进展，绿色亮起说明我们开始部署，红色是因为某个测试结果失败而终止部署，对了，最好绿色能闪烁起来。
总之，要让大家真正的发至内心对于敏捷模式的接受，真正的拥抱变化。
哪怕是到了最后交付日子，也欣然的接受变更，来适应产品在市场上最大价值。
2.任务是否存在串行？
如果任务不可以并行，又何谈敏捷，您的测试人员和开发人员还在串行的做任务么，你有没有考虑把他们的任务并行起来安排，例如，接受了一个需求，是否考虑让他们一起开始理解业务，开发的给测试讲讲自己打算的开放方式，实现的功能，测试人员总结一下自己的测试观点，重点考察的地方。然后分别开始启动，开发人员在接受着测试驱动开发，测试人员在不断的完善测试用例。整个过程就好比，我们是造汽车的公司，我是用最短时间完成一个简单的车子，然后不断的完善车的各个方面，还是我们耗费2年时间，先把车的设计做好。当然用造车来比喻，确实显得不太好，您就当成敏捷开发项目来理解吧。
3.人是否是超人？
敏捷开发本身依赖于人，任何项目管理本身都要以人为本。哪个管理者不向往下面的人都是能力强，沟通顺畅，技术水平高，一帮超人在一起还愁做不出Instagram么，但对于凡人团队哪有这么好的资源，如果没有超人，我们该怎么办？
之后取得Scrum Master认证的时候，开始了解敏捷的方式，叫Cross Functional （跨职能）的团队，知道这种方式是人组合起来，测试开发为一体，组成一个“超人”， 让他们一起工作，工作的同时，开发和测试学习验收方式和标准，测试和开发学习功能实现，或者更好的是不是可以测试和开发学习自动化测试的实现呢？关于这点我也还在实践中，目前还没有得出是否真的有收益。
主要还是为了分享
整体来说，还是为了分享做敏捷的一点心得，更希望因此结实到一群朋友或大神，也可以给刚刚接触敏捷模式的人一点启发。如果文章里有说的不对的地方，您可以尽情指摘，我会及时更新和改正。（转载请加出处）
网友评论