敏捷开发敏捷个人_在敏捷2013中寻找答案

最新推荐文章于 2024-10-28 11:00:05 发布

danpu1174

最新推荐文章于 2024-10-28 11:00:05 发布

阅读量110

点赞数

文章标签：编程语言 python 人工智能 java 大数据

原文链接：https://www.javacodegeeks.com/2013/08/looking-for-answers-at-agile-2013.html

版权

敏捷开发敏捷个人

上周，我去了纳什维尔，参加了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的官方教条。大多数产品负责人不了解他们应该做什么，或者即使他们知道该怎么做也没有时间去做。当然，单一产品负责人的想法也无法扩展–大多数大型组织都在尝试混合方法，产品经理，业务分析师和其他专家在不同级别进行填补。

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

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

有些人正在尝试使用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）但未能成功，或者他们出现在会议上的时间足够长，可以在达成共识之前达成共识斜坡。重要的是他们所知道的和他们今天必须说的话是否相关，他们是否理解以及是否可以帮助解决人们现在面临的问题。

其他事情：