幻象和敏捷

[ozzzzzz]

“敏捷的开发速度快。”我已经不是第一次听到这个说法了，每一次我都会对这个事情做解释，但是每次对方都觉得我多余解释，很不耐烦的去做其他事情了。这个事情从10年前我开始用agile这个词汇开始做推广的时候就开始了，只不过今天几乎我遇到的每一个新来的敏捷者都在说：“敏捷就是速度快啊！”我觉得一个头脑正常的软件从业人员就不该有这个想法。不管这个人年纪多大，地位多高，身份多显赫都应该被开除出这个行业。

《没有银弹》，这篇文章我曾经用一个晚上写了1万多字的博客，来解释和介绍他的观点。费这么大的力气，其实就是因为有个叫张询的硕士，耍小聪明，非要说银弹是可以存在的。今天其实类似张询的人，还是不少，虽然他们可能也像张询那样声称自己现在是敏捷了。当然如果他们是敏捷，那我们是什么？所以首要问题，就是要否认我们这些人存在过，于是就会说agile这种高级货是来自国外的，是来自什么什么外企的。这个是题外话，大家明白就行了，知道虽然有的人看起来很和善，但是实际是比恶狼还凶狠。而我们有些人有心无心的就做了他们的垫脚石。

于是前面有硕士，后面有这些不知道来源的所谓敏捷者，再加上一些市场人员和推广人员，就形成了现在的一个气氛。这个气氛总是在说，或是早暗示敏捷的开发速度是快的，比其他任何方法都快。于是客户们兴奋了，觉得敏捷好啊，是在是个宝贝，拿回家至少可以对付一年半载。于是到处都在说我们要敏捷起来，而且我们一定能敏捷起来。但是过了一段时间，单元测试也做了，持续集成也做了，重构也搞了，故事也用了，也scrum了，也站立开会了，可是速度还是不能达到要求。于是那一日到来的时候，自然这些人就会说敏捷不行，至少在“我们”这里不行。

所以我要早给他们做解释，大声的解释，直到他们完全能听懂我的说法，我才会继续真正的去实施敏捷。

敏捷的快，不是开发速度快，而是反映速度快。开发速度和反映速度，就好比人跑步时候的直线速度和拐弯的速度。我们知道非洲猎豹是直线速度最高的动物，但是他们对付善于转弯的羚羊时，完整不站上风。可以说敏捷的这种快速反应的能力，不仅仅不会增加开发的速度，还会降低速度。这个就跟你只要弯道多，就不可能发挥出最大速度的道理一样。那么我们实际看到的情况怎么解释呢？或者说敏捷如果是一种慢速度的开发方法，怎么会流行起来呢？

其实很简单，问题就在于敏捷的推出，是面向软件危机的，而不是我们今天所面对的这些项目。软件危机是我们开发的时候，遇到的最大问题是我们会失败，也就是我们不能按照预先的设想完成软件开发。而我们今天面对的情况是，我们虽然可以开发出一个软件，但是开发速度太慢了。请认真体会这里的不同。于是我们就会明白，因为采取了敏捷，那些本来就会失败的项目，在早期就会被结束了；那些需求不明确的项目，在早期就已经开发有一个工作的东西了，虽然这个东西还没有完全达到当初的预想；有些项目客户的想法有问题，在早期通过实际的开发他们变得理性了；在项目结束的时候最终达到了一个目标，虽然这个目标并不是开始设定的那个，但是这个很可能比那个还好些。于是人们就形成一个错觉，那就是敏捷的开发速度更快。

实际上敏捷不能直接的给你提供更多的代码行，更多的模块，更多的设计。他仅仅是减少了你犯错误的可能，和降低了你改正错误的成本。

但，是不是说只有敏捷有这个能力，其他方法就没这个能力呢？根本不是这样，只要是靠谱的人，用他们习惯的方法去工作，就可以起到这个效果。是不是就没有办法提供更高的开发速度了呢？当然不是。靠谱的开发者是唯一的真正能提高速度的开发方法。也就是说虽然没有银弹，但是确实存在能人狼的杀手。我们只能说，敏捷至少当初是被一群靠谱的人用着的方法。现在大家都来用敏捷，是不是大家就都靠谱起来了？我看这个事情未必，该是2B开发者的还是会是2B开发者。也许敏捷能让开发者更能提高自己的开发能力，并最终靠谱起来。但是这也仅仅是一种可能性的存在，而不是一个充分条件。

所以如果你希望能有一个提供量级的方法，那你就错了。而且所有的方法，几乎都是为了一个目的而开发的，那就是提供目标的重现性实现，提供更大的可操控性。即使是敏捷也是这样。也就是说，当你要开发一个软件的时候，你自己的能力是唯一决定你能否成功的指标。而方法则仅仅是提供一个在某个区段完成它的可能性。方法今天不会成为一个保障，估计明天也不可能，后天也不可能，在我看得到的日子里都不可能。但是未来的某一天它会实现，但是那将是将来的事情了。

[-=Kobye=-]

速度是速度
质量是质量

效率是效率

2012/11/23 ozzzzzz <ozzzz...@gmail.com>

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
 
 

--
--------------------------------------------------------------------------
I love Java!
I love Sports!
I love this Game !

QQ:33093778
MSN:sportsb...@hotmail.com

home:http://www.jsports.org
blog:http://blog.csdn.net/jsports
       http://blog.matrix.org.cn/page/jsports
--------------------------------------------------------------------------

[Shaopeng]

这个比喻和我想到一块儿去了！猎豹和羚羊。。。

敏捷的快，不是开发速度快，而是反映速度快。开发速度和反映速度，就好比人跑步时候的直线速度和拐弯的速度。我们知道非洲猎豹是直线速度最高的动物，但是他们对付善于转弯的羚羊时，完整不站上风。可以说敏捷的这种快速反应的能力，不仅仅不会增加开发的速度，还会降低速度。这个就跟你只要弯道多，就不可能发挥出最大速度的道理一样。那么我们实际看到的情况怎么解释呢？或者说敏捷如果是一种慢速度的开发方法，怎么会流行起来呢？

