敏捷工程方法

     

Defect和Bug有什么不一样? -Nikita

4760

Defect和Bug翻译成中文都是缺陷的意思,两者有什么区别? Bug是编程错误的结果,Defact缺陷是与需求的偏离。Defect缺陷不一定表示代码.

对于信息系统,DDD事件建模比敏捷更真实有效 - Adam

958

事件建模对信息系统而言比对敏捷性所希望的更为真实。 以我的经验,“敏捷”意味着没有雇用足够的人员,而没有进行充分的.

商业软件开发的下一个重大步骤:协作建模(CoMo)的本质 - WPS

2486 1 3K
我们总结了“协作建模”(以下简称“ CoMo”)背后的想法和概念。在“敏捷”和“领域驱动”之后,我们将“ CoMo”视为商业软件开发的下一个重大步骤。 .

一个软件开发团队多少人合适? 大型团队失败是由于缺乏共识和沟通带来的技术债务 -mfeather

1849 1

拥有非常小的团队规模能使达成共识变得容易。让多个人一起从事某项工作的协调性的补偿性流程会让人感到惊讶。小团队的失败模式是 .

如何划分有界上下文? - nick

1911 1
两个概念之间的耦合与某些属性有关。不论哪个属性更改都会影响一起更改的内容。我们的有界 .

ddd-crew/ddd-starter-modelling-process:DDD设计入门建模流程

10234 6 10K
如果您是DDD的新手,并且不确定从哪里开始,则此流程为您提供了逐步指南,帮助学习和实际应用域驱动设计的各个方面:从围绕组织的业务模型定位到编码域模型。 .

幽默:数十年来TOGAF的致命问题 - Serge Meijboom

1870 1

TOGAF数十年来的方向出错了:数据架构竟然是信息系统架构的一部分,其实信息系统架构应该是和数据架构没有依赖的,数据应该与技术无关。 .

敏捷最佳实践:设计冲刺完整指南 -Useberry

2687 3K
在您的项目中执行设计冲刺(design sprint)的好处是:在非常短的时间内创建用户验证的原型。由杰克·纳普(Jake Knapp)先生在Google期.

减轻敏捷实战中故事点发生漂移的风险 - modernanalyst

958 3K

在许多敏捷项目中,需求通常不是以正式需求文档的形式编写的。取而代之的是,通常使用一组简洁而有效的方法来描述必须构建的内容,即用户故事。用户故事从客户的角度描.

用于业务分析设计的扎克曼框架 -AMIS

3172
敏捷团队使用迭代的、需求驱动的、务实的方法来实现IT实施、变更和运行。这些团队的业务范围如果是有限的,效果则很好。这有助于团队以灵活和富有成效的方式执行任务.

GitHub - mariuszgil/awesome-eventstorming: 事件风暴建模工具集

3416 2

EventStorming是一种基于研讨会的方法,可以快速找出软件程序领域中正在发生的事情。与其他方法相比,它非常轻巧,不需要计算机的特别支持。在宽阔的墙上.

敏捷实战分享:Runtastic停止了估算故事并改善冲刺,效率提高30%

942

我们的一些团队成员是Allen Holub的追随者。他是 .

数字型公司或数字业务的价值链是什么? - modernanalyst

1997
如今,奥迪和汇丰银行等公司在其所有领域中都使用了IT系统。这是否使他们成为IT公司而不是银行?大多数人可能会认为汇丰是一家银行,就像奥迪是一家汽车制造商一样.

使用DDD等方法实现社会技术架构和团队管理:你的经理还用拍脑袋划分团队吗? - Nick Tune

1917 1 2K

很长时间以来,我对公司组织软件开发团队的方式感到失望。 我记得我还是一个年轻的,天真的软件开发人员,我曾假定会存在类似于设计软件架构的结构化过程和模式.

为什么产品经理应该关心业务战略? - romanpichler

1371 3K
作为产品人员,我们可以非常喜欢我们管理的产品。尽管在乎它们是件好事,但我们一定不能忘记它们是达到目的的一种手段:产品的存在仅仅是为了为其用户和业务创造价值。.

