agile - 作为开发人员，敏捷真的对你有用吗？

Question

我遇到了很多敏捷工作的人，他们中的大多数人往往是计划和委派工作的经理和架构师。然而，我真的没有找到多少优秀的开发人员相信敏捷正在为他们工作。

当然，如果敏捷不适合你，你可以说你做得不对。但是，无论有什么敏捷混音，它对作为开发人员的你有用吗？为什么？有没有人认为，在传统（或接近）的团队结构中，敏捷感觉更像是一种微观管理而不是自我管理？

Answer 1

在我的第一份工作中，我们每天进行 scrum，编写自动化测试，进行自动化构建，结对编程等。我们已经在敏捷领域工作了好几年。由于我们的努力，我们获得了我不会用 20 英尺杆接触的软件。我们产品的质量非常糟糕：我将其描述为 100 名业余开发人员的零碎黑客行为。

什么地方出了错：

• 我工作的公司以以最低工资（每年 25-27K 美元是常态）雇用入门级开发人员而臭名昭著，而且我们经常将工作外包给最低的离岸投标人。我听说敏捷不适用于没有经验的开发人员，我认为它通过代码和我们的流动率显示出来。

• 没有任何形式的文件。没有功能文档，没有技术文档，没有要求，没有错误跟踪。从来没有人在持久性媒体上写下任何东西：所有需求和错误都是通过电子邮件、口口相传和通灵读心术传达的。

• 糟糕的测试：我们的自动化测试非常宝贵，但 QA 和 UAT 测试是一场灾难。由于我们没有任何正式的需求文档，QA 用户不知道他们正在测试什么新功能，所以所有的 QA 或多或少都由随意的端到端测试组成。用户验收测试是在生产环境中进行的：我们将产品安装在客户的服务器上，并在生产环境中报告错误。

• 危机驱动的开发：错误是通过使用“OMG 我们必须修复这个并立即重新部署！现在现在现在！没有时间测试只是修复它！”来处理的。管理方法论。

尽管我们所做的一切都是正确的，并且真正遵守了本书中的敏捷原则，但这种方法比我见过的任何其他方法都失败了。

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

我知道很多人都有相反的经历。通常情况下，方法论并不是一把金锤——无论您选择哪种方法，您都可以开始一个成功的项目。根据我对成功和不成功项目的经验，我觉得方法论与环境并不重要：舒适、快乐的开发人员和理智的项目经理是项目成功所需要的一切。

Answer 2

在我的公司，大约 4 年前，当一位新副总裁上任时，我们大规模地转向敏捷实践。这位副总裁过去曾在敏捷方面取得成功，并认为这是我们所需要的。

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

我们的组织有很多才华横溢的开发人员，但我们非常倾向于牛仔编码。一些开发人员不喜欢新做法（“你是什么意思，编写测试？我是开发人员！”），但通常每个人都喜欢这些变化。缺陷率下降了，客户满意度上升了，我们的办公室在我们公司中得到了很好的评价。

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

作为一名开发人员，敏捷确实增加了我处理各种代码领域的信心（现在，每当我更改包中没有 100% 单元测试覆盖率的任何内容时，我都会感到紧张！），教会我变得更好- 全面的程序员（考虑测试影响、业务影响等），并帮助我编写简单的、自我记录的代码。作为一名经理，敏捷和看板给了我可预测性、更短的交货时间、更低的缺陷率和一个授权的团队。这不是理论、推测或挥手——我们的团队士气、缺陷率、客户满意度和资产负债表已经证明，敏捷可以为组织做一些很棒的事情。

Answer 3

根据我在一个尝试过的站点的经验来评论敏捷宣言的原则。

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

对于我的上一个站点来说，这是一把双刃剑——有价值意味着 100% 完美且没有错误。

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

我仍然与那个网站沟通，就在今天，他们坚如磐石的截止日期，他们被要求更改。事情就是这样。这几乎就像他们想要失败一样。

