苏州峻德信息

The "slow" philosophy in agile development

作者: Lemi Orhan Ergin

时间:2021-11-02

没有控制的快速开发可能是技术研发的劲敌。你应该放慢速度的三个主要领域是人员、流程和产品。在深入讨论细节之前,让我先讲一个故事。

大概是在2011年,我加入了一个团队,负责建立一个在线营销平台。我的主要职责是尽快为系统添加新功能。很快我就发现由于前期的技术债务和设计挑战,我们不可能快速完成。几乎每次尝试加快速度,我们都适得其反地增加了复杂性并破坏了质量。在我看来,唯一的方法就是重新编写整个系统。

我记得,我打电话给产品经理说我们需要重写整个系统。电话沉寂了30秒后,项目经理说:“你说你的团队写的产品质量太差,以至于同一团队不得不再次重写相同的产品,但这次更好。对吧?对不起,伙计,这是不可接受的。你应该写得更好。”

盲目求"快"产生“僵尸软件”

根据Standish Group的Chaos报告,94%的项目都是多次从零开始重新开发的。94%!不忍直视啊!当我查看过去开发的产品时,我发现几乎所有的产品都是用新技术、架构和设计从零开始重写的。重写是如此普遍,以至于企业常常将其视为项目管理和创新的唯一选择。我们写啊,写啊,写啊,写啊,写啊。

什么是技术研发中最大的敌人?在研发世界中,速度是至关重要的。不仅对于在市场上处于领先地位很重要,而且通过添加新功能和快速消除bug来响应客户的需求也能保持客户的高满意度。但我们都有“速度”的问题。我们认为,更快、更聪明、更高效地完成任务与设定目标的截止日期有关。我们认为花更多的时间工作,或者与更多的人一起工作,就可以“更快”。因此,我们要么增加新员工,要么加班加点提高生产效率。

然而,匆忙既不会让我们更快,也不会让我们更多产。匆忙只会增加压力,分散注意力,破坏效率。相反,我们需要创造力、效率和专注。

技术研发是非常困难和复杂的。我们无法摆脱复杂性,只能接受它。对速度的追求创造了一个不稳定、不可持续的环境,使我们压力更大、注意力更不集中、效率更低。

团队能力、总体规划、估算、固定工作时间、截止日期和速度概念都是虚构的;无能是现实。

交付时间直接依赖于人员的技能、流程的效率和产出的质量。大多数情况下,开发人员给自己设置了隐藏的截止日期,而没有任何实际需要。

最终,我们得到了遗留产品。最后期限的压力加上无能导致了遗留产品,即死胡同。我给遗留产品起了个更合适的名字:僵尸软件——因为这类产品实际上已经死了,但似乎还在生产中。它在生产中起作用,人们从中获利,但是它需要开发人员的血液、生命和精力来以某种方式继续工作。开发人员不敢碰它,只要它能工作,没有人想要改变它。

Robert C. Martin在twitter上对僵尸软件的症状有一句完美的描述:“如果你的产品越来越难开发,那你就做错了。”“在匆忙中,我们破坏了质量,以至于我们每向前走一步,整个过程就会变得更慢。”我相信,慢下来,直到我们达到一个可持续的状态是唯一的加快速度的方法。

在软件开发中,匆忙是罪恶的

正如Robert C. Martin在谈到CleanCoders的主要价值时提到的,“系统能够容忍和促进这种持续变化的能力是产品的主要价值”。在软件开发中,匆忙是罪恶的。任何匆忙的尝试都会在生产力、注意力、人的效率、适应能力和对产品的容忍度方面造成破坏。

例如,我们总是有时间来修复bug,但是没有时间来编写测试。我们没有重构和编写测试,因为我们没有足够的时间。但我们有时间调试和修复bug。

我们过于关注过程,以至于经常忘记技术研发中的主要资产:人员。流程帮助人们改进他们构建产品的方式,增加动力,培养健康的环境。流程的效率也很重要,但人员是关键。

我们必须承认,没有人和事是完美的。客户、老板、经理、团队成员、友商,甚至你自己,都远非完美。需求、文档、工具、代码、构建的系统和设计,也永远不会是完美的。因此,我们必须停止不受控制的匆忙和加速。要想以可持续的速度更快发展,唯一的方法就是放慢速度,这主要体现在三个方面:

◉ 任用提高专业水平和工艺的人才

◉ 提高适应和效率的流程

◉ 应用提高自动化和质量的产品

当涉及到人的时候,要放慢速度

流程和工具不会生成产品,生产产品的是人。我们必须承认,“人才招聘”是一个组织最重要的功能。它直接影响到公司的未来和产品本身。

