Matthew Skelton与 Manuel Pais 合著了《团队拓扑：组织业务和技术团队以实现快速流程》一书，这是一篇开创性的文本，讲述了如何围绕软件.

当我们考虑如何以最好的方式做事时，首要考虑的是不要以最糟糕的方式做事并阻止以错误的方式做事，Poka-Yoke（“防错”）——这不仅仅是一个听起来很棒的词，.

一位作者分享了他第一次担任工程经理的经历。它会成为你的下一个职业吗？ 最近，我加入  .

这是 .

工程团队需要比以往任何时候都更快地为客户提供价值。云、SaaS 和永远在线服务的兴起意味着客户期望新功能、更少的错误和 99.99%（或更高）的正常运行时间.

富士通全球交付架构团队 Chris Frost 着眼于企业架构和企业敏捷性的基本挑战。 企业架构——通过以下方式应对大规模业务变更和系统设计： .

任何规划过程都必须允许变化，但太多的变化最终是不可改变和无法计划的。 关键不在于数据的捕获或分析，而是如何让正在做决策的人尽早关注异常.

新型产品技术团队模型简述： 没有孤岛，团队专注于了解客户的问题和市场挑战（环境），并由此发现和塑造他们应该如何构建和发展他们的产品（.

是业务决定技术？还是技术决定业务？是人决定IT，还是IT决定人？这是康威定律与敏捷的区别： 一位叫 .

在与 Facebook、Whatsapp、Google、Netflix 和类似组织的工程师交谈时，他们中的大多数人从未使用过 Scrum。为什么？这是因为以.

这篇文章的灵感来自于 HackerNews 上的一条评论，我再也找不到了。它的要点是“虽然架构经常被过度设计，但代码本身却经常被设计不足”。如果有人认出作者.

敏捷宣言忽视了最重要一点：成功的 结果 胜过高效的交付。 什么是结果.

我们中的许多人都去过健身房，最初取得了良好的效果。一旦你的身体适应了，同样的程序可能会帮助你保持，但你不会看到任何进一步的进步，你甚至可能开始倒退。 .

在生态学中，岩石地变成森林的过程被称为 .

你是一家小型初创公司的一部分。您脑子里只有一件事：运送产品并快速找到适合市场的产品。代码为王！软件架构？但是，事实证明，每个系统都有一个架构。无论它是不是好.

如果你想要更好的结果，那就忘记设定目标吧。而是专注于您的系统。 实现我们想要的生活的最佳方式：如塑造更好的身材、建立成功的企业、更多地放松和减少担心、.

没有心理安全、尊重和信任，以下任何事情都不可能发生。 过程存在于为人服务；人是第一位的。 最好的工作方式是协.

在过去十年中几乎无处不在的敏捷软件开发是一场革命。与瀑布式开发不同，其长周期需要提前六到九个月进行规划，敏捷进来了，只需要提前两到四个星期规划快速迭代，每个.

在本文中，了解需求在软件行业中的重要性，因为如果您不清楚自己的需求，您的项目就不会成功。 无论您是从事 IT 行业还是任何其他行业，都没有关系。如果您.

今年敏捷宣言刚满20年，有两个事实似乎不言自明的： 敏捷，作为一个标签，赢了；没有人想被称为非敏捷。 敏捷在实践中远远.

这是关于应对Complicated和Complex的方法： 砍伐树木和修剪树篱之间的区别是：来自 Sonja 的一条推文，她说：“我喜欢修剪树篱与砍伐.

这是敏捷教练THIERRY DE PAUW分享他建议基于Git主干分支开发的思路和经验教训： 2012 年，我开始了一项技术指导任务，以提升一个新手团.

在本文中，您将了解传统和敏捷软件开发团队的结构。了解团队结构的三种不同方法及其优缺点，并了解如何确定您的团队是否与您的产品合作良好。   .

在facebook和amazon工作过20年的Dan Rose回忆杰夫贝索斯的行动偏爱（类似中国俗语：自说自话，说干就干，过于冲动）： 我从杰夫贝索斯那里学到.

在 Tableau， .

在真正的敏捷方法中，对问题的反应总是缩短反馈循环。从来都不是“更好地计划”。   众说纷纭： 这太绝对了，计划多少也是一个权衡。有时，使用.