读《敏捷整洁之道:回归本源》后感

x33g5p2x  于2022-06-16 转载在 其他  
字(3.6k)|赞(0)|评价(0)|浏览(380)

前言

敏捷过程,相信对大家来说并不陌生,在工作中或多或少都会用到敏捷的一些方法,很多概念也都熟悉。但笔者在读完大牛Robert C. Martin(鲍勃大叔)的这本《敏捷整洁之道:回归本源》后,感慨良多。感觉不仅不少概念清晰了,有些想法还得到了纠正,正应了书名,这是一本敏捷“回归本源”的书。

一、敏捷概貌

软件项目的基本原理,被称为管理的“铁十字”:质量、速度、成本、完成。而敏捷是一个框架,它可以帮助开发人员和管理人员进行务实的项目管理。但是,这种管理不是自动的。

软件开发不是一个能够可靠估计的过程,我们程序员在事先是不能准确给出需要多长时间的,是因为在参与和完成任务之前,根本没有办法知道任务的复杂程度。敏捷方法始于分析,并一直贯穿于项目的生命周期,它将整个项目的时间切分为若干个固定长度的时间周期(这些周期被称作迭代或sprint)。

敏捷正是通过不断的迭代来提供必要的数据,使得估算的误差范围不断地缩小,预测不断地清晰,人们不必再通过“幻想”来确定是否能在项目结束日期之前完成交付了。

我们知道,管理者是可以通过变更时间表、人员、质量和范围来调整铁十字,但实际很多时候调整是有局限性的。比如,如果在项目开始后,要想改变时间表,这往往是不可能(大家都懂),除非是提前交付。对于增加人手,根据布鲁克斯定律:为延迟的项目增加人手反而会使它更加延迟,这是因为培训新人的成本很高。

关于质量,大家自然是想质量越高越好,但如果遇到项目时间紧张时就放弃编写测试、停止代码审查,只追求拼命编码的作法,无疑是徒劳的。“产生垃圾代码不会使你走得更快,没有快而脏(quick and dirty)这样的事情”,快速前进的唯一方法就是做扎实。
最后一件可以改变的事情,也许是计划中的某些实际上并不需要在开始定下“deadline”前完成的那些功能,当然这需要比较大的运气,而且还需要利益相关者的同意才可能。

这些就是敏捷的概述,其中省略了不少细节。而正如鲍勃大叔所说,敏捷是一个框架,有许多不同名称的实际过程,包括极限编程(XP)、Scrum、动态系统开发方法(DSDM)、适应性软件开发(ASD)、水晶方法(Crystal)、特性驱动开发(FDD)等,都是达成同一目标的不同手段。其中极限编程是鲍勃大叔认为定义最好、最完整、最不混乱的一个。

二、大师眼中的敏捷

敏捷是一个支持专业软件开发的纪律框架。信奉纪律的人接受和遵守管理者、利益相关者和客户的合理期望,同时也遵守敏捷赋予开发人员和客户的权力。
敏捷不是一个流程,也不是一种时尚,它不仅仅是一组规则,还是构成软件开发职业道德基础的权力、期望和纪律的组合体。
敏捷需要和实践相结合,以极限编程为例,对应图中的“生命之环”,敏捷分为几种实践。

  1. 业务实践——对于业务,软件开发需要遵循的实践有:计划游戏、小步发布、验收测试和完整团队。通过遵循这些实践,业务和开发有一个简单而明确的沟通方式,而这种交流会产生信任。
  2. 团队实践——隐喻、可持续节奏、代码集体所有和持续集成,这些实践支配着团队成员之间的关系,以及团队成员与他们创建的产品之间的关系。敏捷是一组原则、实践和纪律,有助于团队建立交流语言,使团队成员对彼此、对正在构建的项目期望一致,从而帮助小型团队成功构建小型软件项目。
  3. 技术实践——没有测试驱动开发、重构、简单设计及结对编程(结对是可选的,也可是间歇的)的敏捷是虚有其表,起不到作用。敏捷的技术实践是任何敏捷工作中最本质的组成部分。

敏捷有其特有的价值观:勇气、沟通、反馈和简单。从非敏捷到敏捷的转型是一场价值观的转变。敏捷开发的价值观包括敢于冒险、快速反馈、热情、人与人之间跨越障碍和指挥结构的频密沟通。这些价值观可能会与一些大型组织的价值观截然相反,比如敏捷专注于直奔目标前进,而不是划地盘、争权夺利,有不少大型组织重金投入的中层管理结构更重视安全性、一致性、命令与控制以及遵循计划。所以转型意味着转变价值观,这是非常困难的,但要“创建”出允许敏捷团队蓬勃发展的大型组织,鲍勃大叔认为是可以的,而且有许多初创公司采用了敏捷,也有不少的大型、非敏捷的公司在雇佣许多敏捷的咨询公司。以后,会有越来越多的大型公司在内部创建新部门,以便采用敏捷方式进行软件开发;大型组织在无法转变现有开发团队的情况下,会越来越多地雇佣采用敏捷方法的咨询公司。

