关于OpenUP的辩论

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

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

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

与之形成鲜明对照的是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的辩论