InfoQ Geekathon 大模型技术应用创新大赛 了解详情
写点什么

关于 OpenUP 的辩论

  • 2010-04-30
  • 本文字数:1724 字

    阅读完需:约 6 分钟

最近,一个关于统一过程(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 的辩论

活动推荐:

2023年9月3-5日,「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题,策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229(微信同手机号)。

2010-04-30 01:541243
用户头像

发布了 24 篇内容, 共 47191 次阅读, 收获喜欢 0 次。

关注

评论

发布
暂无评论
发现更多内容

架构师训练营 -week2- 作业

Geek_5a6ca3

架构师训练营第二周学习心得

潜默闻雨

总结

chenzt

架构师训练营 -week2- 总结

Geek_5a6ca3

《架构训练营》week2 作业

任鑫

架构

极客时间架构课 Week02- 作业二:学习总结

yulyulcl

Week2-总结

龙7

学习总结 - W2

Kun

极客大学架构师训练营

Week2 课后作业

Geek_165f3d

依赖倒置

架构师训练营-第二周总结

坂田吴奇隆

面向对象与面向对象的设计原则SOLID

imicode

设计

架构师训练营 week2-学习总结

devfan

架构师训练营 -第二周作业

Benjamin

极客大学架构师训练营

Week2 命题作业 — 架构师训练营

小叶

极客大学架构师训练营

架构师训练营第二次作业

+╮(╯▽╰)╭/>……

依赖倒置原则与Cache类设计

走过路过飞过

架构师训练营第二周总结

allen

【架构课笔记 - 第二周】编程方法演进与OOP

Nelson

架构

练习 2-1

闷骚程序员

第2周 课后总结

Coder

框架设计示例

imicode

设计

软件设计原则

Kun

极客大学架构师训练营

架构师训练营 Week2 - 软件设计原则

伊利是个圈

极客大学架构师训练营

架构师训练营 -Week 02 学习总结

华乐彬

《架构师》第二周总结

第二周作业课后作业

iHai

极客大学架构师训练营

架构课第二周作业

嘻哈

架构师训练营第二周总结

养乐多

第二周作业(Cache接口隔离优化)

吴建中

极客大学架构师训练营

【架构师训练营】第二周作业

魔曦

极客大学架构师训练营

面向对象编程

wei

  • 扫码添加小助手
    领取最新资料包
关于OpenUP的辩论_研发效能_Shane Hastie_InfoQ精选文章