信任自然导致自治。事实上，没有它，自治是不可能的。 这几乎就像信任是敏捷的先决条件。 正如我所看到的那样，问题在于我们（作为一个行业）并没有从一.

您可能会在软件开发中听到“ 精益 ”和“ 敏捷 ”这两个术语，并发现两者之间存在一些混淆。 虽然它们看起来可能相互矛盾，但在实际上这些术语及其基本概念.

敏捷并没有死，或者已经过时，或者已经过时了。 敏捷不是Scrum，也不是Less或Safe。 组织，团队和产品都不是敏捷的。 敏捷不是一个.

许多人认为“敏捷”这个词已被腐化到应该完全放弃的程度。我最近看到了“IT中最大的谎言”（我找不到链接），其中许多答案都是“敏捷”。 这个词已被歪曲，意.

1. 程序员测试应该很快 测试反馈不应该扰乱编程流程。 2.程序员测试应该是确定性的。 .

该文比较了软件工程中敏捷和瀑布两个方法，主要是分析了敏捷方法，指出敏捷方法的致命问题：我们们在系统开始时使用敏捷确实节省了分析和定义整个数据模型的时间，但经.

软件开发很难，真的很难，实际上，它不止一门学科，涉及工程，团队合作，设计，复杂的问题解决，领域专业知识等等。 要成为一名优秀的软件开发人员，您需要许多.

开发人员在任何软件项目过程中都会做出数百个微观和宏观决策。有些似乎相对无害，但对下游会有一个很大的影响。几位Cantina工程师聚在一起，回顾了我们在学习了.

“英雄”项目是20％的开发者提供80％或更多贡献的项目。很多项目被放弃，因为这些项目失败源于沟通的瓶颈，但是，关于这个问题的实证证据很少，此外，最近的研究表.

2014年之前，SpareBank 1是在一个单体的Weblogic门户上运行其整个网络银行应用程序，每个开发人员都使用相同的代码库，发布是艰巨的过程，开发.

有时你能做的最好的事情就是不编写代码！请记住，您的价值是能解决问题，而不是编写代码。编写代码也是具有价值，但需要成本、需要部署、维护和升级，它有bug，需要.

如果您正在使用测试驱动开发，请不要衡量单元测试的代码覆盖率，这比无用的统计更糟糕; 它会积极地引导你误入歧途。 你应该怎么做？这取决于你想要完成什么。.

敏捷和DevOps可能看起来像是不同的行为，但如果你看看他们的目标，你会发现它们非常相似。看看Agile和DevOps提供的价值。也就是说，看看DevOps.

几天前，我读完Melissa Perri的 Es.

客户经常会问的一个问题是：如何有效地提升开发团队的水平？你如何让一组从未编写过Python的工程师使其成为高效的Python开发人员？你如何让从未构建过分布.

这是成功的现代软件开发策略的四个基本部分。 无可挑剔，可靠，自动化的构建和部署系统 有效，低摩擦的协作 .

从Google趋势来看UML没有增长，是否意味着已经死亡，UML（以及RUP，AOSD和Essence）的创建者之一 .

没有一个尺寸的裤子适合所有人穿，没有银弹，没有一个解决方案适合所有场景。本文概述了各种软件方法学。 为什么软件方法学都不同？ 软件方法论主要是为.

任何参与敏捷与看板的人都无法避免Little定律（Little's Law），Little定律是一个等式:  L  = λ  W .

在测试代​​码时，仅为每种方法编写一个或两个 .

Symmathesy是“一起学习”的意思，把希腊语前缀Syn / Sym（一起）+ Mathesi，（学习）= Symmathesy。 软件不是一个工.

DDD原则是开发软件需要从业务需求开始。通常倾向于关注技术细节，但通过这种模式，设计基于核心业务目的和逻辑，同时可考虑到公司的战略方向。企业应用程序可能非常.

很多时候，客户对他们想要解决的问题提出的是一个“假的确定性”需求。他们可能没有定义真正的问题需求，而是经常定义解决方案。 风险在于如果将其误以为需求我.

这是一位使用DDD已经五年的经验分享： 我最近一直在谈论领域驱动设计（DDD），无论是在聚会还是与客户，所以我想我会写下我的想法，看看它是否有帮助。<.