频繁地交付工作软件，从几周到几个月不等，优先考虑更短的时间范围。

多年来的规范基本上是每天、每小时、近乎实时地构建和部署......

业务人员和开发人员必须在整个项目中每天一起工作。

一些与此相关的会议/审查很有趣。我们因不与人们一起工作而受到谴责（因为他们要求我们不要这样做，因为他们已经每天工作 9-1​​0 小时），然后因为他们很忙而打扰他们。

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

啊，这是我们的问题……我们有顶级的个人电脑，但业务方面并不支持。大约一年左右后，积极的士气基本上被打败了......这也否定了你对微观管理的担忧（如果实施得当）。

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

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

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

这里毫无疑问。

敏捷流程促进可持续发展。赞助商、开发人员和用户应该能够无限期地保持恒定的步伐。

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

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

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

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

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

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

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

团队定期反思如何变得更有效，然后相应地调整和调整其行为。

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

总而言之，如果您在每个人都了解并采用敏捷方法的地方工作，那么它应该是一个很好的工作场所。当目标是伟大的软件时，任何项目都只能靠动力。

Answer 4

在我当前的环境中，作为一名开发人员，敏捷对我来说非常有用。以下是一些实践以及为什么它似乎运作良好：

• 结对编程——这可以防止任何人感觉到代码的个人所有权。一对开发人员往往比一个人的“疯狂科学”代码编写更好的代码，如果一个人单独编写一堆代码似乎会发生这种情况。这也允许在某人离开时引入其他人，并且该功能或增强必须在该人离开时完成。有时，一位开发人员可能认为某些东西会很棒，但如果没有其他人能够理解代码，那么拥有它是没有用的，除非它是完美的和面向未来的，这是不可能的。

• Scrum - 这创造了责任感和沟通，以便每个人都知道对方在做什么。如果有人想知道 sprint 的进展如何，只需出现在站台上即可。站会非常简单，只有 3 个问题：我昨天做了什么，我今天在做什么，以及什么会阻止我完成这些工作？

• 测试驱动开发——在我工作的地方，我们通常会尝试对我们正在编写的大多数管道代码进行测试，以在我们正在做的大项目中定制一个 CMS。这种心态可能很难进入，尽管随着人们更多地练习它会变得更容易。

• YAGNI - 如果你是一个有洞察力的程序员，通常会将 101 件事作为“好吧，有一天我可能需要这个……”的心态，那么“你不需要它”的原则真的很难。另一种说法是“保持简单，愚蠢”的想法。

• Sprints - 这里的想法似乎只是为了防止一种不知所措的感觉，因为我们只是在这个或那个上工作了 2 周，并且不要看得太远，因为它很可能会改变。

• 演示 - 展示我们所做的事情，获得​​关于什么是好的和什么不好的反馈对于让事情变得更好以及拥有我们希望在项目中“持续改进”以及今天什么已经足够好的心态至关重要，不会明天要足够好，在我们所做的事情上做得更好。

• IPM，回顾 - 回顾回顾中所做的事情的能力对于发泄挫败感、庆祝工作顺利并找到解决痛点的方法很有用。IPM 是我们确定下一个冲刺的未来的地方，根据目标是什么以及我们认为通过使用几种不同的估计工具需要多长时间来完成各种事情，其中​​一个是我们称之为“史诗”的点，以及另一个是几个小时的个人任务或卡片，这是故事的一部分，介于史诗和小作品之间。

• 故事墙和用户故事 - 现在这个低技术工具，因为它只是几个白板，带有分隔线和帖子，它为事物提供了一些结构。我们为每个史诗和各种工作状态列设置了通道：待办事项、开发中、开发中或测试中。还有一些地方可以放置任务积压、阻塞的卡片、问题、标准和实践以及其他一些可能对经理有用的东西站起来。

