BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

关于OpenUP的辩论

| 作者 Shane Hastie 关注 28 他的粉丝 ,译者 鲍央舟 关注 1 他的粉丝 发布于 2010年5月1日. 估计阅读时间: 5 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

最近,一个关于统一过程(Unified Process)的不同派生物及其特质的讨论被公布在这里。 在InfoQ的读者中也有一些关于Open Unified Process (Open UP)的争论。这些争论真实地反映出了更广泛的博客圈的争论。

UP Mentors的共同创始人Mark Lines最近写了一篇标题为"敏捷开发使UP成长"的文章。他在文章中引用了Scott Amber来宣称敏捷界的许多人似乎低估或者忽视了企业界的真实情况:

  • 我们许多人并没有同地协作(co-location)的优势。同地协作要求整个开发团队紧密地工作在一起(理想情况在同一房间中),而且要求用户代表一直在场以回答团队的问题。
  • 结对编程,也就是2个程序员共享一个键盘,是大部分管理者无法认可的支出。
  • 在没有适度详细的(超出用户故事之外的)需求时交付系统,对测试,写培训材料以及产品支持来说都是无法接受的。
  • 边做边修改架构(重构)而没有一些初始的架构设计,对大型企业系统来说是不适合的。
  • 许多项目并不是完全独立的,并不能单独开发,因而需要与其他系统的依赖与集成,也需要一些协同工作。.
  • 组织中通常已经有一些管理实践(如PMO,ISO,CMMI)。这使得一个行政级别和一些文档不可缺少。
  • 每一到两周向用户部署软件对大部分组织来说是不实际的。  仅仅是移交软件通过开发,测试,系统测试,用户验收,产品环境已经是一项繁重的任务。  如果有许多项目每周并行做这样的事情,这完全是不可行的。   
他接着概括了OpenUP,并主张OpenUP提供了足够的框架和流程来处理更广泛的企业级挑战,并同时保留了敏捷的核心。

与之形成鲜明对照的是Michael Dubakov对于OpenUP和常规UP方法的回应- 放心,敏捷开发确实在成长 - 其中他对之前提出的每条质疑予以应答:  

关于同地协作(co-location):

当然我们都知道同地协作的团队更好。咨询师建议团队成员在同一个地点协同工作并不使人惊讶。如果你要赢得一场赛跑,开宝马M3比福特福克斯要好。另外,近几年有很多关于分布式敏捷的讨论。对于如何远程实施敏捷已经有很多想法和经验汇报。敏捷也适用于远程团队。

关于结对编程

这个论点很奇怪。很多管理者不想支持持续集成,迭代开发以及行为驱动开发(BDD)。但这并不意味着这些实践不好。背景和上下文很重要。在一些公司某些项目中结对编程会增加产出率,但是在其他项目中却没有受益甚至有反作用。有多少敏捷教练坚决要求结对编程,说“没有结对编程你们就不敏捷”?不多。在整个敏捷社区中传播这种论点是错误的。

关于详细需求:

少来!用户故事可以非常详细。比如说,你可以用BDD用户故事格式来写很多案例。用这种格式描写的功能可以很容易地转化为单元测试!老实说,这是很惊人的。 http://www.targetprocess.com/blog/2009/10/bdd-and-user-story-specification-examples.html 

关于架构

敏捷社区的很多人都相信花一些时间在架构上是很需要的。同样的,这和背景和上下文很有关联。如果你只是创建一个简单的应用,一天的时间就可以明确所有的重要决定。如果你想创建一个复杂系统,那可能要花好几个月。常识很重要。过度的架构设计总是危险的。可工作的软件才是对一个想法的最好证明。一个叫做“渐进架构(emergent architecture)”的概念正在发展。我喜欢这个想法,这也许是对的方向。http://www.infoq.com/emergent_architecture                  

关于项目独立性

敏捷实施正在迅速传播,现在确实没有公共的标准的方法来解决这个问题。但是我相信随着大公司开始实施敏捷,这个问题会被解决。(事实上我们已经进入了这个阶段) 

关于管理和标准

这是不是意味着PMO,ISO和CMMI是好的,而且我们应该放弃并追随它们的统治?敏捷社区努力与官僚抗争,我本人很喜欢这样。文档化的流程对软件开发项目的成功没有任何作用。90%的情况下,它会把你困着蜘蛛网里限制你的创造力。没有创造力就没有软件开发。醒醒吧,Mark! 

我们生活在这些标准中,但是我们应该反击。 

关于频繁交付:

这个论点太常见了… 而且“在大多数组织中不实际”真是句名言。有统计数据吗?除了企业级Java超大型应用,Mark有没有试过部署任何别东西?许多SaaS服务可以无痛苦地每周更新。一些服务甚至可以无痛苦地每日更新!这很难以置信,但是我喜欢它。客户也喜欢它!

你支持哪一方的观点? 请分享你的反馈。

查看英文原文: 关于OpenUP的辩论

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

还是敏捷好 by Jun Ran

虽然敏捷不容易做到,在实施过程中会遇到一些困难和阻力,但是我们并不应该放弃对实施敏捷的努力和追求。

确实,敏捷既像时尚圈般狂热,又像政党般党同伐异 by s y

Methods Need Theory(方法需要理论)这篇文章从另外一个方面进行了分析

www.drdobbs.com/architecture-and-design/2191002...

Re: 确实,敏捷既像时尚圈般狂热,又像政党般党同伐异 by 吕 新科

同意。
“文档化的流程对软件开发项目的成功没有任何作用”,敏捷/Scrum不也规定了一些类似的文档化的流程么?或许流程这个词已经被用烂了,谈流程而色变.

同时,敏捷如果这样一味的绝对化的否定文档,除了为了图个口快,好像也没什么意义。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

3 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT