Ferrier：这绝对是一种问题。我尝试这样解释这个问题：大型公司通常倾向于创建以公司为中心的系统，而不是以用户为中心的产品。他们只会创建在能力范围内的产品，选择接受内部的各种壁垒，而回避内部的依赖。这也意味着他们所创建的产品无法超越商业体或管理线。因此这种产品称不上产品，充其量只能称之为软件。创建产品的不同之处在于，公司会把这句话挂在嘴边：“亲爱的客户，这是我们为你所做的东西。”
使用道具 举报
Ferrier：我认为过度的关注是有危险的，我也确实看到某些IT组织这么做的后果。许多大型组织中都设立了架构师团队，他们不会交付任何东西，只是为其他团队提供建议。我很质疑这种方式的价值。 但之所以架构管理在大型公司中能占据一席之地，一个原因是因为交付团队对架构不够关注。 我认为有一个十分严重的问题在于，人们似乎很难理解为什么架构级的变更会催生更好的交付实践。其原因在于有许多敏捷专家本身不具有很高的技术水平，他们只是一种非常了解人类心理的人。 为了说明我所说的内容，可以举一个很好的例子，就是依赖。在“事物“、业务流程、技术或其它任何东西之间存在的依赖都是很难处理的。而如果我们在团队之间也存在着依赖，那么事情将更加棘手。这也导致了我们进行项目管理、甘特图、协作等等，也导致了面临着失败的风险。 但依赖的产生是因为我们没有将事物进行足够的分解，也没有构建出合理的契约，让契约双方都能够顺利地取得进展。对于产品相关的问题来说，依赖依然是一个很难解决的问题（但不是无法解决的），但对于技术方面来说，这种问题基本上已经解决了。可以通过面向服务的方式促成代码重用，这些服务应该尽可能保持粗粒度，以避免依赖。我们也可以通过增量式（没有破坏性）变更的方式对服务的契约进行改变。 是的，我说的就是微服务，这是当前的趋势。但这里面的规则并不是新鲜的东西，微服务只是一种代码名称，其含义就是理解正确的粒度级别。 因此，很多时候我们看到项目经理出现在scrum团队中的原因，是由于我们对于架构失去了控制。
Ferrier：我认为实现技术上的正确粒度是非常重要的，它能够真正地解决组织结构上的问题。 但是实现的过程中会有许多来自于技术人员的阻力，我还没有完全弄清楚原因何在。有可能只是那些守旧派会天然地抵触那些“时髦的垃圾”，但我觉得有可能存在一种更深层次的原因，因为技术专家本身也需要接受新的技术与技能的能力。 技术专家在接受新技术这一点上为什么会表现得与非技术专家有所不同？我想原因是许多人在年青时找到了某些能够熟练掌握的东西，并且从那之后就停止了学习。这样一来，他们就会积极地抗拒任何新的事物，否则他们就必须去学习那些新事物…… 而这一点对于解决问题来说是相当有害的。如果对某个问题的解决方案是一种新事物，那么你就无法从那些保守的技术专家那里获得任何支持。
Nic Ferrier是一位程序员，他相信我们能够从创建问题的过程中解决问题。他善于从实践中获取经验，并且在软件行业中已经具有超过30年的经验了。目前他将主要精力专注于为企业传授DevOps方面的知识。在休闲时，他喜欢通过编写软件解决自己的问题。
查看英文原文：Making Agile Deliver Good Software
本版积分规则 发表回复 回帖后跳转到最后一页
楼主: AlexQin
IP卡
狗仔卡
楼主
显身卡