上周，我去了纳什维尔，参加了Agile 2013 ，以寻求有关敏捷开发思想和实践如何通过高度诚信，高度保证发展提供更多帮助的答案； 规模以处理大型项目和计划； 并改善成熟，高性能团队的工作环境。

会议

进行了很多，有200多次会议 ，非正式研讨会，闪电演讲，Open Jams和其他演讲。

关于软人技能的一堆讲座和讲习班：团队建设，领导能力问题，管理冲突，教练，集思广益的游戏，个人评估和个人发展。 几次会议涉及规模问题和管理大型项目和程序的方法，UX设计，设计建模，如何在敏捷团队中完成测试，产品需求定义和积压管理以及少数代码质量（技术债务以及重构和编码挑战） ），其中一项涉及看板，另一项涉及应用程序安全。

关于devop的信息也很完整：其中大部分是关于改进包装，构建和实施持续交付的介绍性内容，以及有关使开发人员和ops一起工作的基础知识以及原因。 对于许多希望变得更加敏捷的组织来说，Devops是自然而然的下一步–如果您在运营中陷入困境，那么在产品设计和开发中更快，更响应的意义何在？ 但是devops必须摆脱友好的同类主厨/人偶/ noSQL Webops的利基市场，并大肆宣传每天部署10或100次是一种很酷的方式，以便与世界其他地区相关。 如果不是这样，“开发”将最终意味着从IBM或HP购买一些昂贵的配置管理和部署工具，这不会使世界变得更美好，对除供应商之外的所有人来说都是令人失望的。

强调

一周初的许多会议都是入门级的概述和经验报告。 几个有趣的话题包括Jeff Patton举办的有关管理需求和积压的智能娱乐会议，以及一些有关在大型敏捷商店中控制质量和测试的现实经验报告。

对我来说，最重要的亮点是星期四，当时我参加了一些特别好的研讨会，讨论如何处理计划管理中的组织和政治问题 （如何在整个组织中建立广泛的信任，确定和处理隐藏的依赖关系）； 召集团队一起制定“ Abuser Stories” ，从攻击者的角度看待功能，以帮助将应用程序安全性构建到敏捷开发中； 以及有关实用重构的技术会议。

关于重构是什么以及什么不是重构 ，仍然存在很多困惑，在关于重构和代码质量的会议上两次非常不同的会议就证明了这一点 。 第一个描述了埃及政府为鼓励一些埃及技术公司大规模“重构”遗留代码而进行的善意却误导的努力，除其中一家以外，其他所有公司都失败了–一个项目成功了，因为它们严重限制了代码清理的数量只需花费很少的时间就可以完成工作，并限制开发人员只进行简单的重构更改就可以开始，直到开发人员和管理人员了解他们在做什么。

这不是重构：使用重构技术和工具不是重构。 重构的真正进步并不是分类清除代码的明显技术 。 它是定义一种纪律严明的迭代方法，以在开发人员进行更改之前和之后立即清理代码结构，这是开发和维护的组成部分。 重组应该是开发的一部分，而不是项目本身需要或应该完成的事情。

您不需要预算来重构。 您应该重构获得的每一个机会。

Llewellyn Falco和Woody Zuill在一个运行良好的大型会议中展示了如何正确地完成此工作，他们对代码进行了实时重构 ，消除了混乱，复杂性和聪明之处，然后消除了重复，所有这些都花了几分钟的小步骤最重要的是，可以使代码在任何时候都比开始时更好。 他们展示了可以安全使用哪些技术和工具，如何对您不太了解（或根本不了解）的代码进行简单的重构以使其更易于理解，以及进行各种更改的回报是什么。

主题和模因

会议上经常出现一些想法，并在会议上与人们交谈。

产品所有权是一个严重的问题，尤其是在大公司中。 简化的产品负责人（“ to之气”）方法不起作用 ，即使它仍然是Scrum的官方信条。 大多数产品负责人不了解他们应该做什么，或者即使他们知道该怎么做也没有时间去做。 当然，单一产品负责人的想法也无法扩展–大多数大型组织都在尝试混合方法，产品经理，业务分析师和其他专家在不同层次上进行填补。

像任何好的会议一样，从演讲者和供应商那里获得的收益也比从会议中遇到的其他人得到的收益更多或更多。

