第二章 变革要以人为本
2.1敏捷需要全员参与
1、不同角色参与者对敏捷的误解
很多企业刚开始导入敏捷的时候，大部分人都以为敏捷转型与自己无关； 而感觉跟自己可能有点关系的人则认为，变革就像一阵风，过去后一切照旧。
1）高管
敏捷是一种项目管理方法，让下面的职能经理以及项目经理们搞敏捷就可以了。
2）职能经理
我们经理层都懂敏捷，但我们不干具体的活，团队自己搞就可以了。
3）开发工程师
领导怎么搞，跟我们没关系，我干我的活。领导让我干的时候，咱再动。
4）产品经理、用户体验设计师（User Experience,简称UX）
敏捷是研发团队的游戏，我们该咋干还咋干。
5）测试工程师
敏捷只在开发团队里转，咱们该怎么测试就怎么测。
2、不同角色参与者都需要做出改变
如果大家都以为不关他们的事，那么敏捷转型到底关谁的事呢？其实，敏捷转型是一场涉及所有人的变革，所有角色都需要做出改变。
1）高管
高管不但是需要深入理解敏捷的人，更是组织转型的领导者和最终负责人。如果你不懂，或者懂了又不关心，那么敏捷转型就无法继续，因为每个员工都在看你的眼色行事。
2）职能经理
职能经理以为自己懂敏捷，但实际上在很多企业里成为转型障碍的往往就是职能经理。为什么会这样？因为很多职能经理其实不懂敏捷或者只对敏捷有肤浅的理解，但是他们却自以为很懂。此外，即使他们懂了也很难自我转变，因为改变自己比改变别人要难得多。如果你不服，那么说说看，如果作为职能经理的你真的懂了，为什么还吆五喝六的指挥团队怎么工作，还向团队要周报、日报，还用那些旧的度量体系衡量团队的工作进展？
3）开发工程师
你是产品每一行代码的真正交付者。你的交付方式、沟通和协作方式将会彻底改变。你闷着头，憋了好几天提交了一次代码，自己没测就直接仍给测试工程师，测试工程师提交了bug之后你也不着急解决。这种方式将一去不复返。
4）产品经理
产品经理的需求提供方式必须改变，不能再把几十页的需求文档扔给研发团队，然后就再也见不到人。你需要与团队一起梳理产品需求，并对它们进行拆分和优先级排序，更重要的是，你需要每天都能让研发团队找到你。
5）UX设计师
你花了一个月的时间做了那么完美的设计，但这样的效率跟不上团队的开发速度。所以你必须快起来，你的设计节奏要跟随团队的迭代而快速迭代。
6）测试工程师
如果你还在过着每日闷头用手测试、提交bug单的生活，那么你已经彻底被淘汰了。
7）测试经理
你不要因为自己有个庞大的测试部门而骄傲，你的部门越大，你越应该检讨为什么你的部门需要这么多的测试工程师。如果你所在的企业里，测试工程师人员与开发人员所占比例越高，说明你们企业的产品测试自动化成熟度越低。测试活动一定要逐步在团队里完成，而不是单靠测试部门来把质量关。敏捷发展到最终境界，就是测试部门逐渐消亡。
3、敏捷对不同角色参与者的价值
每一个参与转型的人要的不是变革本身，而是变革给他们带来的价值。
1）高管
如果你和你的管理团队领导转型比较成功，你的企业就会获得前面所述的敏捷转型的收益，从而实现你的变革愿景。
2）职能经理
如果你领导的部门转型比较成功，你的部门就会得到相应的收益。此外，如果你学会运用敏捷领导力，就能够逐渐感觉到团队的改变，他们再也不是以你为中心，一切等着你来监督才会使项目顺利推进。相反，团队会通过自我管理、主动协作来解决问题，并且他们会在自己的职责范围内敢于决定和承担结果。总之，你会发现由团队逐渐产生的由内而外的驱动力在激励他们工作。
3）开发工程师
你会发现自己的工程技能得到了极大的提高，即从前可能只是做模块的后端代码，现在可以不止做架构设计、编程，还能有机会在前端和后端都得到锻炼，还可以做自动化测试。你还会发现你的工作效率得到了极大的提升，即从前全手工做编译、集成、测试、部署，现在可以用学习到的各种自动化工具完成这些工作。这为一名开发工程师的职业发展打下了坚实的基础。
4）产品经理
你可以看到自己提的需求在每个迭代中落地，而不需要等到最后一刻。你可以在每个迭代结束后变更需求或提出新的需求，团队便可以马上将其落实到产品中，从而让你的产品与市场或用户当下的需要更加匹配。你还会发现，团队跟你的协作更加紧密，团队更懂需求、更懂你，也更懂用户。
5）UX设计师
如果采用敏捷用户体验的设计方法，你会减少大量虽然精致、美丽却没有在团队中落地而浪费的设计稿。你会为能够频繁获取到用户对你的设计的反馈而兴奋。
6）测试工程师
你的测试工作会大大提前，你不再只是在项目后半段验证，而是全程参与需求的讨论，这增加了测试工程师对产品的话语权，以及对自身工作的自豪感。同时，你的工作效率会得到极大提升，因为你的工作以手工为主转变为全部以自动化为主。因此，你不会再继续做大量重复、枯燥的手工操作性测试，而是将精力放在测试的设计、需求的反馈，以及自动化测试的开发上。这有助于测试工程师的职业发展。
了解更多内容，请微信关注：
