摘要：这是敏捷开发智慧敏捷的第六篇。（之一，之二，之三，之四，之五，之六）写多了，才发现前几篇文章中有几篇都落下个章节，就是除了“看着办”之外的一些常见做法，这里总结一下。所谓常见做法，就是为了防止“看着办”看走了眼，而提前可以参考的方法，可以作为起点，但未必真的正好合适，更很难永远合适，所以不是终点。为了阅读方便，在原文中也添加了，这里仅做归纳。“写不写文档”的常见做法常见的文档虽然很多，但下面几个维度几乎永远存在，具体某个文档通过几个维度的分析，处理方法各不相同：信息长期/短期有效的文档 长期有效比如竞争对手分析文档，架构设计文档，需求管理文档（用户故事），产品路线图…… 长期文档适合详细描述， 阅读全文

摘要：这是敏捷开发智慧敏捷的第五篇。（之一，之二，之三，之四，之五，之六）缘起（立项时）甲：“你们的设计文档打算怎么写？”乙：“到时候再说。”甲：“应该有规范的开发流程和模板，才能写好设计文档。”乙：“预先定义的流程和模板未必适用，敏捷开发崇尚推迟决策，只有在具体工作之前才能决定是否写，怎么写最好（maximizing the amount of work not done）。”甲：“你们组才3个人，能比组织级定义的流程和模板还好吗？”敏捷开发定不定流程和模板？先把话说绝点：敏捷开发不定义流程，不定义模板。为什么呢？因为如果预先定义了流程，比如“必须写需求，需求评审过了才能写设计……先检查测试环境， 阅读全文

摘要：这是敏捷开发智慧敏捷的第四篇。（之一，之二，之三，之四，之五，之六） 缘起甲：“我们每日立会会开不起来。”乙：“嘿，我们每日立会开起来了，而且越开越长了，一开就是1个小时，净是些技术细节。”甲：“别人等着他们讨论，那多耽误时间啊……”乙：“我也觉得是，但是看他们交流得那么热烈，讨论的也是正事，到底应该打断还是不打断呢……”为什么每日立会只开15分钟？我们说绝点：每日立会只能开5分钟，而不是15分钟。这5分钟说点什么呢？应该说必须开会才能说明白的东西。先看两个团队，他们有什么是需要开会说明白的。第一个团队，10个人，平时分工细致，各干各的，谁也不干扰谁。这个团队，开会的时间肯定不短，因为所有交互 阅读全文

摘要：这是敏捷开发智慧敏捷的第三篇。（之一，之二，之三，之四，之五，之六） 缘起甲：“敏捷不应该写架构设计，应该每个迭代都是相同的，才能达到自相似性（这是Ken Shweber说的）。”乙：“如果不写架构设计，很容易返工，早晚还得重来。”甲：“大不了重构，这是敏捷开发重要的实践。”乙：“重构？重构的成本很高的，做几个迭代，后面重构都重构不过来了。”甲：“架构设计写了很容易过度设计，而且在编码的时候还很容易全部推翻重来；。”……这个架构文档要不要写呢？写，为什么？不写，为什么？写，怎么写？不写，怎么不写？为什么敏捷不做架构设计？先把话说绝点，敏捷就是不写架构设计。那为什么不写架构设计？还是为了减少浪费 阅读全文