《技术力量-一线技术团队成功启示录》读后感

最近抽空拜读了技术力量这本书，由于时间关系，目前只看完了前两篇，即“团队管理/组织发展”以及“测试管理/质量平台”，对比自己的工作经历和平时的思考，有些想法在此记录。

在“团队管理/组织发展”章节中，共有来自十个不同类型公司的技术管理者分享他们的经验，大至几千人的团队负责人，小的也带领十来个人的开发团队，公司类型覆盖互联网以及金融行业。

第一篇文章中分享了微软的基础团队对整个研发团队的效率以及质量提升。其实，作为一个有技术追求的公司，如果不仅仅满足于做业务系统满足业务需求，或者说当公司技术发展到一定阶段，我认为基础服务团队是有必要组建的。一个实力强劲的基础团队，可以规范不同团队间混乱的架构、制定规范、提供基础服务，减少大家重复建设重复踩坑的成本，同时提供高效稳定的基础组件，提升代码质量。然而，目前我们公司是相对欠缺这一块的，我们还是一个比较分散的小团队组织架构，每个项目在比较大程度上都是自由发挥，定义自己的规范和基础服务包等。也许，随着公司技术团队的扩大，我们的架构组也会慢慢成长，从“业务架构”“技术架构”慢慢转型成开发型的基础服务团队。拭目以待。

整篇读下来，可以看到，这些公司都在做团队的敏捷的转型，期望用敏捷的开发方式，提高技术团队的研发效率、提升交付质量。最近几年敏捷开发迅猛发展，人人都在谈敏捷，而目前来看，其实大多数都只是学了敏捷的一个皮，很难真的贯彻精神。

上一家公司是一家创业公司，技术团队总共二十多人，产品、开发、测试坐一堆，业务就坐隔壁办公室。虽然在开发中途，敏捷开始发展的时候，我们才开始学习敏捷的工具和仪式，比如燃尽图、“用户故事”等，但是，在学习“敏捷”前，我认为我们实际上已经在使用敏捷的思维在工作了：快速响应、快速迭代、早会、回顾会等，为了提高上线速度和质量，还基于docker自主开发了持续集成一键上线的系统。我们不知道scrum是什么，但是随时保持和业务的沟通，以功能点代替了用户故事，也能够快速响应，甚至业务上午提的需求，晚上就能够上线。

然而，在当前的公司情况下，我觉得，敏捷是比较困难的：

1.由于行业性质，公司对文档、流程、规范等把控非常严格，一个业务想法，形成需求、完成讨论、输出设计等文档、制定开发计划、完成开发、SIT、UAT测试再走上线流程…我们不可能像业务期望中的敏捷那样快速响应。
2.此外，由于公司组织架构较大较复杂，人员也比较多，业务、需求分析（类似产品的角色）、开发、项目经理、测试同事、运维，都在不同的办公点办公，那么，遇到问题，怎么才能快速有效的沟通呢？一个项目对接的业务也不是固定的人，如果按照敏捷要求，是需要有这么一个角色每天早上站会跟进和讨论，甚至随时调整需求，但是，在规范的流程限制下以及现实的办公条件下，怎么做到呢？
3.还是由于行业性质问题，公司的网络环境比较复杂，很难做到持续集成，快速上线。在书中第二篇也提到了测试的持续集成，有利于提高测试效率和输出质量，但是目前我们的测试大多数仍然强依赖人力，复杂的网络环境也有一定影响。当然，我们的测试团队同事也在努力推动持续集成，期望自动化测试能够减少人力成本、提高质量。

总的来说，敏捷不仅仅是开发的事，而是需要业务、产品乃至整个公司的文化都要有敏捷的思维和行动模式，目前来看很难在短时间内很好的达成。我们目前能做的，就是吸取一些敏捷中容易落地的工具和仪式，比如故事点、站会、任务拆解、回顾会议等，再融合自身公司的开发流程和规范，期望走出符合自身公司特性的开发模式，能让业务、开发、测试都舒服，让领导也能更好的把控所有项目的进度和风险等。

本文采用署名-非商业性使用-相同方式共享 4.0 国际许可协议，转载请注明出处。