我看“敏捷”

用传统的眼光去看新事物，永远都是错的。
当你不知道怎么样把一张纸从杯底下抽出来时，你一直认为慢慢拉才是硬道理，这种想法可能持续到当你理解牛顿第一定律后，转身飞快地抽出这张纸时，你终于觉得慢慢拉只是一种笨办法。敏捷也一样，它要你抛弃很多你认为“正确”的做法，比如放弃设计，编码，测试的顺序，而去接受TDD，你能做到了吗？

没看明白楼上说的意思，“放弃设计、编码、测试的顺序，而去接受TDD”，这个设计是指什么？

他是说放弃以前那种Big Design Up Front，敏捷讲究演进式的设计，以此类推，对于编码和测试也是类似的态度，
设计、开发、测试的循环周期变得很短，短到几分钟一次循环，前一分钟还在设计，然后就用测试来反映这个设计的接口，然后下一分钟实现。
这里的设计也是很轻量级的，可能只是在白板上画几下，或者索性直接用代码来表达设计。

我觉得这个是最难越过的心里障碍，尤其是对应很多经验丰富的所谓资深人士。

有在白板上画几下就可以编码的设计？既然存在，那是什么样的场景？能否具体一些，我现在觉得我们说的可能不是一回事。

，我们就是这样做的，演进式架构设计。这样做的好处是最终我们得到的是一个最合理、持续改善的架构，以及准确的说明书。

RCFans，你还是没说清楚，你说的设计，是什么内容，而且设计的结果是什么？架构？说明书是什么？跟打拳说的是一回事么？

http://www.iteye.com/topic/786328

你可以看看我这个贴子，直播中，本周末我争取写更详细的东西出来。

简单地说，就是整个完整交付品远超开发团队交付能力的情况下（我相信大多数时候都是这样的），如何去尽可能准时交付并且保障交付品的功能满足及良好的设计，还有质量的保证。

对传统的开发过程，项目中往往会有权衡之事发生，最常见的就是，管他三七二十一，我们把功能实现了就行了，先不管架构、质量，整一个可以跑的东西出来，整上线再慢慢来修修补补。这种情况导致的最恶劣的后果就是质量问题导致不断延期，架构的不合理导致整套系统的生命周期很短。

对一个成熟的敏捷团队的开发过程，如采用Scrum的模式是，我们会在第一时间编写产品积压事项（Product Backlog）来代替传统的需求用例，然后根据Backlog的优先级、依赖顺序进行分组，划一个时间周期为一个Sprint，将一组Backlog加入到这个Sprint中形成Sprint Backlog，指定Backlog负责人、开发人员，开评估会议，定义每个Backlog如何分解成8小时一份的Task来进行完成。每天的状态会更新在看板上，遇到的问题被标记为阻碍Backlog，一个Sprint的目标，就是消灭所有的Product Backlog和阻碍Backlog.

再说一下架构设计方面。在这个开发过程中，没有架构设计的概念。是因为：
1.我们默认我们无法提出良好的架构——通常这样的系统由很多子系统组成，在Project Architecture这一级设计上，我们仅仅提出“我们将采用分布式架构设计，子系统各自的数据库不允许外部子系统直接访问”这样一个概念，除此之外，定义采用何种平台、何种语言、开发环境、发布环境和数据库类型等等，物理架构基本上可以定义，逻辑架构出一个轮廓。无文档产出，无签字确认。
2.在Application Architecture这一级别，我们会定义采用什么样的设计方法，如我们现在的一个业务系统，我们采用领域驱动设计的方法进行设计和开发。在这个过程中，我们发现以前对分布式架构的“如何分布式”的认知有一些偏差，于是，我们在这里将“如何分布式”定义得更准确了，我们将基于业务重用度而不是“隔离应用操作”来定义分布式架构，从另一个角度上来说，我们把整个构架从物理部署上演进到了逻辑应用上，但之所以可以改变的原因是我们是增量交付，架构部分没有文档需要修改，也没有具体的项目解决方案需要重写。
3.持续重构。在我们这个项目中由于时间比较紧，每次我们只会做最关键的重构，而把更新的设计思路体现在下一个Sprint中，这样，至少大部分的结构是优秀的，不断改善的。

目前项目还未进行到一半，欢迎批评指正。

1、恰恰重要的是，持续重构是敏捷的关键，它的目的是提高代码的健壮性，随时保持对变化的响应。而并不是“由于时间比较紧，每次我们只会做最关键的重构”，如果这样理解敏捷，只能说你没有理解敏捷的本质
2、Sprint,积压事项（Product Backlog）只是一种项目管理中任务处理方法，它不但和捕获用户需求的用例方法是两码事，也与敏捷也没有太多关系，不采用这种方法的敏捷团队多的是。并且，有积压事项工具并不意味着质量问题和项目延期问题就自动消除。
3、我倒觉得你所说的“管他三七二十一，我们把功能实现了就行了”却是真正的敏捷做法，但紧接着就需要立即“测试，重构”来完善代码。其实所谓的敏捷就是“修修补补”，它不但不会导致质量下降，而且会更贴近用户需求，适应变化。
4、对于大项目的敏捷做法，目前还缺少很好的工程实践。如果想用敏捷的做法自然形成大项目的架构，我想还是需要慎重

正解

mouge，很遗憾，我不会采取你提出的所有建议。