苏州峻德信息

《敏捷宣言》最重要的是哪句?

作者: 11

时间:2020-12-02

作为敏捷软件开发的纲领性文件,《敏捷宣言》全文有着紧密的内在联系,全文都很重要。不过但凡几句话放在一起,对于特定的环境、特定的读者,总有个优先级可排。对于中国软件业大多数企业、大多数从业者,《敏捷宣言》里哪一句是最重要、最需要认真对待的?

我看到有些搞敏捷的同行弄得很玄虚,说《敏捷宣言》不止是中间的这四句,一定要把上下那几句话也拉上一起看。我觉得吧,这话虽然形式逻辑上没什么错,但是呢,这本来就是一个宣言性质的文本,作者非常刻意地把这四句话工工整整摆在正中间,重点在哪里、强调什么,是很明显的事。非要说“不能只看中间四句话”,这个说好听点叫眉毛胡子一把抓分不清主次,说难听点就叫装x,不值得提倡。

那么中间四句话里面,对于中国的同行,哪一句更重要呢?我认为,在讨论软件开发方法的时候,首先得把软件顺利地开发出来,而这件看起来很基本的事,对于国内很多同行来说都还有很多挑战。所以我的观点,在中国这个行业普遍水平上,应该首先关注《敏捷宣言》的第二句:

可工作的软件 重于 面面俱到的文档

因为当你真正开始关注“可工作的软件”,你才能真正理解,敏捷的若干实践,为什么是今天这个样,应该关注什么要点。比如说,需求应该怎么拆解?站在“可工作的软件”这个角度,答案就会很清晰:不能按照“谁来开发”拆,应该按照“给用户提供什么价值”来拆。因为只有用户能用、能创造价值的功能,才是“可工作的软件”。于是很自然地,一个单体Web应用上硬拆出什么前端需求后端需求,甚至恨不得还拆出个数据库需求,这就是反敏捷的瞎搞。正确的需求拆解方法,一定是“纵切蛋糕”,每一个需求单元拆得再小,也是能够独立发布、独立创造价值的。

既然需求单元长成这样了,项目管理应该关注什么要点?从“可工作的软件”的角度出发,项目管理要管的就一定是如何把小块的需求流动起来,尽快、尽可能频繁地把小块需求交付给用户去使用,因为这才是每周、每天的工作真正体现为“可工作的软件”。把软件开发的各个阶段(分析、设计、开发、测试)拆开一段做完再做下一段,天天盯着人员工作量是否饱满,放在“可工作的软件”这个视角下一看就是很明显的错误做法。正如我经常问的那个问题:当“项目进度60%”的时候如果马上把项目停下,你能得到什么?是已经具备60%功能、能够实现60%用户价值的可工作的软件吗?还是只有一堆文档没有任何软件可用?这个问题,就是《敏捷宣言》第二句最直观的表现形式。

既然项目是以这种方式运作,软件的变更应该如何进行?很明显,你就不能指望一块代码写完测好以后就再也不去动它。你就得接受这个现实:功能是一点一点加上去的,代码是不断反复修改的,并且任何人都有可能修改任何一块代码——如果没有“集体代码所有制”,如果划分代码责任田,每人负责一块代码,那么需求的“纵切蛋糕”就会变成一句废话,并且项目管理也无法开展,因为整个项目的进展无可避免地就会绑死在最瓶颈的那块代码、那个人。

既然已经确定代码要反复修改、大家都能改,那么软件的质量要如何保障?答案是清晰且唯一的:不可能靠人肉回归测试来保障质量,必须依赖全面、可靠、快速的自动化测试来构建软件质量的安全网。测试部的小姑娘可以忍受每两周做一次人肉回归测试,但是再缩短周期就是人类极限了。(这也解释了为什么国内大多数敏捷团队最多能做到每两周一次发布,无法再缩短发布周期。)只有基于全面、可靠、快速的自动化测试开展持续集成,才有可能保证被反复修改的软件一直处于可工作的状态。并且也只有具备了全面、可靠、快速的自动化测试,程序员才有勇气不断重构代码,保障软件的内部质量处于良好的、允许反复修改的状态。

如上所述,只要抓住了《敏捷宣言》的第二句,对于需求管理、项目管理、配置管理、质量保证这4项软件开发的基础能力,应该怎么做都是一目了然的。敏捷有没有做对,只要拿“可工作的软件”为准绳来量一下,基本上是清清楚楚的。应该怎么去改进,答案也是明明白白的。当然了,难免有一些人、一些组织,总想绕着圈子走,不去碰那些最核心、最根本的能力问题。这些人和组织绕了半天圈子以后,你会发现,哎,他们真的就得到了一堆面面俱到的文档,而“可工作的软件”,还是老样子。这就叫求仁得仁。


