敏捷宣言20岁了,你还好吗?
发布于 2021-09-26 07:42
谈及当年耗巨资构建的某系统时，不禁唏嘘，既感慨光阴荏苒，也嗟叹彼时的软件开发思路和如今蔚然成风的小步快跑式交付方法之间的差异。
回想起来，当年的Team Leader也并非没有了解过敏捷开发，还非常清楚的记得他当年讲过这样一句话“来，现在都讲敏捷开发了，让我们来开个站会吧”。于是，十多个人围成一个圈，每个人开始汇报工作内容。
当时该项目通过共享Excel版本的WBS文件让每个人去更新自己的工作项状态及耗时情况，使用内部纯手工打造的后台Java框架及前端JS框架来完成业务流程和操作前端DOM元素。开发团队和测试团队坐在一层楼的两个相隔很远的区域，平时通过Lotus Notes邮件、Sametime以及电话来沟通。
开发完成后，系统部署会由一个专门的配置管理人员来进行，开发人员只需将写好的代码和增量SQL语句，千辛万苦避免冲突后提交到ClearCase，该角色将完成接下来的部署工作。
系统部署完后，测试小组开始测试。该小组是共享资源，前期不会加入项目组参与需求讨论、方案设计以及开发过程，等到开发结束后，基于BA所给出的需求文档进行测试案例编写及功能验证。
测试小组发现Bug后，通过HP的QC系统进行提交，所有问题都会去到一个统一的开发leader处分发给相应的开发人员。开发人员接收后基于之前的代码库开始修复问题，如果碰到棘手的问题，资深开发帮新手开发定位、解决若问题时，两者都会被TL训斥说降低了团队产出。
俱往矣！当年，敏捷宣言10岁。
敏捷和DevOps
今年，敏捷宣言20岁了。这个宣言自从发布后就没有更新过，而软件行业的痛苦，还和10年前类似，甚至有过之而无不及，996、007、ICU等专有名词成为软件行业的标配。
CMMI被抛弃后，言必称“敏捷”的越来越多，市面上的敏捷考证也雨后春笋般冒出来。这10年，也是DevOps蓬勃发展的10年，峰会/培训/认证几套组合拳打下来，在软件行业里走动，没有听说过DevOps都不好意思跟人打招呼。
在有些“敏捷”的组织内，全靠外包团队996来进行响应变化，在有些“DevOps成熟度很高”的组织内，交付一个新的功能特性，还需要走一通冗长的变更流程来获得预算、执行变更。
怎么破？
其实上面提到的问题，可以归结为“技术”和“组织”两个维度。要实现敏捷、DevOps，既需要有卓越的技术能力 - 从技术上实现持续集成、持续交付，构建“质量内建”的交付体系；同时，也得有配套的组织设计。
套用“一切能用钱解决的问题都不是问题”的欠揍说法，“一切能用Google解决的技术问题都不是问题”，而只有组织的设计，才是一个既有技术难度，又有艺术难度的问题。没有一个组织的案例可以拿来当做满分作业直接抄，基本上一千个组织会有一千个实际案例。
为快速响应业务需求，持续交付业务价值，真正让敏捷和DevOps落地，对现有组织进行重构已成为数字化转型中企业不得不进行的工作。组织的重构需要考虑业务和IT的关系，需要考虑内部IT和外包IT的关系，需要从传统预算向敏捷预算转型，需要从“角色-职责”导向的组织设计转向成果导向的组织设计。甚至，还需要考虑沟通机制和办公室布局的设计。
也许这些问题可以在极限编程合作社共同翻译的《敏捷组织设计》中找到启发吧？:) 敬请期待……
更多敏捷组织设计理论与实践
请期待极限编程合作社共创
《敏捷组织设计》中译本
本文来自网络或网友投稿，如有侵犯您的权益，请发邮件至：aisoutu@outlook.com 我们将第一时间删除。
相关素材