-- 

Shaopeng

+86 18600055328

使用 Sparrow 发送

[-=Kobye=-]

 速度快有啥用 一堆BUG 一上线立即造成一堆系统down了

效率高才是好

[胖子]

好吧 好吧

应该是效率高而不是速度高。

其实速度快本身就是效率高的一个另外的说法，上线前应该保证一点的质量，消除一定的bug，这个本身是不需要讨论的。出发是学生写的课堂作业，否则哪个生产环境下，不是都有一点的发布的标准。很多稍微像样点的公司，都有人专门负责发布，都有一个流程保证发布的质量。

而且随着互联网行业的发展，发布的要求也越来越灵活，比如有些bug会存在很多的版本而不被修改。其他事情也在改变。

而实际上我非常不喜欢用开发效率这个词，因为这个东西十分不容易定义出来，而且在实际中也很难说究竟代表了什么。而速度则简单的多，明确的多。最简单的就是明天我就要上线，到时候你能把东西搞出来不？这个最明确，也最容易被审查。

在 2012年11月23日星期五UTC+8下午5时28分12秒，-=Kobye=-写道：

 速度快有啥用 一堆BUG 一上线立即造成一堆系统down了

效率高才是好

[-=Kobye=-]

明天我就要上线，

到时候你能把东西搞出来不？


这种的是比较危险的事情。

搞出来了，上线了，带来一系列的问题。。。。
谁为这个买单？

2012/11/23 胖子 <ozzzz...@gmail.com>

到时候你能把东西搞出来不

[Shaopeng]

to Kobye:

这样说你就误解或者说小瞧那些一定要快的人们了，bug数肯定是和速度指标一起提出的。

-- 

Shaopeng

+86 18600055328

使用 Sparrow 发送

在 2012年11月23日星期五，下午5:28，-=Kobye=- 写道：

 速度快有啥用 一堆BUG 一上线立即造成一堆系统down了

效率高才是好

[-=Kobye=-]

倒不是误解，
不希望出现很多擦屁股的事情

[胖子]

哈哈，你就是误解了。

这里其实是有个背景，那就是软件行业和互联网行业的不同。我现在是在用互联网行业的思维在想问题。

在互联网行业，其实速度是第一位的。因为商机一旦错误，就不可能挽救。所以基本上都会极端的追求速度，而质量会稍微放松点。因为即使很多很多屁股需要擦，但是也是因为有用户才会去擦。而没有用户，根本就不需要擦。所以宁可搞一个漏洞百出的试用版，也不会要一个没有bug的没有人用的正式版。

而我认为，出发是极其特殊的项目，比如12306这个类型的项目，其他项目最后都会像互联网项目靠拢。所以这个应该是一个趋势。也就是虽然是bug，但是如果没有价值也不需要去修正它们。

在 2012年11月23日星期五UTC+8下午5时50分28秒，-=Kobye=-写道：

倒不是误解，
不希望出现很多擦屁股的事情

[-=Kobye=-]

 是的

认同这样的看法

[张克强]

刚开始了解敏捷的人，望文生义，想当然的以为“敏捷软件开发”就能更快的开发软件。

英文Agile的原意貌似也有“快”的意思。

好在随着时间推移，慢慢的有更多人了解敏捷。

但总有人刚刚接触敏捷，总有人在开始想当然的以为“敏捷就是快”。

而且业界确实曾有组织报告，采用敏捷后，开发效率提升了多少多少。

在 2012年11月23日 下午6:01，-=Kobye=- <www.jsp...@gmail.com>写道：

 是的

认同这样的看法

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
 
 

--
张克强

blog: 从高效过程到卓越结果

weibo: http://weibo.com/zhangkeqiang 

[Vincent Lee]

这个邮件组有问题了么？ 我发送到agile...@googlegroups.com 怎么没反应？

[张克强]

貌似没有问题。收到你的信了。

可能是大陆访问Gmail受限的问题。

我通过vpn访问是可以的。

[Aska Ryo]

刚从传统IT业转到互联网行业没多久，一直有个疑问求救各位大牛：

确实我可以理解互联网行业因为业务变化快，商机都是瞬息即逝的，所以很多开发团队都是认为速度>>质量的。

但是同时也有另一种说法是互联网行业竞争压力大，一个细分的行业里就有很多个同类竞争产品，所以一旦发布出去的产品质量不好就会造成用户的流失，且再也无法挽回。

所以这两种观点其实是矛盾的。

而第一种观点，就会导致开发人员不做单元测试，不做代码review，匆忙实现功能，快速上线，发现线上有问题了再快速修复（当然这种修复可能引入新的问题），据我所知包括BAT也是这么做的（当然BAT因为他们的强势地位可以让用户容忍bug）

第一种观点似乎在现在的大环境中更流行一些，但是现在BAT似乎也在强调敏捷转型（当然“敏捷”这个词已经被各种忽悠公司用滥了），但似乎他们仍然不重视单元测试及TDD的作用，主要是期望运用scrum或者kanban这种管理实践来提高开发团队效率。

我个人认为TDD与CI是各种敏捷实践中最核心的实践，但似乎在国内业界主流思想并不这么认为，是我太天真了吗？

[皮宏宇]

如果你能把活干的又快又好就没有这个问题了，所以互联网行业多数要求能力比较强的工程师，稍弱一点都可能被淘汰。另外，互联网行业多数是要求质量>速度的，但是速度也绝对不能慢，于是引入了“PM-〉dev-〉QA-〉”上线 的流程，（在我看来）使用了比传统行业更多的人力去解决同时保证速度和质量的问题

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina

---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Aska Ryo]

所以如何去保证把活干得又快又好呢？

可能我中tdd的毒太深了吧，按我的习惯不先写单元测试都没法下手写代码，就像开车不系安全带就浑身不舒服一样。

但是总有人告诉我，互联网企业就是要快，BAT都不写单元测试，就是为了追求尽快发布，尽快上线，否则市场就被别人抢占了。