上一篇:拥有客户,再服务客户

《敏捷宣言》最重要的是哪句?

《敏捷宣言》最重要的是哪句?

作为敏捷软件开发的纲领性文件,《敏捷宣言》全文有着紧密的内在联系,全文都很重要。不过但凡几句话放在一起,对于特定的环境、特定的读者,总有个优先级可排。对于中国软件业大多数企业、大多数从业者,《敏捷宣言》里哪一句是最重要、最需要认真对待的?

我看到有些搞敏捷的同行弄得很玄虚,说《敏捷宣言》不止是中间的这四句,一定要把上下那几句话也拉上一起看。我觉得吧,这话虽然形式逻辑上没什么错,但是呢,这本来就是一个宣言性质的文本,作者非常刻意地把这四句话工工整整摆在正中间,重点在哪里、强调什么,是很明显的事。非要说“不能只看中间四句话”,这个说好听点叫眉毛胡子一把抓分不清主次,说难听点就叫装x,不值得提倡。

那么中间四句话里面,对于中国的同行,哪一句更重要呢?我认为,在讨论软件开发方法的时候,首先得把软件顺利地开发出来,而这件看起来很基本的事,对于国内很多同行来说都还有很多挑战。所以我的观点,在中国这个行业普遍水平上,应该首先关注《敏捷宣言》的第二句:

可工作的软件 重于 面面俱到的文档

因为当你真正开始关注“可工作的软件”,你才能真正理解,敏捷的若干实践,为什么是今天这个样,应该关注什么要点。比如说,需求应该怎么拆解?站在“可工作的软件”这个角度,答案就会很清晰:不能按照“谁来开发”拆,应该按照“给用户提供什么价值”来拆。因为只有用户能用、能创造价值的功能,才是“可工作的软件”。于是很自然地,一个单体Web应用上硬拆出什么前端需求后端需求,甚至恨不得还拆出个数据库需求,这就是反敏捷的瞎搞。正确的需求拆解方法,一定是“纵切蛋糕”,每一个需求单元拆得再小,也是能够独立发布、独立创造价值的。

既然需求单元长成这样了,项目管理应该关注什么要点?从“可工作的软件”的角度出发,项目管理要管的就一定是如何把小块的需求流动起来,尽快、尽可能频繁地把小块需求交付给用户去使用,因为这才是每周、每天的工作真正体现为“可工作的软件”。把软件开发的各个阶段(分析、设计、开发、测试)拆开一段做完再做下一段,天天盯着人员工作量是否饱满,放在“可工作的软件”这个视角下一看就是很明显的错误做法。正如我经常问的那个问题:当“项目进度60%”的时候如果马上把项目停下,你能得到什么?是已经具备60%功能、能够实现60%用户价值的可工作的软件吗?还是只有一堆文档没有任何软件可用?这个问题,就是《敏捷宣言》第二句最直观的表现形式。

既然项目是以这种方式运作,软件的变更应该如何进行?很明显,你就不能指望一块代码写完测好以后就再也不去动它。你就得接受这个现实:功能是一点一点加上去的,代码是不断反复修改的,并且任何人都有可能修改任何一块代码——如果没有“集体代码所有制”,如果划分代码责任田,每人负责一块代码,那么需求的“纵切蛋糕”就会变成一句废话,并且项目管理也无法开展,因为整个项目的进展无可避免地就会绑死在最瓶颈的那块代码、那个人。

既然已经确定代码要反复修改、大家都能改,那么软件的质量要如何保障?答案是清晰且唯一的:不可能靠人肉回归测试来保障质量,必须依赖全面、可靠、快速的自动化测试来构建软件质量的安全网。测试部的小姑娘可以忍受每两周做一次人肉回归测试,但是再缩短周期就是人类极限了。(这也解释了为什么国内大多数敏捷团队最多能做到每两周一次发布,无法再缩短发布周期。)只有基于全面、可靠、快速的自动化测试开展持续集成,才有可能保证被反复修改的软件一直处于可工作的状态。并且也只有具备了全面、可靠、快速的自动化测试,程序员才有勇气不断重构代码,保障软件的内部质量处于良好的、允许反复修改的状态。

如上所述,只要抓住了《敏捷宣言》的第二句,对于需求管理、项目管理、配置管理、质量保证这4项软件开发的基础能力,应该怎么做都是一目了然的。敏捷有没有做对,只要拿“可工作的软件”为准绳来量一下,基本上是清清楚楚的。应该怎么去改进,答案也是明明白白的。当然了,难免有一些人、一些组织,总想绕着圈子走,不去碰那些最核心、最根本的能力问题。这些人和组织绕了半天圈子以后,你会发现,哎,他们真的就得到了一堆面面俱到的文档,而“可工作的软件”,还是老样子。这就叫求仁得仁。