为你的组织雇佣最优秀的人才。我所说的“最好的”并不是指最聪明、最有经验的人,而是寻找至少具备激︎情、纪律和动力三要素的人才。如果一个人具备这三种特质,那么其他技能的增长对他来说将不是问题。

招聘是一个双赢的过程,双方都应该从中受益。所以你应该放慢你的招聘进程,并投资改善它。人们会加入他们相信的公司。所以,请为你想要看到的行为建模,通过你的公司文化、你的愿景和你的员工,让人才相信你。

自我会慢慢地杀死你的组织。永远不要让自负进入你的组织。从可爱的傻瓜到天才蠢货,永远不要让极端的人加入你的团队。永远不要雇佣自负的人。和这些人在一起,你永远无法建立让人钦佩的公司文化。

停止独自工作,开始一起工作。永远不要让筒仓(一个人的深井)发生,因为筒仓或英雄开发者是组织功能失调的症状。让团队紧密地坐在一起,两人一组,多人一组,一起定义团队标准,一起工作,一起切磋。让团队共同承担责任。

一起练习是提高技能最有效的方法。在合作中,我们不仅相互激励也互相学习。让知识在人与人之间流动。

从2010年开始,我每周都在自己的团队中组织Brown Bag / Lunch & Learn课程。我多次听到我的同事说,“每周三参加会议能让我提高自己,这对我很有激励作用。”这反映了公司内部定期会议的影响力。

收集并提供反馈。为了收集集体反馈,你可以像我多年来所做的那样,组织Grand Retrospectives(大型“复盘”会)。顺便说一下,Grand Retrospectives是一种新型的挖掘问题的复盘会议,每次有20多人参加。

教学和分享是掌握一个主题的最佳方式。做一名演讲者并回馈社区。

开发人员似乎讨厌文档,但实际上恰恰相反。人们阅读的任何输出都是一个简单朴素的文档;从生产代码本身到测试代码,从提交消息到提交图表,从日志消息到错误消息,开发人员无意中记录了很多文档。所以,无论你记录什么,因为人们读它是为了理解,所以请尽可能把它做得更好。

你不是孩子。公司不是你的父母。我们必须拥有自己的事业并投资自己。如果投资意味着花费时间和金钱,那就自己动手吧。

如何通过减慢速度来优化流程?

每一天,我们都面临着新的挑战。这些挑战不应仅仅是市场需求或新要求。技术挑战对我们的进步也有很大影响。

计划什么都不是,但计划就是一切。计划常改常新。特别是在创业的早期阶段,团队需要非常敏捷。通过每日Scrum或每日站会,每天一次校准计划是不够的。你们必须紧密合作,每天不止一次地校准计划,保持迭代的长度较短,最短为一周。通过组织定期的评审和演示会议来创建多个反馈循环通道。

定义短期目标和长期目标。短期目标为团队创造了焦点,长期目标可以防止注意力分散。

如果你想了解哪里出了问题,可以从可视化流程开始,包括技术上的和业务上的。想象失败和糟糕的事情来促进你从过去的经验中学习。

永远不要凭直觉做决定。始终收集数据,并根据数据分析做出决策。允许每个开发人员访问产品和代码指标也很重要。这增加了产品开发的集体所有权和常识。

浪费是你生产的任何没有商业价值的东西。检测并消除办公室、代码和流程中的浪费。童子军们把露营地弄得比他们来之前还要干净。同样的理念在技术研发中也适用。遵循童子军规则,让你的代码更简洁。当你打开一个文件来添加新功能并注意到其中的一个问题时,请在无需提示、无需许可的情况下自觉修复它。在修复问题之前,不要忘记编写测试。这能使你对自己写的代码感到自信和舒适。

你可以在技术研发生命周期的每个点上检测浪费。遵守你对已完成任务的定义,消除“90%完成,90+剩余”的任务。不要留着那些长得太长的“树枝”,它们是邪恶的。不要通过手动测试来验证代码,手工测试只会验证快乐路径。所有其他场景只能通过测试代码进行验证,所以要认真对待。

放慢速度如何提高产品质量?

有一点很清楚,没有高质量的代码库,就做不到敏捷。你需要做的第一件事是消除技术债务并解决bug。或许你需要停止构建功能一段时间,专注于消除bug。

“修复bug并在之后部署到服务器”这样的流程包含着风险和危机。我们需要换一种更好、更有效的方式。当你想要修复一个bug时,首先编写测试并以编程方式重现问题,然后修复bug并检查测试是否通过,之后部署到生产环节中去才是安全的。

