摘要： 想象我正在往一个已有的代码库中添加新的功能。假如我一次只添加一个小修改，这个小修改是如此简单以至于它只有两种状态——写完代码之后只要看一看，我要么是改对了要么是改错了；如果改错了，我就用另一种方式来修改，后者一定是正确的。 如果我一次不是添加一个小修改，而是添加两个，然后把两个修改放在一起来验证。这时可能的状态就有四种：一种正确的，以及三种不同的出错方式。 如果我再贪心一点（或者是因为某些客观条件的约束），一次添加三个小修改然后再验证。这时可能的状态就成了八种：一种正确的，以及七种不同的出错方式。 所以这就是复杂... 阅读全文

摘要： 导语：用户故事的颗粒度一直是一个谈论已久的话题，但参加了很多研讨会，搜索了很多网络资源后发现一直没有定论，只好在这里原创一下。 前言：为何需要讨论用户故事的颗粒度 其实需求颗粒度的问题由来已久，即使是在传统开发中，也没有提及在需求分析阶段应该把需求做到什么颗粒度才可以开工。所以在下面这些分析之后会发现，其实即使反推到传统开发中，下面提及的方法也依然有效。 为何要对用户故事做一个颗粒度约束呢？ 笔者在开发实践中发现，如果大小不一的“用户故事”堆积在一起，很难看出一个产品到底实现了哪些功能（或一个项目到底有哪些需求）。如果回溯到敏捷 开发的源头就会发现，由于敏捷开发中设定用户故事是为了描述开发.. 阅读全文

摘要： 本文是从 Living in the zone 这篇文章翻译而来。 跟程序员相处你一定会有很多的挫折感。比如，程序员会把能让他们达到最高效率的那种神奇的境界叫做”那里“。 ”那里“是真实存在的。至少对于我是这样的，很有可能你也很熟悉那里，只是情形不一样。对于非程序员的人来说，跟程序员的这种境界相对应的情形是， 当你完全投入进一本书或一场电影，你感觉整个世界都消失了，唯一留下了的只有你正在关注的东西。如果你有丰富的创作力，那有可能是在你写一本书或绘一副画 时候。 当你正全神贯注的读一本书上，有人打断了你，通常这会需要你花很长的时间重回到那种状态。通常，当我在读一本书，有人或什么事情(电话！... 阅读全文