《敏捷宣言》最重要的是哪句?

作者: 11

时间:2020-12-02

作为敏捷软件开发的纲领性文件,《敏捷宣言》全文有着紧密的内在联系,全文都很重要。不过但凡几句话放在一起,对于特定的环境、特定的读者,总有个优先级可排。对于中国软件业大多数企业、大多数从业者,《敏捷宣言》里哪一句是最重要、最需要认真对待的?

我看到有些搞敏捷的同行弄得很玄虚,说《敏捷宣言》不止是中间的这四句,一定要把上下那几句话也拉上一起看。我觉得吧,这话虽然形式逻辑上没什么错,但是呢,这本来就是一个宣言性质的文本,作者非常刻意地把这四句话工工整整摆在正中间,重点在哪里、强调什么,是很明显的事。非要说“不能只看中间四句话”,这个说好听点叫眉毛胡子一把抓分不清主次,说难听点就叫装x,不值得提倡。

那么中间四句话里面,对于中国的同行,哪一句更重要呢?我认为,在讨论软件开发方法的时候,首先得把软件顺利地开发出来,而这件看起来很基本的事,对于国内很多同行来说都还有很多挑战。所以我的观点,在中国这个行业普遍水平上,应该首先关注《敏捷宣言》的第二句:

可工作的软件 重于 面面俱到的文档

因为当你真正开始关注“可工作的软件”,你才能真正理解,敏捷的若干实践,为什么是今天这个样,应该关注什么要点。比如说,需求应该怎么拆解?站在“可工作的软件”这个角度,答案就会很清晰:不能按照“谁来开发”拆,应该按照“给用户提供什么价值”来拆。因为只有用户能用、能创造价值的功能,才是“可工作的软件”。于是很自然地,一个单体Web应用上硬拆出什么前端需求后端需求,甚至恨不得还拆出个数据库需求,这就是反敏捷的瞎搞。正确的需求拆解方法,一定是“纵切蛋糕”,每一个需求单元拆得再小,也是能够独立发布、独立创造价值的。

既然需求单元长成这样了,项目管理应该关注什么要点?从“可工作的软件”的角度出发,项目管理要管的就一定是如何把小块的需求流动起来,尽快、尽可能频繁地把小块需求交付给用户去使用,因为这才是每周、每天的工作真正体现为“可工作的软件”。把软件开发的各个阶段(分析、设计、开发、测试)拆开一段做完再做下一段,天天盯着人员工作量是否饱满,放在“可工作的软件”这个视角下一看就是很明显的错误做法。正如我经常问的那个问题:当“项目进度60%”的时候如果马上把项目停下,你能得到什么?是已经具备60%功能、能够实现60%用户价值的可工作的软件吗?还是只有一堆文档没有任何软件可用?这个问题,就是《敏捷宣言》第二句最直观的表现形式。

既然项目是以这种方式运作,软件的变更应该如何进行?很明显,你就不能指望一块代码写完测好以后就再也不去动它。你就得接受这个现实:功能是一点一点加上去的,代码是不断反复修改的,并且任何人都有可能修改任何一块代码——如果没有“集体代码所有制”,如果划分代码责任田,每人负责一块代码,那么需求的“纵切蛋糕”就会变成一句废话,并且项目管理也无法开展,因为整个项目的进展无可避免地就会绑死在最瓶颈的那块代码、那个人。

既然已经确定代码要反复修改、大家都能改,那么软件的质量要如何保障?答案是清晰且唯一的:不可能靠人肉回归测试来保障质量,必须依赖全面、可靠、快速的自动化测试来构建软件质量的安全网。测试部的小姑娘可以忍受每两周做一次人肉回归测试,但是再缩短周期就是人类极限了。(这也解释了为什么国内大多数敏捷团队最多能做到每两周一次发布,无法再缩短发布周期。)只有基于全面、可靠、快速的自动化测试开展持续集成,才有可能保证被反复修改的软件一直处于可工作的状态。并且也只有具备了全面、可靠、快速的自动化测试,程序员才有勇气不断重构代码,保障软件的内部质量处于良好的、允许反复修改的状态。

如上所述,只要抓住了《敏捷宣言》的第二句,对于需求管理、项目管理、配置管理、质量保证这4项软件开发的基础能力,应该怎么做都是一目了然的。敏捷有没有做对,只要拿“可工作的软件”为准绳来量一下,基本上是清清楚楚的。应该怎么去改进,答案也是明明白白的。当然了,难免有一些人、一些组织,总想绕着圈子走,不去碰那些最核心、最根本的能力问题。这些人和组织绕了半天圈子以后,你会发现,哎,他们真的就得到了一堆面面俱到的文档,而“可工作的软件”,还是老样子。这就叫求仁得仁。


上一篇:拥有客户,再服务客户