我所在的团队几乎把所有的时间都花在修复bug和维护代码库上。这会影响效率。为了在修复bug的同时继续开发新特性,你需要将你的团队划分为虚拟团队。例如,我们在每个迭代中选择两个队友来提供直接的技术支持,并继续修复bug。我们叫他们蝙蝠侠和罗宾。无论你正在处理哪种特性,都必须不间断地修复bug。

如今,开发人员通常使用一种方法来减缓进度,以便加快速度——使用拉取请求(pull requests)。他们停止生产线,进行验证和代码审查,以提高代码质量。他们从不将未经审核的代码部署到生产环境中。

我们的最终目标应该是实现持续交付,并经常发布。从git分支机制到部署策略,从反馈机制到自动化测试实践,都需要不同的思路。

你在SDLC中使用的实践表明了你的开发速度。对于git分支机制,“尽早提交、经常提交、稍后完善、发布一次”的理念和基于主干的开发,以及功能切换,可以最大程度地消除浪费。

我已经使用TDD很多年了。许多人向我抱怨TDD对编程速度的影响。Joe Rainsberger在twitter分享了他对TDD的看法:“担心TDD会减慢程序员的速度?他们可能正需要慢下来。”

TDD的重构多于测试,思考多于编码,简单多于优雅。这就是为什么它能带来更好的质量。通过TDD开发,有足够的测试和简单的设计。

你是否曾经达到100%的代码覆盖率?我在一个为期三个月的项目中做到了这一点。我为每一行生产代码编写了单元测试。那时,我觉得自己像一个拥有超能力的英雄。但是当我们部署到UAT的预生产环境时,我发现有四个功能无法工作。我不得不编写集成和功能测试来检测bug并解决它们。然后我意识到单元测试并不能保证良好的设计和工作功能。停止计算代码覆盖率,那玩艺儿毛用没有。

如果你需要30分钟或更短时间来修复bug,别犹豫,直接干!此外,用20%的时间消除技术债务。

通常我们编写代码避免将来要修改它。同样,当我们设计产品时,我们选择适当的技术和工具,以便将来不需要修改它。但我们错了。重构应该出现在开发过程的每个阶段。正如Kent Beck所说,我们必须做一些简单的改变来让改变变得简单。为了实现这一点,我们在一个mono存储库中管理所有的微服务。Mono repository用于简化重构,正是我们所需要的。

把放慢速度当作一种哲学

AndreasMöller在一条推文中提到了他对技术研发的看法:“我不想写那些只能工作的代码:我想写干净、可维护、易于理解和经过充分测试的代码。”

为了实现这一目标,我们需要关注三个领域:人员、流程和产品。

◉ 减少人员,我们的目标是提高专业水平和工艺水准。

◉ 放慢进程,我们的目标是提高适应能力和效率。

◉ 放慢生产速度,我们的目标是提高自动化和质量。

当我们专注于这些领域时,我们开始培养一种能够快速研发的开发文化。

我们不应该忘记以下几点:

◉ 可工作的产品不一定制作精良。

◉ 只有优秀的专业人士才能制作精良的产品。

◉ 只有制作精良的产品才能让你比以往更快地构建功能。

上一篇:搞砸软件外包的十个常见错误 下一篇:好的企业文化通过对员工的塑造实现企业的发展

The "slow" philosophy in agile development

The "slow" philosophy in agile development

没有控制的快速开发可能是技术研发的劲敌。你应该放慢速度的三个主要领域是人员、流程和产品。在深入讨论细节之前,让我先讲一个故事。

大概是在2011年,我加入了一个团队,负责建立一个在线营销平台。我的主要职责是尽快为系统添加新功能。很快我就发现由于前期的技术债务和设计挑战,我们不可能快速完成。几乎每次尝试加快速度,我们都适得其反地增加了复杂性并破坏了质量。在我看来,唯一的方法就是重新编写整个系统。

我记得,我打电话给产品经理说我们需要重写整个系统。电话沉寂了30秒后,项目经理说:“你说你的团队写的产品质量太差,以至于同一团队不得不再次重写相同的产品,但这次更好。对吧?对不起,伙计,这是不可接受的。你应该写得更好。”

盲目求"快"产生“僵尸软件”

根据Standish Group的Chaos报告,94%的项目都是多次从零开始重新开发的。94%!不忍直视啊!当我查看过去开发的产品时,我发现几乎所有的产品都是用新技术、架构和设计从零开始重写的。重写是如此普遍,以至于企业常常将其视为项目管理和创新的唯一选择。我们写啊,写啊,写啊,写啊,写啊。

