One minute
The Phoenix Project 读书笔记
首先,这是一本小说,但是讲的却是我们在软件开发中很常见的问题:需求不断变换,产品发布不断延期,质量不过关,有安全漏洞,管理混乱等等。第一人称主人公:Bill是通过优秀的团队将管理混乱并且效率低下的IT部门扭转成高效率的DevOps部门,进而帮助公司在市场上起死回生。
这本书把IT部门的工作划分成四类:
- Business Project:作为一个公司的IT部门,在掌管公司的信息平台之间,不免还要承担起一些对公司商业活动以来的软件进行开发的责任。这类工作就被划分到这个类别里面。
- Internal Project:这是IT部门内部的工作,主要包括:服务器升级,软硬件维护等等
- Change:前面两个都是大项目,这个相对来说就是小的改动,比方说,数据库里加个表,某个表里加个新列等等。
- Unplanned work:前面的三种都可以说是计划工作,因为可以根据预算以及资源来安排一个时间点解决。可是这个类别的就是具有突然性,往往能让之前的安排都成为泡影的。所以它也是被称为最具有毁灭性的工作。日常的IT工作中就应该采取能采取的措施来避免它的发生。
Unplanned work可以发生在任何时间,任何地点,它是不可预知的,但是它可以通过有效的手段来降低其发生的概率,至少不是从内部发生地。比方说本书中的payroll和Phoenix的第二次部署就是unplanned work。原因都是一样的,某人将某个关键地方给改了,但是IT部门的人不知道,结果导致浪费了大量的时间来修复问题以及改动程序。
为了解决这一些列问题,Bill先是将改动给流程化:所有的改动都必须通过统一的process来提交,只有通过IT部门领导的审批,才能实施。然后将IT部门的constraint:Brent给保护好,让他按照他的schedule做事,不被外部的request所打扰,之后通过Phoneix的失败教训,他加强了IT部门与开发部门和安全部门的联动性,最后,又进一步加强了IT部门与Business部门的联动性,这样能确保IT部门一直是在做对Business最有效的工作上。
其实本书很多的东西都是来自敏捷开发的。比方说,加强跟Busines的合作就是为了提供给Business最有价值的软件以及Phoenix的快速开发部署,就暗暗地符合了敏捷开发的格言:
Customer satisfaction by early and continuous delivery of valuable software
Toyota的Kata流程就更不用说了。
我忽然间觉得无论是哪个产业,方法学这些东西其实是一法通,万法通。用在汽车制造业的方法也可以被应用在软件开发这种看不见摸不着的“软”项目上。本质上其实都是教会人类如何地更高效使用工具而已。