问作为一名开发人员，敏捷真的为你工作过吗？

EN

在我的第一份工作中，我们有每天的scrums，编写自动化测试，自动化构建，结对编程，等等。我们已经在敏捷领域工作了几年。由于我们的努力，我们得到了软件的奖励，我不会用20英尺长的杆子碰它。我们的产品质量太差了:我将其描述为100名业余开发人员的零敲碎打。

哪里出了问题：

我工作过的

• 公司有一个臭名昭著的名声，那就是以最低的工资雇佣入门级开发人员(标准是25-27K美元/年)，而且我们经常把工作外包给出价最低的离岸竞标者。我听说敏捷不适用于经验不足的开发人员，我认为这从代码和人员流失率中可见一斑。
• 没有任何类型的文档。没有功能文档，没有技术文档，没有需求，没有bug跟踪。从来没有人在持久的媒体上写下东西:所有的需求和but都是通过电子邮件、口碑和心理mindreading.
• Lousy测试进行沟通的:我们的自动化测试是无价的，但QA和UAT测试是一场灾难。因为我们没有任何正式的需求文档，QA用户不知道他们正在测试什么新功能，所以所有的QA或多或少都包含了随意的端到端测试。用户接受测试是在生产中进行的:我们在客户的服务器上安装了产品，并在production.
• Crisis-driven开发中报告了错误:错误是通过使用“天哪，我们必须立即修复并重新部署！现在现在！没有时间测试只修复IT!”来处理的。管理方法。

尽管我们做的每一件事都是正确的，并且真的遵循了敏捷原则，但这种方法的失败比我见过的任何其他事情都要严重。

相比之下，我工作的公司现在使用类似瀑布的方法，为每个项目生成几百页的文档，几乎没有自动化测试，但有一个相当大的QA团队。有趣的是，我们的产品质量达到了顶峰，工作环境也比其他公司高出几个数量级。

我知道很多人都有过相反的经历。通常情况下，方法论不是金锤子-无论您选择哪种方法论，您都可能启动一个成功的项目。在我成功和失败项目的经验中，我感觉到方法论并不像环境那么重要:舒适、快乐的开发人员和理智的项目经理就是让项目工作的全部条件。

在我的公司，大约4年前，当一位新的副总裁上任时，我们进行了一次大规模的敏捷实践。这位副总裁在过去经历了敏捷的成功，并决定这是我们需要的。

事实证明，他是对的。我当时是一名开发人员(尽管有点初级)，我喜欢这种做法。结对编程确实有助于知识转移，并防止知识孤岛的形成。单元测试、测试驱动开发和测试重点通常会产生更健壮的代码，而不是过度设计。没有大的前置设计意味着，我们不是花6个月的时间来编写需求文档(当时市场已经与我们擦肩而过)，我们正在进行原型设计，并及时向客户交付真正的价值。与客户代理(在我们的案例中，是技术产品经理)密切合作，大大缩短了周期反馈时间，这帮助我们交付了客户真正想要的东西。

我们的组织有相当多的有才华的开发人员，但我们非常倾向于牛仔编码。一些开发人员不喜欢新的实践(“你是什么意思，写测试?我是一个开发人员！”)，但总的来说，每个人都喜欢这些变化。不良率下降了，客户满意度上升了，我们的办公室在我们公司得到了很好的评价。

大约一年前，我成为了一名经理，我大量使用敏捷实践，并纳入了一些精益原则(价值流分析、消除浪费、看板)。收紧发布周期一直是一项持续的活动，我的团队现在尽可能频繁地发布(有质量的！)-通常是每两周发布一次。在过去的一年里，我的团队没有任何现场报告的缺陷，销售人员和产品管理人员喜欢较短的发布周期。

作为一名开发人员，敏捷确实增加了我在处理各种代码领域的信心(现在每当我在没有100%单元测试覆盖率的包中更改任何东西时，我都会感到紧张！)，教会我成为一个更全面的程序员(考虑到测试的影响，业务影响等)，并帮助我编写简单的、自我文档化的代码。作为一名经理，敏捷和看板给了我可预测性，更低的交付期，更低的缺陷率，以及一个强大的团队。这不是理论，也不是猜测，也不是挥手示意--我们的团队士气、缺陷率、客户满意度和资产负债表已经证明，敏捷可以为组织做出卓越的贡献。

根据我在一个尝试过的网站上的经验，对Principles of the Agile Manifesto发表评论。

我们的首要任务是通过早期和持续交付有价值的软件来满足客户。

这对我的上一个网站来说是一把双刃剑--有价值的网站被认为是100%完美和没有bug的。

欢迎不断变化的需求，即使是在开发的后期。敏捷流程利用变化来获得客户的竞争优势。

我仍然在和那个网站交流，就在今天，他们的截止日期，他们得到了一个需求变化。事情就是这样的；他们似乎想要失败。

经常交付可工作的软件，从几周到几个月不等，并且更倾向于较短的时间尺度。

多年来的标准基本上是每天、每小时、接近实时地构建和部署……

在整个项目中，

业务人员和开发人员必须每天一起工作。

与此相关的一些会议/评论非常滑稽。我们因为没有与人们一起工作而受到指责(因为他们要求我们不要这样做，因为他们已经每天工作9-10个小时)，然后因为他们很忙而打扰他们。

围绕有动力的个人构建项目。为他们提供所需的环境和支持，并相信他们能完成工作。

这就是我们的问题..。我们有最好的个人电脑，但商务方面并不支持。积极的士气基本上在大约一年后就被击败了……这也否定了您的微观管理问题(如果正确实现的话)。

向开发团队和开发团队内部传达信息的最有效和最有效的方法是面对面交谈。

这样做效果很好。就我个人而言，我更喜欢电子邮件，因为我讨厌做笔记。

工作软件是进步的主要衡量标准。

毫无疑问，在这里。

敏捷流程促进可持续发展。发起人、开发人员和用户应该能够无限期地保持不变的步伐。

我100%同意这一点；与我一起工作的最后一个业务团队的问题是，我不同意每天工作30小时，每周工作10天，工作400天的期望。

对技术卓越和良好设计的持续关注提高了敏捷性。

这是需要一些开发人员士气和教育的地方。

简单性--最大化未完成工作量的艺术--是必不可少的。

我喜欢这个，它一直是我的目标之一。然而，有一种“如果你不打字，你就不是在工作”的态度很难克服。

最好的架构、需求和设计来自自组织团队。

我同意这一点，大约90% --我唯一的警告是，他们必须是受过良好教育和消息灵通的团队。

每隔一段时间，团队就会思考如何变得更有效，然后相应地调整和调整行为。

我们只是在这里失败了，这可能会导致我们有很多其他的问题。业务方面真的很擅长说“你需要做我们所说的需要做的事情”。

总而言之，如果你在一个每个人都了解敏捷方法的地方工作，那么它应该是一个很好的工作场所。当目标是伟大的软件时，势头本身就可以承载任何项目。