什么是技术研发中最大的敌人?在研发世界中,速度是至关重要的。不仅对于在市场上处于领先地位很重要,而且通过添加新功能和快速消除bug来响应客户的需求也能保持客户的高满意度。但我们都有“速度”的问题。我们认为,更快、更聪明、更高效地完成任务与设定目标的截止日期有关。我们认为花更多的时间工作,或者与更多的人一起工作,就可以“更快”。因此,我们要么增加新员工,要么加班加点提高生产效率。

然而,匆忙既不会让我们更快,也不会让我们更多产。匆忙只会增加压力,分散注意力,破坏效率。相反,我们需要创造力、效率和专注。

技术研发是非常困难和复杂的。我们无法摆脱复杂性,只能接受它。对速度的追求创造了一个不稳定、不可持续的环境,使我们压力更大、注意力更不集中、效率更低。

团队能力、总体规划、估算、固定工作时间、截止日期和速度概念都是虚构的;无能是现实。

交付时间直接依赖于人员的技能、流程的效率和产出的质量。大多数情况下,开发人员给自己设置了隐藏的截止日期,而没有任何实际需要。

最终,我们得到了遗留产品。最后期限的压力加上无能导致了遗留产品,即死胡同。我给遗留产品起了个更合适的名字:僵尸软件——因为这类产品实际上已经死了,但似乎还在生产中。它在生产中起作用,人们从中获利,但是它需要开发人员的血液、生命和精力来以某种方式继续工作。开发人员不敢碰它,只要它能工作,没有人想要改变它。

Robert C. Martin在twitter上对僵尸软件的症状有一句完美的描述:“如果你的产品越来越难开发,那你就做错了。”“在匆忙中,我们破坏了质量,以至于我们每向前走一步,整个过程就会变得更慢。”我相信,慢下来,直到我们达到一个可持续的状态是唯一的加快速度的方法。

在软件开发中,匆忙是罪恶的

正如Robert C. Martin在谈到CleanCoders的主要价值时提到的,“系统能够容忍和促进这种持续变化的能力是产品的主要价值”。在软件开发中,匆忙是罪恶的。任何匆忙的尝试都会在生产力、注意力、人的效率、适应能力和对产品的容忍度方面造成破坏。

例如,我们总是有时间来修复bug,但是没有时间来编写测试。我们没有重构和编写测试,因为我们没有足够的时间。但我们有时间调试和修复bug。

我们过于关注过程,以至于经常忘记技术研发中的主要资产:人员。流程帮助人们改进他们构建产品的方式,增加动力,培养健康的环境。流程的效率也很重要,但人员是关键。

我们必须承认,没有人和事是完美的。客户、老板、经理、团队成员、友商,甚至你自己,都远非完美。需求、文档、工具、代码、构建的系统和设计,也永远不会是完美的。因此,我们必须停止不受控制的匆忙和加速。要想以可持续的速度更快发展,唯一的方法就是放慢速度,这主要体现在三个方面:

◉ 任用提高专业水平和工艺的人才

◉ 提高适应和效率的流程

◉ 应用提高自动化和质量的产品

当涉及到人的时候,要放慢速度

流程和工具不会生成产品,生产产品的是人。我们必须承认,“人才招聘”是一个组织最重要的功能。它直接影响到公司的未来和产品本身。

为你的组织雇佣最优秀的人才。我所说的“最好的”并不是指最聪明、最有经验的人,而是寻找至少具备激︎情、纪律和动力三要素的人才。如果一个人具备这三种特质,那么其他技能的增长对他来说将不是问题。

招聘是一个双赢的过程,双方都应该从中受益。所以你应该放慢你的招聘进程,并投资改善它。人们会加入他们相信的公司。所以,请为你想要看到的行为建模,通过你的公司文化、你的愿景和你的员工,让人才相信你。

自我会慢慢地杀死你的组织。永远不要让自负进入你的组织。从可爱的傻瓜到天才蠢货,永远不要让极端的人加入你的团队。永远不要雇佣自负的人。和这些人在一起,你永远无法建立让人钦佩的公司文化。

停止独自工作,开始一起工作。永远不要让筒仓(一个人的深井)发生,因为筒仓或英雄开发者是组织功能失调的症状。让团队紧密地坐在一起,两人一组,多人一组,一起定义团队标准,一起工作,一起切磋。让团队共同承担责任。

一起练习是提高技能最有效的方法。在合作中,我们不仅相互激励也互相学习。让知识在人与人之间流动。

从2010年开始,我每周都在自己的团队中组织Brown Bag / Lunch & Learn课程。我多次听到我的同事说,“每周三参加会议能让我提高自己,这对我很有激励作用。”这反映了公司内部定期会议的影响力。

