康威定理

     

软件工程:领导力与价值感

272 4K

领导力是最大的推动力,但也可能是最大的障碍。 要使变革取得成功,我们需要最大限度地激励员工,最大限度地减少对员工的威胁。 .

什么是软件开发中的“两份比萨队”? - martinfowler

239 1

双披萨团队是为特定业务能力提供全面软件支持的小型团队。这个词因用来描述亚马逊如何组织其软件员工而流行起来。 这个名.

什么是团队拓扑? - martinfowler

386 1 2K

任何大型软件工作,如大公司的软件产业,都需要大量人员,而只要有大量人员,就必须想办法把他们分成有效的团队。 组建以.

如何区分微服务还是分布式单体?

458 3K

在没有意识到的情况下,基于 微服务 .

康威定律:团队结构与软件架构之间的相互作用

437 2K
英国议会下议院在1941年的闪电战中被摧毁后,上议院就如何重建下议院展开辩论。 一些人认为这是向马蹄形 "架构 ".

微服务反射和扩展复杂自适应系统 - James Lewis

345 10K

James Lewis是ThoughtWorks的总监,也是 .

软件不只是代码,还有程序员头脑中的人和理论

353 9K

Margaret-Anne (Peggy) Storey和Abi Noda是最近发表的ACM论文 "DevEx: What Actually Drives .

单体炒作很愚蠢 - Darren

420 2

越来越多吹捧单体的炒作如同当初炒作 微服.

领域驱动设计:做正确的事

1099 1 4K

任何给定软件项目的成功都可以归结为一个相当简单的定义或规则:我们需要构建正确的东西,我们需要正确构建这个东西。 这.

逆康威策略在现有系统行不通!

429 2K

逆康威策略不太可能在特定规模和稳定性的现有社会技术系统中发挥作用。在远程公司和分布式团队中工作的可能性更小。 简而.

我对“Spotify 模式”的批判思考 - Yip

812 4K

虽然我在 Spotify 工作了大约 8 年,但我并不熟悉每个领域的运作方式,而且我有自己的偏见、偏好等。而且 .

什么是舍基Shirky原则?

1245

舍基原则(Shirky Principle):复杂的解决方案(如公司或行业)会变得太过于专注于他们所解决的问题,以至于他们往往在无意中延续了这个问题。 .

Leah的增长和组织扩展指南

747 2K

让我们帮助您开始发展和扩展您的组织。本指南面向创始人、PM 和高级领导者(CTO/CPO/CRO/CMO)。 .

您需要模块,而不是微服务

1678 3 12K

架构有时很难——人们不断提出一些新想法,这些想法很快成为主流的“做事方式”,微服务是最新的趋势,现在是我们剖析这个想法并找到正在发生的事情的真正根源的时候了.

Mel Conway:同理心和系统思维

994

为什么深具同理心共情的人性(情商)和系统思维(智商)很难在同一个人身上共存? 我把这部分归因于教育系统:文理分科造成的 .

《人月神话》作者弗雷德里克·布鲁克斯去世

1260 1

来自“UNC计算机科学”的不幸消息——Fred P. Brooks,该系的创始人和长期主席几小时前去世了。 .

DDD实施的一些特定总结 - Thomas

862

1、有效的软件是与业务挑战相一致的软件 我们所说的一致,是指软件从领域中借用正确的术语,正确阐述业务的关键概念,并尽.

康威定律 - martinfowler

1494 1 2K

领域驱动设计在康威定律中发挥作用,帮助定义组织结构:    因为 .

用CAP定理解释成长型组织的大难题 - Nir

1566 1 3K

有人曾经告诉我,任何类型的团队或组织所经历的最艰难的转变是从大约 30 人增长到 60 人。 当时,我记得我在想,“嗯,这很随意。当然,每个组织都是不.

如何在您的公司中引入领域驱动设计? - Fabrizio

1320 1 4K

让我分享一下我尝试在大中型公司中引入它的经验。 有些你会看到的东西听起来很明显,但是这是我的经验,我想和你分享。 这些年来我学到的第一件事是:从.

什么时候微服务是一个坏主意? - semaphoreci

1393 1 7K
微服务听起来很棒,它们是模块化的、可扩展的和容错的。很多公司都使用这种模型取得了巨大的成功,因此 .

你不需要微服务? - itnext

1865 1 6K

亮点:微服务并不能确保良好的模块化:如果您使用 .

团队拓扑:为快速流动而组织你的团队

1322

如果我可以推荐一本专业书籍给任何从事 IT 工作的人阅读,那就是 .

团队如何组织?前后端团队与业务功能团队的比较

3526 1

组件团队:每个团队负责一个系统组件。例如,有一个团队负责前台,一个团队负责后台,还有一个团队负责数据库。这三个团队独立运作,这经常导致团队之间的相互依赖。<.

为什么“敏捷”会浪费这么多时间? - Reddit

935

阶段性工作、回顾、完善和类似的工作所花费的时间是疯狂的。如果我假设每天有15分钟的停顿,两个小时左右的完善和回顾(我曾在一个地方有四个小时的完善),那简直就.

规则引擎并不灵:康威定律不适用于刚性设计 - verraes

1250 1 3K

软件设计与 康威定理 是两.

Pipefy如何使用团队拓扑方法建设敏捷团队?

1722 1 4K

多年来,我们注意到开发具有高性能和高效率的软件是多么困难,以及团队因素在这个等式中是多么重要。有时我们没有意识到,我们并不总是需要最好的语言、技术或任何先进.

为什么我如此讨厌scrums? - Reddit

739 1

我真的希望我们可以作为一个团队做更多的工程,创建、设计、研究和构建出色的软件。但相反,任何在2-4 天内无法完成的事情都会被取消优先级并放入积压工作中。其他.

AdHoc使用团队拓扑方法打造其工程团队

1292 1 2K

AdHoc需要在快速发展的工程团队中推出新的领导层,需要重新构想如何沟通,以及信息将如何在这个新的领导层中流动。   松耦合和高.

团队拓扑快速参考图

1531 1 2K
由 Matthew Skelton 和 Manuel Pais撰写的《团队拓扑——组织业务和技术团队以实现快速流动》一书将帮助您设计团队组织结构,从而帮助您.