• 破碎的窗户/技术债务/任务 - 这些在某些方面是相似的，并且可以用来说明质量问题，即我们不希望破碎的窗户可以通过使用房屋在非技术术语中轻松解释一个社区或纽约地铁系统作为起点。技术债务是一种不会立即增加业务价值的东西，有时它是用来防止某些问题的重要东西，因为特定架构可能存在问题，因此部分冲刺可能会花费在重新构建上进行沟通，以便如果有一个几乎没有演示的 sprint，这就是原因。

我不知道“自组织”或“自管理”团队的想法是否是敏捷的一部分，但对我来说，对我的同事有足够的信心和信任是一个挑战一切都会好起来的。我团队中的其他专业人士知道必须做什么，他们是合理、诚实的人，正直地完成工作，而不是做事的混蛋。没有自负或不良态度确实有助于促进团队建设。

Answer 5

敏捷对我不起作用，主要原因是我通常开发的系统需要一个定义明确且经过深思熟虑的架构，而这很难通过敏捷方法实现。敏捷方法倾向于编写尽可能少的代码来通过适用的测试，从而有机地发展系统。从许多角度来看，这可能很好，但从架构的角度来看，它会造成严重破坏。

Answer 6

根据我的个人经验，敏捷方法从长远来看往往会产生巨大的技术债务，虽然它可能会在短期内为您（作为企业主/管理层）节省几美元，但从长远来看，它会回来并咬人你。无论您现在不解决什么，最终都会花费您许多小时的工作来解决，而成本要比您在最初的问题上投入更多时间所花费的成本要高得多。

从初学者和管理人员的角度来看，敏捷总是很棒，但我不知道有一位经验丰富的程序员真正喜欢它。敏捷的全部意义在于为公司节省开发资金，它与实际产品质量无关。事实上，大多数方法都提倡快速完成糟糕的代码而不是精心设计的代码。不同之处在于，几年后，您必须重新完成整个工作，而精心设计的代码可以持续数十年而无需更正。优秀的程序员大多数时候不需要敏捷方法。

我们有一个 22 年前由一个由 3 名程序员组成的团队使用瀑布方法编写的业务逻辑库，从那时起，该代码就不需要进行一次更正。因为它设计得当，设计精良，三位程序员花时间仔细地实施。相反，敏捷方法会要求这三个人做严格的最低要求，以确保通过一些定义不明确的测试，然后等到下次碰壁时再添加一些胶带代码。这是一种荒谬的工作方式，违背了我体内的每一根工程师纤维。

直到今天我都拒绝在敏捷环境中工作，因为坦率地说我不需要它，而且我不需要一个认为我确实需要它的雇主。

Answer 7

敏捷不是一种方法论，它是具有一组共同目标的方法论的一个子集，而且这些方法论通常不会根据团队构成、企业文化和实施而产生截然不同的结果。

在我的脑海中，纯粹的开发人员敏捷实践将包括结对编程、TDD、用户故事而不是规范、所有代码都将被重构几次的假设（尽管这是 TDD 的一部分）和代码审查比任何事情都重要。影响我们的事情是每日站会、定期直接与用户互动、事后反思以及非常紧凑的开发周期。

Answer 8

我同时是一名开发人员和一名经理，所以我要么有特别的见解，要么我的意见完全无效。;)

我会说敏捷意味着很多东西。在这一点上，它实际上是一整套方法和指南。

将自己暴露在所有这些有趣的想法中确实很重要。作为一名经理，我很难下令整个团队突然采用一种完整的方法，但如果他们看到我不断尝试改进我比赛的各个方面，我想他们会欣赏这一点。希望，如果他们喜欢他们所看到的，他们会效仿我的榜样。

我已经设法慢慢地从 Scrum 中实现了一堆东西，而没有（希望）作为一种工具出现。白板上的燃尽报告、站立会议和故事卡确实使我们在交付软件方面做得更好。例如，在任何项目上，任务都经常提前或延迟完成。在一个非常大的项目中，很难判断这对您的发货日期有什么影响。通过烧毁报告，我可以判断一张单据对我们的发货日期有什么影响，以及我们是否需要开始削减功能以赶上最后期限。