收集并提供反馈。为了收集集体反馈,你可以像我多年来所做的那样,组织Grand Retrospectives(大型“复盘”会)。顺便说一下,Grand Retrospectives是一种新型的挖掘问题的复盘会议,每次有20多人参加。

教学和分享是掌握一个主题的最佳方式。做一名演讲者并回馈社区。

开发人员似乎讨厌文档,但实际上恰恰相反。人们阅读的任何输出都是一个简单朴素的文档;从生产代码本身到测试代码,从提交消息到提交图表,从日志消息到错误消息,开发人员无意中记录了很多文档。所以,无论你记录什么,因为人们读它是为了理解,所以请尽可能把它做得更好。

你不是孩子。公司不是你的父母。我们必须拥有自己的事业并投资自己。如果投资意味着花费时间和金钱,那就自己动手吧。

如何通过减慢速度来优化流程?

每一天,我们都面临着新的挑战。这些挑战不应仅仅是市场需求或新要求。技术挑战对我们的进步也有很大影响。

计划什么都不是,但计划就是一切。计划常改常新。特别是在创业的早期阶段,团队需要非常敏捷。通过每日Scrum或每日站会,每天一次校准计划是不够的。你们必须紧密合作,每天不止一次地校准计划,保持迭代的长度较短,最短为一周。通过组织定期的评审和演示会议来创建多个反馈循环通道。

定义短期目标和长期目标。短期目标为团队创造了焦点,长期目标可以防止注意力分散。

如果你想了解哪里出了问题,可以从可视化流程开始,包括技术上的和业务上的。想象失败和糟糕的事情来促进你从过去的经验中学习。

永远不要凭直觉做决定。始终收集数据,并根据数据分析做出决策。允许每个开发人员访问产品和代码指标也很重要。这增加了产品开发的集体所有权和常识。

浪费是你生产的任何没有商业价值的东西。检测并消除办公室、代码和流程中的浪费。童子军们把露营地弄得比他们来之前还要干净。同样的理念在技术研发中也适用。遵循童子军规则,让你的代码更简洁。当你打开一个文件来添加新功能并注意到其中的一个问题时,请在无需提示、无需许可的情况下自觉修复它。在修复问题之前,不要忘记编写测试。这能使你对自己写的代码感到自信和舒适。

你可以在技术研发生命周期的每个点上检测浪费。遵守你对已完成任务的定义,消除“90%完成,90+剩余”的任务。不要留着那些长得太长的“树枝”,它们是邪恶的。不要通过手动测试来验证代码,手工测试只会验证快乐路径。所有其他场景只能通过测试代码进行验证,所以要认真对待。

放慢速度如何提高产品质量?

有一点很清楚,没有高质量的代码库,就做不到敏捷。你需要做的第一件事是消除技术债务并解决bug。或许你需要停止构建功能一段时间,专注于消除bug。

“修复bug并在之后部署到服务器”这样的流程包含着风险和危机。我们需要换一种更好、更有效的方式。当你想要修复一个bug时,首先编写测试并以编程方式重现问题,然后修复bug并检查测试是否通过,之后部署到生产环节中去才是安全的。

我所在的团队几乎把所有的时间都花在修复bug和维护代码库上。这会影响效率。为了在修复bug的同时继续开发新特性,你需要将你的团队划分为虚拟团队。例如,我们在每个迭代中选择两个队友来提供直接的技术支持,并继续修复bug。我们叫他们蝙蝠侠和罗宾。无论你正在处理哪种特性,都必须不间断地修复bug。

如今,开发人员通常使用一种方法来减缓进度,以便加快速度——使用拉取请求(pull requests)。他们停止生产线,进行验证和代码审查,以提高代码质量。他们从不将未经审核的代码部署到生产环境中。

我们的最终目标应该是实现持续交付,并经常发布。从git分支机制到部署策略,从反馈机制到自动化测试实践,都需要不同的思路。

你在SDLC中使用的实践表明了你的开发速度。对于git分支机制,“尽早提交、经常提交、稍后完善、发布一次”的理念和基于主干的开发,以及功能切换,可以最大程度地消除浪费。

我已经使用TDD很多年了。许多人向我抱怨TDD对编程速度的影响。Joe Rainsberger在twitter分享了他对TDD的看法:“担心TDD会减慢程序员的速度?他们可能正需要慢下来。”

TDD的重构多于测试,思考多于编码,简单多于优雅。这就是为什么它能带来更好的质量。通过TDD开发,有足够的测试和简单的设计。

你是否曾经达到100%的代码覆盖率?我在一个为期三个月的项目中做到了这一点。我为每一行生产代码编写了单元测试。那时,我觉得自己像一个拥有超能力的英雄。但是当我们部署到UAT的预生产环境时,我发现有四个功能无法工作。我不得不编写集成和功能测试来检测bug并解决它们。然后我意识到单元测试并不能保证良好的设计和工作功能。停止计算代码覆盖率,那玩艺儿毛用没有。

