敏捷工程方法

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

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

PO（产品负责人） 和 PM（产品经理） 是同一个组织，不同级别： 产品负责人：构建能解决问题的解决方案 产品经理：提出要解决的问题 集团产品经理：发现要解决的问题 主管：从组织中找到合适的人来解决已识别的问题 VP/CPO/Head of p

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

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

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

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

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

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

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

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

阶段性工作、回顾、完善和类似的工作所花费的时间是疯狂的。如果我假设每天有15分钟的停顿，两个小时左右的完善和回顾（我曾在一个地方有四个小时的完善），那简直就是把一天的冲刺时间浪费在了会议上。 如果团队中的人只是在电子邮件中告诉经理/主管 "我被这个

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

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

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

Shubhro Saha 是 Facebook 的工程经理。他写了一篇很棒的博客文章，介绍了如何更好地估计一个项目需要多长时间才能完成。一个很好的提示是始终清楚地将估计与目标与计划分开。目标可能是最乐观的，而计划是最悲观的（它解释了可能遇到的任何问题）。