我与之交谈的许多人都在大型（有时是大型）公司工作，试图将敏捷引入大型（通常是大型）项目和程序，并试图在敏捷世界中建立或重塑自己的职业。 显而易见的是，敏捷并不能解决大型组织中出现的所有问题。 高管对可预测性的要求没有很好的答案（因为软件开发只是大多数组织中需要交付和协调的内容的一部分），或者如何与成千上万运行多年的人在大型程序中进行沟通和协作跨部门和国家，或者如何处理权力政治和组织惰性，或者如何满足治理和合规性要求。

有些人正在尝试使用SAFe或纪律敏捷交付来适应和整合敏捷实践，但大多数人正在自己整合一些东西，团队级别的Scrum和更高级别的PMO实践。 许多组织在推出之前仍在尝试，但是到目前为止，成功的故事很少。

大多数人似乎都接受了花一些时间使团队团结起来并了解他们真正需要建立的东西的必要性– 您不能只是逐步开始并逐步建立一些东西 。 但是大多数人希望它不被称为“ Sprint 0”，因为它不是Sprint，它是一个单独但重要的前期步骤，着重于从一开始就尽可能地发现并简化操作。

满足需求是每个人的另一个重要重点领域。 精简概念以降低需求以提供最低限度的可行产品被认为是确保成功的唯一方法，特别是对于运行大型项目和计划的人而言—如果您无法为企业或客户提供他们想要的一切，确保您至少给他们他们所需要的最少的东西。

大多数发言者（但不是全部）都同意，应该以任何有意义的格式定义要求，以使观点得以表达的任何要求：大故事或小故事，草图或图片，详细规格（如果有），测试（如果可以）让他们预先定义。 杰夫·帕顿（Jeff Patton）强调，简化的故事模板

作为[用户类型]，我想[做某事]，以便[原因]

可以用作起点和学习工具，但是尝试将每个需求都转换为标准化格式是没有必要甚至不实际的。

还特别强调了教练和培训的必要性（也许是因为这么多的演讲者是教练或培训师吗？），所以您不应该（或至少不必）尝试做所有这些事情而没有帮帮我。

参展商及其他所见所闻

展览室很小。 培训公司和提供教练，敏捷项目管理/ ALM工具的公司对我来说几乎都一样，而一些自动化测试工具供应商则迫不及待地说服您他们所销售的产品比QTP这样的工具要好得多，您过去浪费了太多时间和金钱。

您如何知道IBM并没有真正“获得”敏捷或精益：

• Scrum.Org的URL：www.scrum.org
• IBM敏捷/精益实践的URL：www-01.ibm.com/software/rational/agile/…

一个看板培训和认证供应商坚持认为“看板不是敏捷实践”（尽管他们是在敏捷会议上进行的）。 另一位供应商通过解释“看板像培根的十个原因”来澄清这一点。

看到的其他东西。

一个可怕的家伙在D-Wave的量子计算机上戴着Google Glass进行了一场很酷的照明谈话。 它与敏捷开发无关，但确实很棒。

一些演讲者利用自己的声誉，很少或根本没有努力：在演讲嘉宾坐在舞台上的红色沙发上的任何会议上都是在浪费时间。 我不在乎有人在13年前与肯特·贝克（Kent Beck）合作过一个项目，还是在2001年邀请他们参加“雪鸟”（Snowbird）但未能成功，或者他们出现在会议上的时间足够长，可以在达成共识之前达成共识斜坡。 重要的是，他们所知道的和他们今天必须说的话是否相关，他们是否理解以及是否可以帮助解决人们现在面临的问题。

其他事情：

“ TDD就像是青少年的性行为：每个人都在谈论它，但并不是所有人都在这样做。”

“不要估计或担心故事点。 只需使您的所有故事都具有相同的大小并计算它们即可。”

嗯...您如何在不估计它们的情况下让它们大小相同？？？

“团队建设本身是没有用的。 您必须跟进它，并促使人们就团队的重要组成部分共同努力。”

“如果您查看自己喜欢使用的任何产品，我可以保证您喜欢它的原因不是因为它按时发货。”

继续寻找

我没有得到我一直在寻找的所有答案，而且我认为我在会议上遇到的任何人都没有做到。 但这是了解每个人面临的挑战的好机会，很高兴看到这么多聪明而认真的人为解决这些问题而努力。 它给您希望情况会变得更好。

翻译自: https://www.javacodegeeks.com/2013/08/looking-for-answers-at-agile-2013.html