Lan*_*ali 20 agile methodology
我认识了很多敏捷人员工作得很好的人,他们中的大多数往往是计划和委派工作的经理和建筑师.但是我真的没有发现很多优秀的开发人员确信敏捷正在为他们工作.
当然你可以说敏捷不适合你,你做得不对.但是,除了敏捷的任何混音之外,它是否适合作为开发人员？为什么？有没有人认为,在传统(或接近)的团队结构中,敏捷感觉更像是一种微观管理而非自我管理？
Jul*_*iet 42
在我的第一份工作中,我们每天都有scrums,写自动化测试,自动构建,编程对等等.我们已经在敏捷的沟槽中工作了好几年.为了我们的努力,我们获得了不会用20英尺杆接触的软件.我们产品的质量非常糟糕:我将其描述为100名业余开发人员的零碎攻击.
什么地方出了错:
我工作的公司因雇用入门级开发人员以最低的工资(每年25-27美元/年为标准)而声名远扬,而且我们经常将工作外包给最低的海外投标人.我听说敏捷只对缺乏经验的开发人员不起作用,我认为它通过代码和我们的周转率显示出来.
没有任何类型的文档.没有功能文档,没有技术文档,没有要求,没有错误跟踪.没有人在持续的媒体上写下来:所有的要求和错误都是通过电子邮件,口口相传和心灵思维来传达的.
糟糕的测试:我们的自动化测试是非常宝贵的,但QA和UAT测试是一场灾难.由于我们没有任何正式的需求文档,因此QA用户不知道他们正在测试哪些新功能,因此所有QA都包含或多或少的随意端到端测试.用户验收测试是在生产中执行的:我们在客户服务器上安装了产品,并报告了生产中发生的错误.
危机驱动的开发:使用"OMG我们必须修复它并重新安装PRONTO!现在现在处理错误!现在没有时间进行测试!" 管理方法.
虽然我们做的一切都是正确的,并且真正遵循了本书的敏捷原则,但这种方法比我见过的任何其他方法都更难.
相比之下,我现在工作的公司使用类似瀑布的方法,为每个项目生成几百页的文档,几乎没有自动化测试,但有一个相当大的QA团队.有趣的是,我们的产品质量是通过屋顶,工作环境比其他公司高出几个数量级.
我知道很多人都有相反的经历.通常情况下,方法论并不是一个金钥匙 - 无论您选择何种方法,您都可以开始一个成功的项目.根据我在成功和不成功项目方面的经验,我感觉方法论与环境无关紧要:舒适,快乐的开发人员和理智的项目经理都是项目工作所需要的.
Chr*_*ons 11
在我的公司,大约4年前,当一位新的副总裁进入时,我们批量转向敏捷实践.这位副总裁在过去曾经历过Agile的成功,并认为这是我们所需要的.
事实证明,他是对的.我当时是一名开发人员(虽然有点初级),我很喜欢这些做法.结对编程确实有助于知识转移,并阻止知识孤岛的形成.单元测试,测试驱动开发和测试重点通常用于更强大的代码,而不是过度设计.没有Big Design Up Front意味着我们不是花费6个月编写需求文档(当时市场已经过去了),我们正在进行原型设计并及时为客户提供真正的价值.与客户代理人(在我们的案例中,技术产品经理)密切合作,大大缩短了周期反馈时间,这有助于我们实现客户的实际需求.
我们的组织有很多有才华的开发人员,但我们很容易发生牛仔编码.一些开发人员不喜欢新的做法("你是什么意思,写测试？我是开发人员!"),但一般来说每个人都喜欢这些变化.缺陷率下降,客户满意度上升,我们的办公室在我们公司得到了很好的认可.
大约一年前,我成为了一名经理,我大量使用敏捷实践,并结合了一些精益原则(价值流分析,废物消除,看板).收紧发布周期一直是一项持续的活动,我的团队现在尽可能经常发布(质量好!) - 通常每两周发布一次.在过去的一年里,我们的团队没有现场报告的缺陷,销售人员和产品管理人员喜欢较短的发布周期.
作为一名开发人员,敏捷真的增加了我对使用各种代码区域的信心(当我在一个没有100%单元测试覆盖率的软件包中改变任何东西时,我现在感到紧张!),教会我做得更好接受程序员(考虑测试含义,业务影响等),并帮助我编写简单的自我记录代码.作为一名经理,敏捷和看板为我提供了可预测性,更短的交付周期,更低的缺陷率和更强大的团队.这不是理论,推测或挥手 - 我们的团队士气,缺陷率,客户满意度和资产负债表证明,敏捷可以为组织做出精彩的事情.
我们的首要任务是通过尽早和持续交付有价值的软件来满足客户.
这对我上一个网站来说是一把双刃剑 - 有价值的意思是100%完美且没有错误.
欢迎不断变化的要求,甚至是开发后期.敏捷流程利用变化来实现客户的竞争优势.
我仍然与该网站沟通,就在今天,他们坚如磐石的截止日期,他们被要求更改.那就是那里的事情; 这几乎就像他们想要失败一样.
经常提供工作软件,从几周到几个月,优先考虑更短的时间尺度.
多年来的标准基本上是每天,每小时,近乎实时地构建和部署......
业务人员和开发人员必须在整个项目中每天一起工作.
关于此的一些会议/评论是热闹的.我们因为没有和人们一起工作而受到训斥(因为他们要求我们不要因为他们已经工作了9-10个小时),然后因为他们很忙而打扰他们.
围绕有动力的个人建立项目.为他们提供所需的环境和支持,并相信他们能够完成工作.
啊,这是我们的问题......我们有顶级的PC,但业务方面并不支持.在大约一年左右的时间后,积极的士气基本上被打败了......这也否定了你的微观管理问题(如果正确实施的话).
向开发团队内部和内部传达信息的最有效和最有效的方法是面对面交谈.
这很好.我个人更喜欢电子邮件,因为我讨厌做笔记.
工作软件是进步的主要衡量标准.
毫无疑问.
敏捷过程促进可持续发展.赞助商,开发者和用户应该能够无限期地保持稳定的步伐.
我同意这100%; 与我合作的最后一个业务团队的问题是30小时工作日,10天工作周和400天工作的期望不是我同意的速度.
持续关注技术卓越和良好的设计可提高灵活性.
这是一些开发人员士气和教育需要的地方.
简单 - 最大化未完成工作量的艺术 - 至关重要.
我喜欢这个,这一直是我的目标之一.然而,有一个"如果你不打字,你不工作"的态度很难克服.
最好的架构,要求和设计来自自组织团队.
我同意这一点约90% - 我唯一需要注意的是,他们必须是受过良好教育且知识渊博的团队.
团队定期反思如何变得更有效,然后相应地调整和调整其行为.
我们在这里失败了,它可能会导致我们遇到很多其他问题.业务方面非常善于说"你需要做我们说要做的事情."
如果你在一个每个人都被告知并且采用敏捷方法的地方工作,它应该是一个很好的工作场所.当目标是伟大的软件时,动力本身就会带来任何项目.
在我当前的环境中，作为一名开发人员，敏捷对我来说非常有用。以下是一些实践以及为什么它看起来如此有效：
结对编程 - 这可以防止任何人感受到代码的个人所有权。成对的开发人员倾向于编写比一个人的“疯狂科学”代码更好的代码，如果一个人孤立地编写一堆代码，似乎就会发生这种情况。这还允许在有人离开时引入其他人，并且必须在该人离开时完成该功能或增强功能。有时，一位开发人员可能会认为某些东西会很棒，但如果没有其他人能够理解代码，那么除非它是完美的和面向未来的，否则它是没有用的，这不太可能。
Scrum - 这创建了问责制和沟通，以便每个人都知道对方在做什么。如果有人想知道 sprint 的进展情况，只需出现在站台上。站立会议非常简单，因为它只有 3 个问题：我昨天做了什么，今天我在做什么，什么会阻止我完成它？
测试驱动的开发 - 在我工作的地方实践了这种变化，我们通常尝试对我们正在编写的大多数管道代码进行测试，以在我们正在做的大项目中自定义 CMS。这种心态可能很难进入，尽管随着练习次数的增加它会变得更容易。
YAGNI - 如果您是一个有洞察力的程序员，通常会将 101 件事作为“好吧，有一天我可能需要这个......”的心态，那么“你不会需要它”的原则可能真的很难。另一种说法是“保持简单，愚蠢”的想法。
Sprints - 这里的想法似乎只是为了防止一种不知所措的感觉，因为我们只是在这个或那个上工作了 2 周，不要往前看，因为它很可能会改变。
演示 - 展示我们所做的事情，获得关于什么是好的和什么是不好的反馈对于让事情变得更好以及拥有一种我们希望在项目中“持续改进”以及今天什么已经足够好的心态至关重要明天足够好，并在我们所做的事情上做得更好。
IPM，回顾 - 回顾回顾中所做的事情的能力对于发泄沮丧、庆祝工作顺利并找到解决痛点的方法很有用。IPM 是我们根据目标和我们认为各种事情需要多长时间通过使用几种不同的估计工具来确定下一个冲刺的未来的地方，其中一个用于我们称之为“史诗”的点，以及另一个在个人任务或卡片上花费数小时，这是故事的一部分，介于史诗和小作品之间。
故事墙和用户故事 - 现在这个低技术工具，因为它只是几个白板，带有分隔符和帖子，它为事物提供了一些结构。我们为每个史诗和不同的工作状态列设置了通道：待办事项、开发中、开发中或测试中。还有一些地方可以放置任务积压、被阻止的卡片、问题、标准和实践以及其他一些可能对管理者有用的东西，如果他们想要比他们想要的更大的图景，他们可以查看当前状态的概览站起来。
破碎的窗户/技术债务/任务 - 这些在某些方面是相似的，并且作为一种说明质量很重要的方式很有用，即我们不希望破碎的窗户可以通过使用房屋在非技术术语中轻松解释一个社区或纽约地铁系统作为起点。技术债务是一种不会立即增加业务价值的东西，有时是用来防止某些问题的重要事情，因为特定架构可能存在问题，因此冲刺的一部分可能会花在重新架构上进行沟通，以便如果有一个几乎没有演示的冲刺，这就是原因。
我不知道“自组织”或“自管理”团队的想法是否是敏捷的一部分，但对我的同事有足够的信心和信任，这对我来说有点挑战事情会好起来的。作为我团队其他成员的专业人士知道必须做什么，他们是通情达理、诚实正直的人，他们只需要完成工作，而不是为了完成工作而变得混蛋。没有自负或不良态度确实有助于促进团队建设。
敏捷对我不起作用，主要原因是我通常开发的系统需要一个定义明确且经过深思熟虑的架构，而敏捷方法很难实现这一点。敏捷方法倾向于编写尽可能少的代码来通过适用的测试，从而有机地发展系统。从许多角度来看，这可能很好，但从架构的角度来看，它会造成严重破坏。
根据我的个人经验，从长远来看，敏捷方法往往会造成巨大的技术债务，虽然它可能会在短期内为您（作为企业主/管理层）节省几美元，但从长远来看，它会卷土重来你。无论您现在不解决什么问题，最终都会花费您许多小时的工作时间来解决，而成本要远远高于您在原始问题上投入更多时间所花费的成本。
从初学者和管理的角度来看，敏捷总是很棒，但我不认识一位真正喜欢它的有经验的程序员。敏捷的全部意义在于为公司节省开发资金，它与实际产品质量无关。事实上，大多数方法都提倡通过精心设计的代码快速完成糟糕的代码。不同之处在于，几年后，您必须重新完成整个工作，而精心设计的代码可以持续数十年而无需更正。大多数时候，优秀的程序员不需要敏捷方法。
我们有一个 22 年前由 3 名程序员组成的团队使用瀑布方法编写的业务逻辑库，从那时起，该代码不需要进行任何更正。因为它被正确地处理，设计得很好，并且三个程序员花时间并且小心地执行了他们的实现。相反，敏捷方法会要求这三个人做最严格的最低要求，以确保通过一些定义不明确的测试，然后等到下一次碰壁时再添加一些胶带代码。这是一种荒谬的工作方式，并且违背了我身体中的每一个工程师纤维。
直到今天，我拒绝在敏捷环境中工作，因为坦率地说我不需要它，我不需要一个认为我确实需要它的雇主。