- 浏览: 52368 次
- 性别:
最新评论
-
zwchen:
从技术角度,代码经过3、5年的折腾,基本上腐烂掉,因为最初的架 ...
信息系统之癌细胞 -
eredlab:
看了蛋很疼。垃圾项目就是这样产生的!
项目管理经验的获取 -
duanll:
mercyblitz 写道caoguojian9999 写道r ...
项目管理经验的获取 -
德莫罗:
对抗比尔盖茨的阴谋已经无法购买。楼主是否可以考虑做个电子版出来 ...
我的软件研发和项目管理的图书 -
一蓑烟雨任平生:
你还是看明白我说的话再说什么靠谱。
我的软件研发和项目管理的图书
总体而言,“敏捷”就是一个bizword,几个定制开发项目的公司和技术咨询公司所创造的“蓝海”。
这其中有意无意的忽略了一些关键环节,有些地方很恶劣。比如业务,将因为自己业务经验的匮乏,所带来的项目需求变更和交付期延长等风险,全部转嫁给客户。我们假设自家装修,施工队说你怎么说我怎么做,之所以没有做是因为你当初没有说,如果要改,需要另外付钱,会是什么心情。
同时,除了FDD这样的方法论,有一个完整的过程来支撑外,其它的都是一些成功实践,也就是一些经验之谈,容易让学习的人混乱,角色要哪些,日常怎么来管理?在具体的术上,确实有很多优秀之处,但是所处的层次不是在整个项目上,毕竟开发只是项目实施的一个环节,并不是整个的项目。但是一旦要提过程,我估计是自己打自己耳光。
因为含含糊糊的隐瞒了一些东西,使人无法知道过程优化和改善的方法和指标,这与制造业的敏捷无法同日而语。
想起一个讲咨询培训的策略,“励志、颠覆、速成、炒作”,敏捷方法有点这个意思,我觉得还要加一个“仪式”。过一段时间找个东西出来包装,Scrum把任务和会议管理包了包,不知道下一个目标是什么。
他是说放弃以前那种Big Design Up Front,敏捷讲究演进式的设计,以此类推,对于编码和测试也是类似的态度,
设计、开发、测试的循环周期变得很短,短到几分钟一次循环,前一分钟还在设计,然后就用测试来反映这个设计的接口,然后下一分钟实现。
这里的设计也是很轻量级的,可能只是在白板上画几下,或者索性直接用代码来表达设计。
我觉得这个是最难越过的心里障碍,尤其是对应很多经验丰富的所谓资深人士。
正解
1、恰恰重要的是,持续重构是敏捷的关键,它的目的是提高代码的健壮性,随时保持对变化的响应。而并不是“由于时间比较紧,每次我们只会做最关键的重构”,如果这样理解敏捷,只能说你没有理解敏捷的本质
2、Sprint,积压事项(Product Backlog)只是一种项目管理中任务处理方法,它不但和捕获用户需求的用例方法是两码事,也与敏捷也没有太多关系,不采用这种方法的敏捷团队多的是。并且,有积压事项工具并不意味着质量问题和项目延期问题就自动消除。
3、我倒觉得你所说的“管他三七二十一,我们把功能实现了就行了”却是真正的敏捷做法,但紧接着就需要立即“测试,重构”来完善代码。其实所谓的敏捷就是“修修补补”,它不但不会导致质量下降,而且会更贴近用户需求,适应变化。
4、对于大项目的敏捷做法,目前还缺少很好的工程实践。如果想用敏捷的做法自然形成大项目的架构,我想还是需要慎重
他是说放弃以前那种Big Design Up Front,敏捷讲究演进式的设计,以此类推,对于编码和测试也是类似的态度,
设计、开发、测试的循环周期变得很短,短到几分钟一次循环,前一分钟还在设计,然后就用测试来反映这个设计的接口,然后下一分钟实现。
这里的设计也是很轻量级的,可能只是在白板上画几下,或者索性直接用代码来表达设计。
我觉得这个是最难越过的心里障碍,尤其是对应很多经验丰富的所谓资深人士。
,我们就是这样做的,演进式架构设计。这样做的好处是最终我们得到的是一个最合理、持续改善的架构,以及准确的说明书。
他是说放弃以前那种Big Design Up Front,敏捷讲究演进式的设计,以此类推,对于编码和测试也是类似的态度,
设计、开发、测试的循环周期变得很短,短到几分钟一次循环,前一分钟还在设计,然后就用测试来反映这个设计的接口,然后下一分钟实现。
这里的设计也是很轻量级的,可能只是在白板上画几下,或者索性直接用代码来表达设计。
我觉得这个是最难越过的心里障碍,尤其是对应很多经验丰富的所谓资深人士。
你还没有跳出你自己的圈子
你实际做过“结对编程”吗?
那是你没碰上适合讨论的人罢了。
这其中有意无意的忽略了一些关键环节,有些地方很恶劣。比如业务,将因为自己业务经验的匮乏,所带来的项目需求变更和交付期延长等风险,全部转嫁给客户。我们假设自家装修,施工队说你怎么说我怎么做,之所以没有做是因为你当初没有说,如果要改,需要另外付钱,会是什么心情。
同时,除了FDD这样的方法论,有一个完整的过程来支撑外,其它的都是一些成功实践,也就是一些经验之谈,容易让学习的人混乱,角色要哪些,日常怎么来管理?在具体的术上,确实有很多优秀之处,但是所处的层次不是在整个项目上,毕竟开发只是项目实施的一个环节,并不是整个的项目。但是一旦要提过程,我估计是自己打自己耳光。
因为含含糊糊的隐瞒了一些东西,使人无法知道过程优化和改善的方法和指标,这与制造业的敏捷无法同日而语。
想起一个讲咨询培训的策略,“励志、颠覆、速成、炒作”,敏捷方法有点这个意思,我觉得还要加一个“仪式”。过一段时间找个东西出来包装,Scrum把任务和会议管理包了包,不知道下一个目标是什么。
评论
42 楼
JavaInActoin
2010-11-25
把敏捷中的部分实践当作RUP的补充就好了,哪些实践有用,要看具体什么项目。
41 楼
RCFans
2010-11-20
我在业务梳理中的地位比较高,直接会议对象是业务部门副总、主管,因为在这里重点是说开发团队的组织,所以其它工作没有提及,这方面的我想还是等项目结束的时候专门开个贴总结。
有一点就是,业务梳理和技术团队的工作是两条线在走,工作项和产出都不纳入Scrum的看板中。
有一点就是,业务梳理和技术团队的工作是两条线在走,工作项和产出都不纳入Scrum的看板中。
40 楼
一蓑烟雨任平生
2010-11-20
RCFans,架构设计是你这个项目的首要目标么?如果是的,那么你的做法无可厚非。
如果你做的是个业务系统,如你所说领域驱动,我想你应该梳理一下业务的分析设计在你的过程中是什么位置,会是一个什么样的过程,核心业务的设计和开发是如何来做角色组织和协作等等,这样才算完整,单纯讲开发组的工作意义不大。
我是一个唯业务论者,业务的成熟度决定开发采用什么样的过程方法。很多业务的核心项目,不是什么时候都可以边干边改。现在的很多敏捷方法是唯技术论的,比较符合技术人员的口味,但不是项目这个层面,拿着这种方法去做项目,将业务成熟这个条件刻意淡化的后果可想而知。
业务系统项目失败从我的经验看,技术原因的很少,问题最大的是两类,一个是没有业务经验,一个是项目体制混乱。
Mouge,项目实施过程中,要把握好哪些是不能变,哪些可以小变,哪些可以在什么期间变,而不是无所谓,想怎么变就怎么变。
你不是变形金刚,公司掏钱雇你,客户掏钱给公司,不是没有原则和底限的。如果有些环节不先做好整体的规划和设计(业务的分析和关键业务规则的详细设计),你再敏捷,技术能力再强,也还是会项目延期,然后将课题抛给客户,说客户没说清楚或者说客户业务在变。每个人对可控制的变化是很少的,只有能控制住大部分,才能对小部分的变化做调整,否则就是失控。
现在的敏捷方法有价值的部分,是在配置管理上,怎么用很好的技术手段来应对变化,但这只是项目成功实践的一部分。是的,我们可以应对变化,但我们为什么不想想,为什么会有这么多的变化?
如果你做的是个业务系统,如你所说领域驱动,我想你应该梳理一下业务的分析设计在你的过程中是什么位置,会是一个什么样的过程,核心业务的设计和开发是如何来做角色组织和协作等等,这样才算完整,单纯讲开发组的工作意义不大。
我是一个唯业务论者,业务的成熟度决定开发采用什么样的过程方法。很多业务的核心项目,不是什么时候都可以边干边改。现在的很多敏捷方法是唯技术论的,比较符合技术人员的口味,但不是项目这个层面,拿着这种方法去做项目,将业务成熟这个条件刻意淡化的后果可想而知。
业务系统项目失败从我的经验看,技术原因的很少,问题最大的是两类,一个是没有业务经验,一个是项目体制混乱。
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中,这样,至少大部分的结构是优秀的,不断改善的。
目前项目还未进行到一半,欢迎批评指正。
你可以看看我这个贴子,直播中,本周末我争取写更详细的东西出来。
简单地说,就是整个完整交付品远超开发团队交付能力的情况下(我相信大多数时候都是这样的),如何去尽可能准时交付并且保障交付品的功能满足及良好的设计,还有质量的保证。
对传统的开发过程,项目中往往会有权衡之事发生,最常见的就是,管他三七二十一,我们把功能实现了就行了,先不管架构、质量,整一个可以跑的东西出来,整上线再慢慢来修修补补。这种情况导致的最恶劣的后果就是质量问题导致不断延期,架构的不合理导致整套系统的生命周期很短。
对一个成熟的敏捷团队的开发过程,如采用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中,这样,至少大部分的结构是优秀的,不断改善的。
目前项目还未进行到一半,欢迎批评指正。
你可以看看我这个贴子,直播中,本周末我争取写更详细的东西出来。
简单地说,就是整个完整交付品远超开发团队交付能力的情况下(我相信大多数时候都是这样的),如何去尽可能准时交付并且保障交付品的功能满足及良好的设计,还有质量的保证。
对传统的开发过程,项目中往往会有权衡之事发生,最常见的就是,管他三七二十一,我们把功能实现了就行了,先不管架构、质量,整一个可以跑的东西出来,整上线再慢慢来修修补补。这种情况导致的最恶劣的后果就是质量问题导致不断延期,架构的不合理导致整套系统的生命周期很短。
对一个成熟的敏捷团队的开发过程,如采用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,你能做到了吗?
当你不知道怎么样把一张纸从杯底下抽出来时,你一直认为慢慢拉才是硬道理,这种想法可能持续到当你理解牛顿第一定律后,转身飞快地抽出这张纸时,你终于觉得慢慢拉只是一种笨办法。敏捷也一样,它要你抛弃很多你认为“正确”的做法,比如放弃设计,编码,测试的顺序,而去接受TDD,你能做到了吗?
29 楼
RCFans
2010-11-13
目前正在一家甲方公司担任部门经理,商业平台型的系统,以项目的形式进行实施,正在实践敏捷。
我的看法是:无论是软件工程也好,还是敏捷、Scrum也好,还是其发起者的“动机”也好,都只是一些软件生产模式,就和哈佛商学院产出的各种商业模式一样。项目的各种资源掌握在我们的手上,如何用,首先了解现有的各种运用模式,其次是实际的各种背景和影响力,先运用一切可用的,最后再来看怎样可以改进方法论。
比如“与制造业的敏捷不可同日而语”,那么差别在哪里,怎样可以借鉴提升?记住,我们不是评论家,我们是实践者。
我的看法是:无论是软件工程也好,还是敏捷、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)不太感冒。
本人有洁癖,只对自己代码负责,不让别人动,不让别人思想支配。
本人有洁癖,只对自己代码负责,不让别人动,不让别人思想支配。
那是你没碰上适合讨论的人罢了。
发表评论
-
信息系统之癌细胞
2011-12-30 10:15 1084信息系统经过持续不断的补丁和升级,进化到最后往往如同得了癌症, ... -
我的软件研发和项目管理的图书
2010-12-24 12:38 2206前段时间把家里的图书清理了一次,留了一些质量较好的开发类图书送 ... -
再说敏捷,兼对“对敏捷开发等时髦概念泼点冷水”的回复
2010-04-30 09:49 1217再说敏捷,兼对“对敏 ... -
项目管理的前提是资源
2010-02-04 15:37 1579这么多年碰到很多项目,体会是没有一个项目是能把人配齐,当手上项 ... -
项目管理经验的获取
2010-01-26 16:35 2119看到很多帖子上讲怎么 ... -
项目的成功与主担辅担
2010-01-25 16:27 1487开发能否成功,在于各个角色是否明白各自应该担当的工作内容,目标 ... -
革命与招安
2010-01-24 15:01 1089敏捷与Spring、Hibernate这些东西都一样,草民革命 ... -
TDD
2010-01-21 14:34 1731上次是敏捷,这次说说TDD。 TDD现在的路子不对,讲的再怎 ... -
无坚不摧 唯快不破
2008-04-19 14:21 2349什么人做功能测试比较 ... -
功能测试谁来做
2008-04-03 22:19 2892受微软的影响,项目组单独配备功能测试人员,在很多公司里成为一种 ... -
企业应用干嘛要用做网站的技术
2008-03-31 12:16 6643现在的B/S开发,做企业应用系统,表现层还是基于网站的开发技术 ... -
世界观决定方法论
2008-03-08 16:06 2163世界观决定方法论 Lean,丰田的精益生产方式,把开发当作是 ... -
从二战德军之父冯·西克特看团队培养
2008-03-06 17:00 2717从二战德军之父冯·西 ... -
我对产品化的理解
2008-03-06 16:19 11822我对产品化的理解 产 ... -
基于客户业务能力的软件项目开发的四种模式
2008-03-05 22:17 2354基于客户业务能力的软 ...
相关推荐
最近抽出时间,看了一本关于敏捷的书籍,其中以生动的例子讲解了 scrum 的相关知识 , 让我映象很深刻,当然也受到了不少启发,在此,小弟不才,和大家一起分享下。 关于敏捷,这个大家百度一下就知道了,我就不废话...
敏捷是基于一种不确定性较高,未来环境难以预测的背景下产生的一种管理理念,这种理念并不意味着应该丢弃传统的管理方法中的一些方法而是应该以快速传递价值给客户为目标进行管理,只要某个方法能加速我的价值传递就...
用户故事是从用户角度描述需求的一种方式,如“作为一个用户,我想要...,以便...”。将大的功能拆分为小的、可操作的任务,有助于团队更专注地工作,并能快速反馈和调整。 4. **持续集成与自动化测试** 在敏捷...
它们通常写成:“作为一个[角色],我想要[功能],以便[获得的价值]”。 8. 重构:为了保持代码的清晰和可维护性,敏捷开发鼓励定期进行代码重构,即在不改变外部行为的情况下改进代码结构。 9. 每日站会:敏捷团队...
敏捷是基于一种不确定性较高,未来环境难以预测的背景下产生的一种管理理念,这种理念并不意味着应该丢弃传统的管理方法中的一些方法而是应该以快速传递价值给客户为目标进行管理,只要某个方法能加速我的价值传递就...
这是我一直在思考的一个问题,同时也在敏捷之旅2010成都站提出。这似乎是一个不值得推敲的问题,敏捷就是“敏捷”。但为何某些实践可以称为敏捷实践?方法学可以称为敏捷方法学?是不是存在一根看不见的线把这一切...
我列举了32种耳熟能详的敏捷精益方法或者方法论,大部分现在仍在使用和演进中。如有遗漏和错误,请读者与我微信(JINYI-4013)联系,这也是这个时代的社区文化和共创文化使然。 与之相对,我也搜集了36个中国互联网的...
敏捷软件开发的经典之作,值得阅读,我看了觉得很好
敏捷软件开发.pdf 这本书是老外写的,不过是翻译版。我不推荐,原因是,通常翻译版的看起来,很蹩脚。 还是看原版,英文版吧。 如果你有兴趣看看,可以下,我这提供下载不需要积分的。
你想用最少的代码,快速简便的写一个基本的内容管理系统(CMS)(可以看看Expression Engine)。 你想写一个只有几个标准特性的简单的网站。 1.1.1 节省时间 CI 学习周期短,见效快。让我们试着评估一下相关的...
经过大家的水深火热的探讨答案出来了,但是各有各的想法各有各的不同,但我想他们的所想和所论对于大家都是有帮助的,大家可以看一下这个讨论题,希望在技术上能帮到大家一些。 LoveTT:我觉得敏捷测试不需要写...
我之前blog中全面概要的介绍了一下Scrum方法,如果你不熟悉的而又想了解下面内容,请你最好去去仔细看看我这篇文章《流程-从IT方法论来谈Scrum》,因为下面我将描述我们如何基于Scrum方法来进行个人管理项目的执行...
经过大家的水深火热的探讨答案出来了,但是各有各的想法各有各的不同,但我想他们的所想和所论对于大家都是有帮助的,大家可以看一下这个讨论题,希望在技术上能帮到大家一些。 LoveTT:我觉得
”,“我不这么认为”,猪说,“我全身投入,而你只是参与而已”猪是全身投入项目和Scrum过程的人,有三种角色:产品负责人(ProductOwner)、ScrumMaster、团队(Team)。鸡角色并不是实际Scrum流程的一部分,但是...