如果你需要30分钟或更短时间来修复bug,别犹豫,直接干!此外,用20%的时间消除技术债务。

通常我们编写代码避免将来要修改它。同样,当我们设计产品时,我们选择适当的技术和工具,以便将来不需要修改它。但我们错了。重构应该出现在开发过程的每个阶段。正如Kent Beck所说,我们必须做一些简单的改变来让改变变得简单。为了实现这一点,我们在一个mono存储库中管理所有的微服务。Mono repository用于简化重构,正是我们所需要的。

把放慢速度当作一种哲学

AndreasMöller在一条推文中提到了他对技术研发的看法:“我不想写那些只能工作的代码:我想写干净、可维护、易于理解和经过充分测试的代码。”

为了实现这一目标,我们需要关注三个领域:人员、流程和产品。

◉ 减少人员,我们的目标是提高专业水平和工艺水准。

◉ 放慢进程,我们的目标是提高适应能力和效率。

◉ 放慢生产速度,我们的目标是提高自动化和质量。

当我们专注于这些领域时,我们开始培养一种能够快速研发的开发文化。

我们不应该忘记以下几点:

◉ 可工作的产品不一定制作精良。

◉ 只有优秀的专业人士才能制作精良的产品。

◉ 只有制作精良的产品才能让你比以往更快地构建功能。

The "slow" philosophy in agile development

作者: Lemi Orhan Ergin

时间:2021-11-02

没有控制的快速开发可能是技术研发的劲敌。你应该放慢速度的三个主要领域是人员、流程和产品。在深入讨论细节之前,让我先讲一个故事。

大概是在2011年,我加入了一个团队,负责建立一个在线营销平台。我的主要职责是尽快为系统添加新功能。很快我就发现由于前期的技术债务和设计挑战,我们不可能快速完成。几乎每次尝试加快速度,我们都适得其反地增加了复杂性并破坏了质量。在我看来,唯一的方法就是重新编写整个系统。

我记得,我打电话给产品经理说我们需要重写整个系统。电话沉寂了30秒后,项目经理说:“你说你的团队写的产品质量太差,以至于同一团队不得不再次重写相同的产品,但这次更好。对吧?对不起,伙计,这是不可接受的。你应该写得更好。”

盲目求"快"产生“僵尸软件”

根据Standish Group的Chaos报告,94%的项目都是多次从零开始重新开发的。94%!不忍直视啊!当我查看过去开发的产品时,我发现几乎所有的产品都是用新技术、架构和设计从零开始重写的。重写是如此普遍,以至于企业常常将其视为项目管理和创新的唯一选择。我们写啊,写啊,写啊,写啊,写啊。

什么是技术研发中最大的敌人?在研发世界中,速度是至关重要的。不仅对于在市场上处于领先地位很重要,而且通过添加新功能和快速消除bug来响应客户的需求也能保持客户的高满意度。但我们都有“速度”的问题。我们认为,更快、更聪明、更高效地完成任务与设定目标的截止日期有关。我们认为花更多的时间工作,或者与更多的人一起工作,就可以“更快”。因此,我们要么增加新员工,要么加班加点提高生产效率。

然而,匆忙既不会让我们更快,也不会让我们更多产。匆忙只会增加压力,分散注意力,破坏效率。相反,我们需要创造力、效率和专注。

技术研发是非常困难和复杂的。我们无法摆脱复杂性,只能接受它。对速度的追求创造了一个不稳定、不可持续的环境,使我们压力更大、注意力更不集中、效率更低。

团队能力、总体规划、估算、固定工作时间、截止日期和速度概念都是虚构的;无能是现实。

交付时间直接依赖于人员的技能、流程的效率和产出的质量。大多数情况下,开发人员给自己设置了隐藏的截止日期,而没有任何实际需要。

最终,我们得到了遗留产品。最后期限的压力加上无能导致了遗留产品,即死胡同。我给遗留产品起了个更合适的名字:僵尸软件——因为这类产品实际上已经死了,但似乎还在生产中。它在生产中起作用,人们从中获利,但是它需要开发人员的血液、生命和精力来以某种方式继续工作。开发人员不敢碰它,只要它能工作,没有人想要改变它。

Robert C. Martin在twitter上对僵尸软件的症状有一句完美的描述:“如果你的产品越来越难开发,那你就做错了。”“在匆忙中,我们破坏了质量,以至于我们每向前走一步,整个过程就会变得更慢。”我相信,慢下来,直到我们达到一个可持续的状态是唯一的加快速度的方法。