我也找不到好的办法说服他们，甚至我不知道是不是应该说服他们，因为我的互联网经验尚浅，还是说互联网行业本来就应该是这样的？

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+unsubscribe@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[皮宏宇]

单元测试只是保证质量的一种手段啊，你也可以通过其他手段提升质量，例如结对、例如code review，总之达到目标即可，不要纠结用什么手段，你只要保证结果又快又好就行。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Aska Ryo]

在我的理解里，pair programming和code review并不能作为UT的取代手段，它们可以共同作用，提升产品质量。

比如pair programming和code review并不能阻止引入regression的bug，也不能在引入bug时快速反馈给developer自己，

更不用说以TDD作为设计的工具的作用吧。

如欲退订请发送邮件到 agilechina-unsub...@googlegroups.com

[皮宏宇]

我就这么说把，牛逼的人写完的代码是不会出bug的，菜鸟才会出bug，互联网公司一般是选择牛逼的人，因为他能同时保证质量和效率，而传统行业更期望选择菜鸟，因为他们更便宜。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Aska Ryo]

呃，那也许是我见识太少吧，没有见过一个凭空写完代码从来不出bug的牛人

如欲退订请发送邮件到 agilechina-unsubscri...@googlegroups.com

更多选项，请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+unsubscribe@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

-- 
-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+unsubscribe@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Glen Wang]

有微信群吗？谁来搞一个？

---

Date: Thu, 29 Oct 2015 21:02:27 -0700
From: aska...@gmail.com
To: agile...@googlegroups.com
Subject: Re: [agilechina] 幻象和敏捷

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[ozzzzzz]

现在BAT的问题，并不是TDD能解决的。他们面临的问题，主要还是产品设计。

铁三角，重构，单元测试，持续集成，现在有了发展。重构，由简单设计和框架式开发，已经新的工具的使用，已经几乎很少被人们正式提起。持续集成，也发展到了持续部署，持续交付。唯独单元测试，还是那样。

现在的开发，基本上都是使用某种高能力的工具，快速开发。代码量和复杂度都比较小，而工具的支持也比较好。所以单元测试的迫切程度并不大。工具的复杂性，造成工具的开发反而更加需要引入更多的测试。基本上各个公司都有基础工具部门或者平台部门。

Glen Wang <glenw...@hotmail.com>于2015年10月30日周五 下午12:03写道：

如欲退订请发送邮件到 agilechina-unsub...@googlegroups.com

--

--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---

您收到此邮件是因为您订阅了Google网上论坛上“敏捷中国”群组中的主题。
要退订此主题，请访问https://groups.google.com/d/topic/agilechina/SxIf0NUhg4o/unsubscribe。
要退订此群组及其所有主题，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Aska Ryo]

所以我是不是可以理解为因为BAT的资源丰富，有成熟的支持功能开发的基础工具（可能是第三方的也可能是他们自己开发的），所以依靠这些工具开发出错的可能性比较小，所以单元测试或者TDD都不是必要的。

但是对于开发这些基础工具的团队还是需要的？

另外BAT之外的公司，特别是互联网行业成批起来又成批死掉的创业小公司来说，没有这样的基础设施建设，所以TDD对他们还是适用的？

如欲退订请发送邮件到 agilechina-unsubscri...@googlegroups.com

更多选项，请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+unsubscribe@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

-- 
-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com

如欲退订请发送邮件到 agilechina-...@googlegroups.com

更多选项，请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+unsubscribe@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com

如欲退订请发送邮件到 agilechina-...@googlegroups.com

更多选项，请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+unsubscribe@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com

如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上“敏捷中国”群组中的主题。
要退订此主题，请访问https://groups.google.com/d/topic/agilechina/SxIf0NUhg4o/unsubscribe。

要退订此群组及其所有主题，请发送电子邮件到agilechina+unsu...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[皮宏宇]

“另外BAT之外的公司，特别是互联网行业成批起来又成批死掉的创业小公司来说，没有这样的基础设施建设，所以TDD对他们还是适用的？”—— 是的，不过成批起来又成批死掉的创业小公司来说，活下去才是更重要的。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Bo Yang]

你的目的是什么？你实现目的的手段又是什么？如果一个手段是达到目的不可或缺的，自然会成为教条；若不是，就可有可无。

至于“成批起来又成批死掉的创业小公司”，你得先关心人家为什么死掉。只要不是因为TDD死掉的，就与你的主题毫无关系。

    致
礼

杨波

如欲退订请发送邮件到 agilechina-unsub...@googlegroups.com

更多选项，请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

-- 
-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表

如果想发起讨论，请发送邮件到 agile...@googlegroups.com

如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---

您收到此邮件是因为您订阅了Google网上论坛上“敏捷中国”群组中的主题。
要退订此主题，请访问https://groups.google.com/d/topic/agilechina/SxIf0NUhg4o/unsubscribe。

要退订此群组及其所有主题，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Aska Ryo]

拿我前面说的开车不系安全带作个比喻吧。

我们都知道开车需要系安全带，但是现实情况中不系安全带的人也很多，也并不是说每个不系安全带的人都出车祸死掉了，或者说系了安全带的人就不会死掉。

所以一部分人认为开车系安全带是可有可无的，另一部分人认为开车必须系安全带。估计互相谁也说服不了谁。

就算有人出车祸死了，不系安全带也只是其中一个原因，还有很多其他原因导致车祸的发生，但是这样并不能证明不系安全带跟人出车祸死掉没有关系。

    致
礼

杨波

如欲退订请发送邮件到 agilechina-unsubscri...@googlegroups.com

更多选项，请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+unsubscribe@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

-- 
-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com

如欲退订请发送邮件到 agilechina-...@googlegroups.com

更多选项，请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+unsubscribe@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表

如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com

更多选项，请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+unsubscribe@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com

如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---

您收到此邮件是因为您订阅了Google网上论坛上“敏捷中国”群组中的主题。
要退订此主题，请访问https://groups.google.com/d/topic/agilechina/SxIf0NUhg4o/unsubscribe。

