我认识了很多敏捷人员工作得很好的人，他们中的大多数往往是计划和委派工作的经理和建筑师。但是我真的没有发现很多优秀的开发人员确信敏捷正在为他们工作。
当然，你可以说敏捷不适合你，你做得不对。但是，除了敏捷的任何混音之外，它是否适合作为开发人员？为什么？有没有人认为，在传统（或接近）的团队结构中，敏捷感觉更像是一种微观管理而非自我管理？
答案 0 :(得分：41)
在我的第一份工作中，我们每天都有scrums，写自动化测试，自动构建，编程对等等。我们已经在敏捷的沟槽中工作了好几年。为了我们的努力，我们获得了不会用20英尺杆接触的软件。我们的产品质量非常糟糕：我将其描述为100名业余开发人员的零碎黑客。
出了什么问题：
我所工作的公司因雇用入门级开发商以最低工资（每年25-27美元/年为标准）而声名远扬，而且我们经常将工作外包给最低的海外投标人。我听说敏捷只对缺乏经验的开发人员起作用，我认为它通过代码和我们的周转率显示出来。
没有任何类型的文档。没有功能文档，没有技术文档，没有要求，没有错误跟踪。没有人在持续的媒体上写下过的东西：所有的要求和错误都是通过电子邮件，口口相传和心灵思维来传达的。
糟糕的测试：我们的自动化测试非常宝贵，但QA和UAT测试是一场灾难。由于我们没有任何正式的需求文档，因此QA用户不知道他们正在测试哪些新功能，因此所有QA都包含或多或少的随意端到端测试。用户验收测试是在生产中执行的：我们在客户服务器上安装了产品，并报告了生产中发生的错误。
危机驱动的开发：使用“OMG我们必须修复它并重新开始PRONTO！现在现在处理错误！现在没有时间进行测试！”管理方法。
虽然我们做的一切都是正确的，并且真正遵循了本书的敏捷原则，但这种方法比我见过的任何其他方法都更难。
相比之下，我现在工作的公司使用类似瀑布的方法，为每个项目生成几百页的文档，几乎没有自动化测试，但是规模庞大的QA团队。有趣的是，我们的产品质量是通过屋顶，工作环境比其他公司高出几个数量级。
我知道很多人都有相反的经历。通常情况下，方法论并不是一个金钥匙 - 无论您选择何种方法，您都可以开始一个成功的项目。根据我在成功和不成功项目方面的经验，我感觉方法论与环境无关紧要：舒适，开心的开发人员和理智的项目经理都是项目工作所需要的。
答案 1 :(得分：11)
在我的公司，大约4年前，当一位新的副总裁进入时，我们批量转向敏捷实践。这位副总裁在过去曾经历过Agile的成功，并认为这是我们所需要的。
事实证明，他是对的。我当时是一名开发人员（虽然有点初级），我喜欢这些做法。结对编程确实有助于知识转移，并阻止知识孤岛的形成。单元测试，测试驱动开发和测试重点通常用于更强大的代码，而不是过度设计。没有Big Design Up Front意味着我们不是花费6个月写出需求文件（当时市场已经过去了），我们正在进行原型设计并及时为客户提供真正的价值。与客户代理人（在我们的案例中，技术产品经理）密切合作，大大缩短了周期反馈时间，这有助于我们实现客户的实际需求。
我们的组织有很多才华横溢的开发人员，但我们很容易受到牛仔编码的影响。一些开发人员不喜欢新的做法（“你是什么意思，写测试？我是开发人员！”），但一般来说每个人都喜欢这些变化。缺陷率下降，客户满意度上升，我们的办公室在我们公司得到了很好的认可。
大约一年前，我成为了一名经理，我大量使用敏捷实践，并结合了一些精益原则（价值流分析，浪费消除，看板）。收紧发布周期一直是一项持续的活动，我的团队现在尽可能经常发布（质量好！） - 通常每两周发布一次。在过去的一年里，我们的团队没有现场报告的缺陷，销售人员和产品管理人员喜欢较短的发布周期。
作为一名开发人员，敏捷确实增加了我对使用各种代码区域的信心（当我在一个没有100％单元测试覆盖率的软件包中改变任何东西时，我现在感到紧张！），教我成为一个更全面的程序员（考虑测试含义，业务影响等），并帮助我编写简单的自我记录代码。作为一名经理，敏捷和看板为我提供了可预测性，更短的交付周期，更低的缺陷率和更强大的团队。这不是理论，推测或挥手 - 我们的团队士气，缺陷率，客户满意度和资产负债表证明了敏捷可以为组织做出精彩的事情。
答案 2 :(得分：6)
根据我在尝试的网站上的体验评论Principles of the Agile Manifesto。
我们的首要任务是满足 客户通过早期和持续 交付有价值的软件。
这对我上一个网站来说是一把双刃剑 - 有价值的意思是100％完美且没有错误。
欢迎改变要求，甚至 发展晚了。敏捷过程 为客户改变线束 竞争优势。
我仍然与该网站进行沟通，就在今天，他们坚如磐石的截止日期，他们被要求更改。那就是那里的事情;这几乎就像他们想要失败一样。
经常提供工作软件， 从几个星期到几个星期 几个月，优先考虑 时间缩短。
多年来的标准基本上是每天，每小时，近乎实时地构建和部署......
商务人士和开发人员必须 整个日常工作 项目
有关这方面的一些会议/评论很有趣。我们因为没有和人们一起工作而受到训斥（因为他们要求我们不要因为他们已经工作了9-10个小时），然后因为他们很忙而打扰他们。
围绕积极性建设项目 个人。给他们 他们需要的环境和支持， 并相信他们能够完成工作。
啊，这是我们的问题......我们拥有顶级PC，但业务方面并不支持。大约一年左右的时间后，积极的士气基本上被打败了......这也否定了你的微观管理问题（如果正确实施的话）。
最有效率 传递信息的方法 在一个开发团队中 面对面的谈话。
这很好。我个人更喜欢电子邮件，因为我讨厌做笔记。
工作软件是主要的 衡量进展情况。
毫无疑问。
敏捷流程促进可持续发展 发展。赞助商， 开发人员和用户应该能够 保持稳定的步伐 下去。
我同意这100％;与我合作的最后一个业务团队的问题是30小时工作日，10天工作周和400天工作的期望不是我同意的速度。
持续关注技术 卓越和良好的设计增强 灵活性。
这是一些开发人员士气高涨的地方。需要教育。
简约 - 最大化的艺术 未完成的工作量 - 是 是必不可少的。
我喜欢这个，这一直是我的目标之一。然而，有一个“如果你没有打字，你没有工作”的态度很难克服。
最好的架构，要求， 和设计出现 自组织团队。
我同意这一点约90％ - 我唯一需要注意的是，他们必须是受过良好教育且知识渊博的团队。
定期，团队 反思如何变得更多 有效，然后调整和调整它 相应的行为。
我们在这里失败了，这可能会导致我们遇到很多其他问题。业务方面非常善于说“你需要做我们说要做的事情。”
总而言之，如果你在每个人都知情并且使用敏捷方法的地方工作，它应该是一个工作的好地方。当目标是伟大的软件时，动力本身就会带来任何项目。
答案 3 :(得分：4)
在当前环境中，Agile作为开发人员为我做了很棒的工作。以下是一些实践以及为什么它似乎运作良好：
结对编程 - 这可以防止任何人感受到代码的个人所有权。成对的开发人员倾向于制作比一个人的“疯狂科学”代码更好的代码，如果一个人孤立地编写一堆代码，这些代码似乎就会发生。这也允许其他人被带入，如果有人离开，并且该功能或增强必须在该人离开时完成。有时候，一个开发人员可能认为某些东西会很棒，但如果没有其他人能够理解这些代码，那么除非它是完美的并且未来不可能，否则它是没用的。
Scrum - 这会创建一个问责制和沟通，以便每个人都知道对方在做什么。如果有人想知道冲刺的进展情况，只需站出来。站起来非常简单，因为它只有3个问题：我昨天做了什么，今天我在做什么以及什么会妨碍我完成这项工作？
测试驱动的开发 - 在我工作的地方实践了一个变体，我们通常会尝试对我们正在编写的大多数管道代码进行测试，以便在我们正在进行的大项目中自定义CMS。这种心态可能很难进入，但随着人们更多地练习它会变得更容易。
YAGNI - “你不会需要它”的原则，如果你是一个有洞察力的程序员，通常会把101件事作为“好吧，我有一天可能需要这个...... 。“ 心态。另一种说法是“保持简单，愚蠢”的想法。
短跑 - 这里的想法似乎只是为了防止被压倒的感觉，因为我们只是在这个或那个工作了两个星期，而且看起来不太好，因为它可能会改变。
演示 - 炫耀我们所做的事情，获得有关什么是好的和什么不是好的反馈对于让事情变得更好并且拥有我们想要在项目中“持续改进”的心态以及什么是好事是至关重要的今天足够好，明天不够好，我们做得更好。
IPM，回顾 - 回顾一下回顾过去所做的事情的能力对于发泄挫折，庆祝运作良好以及找到解决痛点的方法很有用。 IPM是我们通过使用几种不同的估算工具来确定下一个冲刺的未来，我们将通过使用几种不同的估算工具来确定各种事物需要多长时间，一种用于我们称之为“史诗”的点和另一个人在个人任务或卡片上花费数小时，这是史诗和一小部分作品之间的故事的一部分。
故事墙和用户故事 - 现在这个低技术工具，因为它只是几个白板，有分隔线和贴子，它为事物提供了一些结构。我们为每个史诗和各种工作状态列提供了通道：积压，开发，开发或测试。任务积压，封锁卡，问题，标准和实践以及其他一些可能对管理人员有用的事情可能有用，如果他们想要比他们想要的更大的图片，那么可以查看当前状态的概况站起来。
破窗/技术债务/任务 - 这些在某些方面类似，并且有助于说明质量很重要，即。我们不希望破碎的窗户可以通过使用附近的房屋或纽约地铁系统作为起点，以非技术术语轻松解释。技术债务不会立即增加业务价值，有时候这是一个重要的事情，可以用来防止某些问题，因为特定架构可能存在问题，因此部分冲刺可能会花费在进行重新调整沟通，如果有一个很少演示的冲刺这就是原因。
我不知道“自组织”或“自我管理”团队的想法是否是敏捷的一部分，但对我来说，对我有足够的信心和信任对我来说是一个挑战。工作人员认为事情会好起来的。我团队其他成员的专业人员都知道必须做些什么，合理，诚实的人才能完成工作而不是成功完成任务。没有自负或不好的态度确实有助于培养团队。
答案 4 :(得分：3)
敏捷不是一种方法论，它是具有一套共同目标的方法论的子集，而且更常见的是，这些方法论在团队构成，企业文化和实施方面的结果大不相同。
在我的头脑中，纯粹的开发人员敏捷实践将包括结对编程，TDD，超出规范的用户故事，假设所有代码将被重构多次（尽管这是TDD的一部分）和代码审查更多什么都有。影响我们的事情是每天的立场，定期和直接与用户接触，事后监督，以及非常紧张的开发周期。
答案 5 :(得分：3)
我同时是开发人员和经理，所以我要么有特别的见解，要么我的意见完全无效。 ;）
我会说敏捷意味着很多事情。在这一点上，它实际上是一整套方法和指南。
让自己暴露于所有这些有趣的想法是真的。作为一名经理，我很难宣布整个团队突然采用整个方法，但如果他们看到我不断尝试改进游戏的各个方面，我认为他们很欣赏。希望如果他们喜欢他们所看到的，他们会效仿我的榜样。
我已经设法从Scrum中慢慢实现了很多东西，但没有（希望）作为一种工具。在白板上烧毁报告，站立会议和故事卡真的让我们更好地运送软件。例如，任何项目任务都会提前或延迟完成。在一个非常大的项目中，很难说出你的发货日期是做什么的。通过烧毁报告，我可以告诉我们的发货日期是什么，以及我们是否需要开始切割功能以满足截止日期。
这更像是一种管理方式，但其他开发人员关心它，因为这可能意味着他们可以保住工作或避免死亡之旅。 :)
但这不仅仅是管理方面的事情。敏捷中有很多关于源代码控制，单元测试等的最佳实践。只有良好的可靠性最佳实践。作为一个行业，我们对指导非常糟糕，所以这些信息就在那里很好。
答案 6 :(得分：3)
从我个人的经验来看，敏捷方法往往会在长期内产生巨大的技术债务，虽然它可能会为您（作为企业主/管理层）短期内节省几美元，但从长远来看，它会来回来咬你。无论你现在没有修复什么，最终都会花费你很多时间来修复成本，而不是花费你多花些时间来解决原始问题。
从初学者和管理者的角度来看，敏捷永远是伟大的，但我不知道一个有经验的程序员真正喜欢它。敏捷的全部意义在于为公司节省开发资金，这与实际产品质量无关。实际上，大多数方法都会通过精心设计的代码快速完成错误的代码。不同之处在于，未来几年，您必须重新完成整个工作，而精心设计的代码可以持续数十年而无需更正。优秀的程序员大多数时候都不需要敏捷方法。我们有一个22年前由一个由3名程序员组成的团队使用瀑布式方法编写的业务逻辑库，该代码从那时起就不需要进行单一的更正。因为它是正确的，经过精心设计，并且三位程序员花了他们的时间并且小心他们的实现。敏捷方法会反过来要求这三个人做严格的最小化，以确保通过一些定义不明确的测试，然后等到下一次你到墙上添加一些管道磁带代码。这是一种荒谬的工作方式，与我体内的每一位工程师纤维相对立。
直到今天，我拒绝在敏捷环境中工作，因为坦率地说我不需要它，而且我不需要雇主认为我确实需要它。
答案 7 :(得分：2)
从开发者的角度来看，我认为它运作良好。在我看来，敏捷技术的共同之处在于，与非敏捷方法相比，定义任务，处理任务和从该任务获得反馈之间的循环非常小。
以TDD为例：编码测试，红条，编码功能，绿条，重构，红条，修复，绿条。
从管理者的角度来看，这个更快的反馈循环也是如此：每日会议一，绿色状态，每日会议二，状态黄色，对策/重新分配资源，每日会议三，状态绿色。
立即反馈并了解您的目标，给人一种安全感。
答案 8 :(得分：1)
敏捷并没有为我工作，主要原因是我经常开发的系统需要一个定义明确且经过深思熟虑的架构，这很难通过敏捷方法实现。敏捷方法倾向于编写尽可能少的代码来传递适用的测试，从而有机地扩展系统。从许多角度来看，这可能会很好，但它会从架构角度造成严重破坏。
答案 9 :(得分：0)
在所谓的“传统团队”中，敏捷开发将提高个体开发人员对管理层的可见性。这可能会让经理和建筑师更好地规划他们的工作。当然，可以解释为微观管理。
但是从组织的角度来看，如果它产生了结果，谁会关心。
答案 10 :(得分：0)
我想是什么使“敏捷”项目变得敏捷，方法是：“为今天而不是为明天而设计”。
对于任何非生命关键型软件系统，这是一种让程序员编码而不是讨论设计年龄的方法。请注意，设计不会报废，只是在更小的，因此更可监控的块中完成。
与敏捷相关的所有其他技术，如结对编程，都是借用的想法，也可以在任何其他方法中有效使用。
现在，这种技术“有效”吗？是!如果应用得当，该技术可以促使软件产品随时准备发货以对竞争作出反应。
另一方面，由于程序员感觉他们编码更多，他们通常更快乐。而且他们对编写规范不那么恼火，因为这个阶段本质上总是很小。
但是，如果你确切地知道你的产品将会是什么，特别是如果它像航天飞机一样对生命至关重要，那么敏捷开发并不是你想要的。
答案 11 :(得分：0)
现在几乎每个管理层都知道“敏捷”：这就是这个，你知道吗？单独你最初的问题我会认为某些事情真的出错了。我真的建议你读一本像Practices of an Agile Developer这样的书（正如标题所暗示的那样 - 它是关于你的内容）。
一些管理人员读了一本书，然后知道什么是敏捷。他们告诉你该怎么做，一切都很好，不是吗？
如果您环顾四周，有很多开发人员（在敏捷公司中）无法在一秒钟内告诉您
看看时间跟踪（以及时间估算） - 有些经理认为衡量你做了多少工作：嘿，你有一个40小时的合同，但时间跟踪工具说你本周只工作38小时！这不是它的用法。
你唯一能做的就是：你需要了解那里的敏捷方法。平庸的经理会挑选他们感兴趣的经理。优秀的管理者将掌握为什么而不仅仅选择直接利益的方法 - 而且还要使团队更加快乐/高效/团队合作（团队与工作组）。
P.S。你真正需要照顾的事情：在敏捷中，没有懒惰的地方。每个人都必须自己做事。您必须将个人兴趣投入到产品的成功中。如果你不自己做事，有人会告诉你该怎么做（然后是微观管理）。
答案 12 :(得分：-1)
敏捷真的有效吗？ “的 是的即可。”
在出现“敏捷编程”之前，有一些基本上未被认识的方法论。我认为这些被称为增量原型但显然这已被分解为进化原型。
我怀疑许多或大多数成功的系统是如此构建的。仅仅因为这种方法有了新名称并不意味着它突然出现了。
只是瀑布和其他破碎的管理技术才能得到所有的新闻。
我说敏捷有效。 我说这是唯一有用的东西。