敏捷工程方法

你们中的大多数人都熟悉加入一家新公司的感觉，并有那种重写一切的冲动。看到你的新团队成员几年前犯下的亵渎神明的行为，让你的眼睛很痛。当然，你知道的更多，你会在开发该功能时遵循最佳实践。对吗？ 可能是吧。但多年来，我了解到，"最佳实践 "的问题在于它们

组件团队：每个团队负责一个系统组件。例如，有一个团队负责前台，一个团队负责后台，还有一个团队负责数据库。这三个团队独立运作，这经常导致团队之间的相互依赖。这些团队不是为最终用户提供价值，而是花了很多时间来讨论依赖关系和测试各组件的行为。从买方的角度来看，这些要素完全不重要。组

如果我可以推荐一本专业书籍给任何从事 IT 工作的人阅读，那就是Mathew Skelton 和 Manuel Pais 的《团队拓扑》。顾名思义，主题是关于组织业务

来自 PayPal、Wealthfront、Pinterest、Netscape 等公司的创业老手已经确定了精益创业的四个核心挑战： 挑战#1：精益创业鼓励不可知论的实验，而不是从一个引人注目的战略开始。精

Big Design Up Front（简称BDUF） 是一种在开始实施之前预先完成和完善网站、应用程序或软件设计的方法。它需要一个瀑布过程，并且依赖于预测。这是在敏捷出现之前几十年的流行方法。过去，网站和软件的构建成本非常高，因此有必要在成本高昂的工程发生之前解决尽可能多的问题。把

Eliyahu Moshe Goldratt是以色列的商业管理大师，他是优化生产技术、约束理论(TOC)和其他TOC衍生工具的创始人。 约束理论是一种方法，用于识别阻碍实现目标的最重要的限制因素（即约束），然后系统

可逆的决策（Reversible Decisions）可以快速做出，而且不用纠结于寻找完整的信息。这种决定不是鲁莽行事或信息不足的借口，而是一种信念，即我们应该使我们的决策框架适应我们所做的决策的类型。 一旦你面临一个决定，问题就变成了你应

无论大小，无论产品还是服务，每个组织在实现精简流程方面都有多个路障。一个解决方案是解决工作流程的瓶颈问题。 当有更多的工作超出流程所能处理的范围时，就会出现瓶颈问题。由于两边的能力已满，以及生产的涓涓细流流向了下一个步骤，瓶颈就会产生等待。

按重要性和紧迫性确定您的行动和任务的优先级 以美国总统德怀特-D-艾森豪威尔的名字命名，这个优先级框架将帮助你按重要性和紧迫性组织你的任务和活动。当你很忙但又觉得你所做的事情没有什么影响时，它就特别有用。

产品导向增长 (PLG) 是一种业务方法，其中用户获取、扩展、转换和保留都主要由产品本身驱动。它围绕产品创建整个公司范围内的团队，从工程到销售和营销，这些是作为可持续、可扩展业务增长的最大来源。 公司的各个团队如营销、销售、CS、设计、工程以产品为

敏捷无处不在。似乎每个人都想成为敏捷。如果你没有敏捷的团队，你就是一个恐龙。 但是，一个组织并不是简单地成为敏捷。下面是组织在成为敏捷时犯的十个错误。 10. 自上而下的敏捷实施

在构建产品时确定速度和质量之间的权衡。 在产品开发中，速度和质量是两个重要的变量。优先考虑一个通常是以牺牲另一个为代价的。该工具将帮助您做出权衡。 您优先考虑速度或质量的决定应基于您对以下方面的信心：

”流程process“是为了完成一项任务而要遵循的指令清单。例如：一个业务流程，像一条装配线，有离散的步骤和/或交接的编排。 “技巧technique” 是一种执行过程的方式，在某一领域有经验的人随着时间的推移学会了这种方式，即 "交易技巧"。例如

Scrum承诺要解放开发者：它是对定义许多瀑布项目的命令和控制做法的彻底转变。Scrum是关于自我管理的团队和可持续的步伐。它应该是一种 "高贵的体验"（Agile Software Development with Scrum (Schwaber and Beedle), 2001

敏捷项目已经变成了 2 周冲刺的臃肿、懒惰的瀑布项目。瀑布式生产线方法适用于具有已知需求或制作小部件的项目。 敏捷宣言充满

关于如何更快地交付软件的讨论在我们的社区中无处不在。围绕着流程和组织结构的讨论有很多，但围绕着提高信任度作为快速流程的促成因素的讨论却不多。 今年，我有一些对话和经历，让我真正意识到信任的重要性。特别是，领导层和工作团队之间的信任关系。这是我已经观