要退订此群组及其所有主题，请发送电子邮件到agilechina+unsu...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+unsubscribe@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Jeff Xiong]

这个逻辑是对的。TDD管的是质量尤其是可维护性（前面说bug的其实没怎么说到点儿上哈），但是可维护性尤其是单个代码库的可维护性这事儿究竟有多重要，我现在越来越有疑问。作为《重构》的译者，我的感觉，重构这个技术正在越来越变成一个屠龙技。

    致
礼

杨波

如欲退订请发送邮件到 agilechina-unsub...@googlegroups.com

更多选项，请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

-- 
-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表

如果想发起讨论，请发送邮件到 agile...@googlegroups.com

如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---

您收到此邮件是因为您订阅了Google网上论坛上“敏捷中国”群组中的主题。
要退订此主题，请访问https://groups.google.com/d/topic/agilechina/SxIf0NUhg4o/unsubscribe。

要退订此群组及其所有主题，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表

如果想发起讨论，请发送邮件到 agile...@googlegroups.com

如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表

如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

Jeff Xiong

http://gigix.thoughtworkers.org

[皮宏宇]

跟安全带不一样，都是成本收益问题，系安全带成本大约需要启动前花费5秒钟（多数时候还是车在运行中），就削减了重大事故中40%甚至更多的风险。但是施行一种新的开发方法（规则）需要大量的培训、学习成本，对那种明天搞不好就死掉的创业团队来说，是否具有性价比，有待考证。

最后，tdd也好单元测试也好，都是目前时代的一种保证质量的方法，这些东西，对于牛逼的人来说是轻车熟路的，所以，团队牛逼与否（能不能开心的活下去），主要是靠人给不给力（因为方法也是需要靠人去执行），不是靠使用了什么方法。

在未来，我们也许用机器去写代码，我们只给出思路和理念就够了^_^，到时候我们可以详细探讨下如何让机器更优雅的书写代码，因为这是机器做不到的。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Glen Wang]

如果是机器写，那么也应该由机器检查，就不用优雅了，就只用正确，不用可读性，规则都得推倒重来。

---

From: ds3...@gmail.com
Subject: Re: [agilechina] 幻象和敏捷
Date: Fri, 30 Oct 2015 15:26:52 +0800
To: agile...@googlegroups.com

[皮宏宇]

可读性是一定要的，万一哪天写出一个Architector，然后这个 Architector 又造出了Matix，如果没有人工干预的审查制度，我们就都变成化学燃料电池了 

(-̩̩̩-̩̩̩-̩̩-̩̩̩_-̩̩̩-̩-̩̩̩-̩̩̩)

[Jeff Xiong]

> 在未来，我们也许用机器去写代码，我们只给出思路和理念就够了

这个是幻想。编程的根本困难是对连续的、模拟的物理世界进行离散的、数字的建模，将一个模拟问题描述为一个图灵机可计算的问题。至于这个模型怎么实现，《人月神话》说了，那是偶发困难。大多数人不会编程，不是因为不懂Java，而是因为不会逻辑地思考。普元的黄柳青当年说，只要在一个图形化的界面上拖拽，你就不需要编程了。结果呢？结果大家发现，你要把问题想清楚，然后选择合适的元件加以合适的装配，这个就叫编程。思路和理念，你要么表述得模糊、抽象、不清晰，因此图灵机不可计算，因此机器写不出代码；要么你表述得清晰、明确、图灵机可计算，那么你做的事就叫编程，其复杂度跟今天的编程不会有本质区别。

    致
礼

杨波

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

-- 
-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Aska]

深有同感，不光是重构，整洁代码，结对编程等实践似乎也都使不上力。

在互联网环境下，可能业务变了，这个功能过两个版本就没了，我今天开发的代码过不了多久就不用了，我何必去管它的可读性可维护性或者可扩展性？又何必去给它加单元测试？

似乎人们渐渐都开始接受这样的思想，而且有一个破窗效应在里面，渐渐波及到其他的我们以前认为正确的实践。

这也是我最近比较迷茫的地方，是这些实践真的跟不上时代的发展了吗？

[Jeff Xiong]

跟不上时代的发展也是很正常的事。单一代码库的可维护性变得不那么重要，那么代码库与代码库之间（在运行时通常是进程与进程之间）的可维护性就会变得愈发重要。容器，微服务，都是在讲这个事。重构这种特定的技术过时了，康威法则仍然生效，Martin Fowler说的“白痴都能写出机器能读的代码，好的程序员要写人能读的代码”仍然生效。知识过时，学习不过时。

[Bo Yang]

单元测试是手段不是目的。重构，整洁代码，结对编程都是手段。可读性可维护性或者可扩展性，也是手段，目的是产品的长期生命。

目的有轻重缓急，手段自然需要相应选取。如果你有资源有时间做单元测试，自无不可。如果你东西不上就丢饭碗，急着上了会冒出大问题被责骂的风险，多数人还是会冒冒险的。至于不知道哪天死的创业企业就完全看决策者的情怀了。他们的生存还是死亡，优先短期还是长期收益，他们自己都不见得弄得清楚，我们从旁妄加评判，终归有点“站着说话不腰疼”的感觉。而且，他们做错了决定，市场会让他们关门的。

撇开这些不谈，工程的事，大部分的准则都有上下文的，适不适用，用的人才清楚。

    致
礼

杨波

2015-10-30 16:00 GMT+08:00 Aska <aska...@gmail.com>:

[吴亭]

哈哈哈，看笑了，写的好😀

[Xu Yi]

建了一个，大家加吧，不过这个群沉默很久了，不晓得是否有这个需求，试试吧。群二维码过期的话，可以加我，注明“加敏捷中国谷歌讨论组”即可

- - - - - - - - - -
Xu Yi, Kaverjody
Site: http://kaverjody.com

WeChat / Skype / Twitter: kaverjody

LinkedIn: http://www.linkedin.com/in/kaveri
- - - - - - - - - -

