agile

这篇文章主要来源是StackOverflow上的一个回答——“How deep are your unit tests?”。一个有13.8K的分的人（John Nolan）问了个关于TDD的问题，这个问题并不新鲜，最亮的是这个问题的Best Answer，这个问题是—— “TDD需要花时间写测试，而我们一般多少会写一些代码，而第一个测试是测试我的构造函数有没有把这个类的变量都设置对了，这会不会太过分了？那么，我们写单元测试的这个单元的粒度到底是什么样的？并且，是不是我们的测试测试得多了点？” 答案 StackOverflow上，这个问题的答案是这样的—— “I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but tha ...

【感谢 @常新居士 投递此文 】 这几年，持续集成随着敏捷在国内的推广而持续走热，与之相伴的持续部署也一直备受关注。自前两年，持续交付这个延续性概念又闯进了国内IT圈，慢慢开始在社区和会议中展露头角。许多不明真相的群众跟风哭着喊着要“上”，而许多前CI的半吊子玩家换件衣服就接着干，有的甚至衣服都来不及换……。国内的这些土财主如果不巧请了某些所谓的战略家，除了建了一堆持续集成环境，以及每天嚷嚷着要这个要那个，混乱的状况在根本上没有得到改善。本文无意费力探讨持续集成和持续交付的概念，而是打算谈谈对于大型软件企业，以持续集成为基础实现持续部署（交付）时，所要面对的问题以及可行的解决方案。地主老财们，夜黑风正猛，山高路又远，注意脚下…… And God Said, Let there be light: and there wa— GENSIS, Charpter 1, King James 目录 一、起步 1.1）编译时依赖和运行时依赖 1.2）依赖时的复杂度 1.3）任务分工 1.4）自动化部署 ...

自从我发布了“Scrum为什么不行”，并被CSDN推成首页头条后，我在我的新浪微博上就经常被敏粉们@去讨论他们的一些话题。他们似乎想要从我这里听到一些不同的声音，我很喜欢他们的这种态度，在这里先赞他们一个。既然，让我来评论他们的东西，我就不客气了，板砖自然是少不了的。 我觉得我在微博上的观点比较散，所以在这里做一个汇总。我在所有批评敏捷的文章里都重复说过我的立场，这里还要再说一遍，因为那群人很敏感——“我承认敏捷中有一些东西我是认可的，但对敏捷社区的推广和思维方式我持否定态度”。 目录 敏捷词汇表 敏捷宣言 博文评论 后续 糊弄客户？ 敏捷词汇表 我被@吴穹adam邀请进入了一个敏捷词汇表的微群，这个群就是想明确的定义一下敏捷的各种词汇，比如，他们想把TDD定义成就是UT。呵呵。我对这个群仅保持了30分钟的热度，我在里面发了一个“你们不想讨论技术吗？”的帖子，就再也不想关注了。因为我的观点如下： 我不知道干这件事有什么意义。标准化还是洗脑？One World, One Agile?  – horse sh ...

这篇文章的原文在这里（原文链接）（下文不是全译，也不是部分译，我只是把其总结，有我自己的发挥，但是原意大致不变），这篇文章完全是在调侃Scrum的，作者第一段就是一个免费声明，其说他是Scrum和其它敏捷方法的big fan， 他也认为Scrum 100% 对 软件开发可行。作者使用Scrum 5年了，也公开作过几次敏捷的分享会。他觉得写这篇文章只是为了好玩，因为他们戴上Edward de Bono 的 black hat （黑礼帽 – 是6个思考之帽中的一种——负面思考，思考事物的负面因素，这样才知道：它会起作用吗？缺点是什么？它有什么问题？为什么不能做。） 因为本人经常站在Agile的风口浪尖，所以我有必要也来一个“免责声明”。Shit！其实我想来的是“不免责声明” ——下文中的九大原因是对中国的各种Agile实践者咨询师不注重实际只重方法论的批判，本人必然要和那种只以流程方法论为中心的软件开发斗争到底。其实我没有那么嚣张，我只是想说，下面的这些东西相当的现实。希望各种Scrum的实践者们认识到这些问题，从而可以让你们明白软件开发中的人的重 ...