这更多是管理方面的事情，但这里的其他开发人员关心它，因为这可能意味着他们可以保住工作或避免死亡行军。:)

但这不仅仅是管理的东西。敏捷中有大量关于源代码控制、单元测试等的最佳实践。只是好的可靠的最佳实践。作为一个行业，我们对指导非常糟糕，所以这些信息就在那里是件好事。

Answer 9

从开发人员的角度来看，我认为它运作良好。在我看来，敏捷技术的共同点是，与非敏捷方法相比，定义任务、处理任务和从任务中获取反馈之间的循环非常小。

以 TDD 为例：编写测试代码，红色条，编写功能代码，绿色条，重构，红色条，修复，绿色条。

从经理的角度来看，这种更快的反馈循环也是正确的：每日会议一，状态绿色，每日会议二，状态黄色，对策/重新分配资源，每日会议三，状态绿色。

即时反馈和了解您的前进方向会给人一种安全感。

Answer 10

在所谓的“传统团队”中，敏捷开发将增加单个开发人员对管理层的可见性。这可能会让管理人员和架构师更好地规划他们的工作。当然，这可以解释为微观管理。

但从组织的角度来看，如果它产生结果，谁在乎。

Answer 11

我想是什么让“敏捷”项目变得敏捷，是方法论：“为今天而不是明天设计”。

对于任何非生命关键的软件系统，这是一种让程序员保持编码而不是讨论设计年龄的方法。请注意，设计并没有被废弃，它只是在更小，因此更容易监督的块中完成。

与敏捷相关的所有其他技术，例如结对编程，都是更多借用的想法，也可以在任何其他方法中有效地使用。

现在，这种技术“有效”吗？是的！如果应用得当，该技术可以促进软件产品随时可以交付以应对竞争。

另一方面，由于程序员感觉他们编码更多，他们通常更快乐。而且他们对编写规范不那么恼火，因为这个阶段本质上总是很小的。

但同样，如果你确切地知道你的产品将是什么，特别是如果它像航天飞机一样对生命至关重要，那么敏捷开发不是你想要的。

Answer 12

现在几乎每个管理层都知道“敏捷”：就是这个东西，你知道吗？仅凭您最初的问题，我就认为确实出了问题。我真的建议你阅读像《敏捷开发人员实践》这样的书（正如标题所暗示的那样——它是关于你的内容）。

一些经理读了一本书，然后就会知道敏捷是什么。他们告诉你该怎么做，一切都很好，不是吗？

如果您环顾四周，有很多开发人员（在敏捷公司中）无法在一秒钟内告诉您站立会议的目的是什么——这是一个问题。如果您（甚至可能没有其他人）不知道为什么StandUp 不会让事情变得更好。

看看时间跟踪（和时间估计）——有些经理认为这是衡量你做了多少工作：嘿，你有一份 40 小时的合同，但时间跟踪工具显示你本周只工作了 38 小时！这不是它的用途。

你唯一能做的就是：你需要了解有哪些敏捷方法。平庸的经理会挑选他们觉得有趣的人。优秀的管理者会把握原因，不仅会为他们的直接利益选择方法，而且还会选择那些能让团队更快乐/更有效率/更有团队精神的方法（团队与工作组）。

PS 你真正需要注意的事情：在敏捷中没有懒鬼的地方。每个人都必须自己做事。您必须将个人兴趣投入到产品的成功中。如果您不自己做事，有人会告诉您该做什么（然后是微观管理）。

Answer 13

敏捷真的有效吗？“是的。”

在“敏捷编程”出现之前，有相当多的方法在很大程度上未被认可。我认为这些被称为增量原型，但显然这已被分成那个和进化原型。

我怀疑许多或大多数成功的系统都是这样构建的。仅仅因为该方法有了一个新名称，并不意味着它突然出现。

只是瀑布和其他糟糕的管理技术得到了所有媒体的关注。

我说敏捷有效。我说这是唯一有效的方法。