懒癌不治,敏捷与DevOps方法论也治不了你的交付顽疾
“我们可以因地制宜对一些书本上的具体方法和实践进行合理的裁剪,但裁剪的原因一定不能是因为懒得做。”
前两天和敏捷圈的朋友吃饭,聊到很多敏捷、DevOps实践很难落地和坚持。像TDD这样的实践,理念上所有人都认同,但实际上在坚持实践的团队却凤毛麟角。
前段时间应邀参加我参与过的项目的敏捷Workshop,我们对项目执行过程进行了回顾,包括哪些方面做得好,哪些方面需要改善。在改善点上,我发现很多在Workshop上提出的问题其实曾经都有过解决方案,但是由于没有坚持下来,问题又重新浮现。
其实,对于软件交付的大部分问题,敏捷与DevOps方法论里都有解决方案,但重要的是落实和坚持。
01
—
实践落不了地,是因为懒惰
最典型的例子就是测试驱动开发(TDD)。我们可以听到100个借口说TDD在团队无法落地。但其实最核心的原因是因为懒。
很多开发人员,在实践TDD以前就不重视单元测试。写出来的程序基本上是“裸奔”,质量主要指望后续QA的集成测试和用户的验收测试来弥补。
所以程序质量不好,其中一个重要的原因是单元测试不充分。这种习惯一旦形成,就算学习了TDD,也会懒于写测试用例。这不是TDD的问题,而是很多人对内部质量和单元测试的轻视和对自己该做的事情的无视,就是懒惰。
验收测试驱动开发或实例化需求难以落地,是因为用户以前在验收测试前就没有认真思考该如何验收,现在要求他们在提需求时就要想好具体的验收条件和测试用例,他们便觉得要做的事情比以前多了,产生抵触。
结对编程无法落地,核心问题是团队在学习结对编程之前就不重视代码评审,甚至是完全不做代码评审。在这种情况引入结对编程,必然会被视为原来一个人干的活变成两个人干了,“成本大大增加”了。
很多团队用Jenkins搭了持续集成,但会把静态代码分析和自动化测试关掉,因为修复缺陷太费劲,交付压力又大,无暇兼顾。
放弃做应该做的事情,是交付效率和质量无法提升的主要原因,也是敏捷与DevOps转型效果不好的重要原因。这个现象,其实在原来的瀑布模式已经存在,现在只是被带到了新的时代。
02
—
有了方法,更重要的是勤奋
有人说,管理是一个费劲的过程,团队行为是一种不稳定态,即使有了具体的方法和流程,还得靠人来进行持续监督和维护,需要管理人员的勤奋。这也是为什么一家公司需要那么多管理人员。管理能力,在任何交付模式下都是重要的。
针对各种交付问题,敏捷与DevOps方法论都提供了方法,要落实和坚持这些方法,需要勤奋。
但人总是懒惰的,那么有什么有效方法固化勤奋呢?
首先是自律。像TDD这样的方法,无法强迫,只能靠自律,程序员要有工匠精神,对自己的交付有很强的责任感。在这一点上,我观察国外程序员普遍要比国内程序员纪律性要高。
其次,例会也是很重要的手段。
什么叫例会?——固定时间、固定议程和固定人员的会议。固定周期的例会可以让团队“被动”地围绕固定的议程进行持续关注。例会邀请必须发给每一个参与者,“强行”占用每个与会者的时间。
每日例会帮助我们持续关注交付进度、障碍和持续集成的情况,防微杜渐。团队在这个会议上要对不做正确的事采取零容忍,发现任何不符合约定的偷懒行为必须及时指出和修正。
每日例会的另一个“副作用”是,过去我作为开发人员的体验是,我知道老板每天都会关注我的进度,我无法偷懒,每天总得交功课,而且要正确地交功课。
固定周期的回顾会议帮助我们持续寻找适合我们的具体方法,一旦约定下来,坚持落实。
过去我们对一些重要但不紧急的事情总是缺乏关注,拖延处理,包括遗留的安全问题、故障打补丁后的长期解决方案、故障数据分析等,持续改进总被搁置。我们通过设立专门的例会,并引入外人进行进度监督,大大降低了拖延的情况,使这些重要的改善得到及时的落实。
这些都是持续的事情,懒不得,一旦松懈,前功尽弃。
我们可以因地制宜对一些书本上的具体方法和实践进行合理的裁剪,但裁剪的原因一定不能是因为懒得做。
世上无易事,贵在坚持!
近期必读:
关于作者
刘华(Kenneth)
就职于世界500强银行,负责基金服务业务软件开发与交付
敏捷、精益、DevOps专家
精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈
曾在GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit等论坛发表主题演讲
著有《猎豹行动:硝烟中的敏捷转型之旅》一书
小说体敏捷/DevOps转型教科书
和实战经验分享
购书指南
—
纸质书、电子书在京东、当当、亚马逊等渠道已全面上架,搜索关键字“猎豹 敏捷”即可找到。点击阅读原文可直接购书。
有声书已登录喜马拉雅,适合路上听书的你。
关注公众号看其他原创作品
觉得好看,点个“在看”或转发给朋友们,欢迎你留言。