我看“敏捷”

总体而言，“敏捷”就是一个bizword，几个定制开发项目的公司和技术咨询公司所创造的“蓝海”。

这其中有意无意的忽略了一些关键环节，有些地方很恶劣。比如业务，将因为自己业务经验的匮乏，所带来的项目需求变更和交付期延长等风险，全部转嫁给客户。我们假设自家装修，施工队说你怎么说我怎么做，之所以没有做是因为你当初没有说，如果要改，需要另外付钱，会是什么心情。

同时，除了FDD这样的方法论，有一个完整的过程来支撑外，其它的都是一些成功实践，也就是一些经验之谈，容易让学习的人混乱，角色要哪些，日常怎么来管理？在具体的术上，确实有很多优秀之处，但是所处的层次不是在整个项目上，毕竟开发只是项目实施的一个环节，并不是整个的项目。但是一旦要提过程，我估计是自己打自己耳光。

因为含含糊糊的隐瞒了一些东西，使人无法知道过程优化和改善的方法和指标，这与制造业的敏捷无法同日而语。

想起一个讲咨询培训的策略，“励志、颠覆、速成、炒作”，敏捷方法有点这个意思，我觉得还要加一个“仪式”。过一段时间找个东西出来包装，Scrum把任务和会议管理包了包，不知道下一个目标是什么。

评论

42 楼 JavaInActoin 2010-11-25  

把敏捷中的部分实践当作RUP的补充就好了，哪些实践有用，要看具体什么项目。

41 楼 RCFans 2010-11-20  

我在业务梳理中的地位比较高，直接会议对象是业务部门副总、主管，因为在这里重点是说开发团队的组织，所以其它工作没有提及，这方面的我想还是等项目结束的时候专门开个贴总结。

有一点就是，业务梳理和技术团队的工作是两条线在走，工作项和产出都不纳入Scrum的看板中。

40 楼 一蓑烟雨任平生 2010-11-20  

RCFans，架构设计是你这个项目的首要目标么？如果是的，那么你的做法无可厚非。

如果你做的是个业务系统，如你所说领域驱动，我想你应该梳理一下业务的分析设计在你的过程中是什么位置，会是一个什么样的过程，核心业务的设计和开发是如何来做角色组织和协作等等，这样才算完整，单纯讲开发组的工作意义不大。

我是一个唯业务论者，业务的成熟度决定开发采用什么样的过程方法。很多业务的核心项目，不是什么时候都可以边干边改。现在的很多敏捷方法是唯技术论的，比较符合技术人员的口味，但不是项目这个层面，拿着这种方法去做项目，将业务成熟这个条件刻意淡化的后果可想而知。

业务系统项目失败从我的经验看，技术原因的很少，问题最大的是两类，一个是没有业务经验，一个是项目体制混乱。

Mouge，项目实施过程中，要把握好哪些是不能变，哪些可以小变，哪些可以在什么期间变，而不是无所谓，想怎么变就怎么变。

你不是变形金刚，公司掏钱雇你，客户掏钱给公司，不是没有原则和底限的。如果有些环节不先做好整体的规划和设计（业务的分析和关键业务规则的详细设计），你再敏捷，技术能力再强，也还是会项目延期，然后将课题抛给客户，说客户没说清楚或者说客户业务在变。每个人对可控制的变化是很少的，只有能控制住大部分，才能对小部分的变化做调整，否则就是失控。

现在的敏捷方法有价值的部分，是在配置管理上，怎么用很好的技术手段来应对变化，但这只是项目成功实践的一部分。是的，我们可以应对变化，但我们为什么不想想，为什么会有这么多的变化？

39 楼 RCFans 2010-11-20  

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

38 楼 mouge 2010-11-20  

daquan198163 写道

一蓑烟雨任平生 写道

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

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

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

正解

37 楼 mouge 2010-11-20  

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、对于大项目的敏捷做法，目前还缺少很好的工程实践。如果想用敏捷的做法自然形成大项目的架构，我想还是需要慎重

36 楼 RCFans 2010-11-19  

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中，这样，至少大部分的结构是优秀的，不断改善的。

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

35 楼 一蓑烟雨任平生 2010-11-19  

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

34 楼 RCFans 2010-11-19  

daquan198163 写道

一蓑烟雨任平生 写道

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

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

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

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

33 楼 一蓑烟雨任平生 2010-11-19  

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

32 楼 daquan198163 2010-11-19  

一蓑烟雨任平生 写道

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

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

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

31 楼 一蓑烟雨任平生 2010-11-19  

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

30 楼 mouge 2010-11-18  

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

29 楼 RCFans 2010-11-13  

目前正在一家甲方公司担任部门经理，商业平台型的系统，以项目的形式进行实施，正在实践敏捷。

我的看法是：无论是软件工程也好，还是敏捷、Scrum也好，还是其发起者的“动机”也好，都只是一些软件生产模式，就和哈佛商学院产出的各种商业模式一样。项目的各种资源掌握在我们的手上，如何用，首先了解现有的各种运用模式，其次是实际的各种背景和影响力，先运用一切可用的，最后再来看怎样可以改进方法论。

比如“与制造业的敏捷不可同日而语”，那么差别在哪里，怎样可以借鉴提升？记住，我们不是评论家，我们是实践者。

28 楼 xuzhfa123 2010-09-20  

Durian 写道

对结对编程（Pair-Programming）不太感冒。
本人有洁癖，只对自己代码负责，不让别人动，不让别人思想支配。

你还没有跳出你自己的圈子

27 楼 xuzhfa123 2010-09-20  

方法论并不是什么场景都可以使用的，有约束条件。敏捷方法论只能用来借鉴，否则就是玩过火了，那样使得其反。三个人十来条枪你搞结对，你不是瞎扯。

26 楼 abraham_xi 2010-09-17  

也有适用范围，限制条件

25 楼 kitt1987 2010-02-23  

我没有别的意思，只是说说自己的看法。至少楼主还不知道敏捷是什么。你说的那些都只是被大家神话了的一些敏捷实践，这些永远都只是表面的东西。如果你真的敏捷了，你就有胆量抛弃这些你看来并没有太大意义的方法，而去选择一些真正对你有用的方法。另外，不要武断的说某个东西好还是不好、有用或者没用，即使不能实践也要稍微思考下，这也是敏捷的一部分。大家都说敏捷已经被说烂了，我很无语。

24 楼 tuti 2010-01-26  

Durian 写道

对结对编程（Pair-Programming）不太感冒。
本人有洁癖，只对自己代码负责，不让别人动，不让别人思想支配。

你实际做过“结对编程”吗？

23 楼 iamlotus 2010-01-20  

Durian 写道

对结对编程（Pair-Programming）不太感冒。
本人有洁癖，只对自己代码负责，不让别人动，不让别人思想支配。

那是你没碰上适合讨论的人罢了。