关于大型组织中的敏捷应该怎么办?多年来,有不少人试图回答这个问题,但鲍勃大叔有自己的看法。敏捷是为中小型团队服务的,从来不是为大型团队设计的。大型团队的问题是所有社会、所有文明共同的问题,而且从现在的文明来看,这个问题我们似乎解决的不错,比如建造金字塔、打赢第二次世界大战、把人送上月球并安全带回地球等等。
小型软件团队的问题才是20世纪80年代末敏捷运动开始时尚未解决的问题,如何有效地组织一个相对较小的程序员团队来提高效率,敏捷解决的正是这个问题。而解决的的重点在于,要明白这是一个软件的问题,而不是小团队的问题。敏捷是我们组织小型软件团队的一套纪律。在解决好了小型软件团队的问题后,对于如何组织大型团队的问题,就迎刃而解了:将其拆分成小团队。

此外,鲍勃大叔还谈到了敏捷教练辅导,教练的角色完全是团队内部的,是团队的成员,其职责是捍卫团队中的流程。在看到例如停止重构、忽略持续构建中的失败等现象时,向全团队指出来。另外教练也可能诞生出新的职业,从过程专家成为敏捷专家。如果把敏捷理解为一种算法,它可以找到市场上价值最高的产品特性,然后将它们更快地转化为收入。专门为敏捷专业人士服务的认证教练学校已经成立,敏捷教练的未来是光明的。

三、敏捷与匠艺

为了提高软件开发的水准,并重新明确敏捷最初的目标,一群开发人员在2008年11月聚集到芝加哥,发起了一个新的运动:软件匠艺(Software Craftsmanship),并在《敏捷宣言》的基础上提出了一个新的宣言:

  • 不仅要让软件工作起来,更要精雕细琢;
  • 不仅要响应变化,更要稳步增加价值;
  • 不仅要有个体与交互,更要形成专业人员额社区;
  • 不仅要与客户合作,更要建立卓有成效的伙伴关系。

软件匠艺宣言描述了一种思想体系、一种观念。它强调从几个角度来提升职业水准:精雕细琢、稳步增加价值、形成专业人员的社区、建立卓有成效的伙伴关系。不再把工作看做上班打卡,而是提供专业服务,掌控自己的职业生涯,投入自己的时间和金钱来改善自己的工作。这些不仅是专业价值观,也是个人价值观。

思想体系是思想和理想的系统。方法论是方法和实践的系统。敏捷的主要目标是提供业务敏捷性和客户满意度,这是通过紧密协作、迭代开发、短反馈循环和卓越技术来实现的。软件匠艺不包含固定的一组实践。相反,它提倡不断去探索更好的实践和工资方式。如果将特定的实践与软件匠艺相绑定,就会使它变得脆弱和过时,因为总会有更好的实践会被发掘出来。但并不意味着匠艺不倡导任何实践,相反它倡导小步提交改动、小步发布和持续交付;倡导模块化软件设计,以及一切能去除手动重复劳动的自动化措施。匠艺不仅仅包括技术实践、工程实践和自我完善,它还包括职业精神,赋能客户以实现其业务目标。

匠艺对个人的影响——它提倡将软件开发作为一种职业而不是工作。工作是我们要做的事情,但并不是我们自己的一部分,而职业则是我们的一部分。这意味着我们能够找到一种平衡所有承诺和兴趣的方法,使得我们能够过上完整、平衡而幸福的一生。

匠艺对行业的影响——通过匠艺社区,开发人员学习测试驱动开发(TDD)、持续集成、结对编程、简单设计、SOLID原则、整洁代码、重构、微服务系统架构、自动化部署流水线,以及如何将系统迁移到云等等。匠艺社区极为包容,不论他们当前专业水平高低,它都欢迎,且致力于培养下一代专业人士,使加入我们行业的人们可以学习必要的实践,以构建精雕细琢的软件。

匠艺对公司的影响——公司需要可靠的系统(能够快速响应业务需求的系统),公司还需要积极进取、能力合格的技术团队,这样的团队才能做好创建和维护系统的工作。这些正是软件匠艺擅长的领域。

有些开发人员觉得匠艺和敏捷是互相排斥的。参与匠艺运动的人士可能会批评敏捷过分关注过程,缺乏对工程的关注,而敏捷运动的参与者则批评匠艺的关注点太窄,或者缺乏对实际业务和人员问题的关注。大多数的分歧是由于立场不同,而非根本意见分歧。本质上,两个运动的目标非常相似,两种都希望客户满意、渴望紧密合作、希望交付高质量有价值的工作,并且都要求专业性。为了获得业务敏捷性,公司不仅需要协作和迭代过程,还需要良好的工程技能。敏捷和匠艺的结合是实现这一目标的完美方法。

小结

读完鲍勃大师的这本书后,令笔者印象比较深刻的是,敏捷从来都是针对管理小团队完成小项目的方法,大团队的问题应该通过拆解为小团队的任务后不断进行迭代。另外还了解到匠艺运动,让笔者对鲍勃大师去年出版的《匠艺整洁之道:程序员的职业修养》产生了浓厚兴趣,有机会再拜读。

Jackson

相关文章

微信公众号

最新文章

更多