在软件开发中,匆忙是罪恶的

正如Robert C. Martin在谈到CleanCoders的主要价值时提到的,“系统能够容忍和促进这种持续变化的能力是产品的主要价值”。在软件开发中,匆忙是罪恶的。任何匆忙的尝试都会在生产力、注意力、人的效率、适应能力和对产品的容忍度方面造成破坏。

例如,我们总是有时间来修复bug,但是没有时间来编写测试。我们没有重构和编写测试,因为我们没有足够的时间。但我们有时间调试和修复bug。

我们过于关注过程,以至于经常忘记技术研发中的主要资产:人员。流程帮助人们改进他们构建产品的方式,增加动力,培养健康的环境。流程的效率也很重要,但人员是关键。

我们必须承认,没有人和事是完美的。客户、老板、经理、团队成员、友商,甚至你自己,都远非完美。需求、文档、工具、代码、构建的系统和设计,也永远不会是完美的。因此,我们必须停止不受控制的匆忙和加速。要想以可持续的速度更快发展,唯一的方法就是放慢速度,这主要体现在三个方面:

◉ 任用提高专业水平和工艺的人才

◉ 提高适应和效率的流程

◉ 应用提高自动化和质量的产品

当涉及到人的时候,要放慢速度

流程和工具不会生成产品,生产产品的是人。我们必须承认,“人才招聘”是一个组织最重要的功能。它直接影响到公司的未来和产品本身。

为你的组织雇佣最优秀的人才。我所说的“最好的”并不是指最聪明、最有经验的人,而是寻找至少具备激︎情、纪律和动力三要素的人才。如果一个人具备这三种特质,那么其他技能的增长对他来说将不是问题。

招聘是一个双赢的过程,双方都应该从中受益。所以你应该放慢你的招聘进程,并投资改善它。人们会加入他们相信的公司。所以,请为你想要看到的行为建模,通过你的公司文化、你的愿景和你的员工,让人才相信你。

自我会慢慢地杀死你的组织。永远不要让自负进入你的组织。从可爱的傻瓜到天才蠢货,永远不要让极端的人加入你的团队。永远不要雇佣自负的人。和这些人在一起,你永远无法建立让人钦佩的公司文化。

停止独自工作,开始一起工作。永远不要让筒仓(一个人的深井)发生,因为筒仓或英雄开发者是组织功能失调的症状。让团队紧密地坐在一起,两人一组,多人一组,一起定义团队标准,一起工作,一起切磋。让团队共同承担责任。

一起练习是提高技能最有效的方法。在合作中,我们不仅相互激励也互相学习。让知识在人与人之间流动。

从2010年开始,我每周都在自己的团队中组织Brown Bag / Lunch & Learn课程。我多次听到我的同事说,“每周三参加会议能让我提高自己,这对我很有激励作用。”这反映了公司内部定期会议的影响力。

收集并提供反馈。为了收集集体反馈,你可以像我多年来所做的那样,组织Grand Retrospectives(大型“复盘”会)。顺便说一下,Grand Retrospectives是一种新型的挖掘问题的复盘会议,每次有20多人参加。

教学和分享是掌握一个主题的最佳方式。做一名演讲者并回馈社区。

开发人员似乎讨厌文档,但实际上恰恰相反。人们阅读的任何输出都是一个简单朴素的文档;从生产代码本身到测试代码,从提交消息到提交图表,从日志消息到错误消息,开发人员无意中记录了很多文档。所以,无论你记录什么,因为人们读它是为了理解,所以请尽可能把它做得更好。

你不是孩子。公司不是你的父母。我们必须拥有自己的事业并投资自己。如果投资意味着花费时间和金钱,那就自己动手吧。

如何通过减慢速度来优化流程?

每一天,我们都面临着新的挑战。这些挑战不应仅仅是市场需求或新要求。技术挑战对我们的进步也有很大影响。

计划什么都不是,但计划就是一切。计划常改常新。特别是在创业的早期阶段,团队需要非常敏捷。通过每日Scrum或每日站会,每天一次校准计划是不够的。你们必须紧密合作,每天不止一次地校准计划,保持迭代的长度较短,最短为一周。通过组织定期的评审和演示会议来创建多个反馈循环通道。

定义短期目标和长期目标。短期目标为团队创造了焦点,长期目标可以防止注意力分散。

如果你想了解哪里出了问题,可以从可视化流程开始,包括技术上的和业务上的。想象失败和糟糕的事情来促进你从过去的经验中学习。

永远不要凭直觉做决定。始终收集数据,并根据数据分析做出决策。允许每个开发人员访问产品和代码指标也很重要。这增加了产品开发的集体所有权和常识。