当心SAFe(企业级扩展敏捷框架)变成黑暗的邪恶化身 - Sean Dexter

2719 1 3K

企业级可扩展敏捷框架是一些原则和实践的集合,旨在为大型公司提供一种“扩展”敏捷工作模型的方法。自2011年成立以来,SAFe经历了巨大的增长。全球将近 .

鲍勃大爷:“如果您不喜欢结对编程,就不要结对, 但是要做好准备让那些已经使用配对技巧的人飞越您。”

1237

众说纷纭: 嗨,鲍勃:从您的经验来看,您确定两位从事同一任务的程序员的身价比从事不同任务的程序员的价值高两倍吗? 鲍勃大爷回:那当然是我的经验。.

向领域驱动设计前进: 如何使用DDD从单体到微服务迁移打造业务平台或中台? -Kevin Mas Ruiz

5455 5 5K
如果您的公司建立在单体monolith之上。由于您的业务知识在内部传播,因此这种单体monolith可能是您的最佳资产,但是由于多年的技术债务和团队在相互沟.

鲍勃大爷:敏捷是让经理面对惨淡的现实!是不是这种试错成本太高?

1499 1

敏捷并不是要更快。敏捷是要摧毁希望。一个优秀的敏捷团队所产生的数据为经理们提供了冷淡的现实,使他们能够及时进行管理。 .

软件质量的认识论:每晚有多少睡眠?你工作愉快吗?这些是最影响软件质量的问题。 - increment

1560 2 2K

研究表明,人为因素最影响我们的工作质量,可是为什么我们会投入更多精力希望通过技术性解决方案解决软件质量呢? 假设您经营一个新团队。您可以一刀切地实施任.

为什么软件工程师或程序员脾气暴躁? -Human Who Codes

5361 3 11K

通常,软件工程师通常以傲慢,不愉快和喜怒无常而著称。声誉不是随机分配的,它们是根据经验获得的。使声誉困扰我的是,我本人认识许多软件工程师,并且他们通常是爱好.

瀑布和迭代可混合:敏捷定义者Martin Fowler定义瀑布法

5028 1 3K
在软件世界中,“瀑布”通常用于描述一种软件过程样式,该样式与迭代样式或敏捷样式的思想形成对比。像软件中的许多著名术语一样,其含义不明确且来源不明确-但我发现.

DDD与敏捷非常类似,它们都喜欢哲学、思维方式、原则与规则。 - jamesmh

1835

dddesign就像agile。许多人认为这与低级的具体实现细节和策略有关。但是,实际上,两者或多或少都像是一种思考软件和业务问题的方式。他们喜欢哲学....

Michael Feathers预言:在5年内,对特性团队(Feature Team)是个错误的想法将达成共识。至少不会像现在这样流行。

2707 3

围绕一个系统的某个区域的活跃的领域知识才是有保存价值的基本单位,但是这容易被破坏隔离,领域的知识连续性很重要,DDD的有界 .

幽默:如果你听人说:它昨天还挺好啊,那么可以断定你们是在一个软件项目。

1565 1

Mario Fusco总结对软件系统的误解和谬论: 如果X为大公司Y工作,它也会很适合我们。 100%的测试覆盖率意味着100%的正确性。 .

幽默:如何变得敏捷?- tottinge

745

“我们如何变得敏捷?” “首先,重视个人和交互,而不是流程和工具。” “很棒!让我们安装该流程和一组用于执行该流程的工具。” “等等……个.

被Medium删除后又恢复的敏捷文章:我们何不称敏捷为女权主义者? - Hanna Thomas

714 1 4K

敏捷运动倡导人Ron Jeffries特地致意Medium媒体:我是撰写敏捷宣言的“老白人”之一。我读过这篇文章,虽然我不同意每一个字,但它是一篇完全合理的.

经验分享:在金融企业中实施领域驱动设计的敏捷实践 | 敏捷联盟

1884 2 11K

我参与了几次敏捷转换。我所工作的每家公司都提出了同样的问题:我们如何将当前的软件划分为团队,以及我们如何使这些团队与我们的业务目标保持一致?在本报告中,我将.