如何建立一个大型的敏捷组织
好的......考虑这种情况。我们有300人店铺负责开发自动化大型建筑物的控制系统。这些系统需要前端开发人员，中间件开发人员、固件开发人员和硬件工程师。这个系统的一个特性要求我们编写涉及整个系统架构的每一层的代码。就目前的情况来看，球队是围绕着大联盟组织的子组件在整体解决方案框架内。
像这样的公司是如何采用敏捷的?第一个倾向可能是拆分组件团队，创建跨功能特性团队。每个团队都有一些前端开发人员，中间件开发人员、固件开发人员和硬件人员……对吧?一般的想法是，这些跨功能特性团队中的任何一个都能够为整个系统的任何部分编写软件。团队中的每个人都成为了专业的多面手。
虽然过于培训专门的人并非不可能用户界面与有关固件（或硬件）热情的人的开发......但我的猜测是大多数人都不是为了它。我的赌注是，大多数组织没有测试覆盖范围，以使这种实验安全。我已经与若干组织谈过了这一镜头，而改变是如此破坏性，他们无法完成任何事情。说真的......没有做任何事情。
我想建议一下，我们的目标并不是真正创建跨职能的功能团队;我们的目标是构建团队，让他们拥有构建工作软件增量所需的一切。我认为两者之间是有区别的。为了保持敏捷，我们需要建立一个团队，这个团队可以在一段时间内保持团结，随着时间的推移变得高效，并随着时间的推移与客户建立信任。他们需要构建工作产品。
我们倾向于假设，为了实现这一点，我们需要围绕端到端特性组织团队。当我们谈论小团队和小产品时，我同意这种方法。当我们谈到更大的团队、更大的、更复杂的、技术更多样化的产品线时，这个建议就不成立了。敏捷社区需要一个更稳定、更健壮的比喻来讨论这类组织。
以下是我在过去几周开始思考这个问题的方式，我开始认为这种语言是有效的……让我们开始讨论在我们的组织中围绕那些最不可能改变的事情建立团队。
如果我们是一家小型产品公司，只有一种产品，不变的可能是一种产品。如果我们是一家更大的产品公司，提供更复杂的产品，我可能会围绕一些静态的特性分组来组织团队。如果我们是在一个非常大的组织中，一个有多个相互依赖的产品的组织，随着时间的推移投资不是水平的……我们组织的东西可能是一个组件或一些服务。
问题是，产品的功能流往往不是最短暂的。有时候，我们无法建立一个拥有足够专家或专业通才的团队来完成工作。当这种情况发生时，在某种程度上它会发生，我们希望开始寻找不变的东西。当我们发现不变的东西时，我们就开始建立敏捷团队。这是我们保持团队团结的最佳机会。
当您采用这种方法时，您必须记住，不再有任何一个团队负责端到端的价值交付。每个团队在每次迭代中都交付“已完成”的工作，但作为一个整体的企业，你必须开发一种能力，以便在每个不同的敏捷能力团队中有效地管理价值流。这就是敏捷停止提供良好指导的地方，我们需要别的东西。
这就是精益/看板。
所以请考虑一下……围绕企业中的持久对象(无论它们是什么)建立敏捷团队。使用Scrum或XP要么看板或者其他其他敏捷方法在团队级别漂浮着船只。团队可以变得过高富有成效，并具有尽可能多的敏捷良好。为了缩放所有这种敏捷的善良，请使用精益/看板管理跨团队的价值流的方法。
那么，回到我最初的问题……对于我们这个大型控制系统公司来说，最有效的敏捷策略是什么?
组织前端周围的敏捷团队中间件，固件和硬件。创建一个企业积压的值，该功能将分解为用户故事并分发团队。从属于每个团队的积压到企业积压，并创建一个拉动系统，其中一旦团队有能力才能工作，只能开始新功能。在每个团队中设置过程限制的工作，以减少我们可以在滚动到值功能之前开始的工作量。投资受限制的能力，以提高系统的总体价值流程。
合理？任何问题？
评论（33）
鲍勃•马歇尔
嗨迈克，
这确实是一个重要的问题，而且不仅仅是对于拥有数百名或更多工程师的大型组织而言。
我已经研究这个问题好几年了。并有一些想法(对此我正在写一本书)。
我同意您关于价值流的观点，看板可能是处理价值流的候选者。
至于要围绕的东西，我想说的是，无论组织规模如何，产品(或服务)线都是一个不错的选择。我之所以这么说，是因为产品通常是价值流向客户的工具。
至于团队，我们是完全相反的。我开始相信，与其试图将(小型的、敏捷的)团队保持在一起，我们应该尝试寻找减少或消除项目和团队带来的功能障碍的方法。也就是说，我们要找到一种方法，使人们能够快速地聚集在一起工作，而不是通常的“形成-风暴-规范-执行”的空谈，直接跳到“执行”。
我非常证明团队的力量，但我相信力量不是团队本身的功能，而是来自人们一起工作的更基本方面。像信任，共同的目标，共同的背景等等，我认为这些都可以体现团队的想法。
我建议没有团队的一项工作，是为了形成和改革人群（三到五，比如说）经常（每周两三次，甚至每天），使人们习惯，而且随着时间的推移发现方法可以更好地制作它。
顺便说一下，FlowChain在某种程度上基于这种方法。
HTH
干杯
鲍勃
Machiel Groeneveld.
这种方法的一个问题是炉子管道图案。解决您可以添加跨功能集成团队。这些就像功能团队一样，但不要构建任何东西，他们都能融入其他团队构建的内容。如果您在这支球队上旋转人员，则将“大图片”保持一部分运营。
对此的一个很好的解释是在肯苏贝尔的;企业中的Scrum。
Mike Cottmeyer
鲍勃,
我打赌，如果你和我一起去啤酒，我真的有机会解释我试图解决的那种问题，以及我想要解决它们的公司各种各样的公司，我们将截然不同。
从我对你的观点的了解一点，我知道你正在谈论更多的理想结束状态。如果我从头开始建立公司，我也可能不做我在这里的说法。我可能对产品开发，团队和组织结构进行了彻底不同的方法，以及我们所有人的价值如何。
这并不是我在这个博客上要讲的。
我正在做的是试图帮助那些对敏捷持开放态度的根深蒂固的瀑布型组织。我试图帮助那些对精益或看板持开放态度的敏捷组织。我发现，很多很多公司都在纸上谈心地接受书本和演讲者的指导，把事情搞得一团糟。
他们被告知Scrum是简单的，在三个迭代中他们就可以获得超高的生产力……但通常情况下并不是这样的。
谢谢你的评论。
Mike Cottmeyer
Machiel,
《企业Scrum》这本书对您的组织性质做了一些假设。它假设每个组件团队都嵌套在单个集成团队之下。集成团队就像Scrum中的Scrum，封装了组件团队创造的价值。
如果您有多个跨多个组件团队工作的集成团队呢?问题是您在团队级别的速度并不是集成团队级别的速度的预测器。任何一个组件团队都可以让任何集成团队失去价值。
此外，协调大规模的架构问题几乎是不可能的，几乎不可能达成一致的承诺，或者有任何有意义的能力告诉业务，他们什么时候能够交付。亚博vip9通道
我认为对于许多人来说，这是一个学术或理论上关于如何运作的人，或者应该“应该的工作”。我的大多数写作是我合作的许多组织可能的结果。如果Ken的方法可以为您工作，那将是优选的。在许多情况下，Ken的方法将导致团队来到绝对的停顿。
我试图在去年在一个VersionOne的街卡广播中解决这个问题。看看，让我知道你的想法。
//www.nakata-dc.com/2009/08/adopting-agile-video.html
麦克风
鲍勃•马歇尔
迈克,
当然你是对的。我对基于纯粹的敏捷视角将敏捷扩展到企业的方法提出了质疑，这有点不公平。例如，尝试让敏捷在大范围内发挥作用。:)
是的，我在谈论一个理想的未来状态（有没有结束？）。
然而,在混乱的风险进一步的人可能已经发现一些挑战就敏捷,我觉得我们就应该指出,对于某些类型的问题(建设高效开发* *组织,例如),也许敏捷并不是最好的起点,也不是最合适的未来状态?
我赞扬您对您描述的观众的评论 - 过渡的瀑布和最近的敏捷者 - 您的言语和建议确实会用于谁。
我非常期待那个啤酒！:)
鲍勃
Mike Cottmeyer
鲍勃,
别担心“不公平”的事情……看在上帝的份上，这是一个博客;-)下次我去伦敦喝啤酒时，我会给你打电话的。我需要找个理由去英国呆一段时间。
麦克风
大卫
采用一种有点破坏性的方法，你可以将团队组织成问题组和解决方案组。每个团队都可以由跨职能的团队组成，这可能会减轻您上面列出的一些担忧。
大多数leanstartup家伙都在讲道，但它可能更适合初创公司。
Mike Cottmeyer
大卫，你有没有可以分享的文章或其他东西的链接。我不熟悉这种方法。
stanimir dochev
嗨迈克，
我是一个遵循敏捷方式的团队的一员。你的想法帮助我克服了一些障碍，并为悬而未决的问题提供了答案。所以，谢谢你;-))
上周我看了一部小电影，是关于保时捷的一家工厂，以及他们是如何实施精益原则的。他们将整个产品分成小组，并让每个小组作为一个独立的scrum团队。例如，生产被分为工厂的物流和组装。每个物流和装配单位都在努力优化。整个过程由一个中心单元指导，而这个中心单元又有它的scrum sprint。这听起来像是宏观层面的瀑布，微观层面的敏捷。
到目前为止，我在软件行业的经验也与此类似。拥有一个可以交付复杂产品的跨功能特性团队的努力，迟早会产生一群小型scrum团队，围绕着“企业中的持久对象”工作。他们中的每一个人都充当其他项目的涉众，并“拉动”它所需要的特性。
也许这是一个更好的实施的第一步和更痛苦的一步，但我仍然遇到它。所以你的提案听起来像是目前最好的解决方案。
问候,
Stanimir
大卫
迈克,
大多数材料都可以在Steve Blank, Eric Ries和Dave McClure的网站上找到，但是这张幻灯片的第四张提到了它:http://www.slideshare.net/startuplessonslearned/2010-01-11-customer-discovery-crash-course
正如我所说，它大多是初创公司，但可以在企业中杠杆化。
也许我有点离题了，但大型组织可以很好地捍卫市场份额，或者使用这些技术进入新市场。也就是说，如果他们愿意放弃传统的竖井，在产品和开发中使用跨功能、迭代的方法……
Pawel Brodzinski
虽然可以很难实现，但有意义。我看到的问题完全相同，在缩放Kanban期间出现。在某些时候，您需要一个非常好的产品所有者/产品经理，他们能够处理整个产品。
是的，他们可以相当普遍存在一般水平，但他们仍然应该了解产品发生的情况。
如果你考虑多个产品的情况，重点和责任就会落在某个总经理或能够协调不同项目/产品之间工作的人身上。
简而言之，只要有一个以上的产品经理和共享的构建器池，就总是会看到产品之间的冲突。解决这些问题需要一个强有力的领导者。这正是我在这个方法中所关注的。
瓦斯科杜阿尔特
从这篇文章中难以理解，你试图规模。
你扩展吗?
-“团队管理”
-“工作管理”
- “管理管理”
- "价值管理"
你认为在你尝试着扩展功能团队的方法时，会遇到哪些障碍?
已有“通过需求进行项目管理规模化”的模型。这里有一个观点:
http://bit.ly/c6JNX5
我有兴趣继续这种对话，我认为在这个领域我们需要进一步发展。
Mike Cottmeyer
斯坦尼维尔，
谢谢你的评论，我希望这个方法对你有用。我开始思考，对于大型复杂组织来说，这不仅仅是一个不那么痛苦的模型，它可能是唯一合理的模型。
有什么进展请告诉我。
麦克风
Mike Cottmeyer
Pawel，
完全同意。您不仅需要为每个产品提供一个出色的PO，还需要为每个静态组件团队提供一个出色的PO。在项目早期，您还需要非常敏捷的项目组合管理和一定程度的架构和产品远景。您还需要您的组织开始将项目分解成更小的块，这样您就可以增加整个系统的流程。使用与故事相同的INVEST模型来确定项目或大价值特性的范围。
无论如何，这不是我关于这个主题的最后一篇文章，我希望在接下来的几个月里更全面地展开。
麦克风
Mike Cottmeyer
嗨,瓦斯科,
从某种意义上说，我试图将上述所有因素都放大。最后，我们试图让整个系统更快地交付价值。在很多情况下，如果其他团队没有以一种协调的方式相互合作，那么与单个团队合作也不会有什么好处。
有很多情况，特征团队模型将是优选的方法。还有其他案例，组件团队模型是优选的方法。当有人告诉我，我们必须在所有费用中拥有功能团队，我要求他们做一个思想锻炼来提出一些环境团队无法工作的环境......他们会做什么？
即使您可以将所有开发封装到一个功能团队中，您对销售和营销有什么作用，您对下游支持进行了什么？它们也是价值流的一部分...理想地，我们需要有一种方法来管理它们。他们应该成为Dev团队的一部分吗？不可以。这种方法也用于管理非IT组。
我保证您，在您的环境中有一些示例，我可以提出，其中特征团队分解。再次，我们该怎么办？我正在接受“所有费用的特征团队”咒语的思想是对许多敏捷实现的危害。
麦克风
Mike Cottmeyer
Vasco，还有一件事，通常当我发现有人说他们是一个大型组织中的“功能团队”时，他们实际上是一个“组件团队”，并没有过多关注他们周围的其他团队。这导致了企业级别的次优化。
r
我同意Vasco的观点，这篇文章有更多的问题。
这个300人的IT商店和其他300人以上的100或1000人的IT商店有什么不同?你是想说，与其他公司/企业IT商店相比，由于固件/硬件方面的原因，有一些根本不同的东西，还是仅仅基于规模?
你的“在”对这个环境中是什么 - 这是一个从管理层的敏捷推动，或者是部门或团队内部的基层努力？
如果敏捷的一个方面是将决策制定责任向下推并在各个范围内分布(并对这些决策负责)，那么加强烟囱式孤立系统开发(但是管道内的“敏捷”)有什么帮助呢?
您如何区分建筑物围绕“最不可能改变的事情”，并且需要实际破坏性，因为现状不起作用？
Mike Cottmeyer
r，
让我看看我是否可以解决你的一些问题，而不是写一篇完整的博客文章;-)
是的......我在说在大型多样化组织中谈论缩放敏捷时，系统架构中所需专业化的规模和所需专业化程度。
它们的不同之处在于它们分散在世界各地，产品由其他产品组成，多个产品所有者参与其中，是的，硬件人不做软件，软件人不做硬件。
我的“在”这个环境中是一个高级的水平，在整个交付流中产生影响。大多数与团队开始的最敏捷，在一个大型企业中，最终会成为每个人的子项化，每个人都想知道为什么我们无法更快地将产品从门出来。如果我从团队一级开始并努力工作的话，我还有另一个策略......无论你来自哪个方向，你都可以取得成功。
我同意敏捷关于推动决策，但这并不意味着团队中的每个人都能做出他们想要的事情。有些限制来自更大的组织和反馈循环返回。这是团队协调决策所必需的。
我不同意这种加固烟囱的说法。就像我对Vasco说的，在许多组织中，我的功能团队就是你的烟囱。这完全取决于视角。你知道有多少敏捷团队真正拥有终端到终端的产品?不是很多。如果你认为他们有，那就问问他们是否有营销部门....自己做销售。他们有自己的支持吗?他们有自己的包装、集成和售后服务吗?所有这些都是价值流的一部分。
我完全支持破坏性的改变，只要是有目的的改变。只要改变是有效的。
所以让我翻回你的问题...告诉我如何扩展我在这里谈论的组织？记住... 300人......至少4个非常不同和不同的技能组织......他们中的每个人都必须尽快将产品带到市场上，因为组织想要的......多种产品支持共同的架构???
30跨功能特征团队????再试一次......或者试图说服我。你的来电 ;-）
r
让我拿出我的逻辑谬论小抄，以便我能正确地为你们识别它们。:)
我如何回答“30跨功能特征团队”，当我从未提到过这个概念时，甚至间接地？我不需要尝试“说服你”看到我所做的一切都问了一些问题。所以把你的小偏见放在鞋盒中，把它推到床下几分钟。
你必须知道，即使在写最初的博客文章时，你的问题也没有唯一的答案。关于这个主题的书籍已经写过了，比如Jutta Eckstein的《大型敏捷软件开发》或者Dean Leffingwell的《软件敏捷扩展:大型企业的最佳实践》。我并不是赞同这两种答案——如果一本书能解决企业的敏捷转换问题，你就没有工作了。但是，这肯定不是一个可以在博客帖子中回答的问题。
所以，我所拥有的所有上下文都是这个页面上的单词......考虑到问题的大小，这并不多。（是的，“不是。”）并且这就是我想要解决问题的全部，没有cookie刀具公式，没有敏捷的公式。对？
但鉴于所有这些，我认为你的最后一个回应有一个线索。我个人不认为可以从顶部'推'敏捷。你的“在”，正如你所说，是在高级层面，但这并不意味着敏捷必须被迫。你处于理想的位置，因为很多底层变换的问题是管理推回。
你说：“如果我从团队一级开始并努力工作的话，我有另一个策略......无论你来自的方向如何，你就可以取得成功” - 我会说这将是一个起点。如果你有一个策略，那么你可以成功，那么就是不是一个工作的地方？
Daryl K.
嗨迈克，
我读了这篇文章和前几条评论。
我想你搞错了。你试图让组织保持原来的组织方式，因为这更简单，而且很难改变一艘大船。
但是，早到晚是显示实际进展的唯一方式。如果您构建了一些没有内在业务价值的内部组件，作为产品所有者，我看到的是零进展。亚博vip9通道对技术人员来说，这似乎是一种进步，但从商业角度来看，这是一种虚无缥缈的进步。亚博vip9通道所以现在我们已经进行了迭代但你没有从我这里得到任何反馈。
这些紧张迭代，中央目的的目的是向企业展示进度并获得反馈。亚博vip9通道
我不能说我和一个300人的团队合作过，但我指导过一个55人的团队。我们每周都进行跨职能的迭代。
当你说跨职能团队时，你跳到“专业化的一般主义者”。对我来说，这些是两个概念。跨职能团队可能是一个不知道多层的专家团队。一个UI专家，商业规则专家，数据层专家亚博vip9通道。他们不知道其他层，他们不打算学习。但它们是交叉功能，因为它们与其他层的人密切合作，而不是在自己的层茧中。这样，我们可以尽早建立最终作为一支球队。
在我早期的项目经验中，很明显，大项目总是失败，小项目总是成功。我能想到的解决大项目的唯一方法就是把它分解成小项目。最好的方式是端到端，因为这是我展示业务价值和获得业务反馈的唯一方式。亚博vip9通道
你让我读它......
Larry Maccherone.
迈克,
我迟到了这次讨论，所以我不会跳到关于在艰难创建交叉功能团队的“可能”的“可能”的讨论。但是，我要对您的核心想法发表评论。我想首先说我钦佩你的勇敢，以提出这个有效的替代方面的跨职能团队的标准敏捷建议。我最近开始向大型产品开发工作推出基于Scrum的过程，即80％的机械和电子产品，只有20％的软件。在这样的情况下，您无法将产品刻为功能团队。你必须把纪律团队留在奇观。
您的帖子首先通过认识到这种困难，但随后您浮动该原则，球队应该组织最不可能改变的东西。我的第一个回应是“有趣的，让我用自己的经历来测试。”但在我的经历中，我只遇到了你提到的三个案例，我很难说你的原则有助于这些情况。我全都是为了在制定未知的模式之外的决定时回到核心原则，但我的经验只有这三种模式，所以为什么不只是捕获这三种模式的特征并应用它们？为什么我需要一个原则？
那么，在哪些情况下，人们可以更容易地识别出最不可能改变的东西，然后你就可以说，这三种选择中哪一种“更适合”这种情况?
如果我们找不到上述问题的大量肉，那么我很乐意在围绕条件进行讨论，表明三种替代方案中的哪一个更适合。我认为这是一个重要的问题，即人们一直害怕提出......但是务实主义者默默地偏离标准推荐时......善于务实。
Mike Cottmeyer
达里尔,
谢谢你的评论。我同意你说的大部分。是否存在“跨功能特性团队”不工作的情况?如果有这样的情况，您将如何管理工作以确保业务获得价值?亚博vip9通道这就是我在这里谈论的情况。
我同意制作较小的项目更好。是否存在风险，我们使项目如此之小，以使我们的“跨职能特征团队”成为对团队有价值的东西对企业对企业的价值不再有价值？我们是否以“跨功能特征团队”结尾的风险，这只是较大的企业内的组件团队？因为真的，除非团队负责概念到现金，除非是最多的，否则最不重要，还有一个必须在团队中管理的要素。
希望所有的项目都能被分解成对一个6-8人的团队有意义，并且仍然与业务相关，这是不可能实现的。亚博vip9通道很好的对话，谢谢你的评论!
麦克风
麦克风
Mike Cottmeyer
拉里,
谢谢你的评论。我开始使用'寻找不会改变'不是那么多规则的语言，而是作为开始对话的方式。我曾经为VersionOne咨询。当我帮助人们在应用程序中设置他们的树形结构时，我将始终查找每个组织中的一致性，以及瞬态在每个组织中的瞬态，以及用一组对象模拟持久性，以及与另一组对象的瞬态事物。
试图围绕不断变化的事物建立团队并不利于保持团队的团结。你可以认为任何团队都能解决任何问题，但这并不总是正确的。对我来说，敏捷的核心是团队。如果我们不能从那里开始，我们就无法开始。我宁愿建立团队并管理跨团队的价值流，而不是根据计划的需求来构建和解构它们。
无论如何，怀疑我解决了你的问题。也许稍后另一个博客帖子;-)
Larry Maccherone.
迈克,
事实上，它在某种程度上回答了我的问题，因为现在我更好地理解了你的意思，我可以从我自己的经验中找到适合的例子。
所以你的原则并没有多大帮助，但你上面的评论提醒了我，你正在尝试优化以保持团队在一起。你可能在最初的帖子中说过，但在我的阅读过程中我忘记了。你是说，让团队团结在一起比组建一个完全跨职能的团队更重要。所以，也许你的下一篇博客文章应该讨论一下不跨职能的利弊。
谢谢,
拉里
joshilewis
我对这种方法有两个担忧:您谈到“每个团队在每次迭代中都交付‘已完成’的工作”。我的观点是，设计是一个完全非连续的过程，在没有各方参与的情况下是不可能完成的，包括“不同级别人员”(如中间件、UI等)和“不同活动人员”(如开发者、分析师和测试人员)。因此，我真的不相信非跨职能团队能够完成“已完成”的工作。
因此，我认为围绕活动(而不是可交付的功能)组织人们，我们根据“测试”或“开发”来利用这些活动，会导致可用性资源瓶颈。如果作为开发人员，我需要从分析人员(或开发人员的测试人员，或中间件工作人员的UI开发人员)那里得到澄清，我需要等的时间越长，团队遭受的损失就越大。对我来说，跨职能团队的目标是尽可能地提供所有必要的人员。
几周前，在Kanbandev邮寄名单上有一些讨论。
阿米特
你好，你的博客真的很棒，我读的时候真的很喜欢。
mba印度
斯坦·Yanakiev PMP
嗨,迈克。这是一篇有趣的文章，因为扩展敏捷确实是一个关键问题。但是你所描述的与传统的矩阵式组织和世袭结构有什么不同呢?虽然存在差异，但并没有那么显著。界限对我来说越来越模糊了。
斯坦......
不确定如何回答你的问题。传统的组织团体人民通过角色专业。我建议我们创建与产品，服务或甚至业务流程等商业对象对齐的跨职能团队。亚博vip9通道我们必须具有控制机制，用于协调多个团队的输出。认为整个价值流将包含在单个Scrum团队中，这是天真的。合理？回答你的问题？
斯坦·Yanakiev PMP
迈克:
你建议的方法可能会奏效。我试着去理解其中的新奇之处。一些敏捷人员声称标准的管理方法和结构已经完全过时了，没有它们，敏捷组织也可以实现。我还没见过这样的模型，即使是理论上的。另一方面，跨职能团队在今天也存在，当矩阵型组织启动一个项目时，人们来自不同的部门。也许有些部门也有不同技能的员工。但如果是一些专门的部门，比如会计，我认为跨职能团队就不是个好主意。
我认为你可能会在这里缺少细微差别。我正在谈论创建一个跨职能的人团队，在长时间保持在围绕企业内的商业对象组织的长时间。亚博vip9通道这些人可以拥有一个功能经理，因此将“矩阵”进入团队中，但我希望矩阵的强大一面成为团队，而不是功能群体。我不是在谈论项目团队，我在谈论持久的交付团队。它需要了解组织业务体系结构，了解交付团队的价值流程，以及管理价值流动的机制，以提供端到端的业务结果。亚博vip9通道
And for the record, I don’t claim anything on this blog to be insightful or novel… I just write about my ideas, opinions, and observations in hope that they might help someone else who is struggling with the same issues ;-) Hope this reply helped!
斯坦Yanakiev
我知道了。在公司中组织持久的跨职能交付团队，在公司中的“商业物品”中是一种扩大敏捷的方式。亚博vip9通道虽然，球队可能不会长时间保持在一起。当业务对象的变化时亚博vip9通道，团队将必须重新配置，公司结构将改变。例如，公司可能会从桌面应用程序的开发转向服务器。改变团队，管理和结构可能是好的，因为它提供了灵活性，但也可能存在一些挑战。