有微信群吗？谁来搞一个？

如欲退订请发送邮件到 agilechina-unsub...@googlegroups.com

[ozzzzzz]

不是这个意思。

BAT这样的公司，即使有各种条件，还是需要测试的，特别是单元测试。

我的意思是，互联网公司，因为各种情况，他们自己看不到单元测试的迫切性，也看不到这样做的收益，也没有这样的习惯。而从另外的方面讲，单元测试的优先级在互联网公司要靠后些。

Xu Yi <kave...@gmail.com>于2015年10月30日周五 下午10:55写道：

[liyin...@gmail.com]

我严重怀疑事情没有你们说的那么急，互联网怎么了，快鱼吃慢鱼也说得是宏观上的快，

如果码农们把这当做不写测试不做重构的理由，那要么是真糊涂要么是偷懒；

况且退一百步说，就算你写的东西半年后就会丢弃，你也没有因为偷工减料而节省你的时间和生命，

高质量的工作永远都是最快的工作。我做个POC之类的小项目都经常能感受到这一点。

---

liyin...@gmail.com

 

发件人： Bo Yang

发送时间： 2015-10-30 16:15

收件人： agilechina

主题： Re: [agilechina] 幻象和敏捷

[Bo Yang]

可是可是我有说不写测试不做重构吗？？

高质量的工作是怎么来的？是单元测试带来的吗？还是你自己认真思考，认真处理带来的？单元测试带来的是什么？是信心。是以几乎最小的代价确定代码在这条路径上如预期一样工作。那么，单纯从理论上来说，我对自己的代码有信心，我就不需要单元测试了，甚至不需要测试了。事实上，你会测试JDK的API吗？

那么我优先考虑的永远是去弄清楚问题，弄清楚实现思路，用单元测试验证并保证不是那么清晰的部分。（我当然希望我能弄清楚所有，然而很不幸，这就是现实，或者说个人能力有限，但我也不能因此停下来。）当然，没有单元测试的部分可能出错，但有单元测试就不出错了吗？不过是概率。我用经验去衡量成本风险收益了而已。呵呵，如果时间充裕的话，可能测试会写得更多。不过实话实说，习惯形成了就很难改了，除非公司改工作文化，例如测试加入考核，这就是另一码事了。

不写测试不做重构和一定要TDD一定要覆盖率一样，都是教条，不过分属两个极端而已。最重要的，还是人的工作，还是人。

    致
礼

杨波

[liyin...@gmail.com]

你倒是没说不做，你只是说了什么“轻重缓急、 如果你有资源”之类的貌似成立的理由，

然后又针对单元测试说了一番，不知为何又回避了重构，单元测试难道很大程度是不是为了保证重构安全么？

你写一些很熟的代码 是可以很有信心，但是不熟的呢，用了不熟的第三方的SDK呢？ 别人接手你的代码之后呢？ 别人需要改你的代码的时候呢？ 你的文档不全的时候呢？ 你的文档虽然全 但是没及时更新时呢？

我觉得有太多的人对编程工作不严肃不职业，仅仅满足于“我的代码今天下班前如我所希望的那样工作了”，

这样的程序跟大四学生做的毕业设计有什么本质区别么？

---

liyin...@gmail.com

 

发件人： Bo Yang

发送时间： 2015-11-02 15:57

收件人： agilechina

主题： Re: Re: [agilechina] 幻象和敏捷

[Aska]

其实你们两个说的没有太大矛盾，只是基于不同的前提提出的不同的观点。