浪费是你生产的任何没有商业价值的东西。检测并消除办公室、代码和流程中的浪费。童子军们把露营地弄得比他们来之前还要干净。同样的理念在技术研发中也适用。遵循童子军规则,让你的代码更简洁。当你打开一个文件来添加新功能并注意到其中的一个问题时,请在无需提示、无需许可的情况下自觉修复它。在修复问题之前,不要忘记编写测试。这能使你对自己写的代码感到自信和舒适。

你可以在技术研发生命周期的每个点上检测浪费。遵守你对已完成任务的定义,消除“90%完成,90+剩余”的任务。不要留着那些长得太长的“树枝”,它们是邪恶的。不要通过手动测试来验证代码,手工测试只会验证快乐路径。所有其他场景只能通过测试代码进行验证,所以要认真对待。

放慢速度如何提高产品质量?

有一点很清楚,没有高质量的代码库,就做不到敏捷。你需要做的第一件事是消除技术债务并解决bug。或许你需要停止构建功能一段时间,专注于消除bug。

“修复bug并在之后部署到服务器”这样的流程包含着风险和危机。我们需要换一种更好、更有效的方式。当你想要修复一个bug时,首先编写测试并以编程方式重现问题,然后修复bug并检查测试是否通过,之后部署到生产环节中去才是安全的。

我所在的团队几乎把所有的时间都花在修复bug和维护代码库上。这会影响效率。为了在修复bug的同时继续开发新特性,你需要将你的团队划分为虚拟团队。例如,我们在每个迭代中选择两个队友来提供直接的技术支持,并继续修复bug。我们叫他们蝙蝠侠和罗宾。无论你正在处理哪种特性,都必须不间断地修复bug。

如今,开发人员通常使用一种方法来减缓进度,以便加快速度——使用拉取请求(pull requests)。他们停止生产线,进行验证和代码审查,以提高代码质量。他们从不将未经审核的代码部署到生产环境中。

我们的最终目标应该是实现持续交付,并经常发布。从git分支机制到部署策略,从反馈机制到自动化测试实践,都需要不同的思路。

你在SDLC中使用的实践表明了你的开发速度。对于git分支机制,“尽早提交、经常提交、稍后完善、发布一次”的理念和基于主干的开发,以及功能切换,可以最大程度地消除浪费。

我已经使用TDD很多年了。许多人向我抱怨TDD对编程速度的影响。Joe Rainsberger在twitter分享了他对TDD的看法:“担心TDD会减慢程序员的速度?他们可能正需要慢下来。”

TDD的重构多于测试,思考多于编码,简单多于优雅。这就是为什么它能带来更好的质量。通过TDD开发,有足够的测试和简单的设计。

你是否曾经达到100%的代码覆盖率?我在一个为期三个月的项目中做到了这一点。我为每一行生产代码编写了单元测试。那时,我觉得自己像一个拥有超能力的英雄。但是当我们部署到UAT的预生产环境时,我发现有四个功能无法工作。我不得不编写集成和功能测试来检测bug并解决它们。然后我意识到单元测试并不能保证良好的设计和工作功能。停止计算代码覆盖率,那玩艺儿毛用没有。

如果你需要30分钟或更短时间来修复bug,别犹豫,直接干!此外,用20%的时间消除技术债务。

通常我们编写代码避免将来要修改它。同样,当我们设计产品时,我们选择适当的技术和工具,以便将来不需要修改它。但我们错了。重构应该出现在开发过程的每个阶段。正如Kent Beck所说,我们必须做一些简单的改变来让改变变得简单。为了实现这一点,我们在一个mono存储库中管理所有的微服务。Mono repository用于简化重构,正是我们所需要的。

把放慢速度当作一种哲学

AndreasMöller在一条推文中提到了他对技术研发的看法:“我不想写那些只能工作的代码:我想写干净、可维护、易于理解和经过充分测试的代码。”

为了实现这一目标,我们需要关注三个领域:人员、流程和产品。

◉ 减少人员,我们的目标是提高专业水平和工艺水准。

◉ 放慢进程,我们的目标是提高适应能力和效率。

◉ 放慢生产速度,我们的目标是提高自动化和质量。

当我们专注于这些领域时,我们开始培养一种能够快速研发的开发文化。

我们不应该忘记以下几点:

◉ 可工作的产品不一定制作精良。

◉ 只有优秀的专业人士才能制作精良的产品。

◉ 只有制作精良的产品才能让你比以往更快地构建功能。

上一篇:搞砸软件外包的十个常见错误 下一篇:好的企业文化通过对员工的塑造实现企业的发展