下面的文章转自Todd Wei 的《TDD到底美还是不美？》，对于这篇文章，我个人能过透过作者的观点感受到他的项目中使用TDD的难点，同样可以感受到作者内心的纠结。不管怎么样，我能够感到作者Todd Wei在独立思考，独立思考总是好的，因为那是走向成熟的必要条件。(另，大家可以移步过去看看相关的评论，挺有意思的) ———————————————————————————————————— 最近CoolShell上的一篇《TDD并不是看上去的那么美》引起了敏捷社区的高度关注和激励辩论。今天，InfoQ甚至专门举行了一个“虚拟座谈会”《TDD有多美？》，几位国内敏捷社区的名人专门就此问题展开了深入地讨论。不论结果如何，这个纯技术的探讨精神还是非常值得赞赏的。事件实际上可以简单地归纳为“一个有一定影响力的开发人员质疑TDD，一群敏捷社区名人对TDD进行解释和辩护”。现在，就让我坚定地站在CoolShell一边，为对TDD的质疑和批判添砖加瓦吧！ TDD的核心理念是什么呢？第一是Specification by Example，即把测试用例作为表达需求的一种方式。传统的需求表 ...

以前给大家介绍过一些非常有意思的杂项资源，今天再给大家介绍一些。（虽然没有上次的多，也算是一个新年礼物吧） 首先，如果你想在你的web页上做一个小提示，你不妨到http://projects.nickstakenburg.com/tipped上看看，各种各样的提示风格，很不错。而且兼容于四大主流浏览器——Chrome, Firefox, IE, Safari。 如果你想让Java变成一个动态语言，你可以试试这个开源项目：http://code.google.com/p/ductilej/ 如果你想把你的Windows蓝屏改成红屏或是绿屏，你可以看看这篇教程：http://blogs.technet.com/b/markrussinovich/archive/2010/12/14/3374820.aspx，还是挺Cool的。 如果你想使用HTML5+Javascript做一个游戏，就像制作这些HTML5的小游戏一样，你不妨考虑使用一下这个游戏框架：http://www.propulsionjs.com/ 如果你想学习Emacs，而又不害怕这样的学习曲线，那 ...

文章来源 – Martin Fowler 和 Neal Ford 在 Paris – USI 2010 的演讲 有很多的书籍讨论敏捷方法是怎样工作的（How it works？），在这个主题演讲中，Martin Fowler 和他的同事 Neal Ford 讨论了敏捷方法能够在软件开发项目中行之有效的原因（Why it works？）。作为敏捷方法的发起人和传道者，Martin Fowler 和 ThoughtWorks 一直试图从理论层面证明敏捷方法的可行性，同时不厌其烦地解答着客户们的各种困惑，正如他们所说，敏捷方法中的很多概念不是特别的直观，除非人们真正实践过一段时间，否则有些概念很难从字面上去完全理解。 Martin Fowler 谈到一个有意思的现象，那就是今天许多人们口中谈论的敏捷方法，和最初的敏捷方法大相径庭，他把这种现象称为“语义扩散（Semantic Diffusion）”，大意是某种思想在传播的过程中，在逐渐扩散的同时，其语义也渐渐变得模糊。在敏捷开发领域里，“语义扩散”导致的一个问题是，在一些使用敏捷方法的项目或者公司中，我们甚至无法辨别出敏捷方法的影子，原因是 ...

结对编程(Pair-Programming)可能是近年来最为流行的编程方式。所谓结对编程，也就是两个人写一个程序，其中，一个人叫Driver，另一个人叫Observer，Driver在编程代码，而Observer在旁边实时查看Driver的代码，并帮助Driver编程。并且，Driver和Observer在一起时可以相互讨论，有效地避免了闭门造车，并可以减少后期的code review时间，以及代码的学习成本。 有实验证明，平均下来，结对编程所花费的时候比单人编程增加了10%，但也会比单人编程减少15%的代码BUG。如果再算上后期代码的维护和学习成本，结对编程比单人编程更有效率，还更为节省成本。无论是对开发团队还是对于Business，结对编程都会是非常不错的Programming Practice。 下面是一些结对编程的优点： 程序员互相帮助，互相教对方，可能得到能力上的互补。 可以让编程环境有效地贯彻Design。 增强代码和产品质量，并有效的减少BUG。 降低学习成本。一边编程，一边共享知识和经验，有效地在实践中进行学习。 在编程中，相互讨论，可能更快更有效地解决 ...