敏捷工程方法

     

Jay Little:低代码软件开发是一个谎言

807 2

设计一个该死的解决方案实际上是软件开发过程中最困难的部分。低代码工具通过暗示编写代码是最难的部分来欺骗客户。任何低代码工具都不能使你免于花时间正确设计你的定制软件,也不能使你免于在围绕半成品设计建立解.

​​​​​​​“交付日期”是最糟糕的瀑布式思维 - Allen Holub

510 1

“交付日期”是最糟糕的瀑布式思维。具体交付什么是我们在工作中学习如何交付。每天交付。逐步改进,先做最重要的事情。大批量思维是一种反模式!问:很多年前我有过一次艰难的交货日期。 一个系统正在进入挪威山顶.

如何在产品领导力培训中使用决策工具栈? - Petra

399 2K

如果您发现自己在担任产品负责人时难以做出有效的决策,或者您在想出一个有凝聚力的产品策略时遇到困难,那么您并不孤单。也许您的直接下属不断向您寻求指导和方向,但不确定该走哪条路。听起来有点熟?如果是这样,.

什么是垂直软件开发?

879 6K
敏捷方法现在可能很普遍,并且有了它,增量方法的概念应该被开发社区所了解和利用。尽管如此,在与开发人员交谈时,我仍然发现它的理论与它在日常开发实践中的应用之间存在脱节。我认为这种脱节部分是由于我们分层构.

大语言模型LLM能否对自己的成果进行批判和迭代? | evjang

631

在计算机科学的许多领域(密码学,NP复杂性),验证解决方案比生成解决方案容易得多。这篇博客文章发现大语言模型LLM(主要是GPT-4)可能能够自我验证其解决方案。与概率推理和最优控制中的大多数算法思想.

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

939 4K

虽然我在 Spotify 工作了大约 8 年,但我并不熟悉每个领域的运作方式,而且我有自己的偏见、偏好等。而且情况会发生变化敏捷 > ScrumSpotify 早期主要采用 Scrum(在我的时间之前.

很容易用敏捷构建错误的东西 - Reddit

863

敏捷会帮助你高效地建造东西,但你最终可能会在建造错误的东西时非常高效。产品迭代的短反馈循环是敏捷如何比瀑布格式更不可能构建错误的关键所在,反馈是敏捷的燃料。与您的客户、用户和/或利益相关者交谈。与您的.

困扰开发人员使用 Scrum 的 9 个实践

968 8K

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

认知偏差:什么是可逆和不可逆决策?

1247 2K

可逆的决策(Reversible Decisions)可以快速做出,而且不用纠结于寻找完整的信息。这种决定不是鲁莽行事或信息不足的借口,而是一种信念,即我们应该使我们的决策框架适应我们所做的决策的类型.

敏捷工程中流程,技巧,方法和方法论之间有什么区别?

988

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

精益创业方法论的四个主要问题 — Reforge

1479 3K

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

几种著名的战略思想设计工具介绍 - Chris

2151 1 4K

本文是对我探索过的一些想法/书籍和概念的简短探索:1、《好的战略/坏的战略》 - 理查德-鲁梅尔特大多数战略都很糟糕,或者是超级衍生的、通用的和模糊的。这是一本关于如何制定战略以帮助人们在组织内做出决.

什么是Big Design Up Front以及利弊?- Benek

1399 4K

Big Design Up Front(简称BDUF) 是一种在开始实施之前预先完成和完善网站、应用程序或软件设计的方法。它需要一个瀑布过程,并且依赖于预测。这是在敏捷出现之前几十年的流行方法。过去,.

提高信任以实现快速流动 - Nick

737

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

敏捷项目已成为Sprint的瀑布项目 - Ben

845

敏捷项目已经变成了 2 周冲刺的臃肿、懒惰的瀑布项目。瀑布式生产线方法适用于具有已知需求或制作小部件的项目。敏捷宣言充满热情、活力和可以做的态度。它使小型团队能够在最少的指导下创建软件,并告诉他们去获.

软件开发是非常主观的 - vadim

1700 1 2K

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

什么是产品主导型增长? - productled

1102 5K

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

Slack使用“产品三人组”模型构建微服务团队 - smnbs

1762 1 2K
在过去的 10 年中,我曾参与过多次扩大规模的工作,因此我采用了一些原则来扩大技术和产品团队的规模。第一个,是组织跨职能的团队。通常,要构建任何产品,您需要产品经理代表业务,产品设计师代表客户和工程师.

公司为变得敏捷而犯的10大错误

1089 3K

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

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

1537

如果我可以推荐一本专业书籍给任何从事 IT 工作的人阅读,那就是Mathew Skelton 和 Manuel Pais 的《团队拓扑》。顾名思义,主题是关于组织业务和技术团队以实现快速流动。我想说这.

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

3658 1

组件团队:每个团队负责一个系统组件。例如,有一个团队负责前台,一个团队负责后台,还有一个团队负责数据库。这三个团队独立运作,这经常导致团队之间的相互依赖。这些团队不是为最终用户提供价值,而是花了很多时.

五个步骤移除约束瓶颈 - sbj

1241

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

几条有关约束理论的管理格言

1388

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

速度与质量之间权衡 | Untools

1019

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

思考工具之艾森豪威尔矩阵 | Untools

1201

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

产品经理和产品负责人之间的职责是如何划分? - Reddit

1409 1

PO(产品负责人) 和 PM(产品经理) 是同一个组织,不同级别: 产品负责人:构建能解决问题的解决方案 产品经理:提出要解决的问题 集团产品经理:发现要解决的问题 主管:从组织中找到合适的人来解决已.

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

1053

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

软件工程估算的技巧 - shubhro

665

Shubhro Saha 是 Facebook 的工程经理。他写了一篇很棒的博客文章,介绍了如何更好地估计一个项目需要多长时间才能完成。一个很好的提示是始终清楚地将估计与目标与计划分开。目标可能是最乐.

软件工程团队的基于领域的结构 - snaptravel

825 2K

2021年初,在Snapcommerce,我们有25名工程师在班组工作。每个小组都有一个工程经理(EM)作为所有项目的负责人和技术负责人(TL),一个产品经理(PM),一个设计师,一个QA团队成员,以.

认知偏见之锚定偏差

5681 2K

锚定偏差(第一印象偏见:anchoring bias)是一种认知偏见,它导致我们过于依赖我们获得的关于某个主题的第一条信息。当我们制定计划或对某事进行估计时,我们会从锚点的参考点解释新的情况,而不是客.