kent beck在stackoverflow上回答“单元测试该写到什么程度”的时候说：我拿钱是为了写程序的，而不是写测试的，所以我的哲学是写尽量少的测试代码，只要我对我的代码有信心(当然他的标准高于行业平均水平）。

但是，这句话的前提是仅对kent beck有效，或者仅对专业的programmer有效，每个人的个人能力都是不一样的。这句话不应该成为一些初级程序员的借口：你看TDD之父自己都不怎么写测试，TDD已死！这些人就是你说的不严肃不职业的码农。当然，可惜的是，这群人占大多数，还有劣币驱逐良币的趋势。

[Bo Yang]

你这语气。。麻烦不要假设我是你公司里的员工好不好。我只是说了我所喜欢的做法和背后我认可的逻辑，至于在你那儿行不行得通，那可不是我关心的。

我觉得我说得已经很清楚了。实际操作的人应该知道自己做的每个决定所产生的收益和对应的成本，以及各种因素之间的相关性和约束。如果是leader还应该了解团队的水平和习惯。但说实话，无论用不用TDD，写多少单元测试，如果某个人写的代码质量一直不咋地，解决方法应该是开导(掉)他。不要告诉我你没法知道他代码不行哦。

    致
礼

杨波

[Glen Wang]

创业靠英雄（和运气），守成和基业长青靠系统，丰田是最好的例子。

---

Date: Mon, 2 Nov 2015 17:04:45 +0800
Subject: Re: Re: [agilechina] 幻象和敏捷
From: yab...@gmail.com
To: agile...@googlegroups.com

[liyin...@gmail.com]

你想多了，这里只是开放的讨论交流想法，你不妨直接回答下我质疑的那一串问题，

说不定这些问题可以帮把你的决定的成本收益弄得更清楚。

---

liyin...@gmail.com

 

发件人： Bo Yang

发送时间： 2015-11-02 17:04

[Glen Wang]

大学之道，在明明德，在亲民，在止于至善。

知止而后有定，定而后能静，静而后能安，安而后能虑，虑而后能得。物有本末，事有终始。知所先后，则近道矣。

古之欲明明德于天下者，先治其国；欲治其国者，先齐其家；欲齐其家者，先修其身；欲修其身者，先正其心；欲正其心者，先诚其意；欲诚其意者，先致其知。致知在格物。物格而后知至，知至而后意诚，意诚而后心正，心正而后身修，身修而后家齐，家齐而后国治，国治而后天下平。自天子以至于庶人，壹是皆以修身为本。

其本乱，而末治者否矣。其所厚者薄，而其所薄者厚，未之有也。

天命之谓性；率性之谓道；修道之谓教。

道也者，不可须臾离也；可离，非道也。是故君子戒慎乎其所不睹，恐惧乎其所不闻。

莫见乎隐，莫显乎微。故君子慎其独也。

喜、怒、哀、乐之未发，谓之中。发而皆中节，谓之和。中也者，天下之大本也。和也者，天下之达道也。

致中和，天地位焉，万物育焉。

[皮宏宇]

求翻译成Java  或者C#

-- 

[Bo Yang]

可以不吝赐教吗？当然不说也无妨，我并不怎么需要点拨，我的环境我很清楚。

我是真的没这么空，在网上和人讨论太过细节的东西。你说的回避重构啥的，其实是因为根本不在(我预定)的讨论范围内。

当然你可能认为在夸夸其谈。那也随意。对我也没有影响。

    致
礼

杨波

[刘松]

这群平时没话题，一来话题就是各种执念和洪荒之力，不过内容够精彩，每发必转。

我较赞同杨波，关于手段和目的之说，很清楚。

孙子说：兵无常势，水无常形。

老子说：为学日益，为道日损。损之又损，以至于无为。 无为而无不为。

Glen Wang的观点，是不是可以解释成，重构和TDD是守城术，像加固城墙，挖大沟一类的技能？在攻城方，这玩意派不上啥用场，还是搞点投石车、云梯一类的实惠？

那么，看到攻城的不加固城墙，咱就不应该指责他对攻城事业不严肃不职业了哈。当然，军事牛人好多是能攻能防的。曾国藩那种攻城前先修防线的，当时也是遭左宗堂等人鄙视的，不敏捷呗，但好歹够勤奋。

[刘松]

"况且退一百步说，就算你写的东西半年后就会丢弃，你也没有因为偷工减料而节省你的时间和生命，"

半年才丢的代码，得多幸运啊。我见过太多几个月就丢的代码，给它们写一堆测试代码真的有用吗？

[Harrison Yao]

看大家讨论如此热烈，我也来叽歪几句。

首先，BAT的公司，不是不讲究单元测试的，这个需要明确的指出，很多项目团队或者产品线，甚至严格了发布时的单元测试分支覆盖率。但非核心业务尤其部分现在来看有些鸡肋的业务线，没有明确的单元测试覆盖率要求，但也都尽力鼓励大家去写单元测试。就像maillist中有同学所说，让自己第一时间收到靠谱的反馈，一样的道理。

其次，TDD确实应用比较少，我也只是在几个项目中实践过，自己体会确实能让设计更清晰，确实是好方法。但是，放在团队里面，如果团队的平均水平比较高、有比较好的基础、且业务团队风气较好、同时业务线也不以产品上线时间为第一要素的话，确实能起到很大的作用，大家的反馈都会很爽。否则，可能产生的代价也是一个项目经理或者架构师不愿意看到的，还不如节约时间事前多设计讨论确定细致，再动手干活，尤其在几十人同时做一个项目，宁可大家事前做好所有关键性的设计，细化所有接口，交给初级或者中级的工程师去实现。

最后，赞同一个观点，任何方法都不是唯一产生决定性作用的方法，包括敏捷方法，也并不是你应用了scrum或者xp、kanban中的某一个方法就算是敏捷了，它只是一个反思，让工程质量、效率、参与人员的感受度上达到一个最佳平衡。就像code review不能取代UT是一个道理，往往需要根据团队整体的成员技术情况、业务线的特点进行选择。

另外，BAT的资源丰富度确实不是普通小创业公司所能去企及的，小创业公司更多需要根据当下团队内部的认知水平，去整理合适的方法。我自己就曾经偏激的应用kanban／scrum、TDD、CI、codereview等多种方法，最后实践下来，我只保留了CI。但这不代表我不追求UT，我还是会引导我的团队慢慢提升自身技能，走向UT、TDD等等。

Thanks,

——————————————————————————

Technologies make tomorrow better ~!

[Vincent Lee]

“节约时间事前多设计讨论确定细致，再动手干活，尤其在几十人同时做一个项目，宁可大家事前做好所有关键性的设计，细化所有接口，交给初级或者中级的工程师去实现”

这已经让我无力吐槽了，完全跟敏捷是反着来的，就算不提敏捷，你们不觉得这做法基本等于文档驱动了么？（我理解你说的“事前做好所有关键性的设计，细化所有接口 ”指的是文档）

在现实工作中当然有各种实际情况 让我们有各种理由去违背敏捷实践和原则，但是请不要自欺欺人说这也是OK的，

就好比我今天吃了垃圾食品，晚上也犯懒没做有氧运动，我会对自己说这对身体有害，我不会骗自己说这没什么问题。

[Vincent Lee]

问个问题：代码几个月就被丢弃 这个事实，更多的是不写UT的结果呢 还是 不写UT的正当理由？

有个陷阱叫自我实现的预言：

* 这个小项目 估计行不通，大概几个月后就丢弃了；

* 没必要花太大代价，快速垒起来就好了，先不写UT了，更没必要重构，快速迭代嘛；

* 很快开始闻到代码的味道了，我忍，几个月就过去了嘛；

* 捏着鼻子开发，团队里开始产生厌倦和抱怨，尽快把那些PM的想法交付上去；

* 慢慢的对这个项目失去激情和兴趣，做出的东西也就那么回事儿

* 终于有一天公司失去耐心，放弃这个产品

* 你看吧，每次都是这样…… 我就知道。

我在这里不负责任的估计，这世界上曾经有一百个本可以成为各自领域 行业的“微信”、“Oracle”、谷歌那样的产品，

它们的设计创意都很好，但是不幸的它们的程序员不写UT 很少重构，结果在它们发展到一定规模的时候，由于技术债增长过快，早早的陷入了软件工程的焦油坑，

在离成功临界点就差一步的时候，它们的组织没能挺过去，由于一个重要特性没能及时的发布，失去了一笔重要的融资…………

然后这个产品被丢弃了，团队解体了，它的开发人员摊摊双手：这本来就行不通嘛，没关系，至少我们快速的试错了，还好没浪费太多精力在上面……

[Joseph Tseng]

产品的成功还有很多其他因素, 所以这个[自我实现的陷阱]没法证实也没法证伪.   所以只是一种信仰咯

Joseph Tseng

[Vincent Lee]

敏捷的很多实践都是相互影响的，比如ci ut 和重构，尤其单元测试和重构，

因为没有足够的测试覆盖度就没法安全的重构 等于难以重构(当然如果单元测试写的不好 太脆弱 也会妨碍重构 这是另外一个问题)。

高质量代码当然不是只靠单元测试带来的，

但高质量代码一定是不断重构才保持了高质量 并且靠ci不断运行自动化的单元测试 保证质量没有被破坏和衰退(回归测试也译为衰退测试)。

几个月后就丢弃的代码 就不需要ut和重构了么？ 

这根本是个伪问题，是自我实现的预言陷阱。

资源有限 时间紧，还需要ut和重构么？ 

废话，你以为敏捷实践是没事儿闲的时候发明出来的么？

团队水平参差不齐，推不下去啊！
那就手把手教 结对儿带。（测试加入考核 跟把源代码行数作为KPI一样愚蠢）
 太麻烦？那活该你加班 被客户骂 写的东西几个月后就被丢弃

[Bo Yang]

不知道怎么回复到个人上去了。可能是因为翻墙没弄好，图标都没图点错了。

---------- Forwarded message ----------
From: Bo Yang <yab...@gmail.com>
Date: 2015-11-04 12:40 GMT+08:00
Subject: Re: [agilechina] 幻象和敏捷
To: liyingquan <liyin...@gmail.com>

我说什么好呢？你好像不是在对我说话，而是对着一个你想象的“我”说话。你可以从头把帖子过一遍么？我真怕你连个我的观点都总结出来，为方便旁人，我来吧——UT是很好，然而不是圣经，自己看着来。忽然间想到， 平均一个创业企业活多少年？

你说“没有足够的测试覆盖度就没法安全的重构"，可是”足够“是你来定的么？我的项目我不比你清楚？当然，这个点靠 口水是没有什么结论的，只能看看项目的生存状况。然而即便如此也不能证明什么，只能是经验结果。我说不讨论细节，你认为这也算 细节的话那就不谈了——这里哪段 回复很长吗？哪儿 细得起来。

最后最后，结果论而言，我既不加班也没被客户骂。当然写的东西也没有几个月就丢，这本来就不是我说的话，不知道怎么算我头上了。然而就算真出现这种情况，客户OK我OK公司OK，你管得着么？想试验点新东西时，例如新的一套框架组合，发现思路不对整个扔了重来，不比重构啥的成本低多了？当然又可以有“拿大量上班 时间让你个人搞研究啥的不是时间很紧”的质问出来，那回答就两个字——呵呵——我可以干，你管不着。

    致
礼

杨波

2015-11-03 20:52 GMT+08:00 liyingquan <liyin...@gmail.com>:

一边说自己没空，一边又写这么一段没啥营养的文字。哎，虽然你不需要，但可以借着回复你说给需要的人吧:

敏捷的很多实践都是相互影响的，比如ci ut 和重构，尤其单元测试和重构，因为没有足够的测试覆盖度就没法安全的重构 等于难以重构(当然如果单元测试写的不好 太脆弱 也会妨碍重构 这是另外一个问题)。

高质量代码当然不是靠单元测试测出来的，但高质量代码一定是不断重构才保持了高质量 并且靠ci不断运行自动化的单元测试 保证质量没有被破坏和衰退(回归测试也译为衰退测试)。

几个月后就丢弃的代码 就不需要ut和重构了么？ 这根本是个伪问题，是自我实现的预言陷阱。

资源有限 时间紧，还需要ut和重构么？ 废话，你以为敏捷实践是没事儿闲的时候发明出来的么？

团队水平参差不齐，推不下去啊！

那就手把手教 结对带。
 太麻烦？那活该你加班 被客户骂 写的东西几个月后就被丢弃

---Original---

From: "Bo Yang "<yab...@gmail.com>

Date: 2015/11/2 18:02:23

To: "agilechina"<agile...@googlegroups.com>;

Subject: Re: Re: [agilechina] 幻象和敏捷

[Bo Yang]

技术债技术债，人一辈子借点钱再稀松平常不过了。我现在认为创业公司欠点技术债才是正确的策略。至于公司活下来了，是否会有人有意识把债还上就是另一码事了。这个其实很难，因为什么样的人做什么类型的事，人本身的认知和人的屁股坐在哪里决定了人会怎么做。但这不影响前期策略该怎么选择，策略的选择永远只涉及问题本身和资源。

    致
礼

杨波

[Jeff Xiong]

打个圆场……很多公司/团队/产品确实不敏捷，并且不敏捷也确实是他们没做好的重要原因之一。但是这个不敏捷，很少体现在代码上，更多是体现在idea的反馈周期太长。精益创业讲build-measure-learn，我见到太多的团队做一个东西做半年，一直在build，没有任何真正的用户用到，更不要说measure和learn。这样的东西，怎么会不失败呢？代码写得再好又怎么？你稍微往后站几步，像这种假迭代、假敏捷，idea本身的hypotheses几个月没有任何验证，这样的事情太多了。你在这么一个项目里面讲代码写得敏捷、故事卡管得敏捷，有啥用呢。

那么真正在build-measure-learn的团队，他首先是要验证一个“problem-solution match”，即第一确实有这么个问题存在，第二我的解决方案确实能解决这个问题。那么在这个阶段他需要的东西，确实是很快的，确实是用完就扔的，确实不咋需要高质量。这个阶段基本上也就相当于天使投资轮。我甚至有个激进的观点：这个阶段根本就不应该写代码，而是应该拿起一切手边能用的东西，走通一个流程来验证problem-solution match就行了。

走过了这个阶段，下一个阶段就要验证一个“solution-market match”，即第一确实有人愿意花钱解决这个问题，第二愿意花这个钱的人还不少。那这个阶段就需要scale了，系统的各种内部外部质量也变得重要了，数据也不能随便说丢就丢了。这个时候才开始需要传统意义上敏捷的工程实践。

那么我们在讨论“创业公司”、“互联网公司”如何如何的时候，我觉得有必要说明一下：讲的到底是哪个阶段的公司/团队/产品，它这个阶段到底是在验证problem-solution match，还是在验证solution-market match。

P.S. 关于敏捷/精益在现代的互联网环境中应该如何应用，强烈推荐Jez Humble的新书《Lean Enterprise》。

[liyingquan]

行了，这个架没白吵，引出gigix这番精彩点评。 
受教了，本质还是快速反馈啊

---Original---

From: "Jeff Xiong "<gigi...@gmail.com>

Date: 2015/11/4 13:30:13

To: "agilechina"<agile...@googlegroups.com>;

Subject: Re: [agilechina] 幻象和敏捷

    致
礼

杨波

不知道怎么回复到个人上去了。可能是因为翻墙没弄好，图标都没图点错了。

    致
礼

杨波

[Aska]

确实，很多公司，不管是国内还是国外的公司，不管是标榜自己敏捷还是不敏捷的公司，都容易陷入这个“build trap”之中，不停的build build build，却不去验证是否在build the right thing。在这种情况下，去探索是不是有UT有TDD有Scrum没有太大意义。因为现在反馈的cycle还没有到编码与UT的级别。

另外，我个人认为哈，我们作为敏捷的实践者，要注意避免成为敏捷狂热者，认为任何“不敏捷”的行为或实践都应该被“净化”。这是我们之中很多人容易走的弯路，我以前也走过。现在我的心态平和了许多，始终保持open的心态，才能更让别人接受自己的观点，也更容易影响别人。

[Joseph Tseng]

同意这样非常务实的态度.   其实对于产品成功, 外部的用户价值的验证, 比内部质量更为紧迫和重要. 很多团队都没做好,这才是更大的浪费.

Joseph Tseng

[Harrison Yao]

To Vincent, 

呵呵，你的臆想完全误解了当时的实际情况和我所想表达的内容（可能我没做背景铺垫，误导了你，抱歉），当一个团队七八十个人横跨九条业务线，各自对其他人的业务不甚了解的时候，你如何去单凭早上的站立例会完成沟通、同步项目现状？你如何做到设计不会产生对他人的影响？

我理解的敏捷原则和实践不是形而上学的临摹，更应该是内在精髓的把控，当一个项目团队过大，本身在进行项目管理的时候，不需要照搬所有文字上的条条框框，更应该灵活应用。把一个大项目拆散成多个子项目，项目涉及业务线的架构师自发形成架构团队，每日加强沟通，并形成关键设计的记录，把最重要的点传递给自属业务线，让所有人知道自己的代码和设计可能会影响到别人的那个部分，难道这就是违背敏捷的原则了么？

当一个团队的沟通成本成为一个项目最大阻碍的时候，为什么不能让简单的文档、大家都能理解的图表去打消一些不必要的沟通误解？ 

我是在实践了两年以后才去参加Scrum培训的，那个时候我问我的导师 Alen (圈里的朋友应该都知道他) 是不是一个组织完全应用了scrum的所有方法就是成功的scrum 组织，他给我的回答是否定的。他告诉我说（语言问题，不述原话，仅作语义的阐述），任何经验的获得以及方法的总结，都是有前提、有场景的，敏捷方法建议团队人数不要太多，但并不代表大团队就不能应用敏捷思想和scrum的一些方法，更不能说团队一大，就不敏捷。有的团队虽然每天早上开站立会议，但没有实际作用和效果，他也一样不能算成功的方法应用，所以找到适合自己团队的内容，根据团队的实际情况去加以约定，用敏捷的思想和方法变通的应用进去，只要达成时刻能交付有价值的产品、团队成员都有成就感、相比以前的情况节约了时间和成本，那就应该是成功的敏捷团队。所以，“好的沟通胜过面面俱到的文档”这句话，我的理解是：根据团队成员结构和实际项目情况的需要，保留必须的文档，同时加强有效的团队内部沟通，并非形而上学的摒弃文档。

小的时候热衷于武侠片中所描述的各位大侠，身怀绝技、飞檐走壁，一个人一口气能吹翻360度几十个清兵、宋兵（奇怪，影视剧为啥很少涉及宋明清之前的武侠作品？），对大侠们的武术招式也深感神秘，在大院里其他孩子面前，属于典型的武侠迷，身后也常常跟着一堆穿着开裆裤就跟我装模作样的小屁孩。后来影视剧作品看多了，发现越来越多的作品中对于一个大侠的描述不再是一个人勇闯天涯式的英雄，发现大侠也会遇到困境和磨难，也会受伤，而且往往在经历诸多磨难后，总结的答案就是 “此时无招胜有招” 或者 “手中无剑 但心中有剑”式的一招鲜，在经历大结局的最终对决时，结果往往都如同 “大侠披风一挥，向远方走去，消失在屏幕下方，唯留下重伤不治的败寇，或伏地作揖，或血洒疆场”的表现手法。

这些内容如同最近大家在讨论的东西一样，UT、TDD、CI等等技术手段，都不是唯一决定项目成败的关键，也不是唯一决定某个团队牛X还是傻X的因素，工具始终是工具，可以利事也可以坏事，关键让每个人找到合适的方法，在一个普遍具有一定意义的情况下，去适时的尝试、改进自己的方法，以实现最终目的——随时交付有价值的产品

个人拙见，还请轻拍....

Thanks,

——————————————————————————

Technologies make tomorrow better ~!

[Harrison Yao]

赞同 Jeff的观点，任何方法都离不开 build-measure-learn这个内容，任何工具也都是为了实现build-measure-learn而产生。

Thanks,

——————————————————————————

Technologies make tomorrow better ~!