|
有智者曾经言道：你建构了你所知，你所知又影响了建构的方式。这并不是 1968 年，程序员康威说出的原话，但大意如此。 他的社会学观察，被称为康威定律，其内涵是：设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。 时至 2015 年，许多组织都在盯着单一应用程序和架构，并想知道他们是如何到达那里。而且，也许更重要的是，他们在将何去何从？ 我认为很少有技术问题实际上涉及到技术。无论你是想从一个单一和供应商相关的模式演变，或准备接受微服务，是时候来看看内部文化，人员和系统是如何影响应用程序的开发速度和性能了。 这里有 5 点建议，供你参考。 在披萨订单上放顶帽子：创建小的团队。 许多企业认为一个团队的人越多，效果越好，这其实是个陷阱。在 21 世纪初，亚马逊创始人兼 CEO 杰夫·贝索斯挑战了这一概念，他认为团队应该更有效地工作，更好地沟通，并快速移动。他认为，一个团队的人数不应该大于 2 比萨饼可以喂饱的人数，创建了现在被称为「双比萨团队」的规则。 这个想法意味着建立一个达成了强有力协议（例如一些需求文档和 API）的小而敏捷的团队。这使得团队可以积极做出对于代码段的修正，只要他们不违反将团队和代码绑在一起的协议。 技术如微服务是这个想法的一个延伸。在微服务模型忠，复杂的应用程序都是由小的，独立的组件构成的。这种模块化方法的发展降低了任何一个的服务的一个问题也许会导致整个应用程序无法满足其最终用户的需求或期望，或者难以满足一个服务级别协议（SLA）。设计容许失败使得整个开放过程有一个更加积极的客户体验，更好的开发者体验，以及更自由，更快速地移动内部团队。 识别和授权先锋 即使建立一个单一的服务团队可能会产生对公司主流的文化挑战，但更为重要的是开始建立这个团队，这个团队是小的，好的。 在创建一个团队之前，你需要先选择团队的先锋，识别谁是天生的领导者，谁拥有的好奇心和解决问题的能力，谁具有天生的感觉，和谁不能容忍不明确。你希望他能够毫无畏惧地说，「现在还不清楚，我们将如何完成这项特殊的任务，但我会想出一个办法弄明白。」 请记住，这些开拓者最好有多元而丰富经验。你需要一个团队，其中包括有的人有着在现有单片结构深刻的背景，有些人则来自外部有着新鲜的眼光和视角，以及其他虽然经验较少，但有信心问出为什么要朝着目前的方向发展「哑巴」的问题。要确保它是一个团队，至少个性冲突不影响可以一起工作。 强化使命 请注意，不仅要选择谁将进入你的先锋团队，也要与那些没有被选中的人沟通。加强与所有利益攸关方的沟通，新的团队是意味着每个组织中的人都将参与建立，设想，并交付。这涉及到改造整个组织，只有通过早期的开拓者不断提交「实地考察报告」，提高他们的参与感和鼓励透明度，才能成为对抗新的各式风险的有力武器。 值得注意的是，整个团队有被拉入公司整体谎言的风险。 建立高度信任的文化 沿着这些同样的思路，重要的是要建立可以容忍失败并共同分享的文化。过渡到这种新的模式，并不会一切顺利。你需要鼓励个人从不可避免的灾难和挑战中进行学习，并将学习成果反馈到开发周期。要积极主动地建立一个内省的文化，在团队这的人员，可以感觉到他们有权采取风险措施，同时需要承认错误，而不是对别人进行指责。 慢慢来 低估所需的社会变化量是我见过的各个组织都可能面对的共同陷阱。毕竟，你不只是改变代码，而且是从顶部到底部改变该组织如何运作。 这种重大的变化不一定能够完全适合你的组织。有些组织难以对迅速多文化和技术的变化做出相应的反应；也许你现在根本就没有足够的空间或能力或者优先的意识来采取这样的变化。例如，将一个大型程序打散为 100 个小团队，在 12 个月内完成是不现实的，那也许可以尝试先将你的团队按照一块一块的代码和服务打散成小的团体们。 为了打破约束的过程，并形成一种自上而下的命令组织，保证刚性控制，也许我们需要借鉴那些原开拓者的做法。回到劈柴和运水，以创建一个共享的旅程，成长感的日子中去。享受其中的乐趣，相信自己的团队，记得康威定律----目标是创建一个灵活，功能强大，与软件相匹配的自主的组织结构。 文章来源：readwrite 本文由 TECH2IPO/创见 叶孤城 编译，首发于TECH2IPO/创见（http://）转载请保留此信息 |
|
|
