我正在创建一家金融软件公司，在此过程中，我一直在研究敏捷原则和方法，而我尚未看到的开发方面之一是在哪里满足开发人员不断学习新技能和新技术的需求处理。

在过去几年从事财务软件工作之前，我大部分时间都是3D图形程序员，从事视频游戏以及GIS和生物识别软件的开发，而我一直很简单，就不得不从悬崖下钻研东西，并弄清楚如何飞。虽然我一直都成功，但我确信如果我没有一次又一次地每周工作数百个小时，甚至数月不致自杀，我将不会活到现在。

现在，我正在创建一家软件公司，该公司对3d图形的创新要求不高，因此我想建立一种更全面的开发方法。

也许敏捷只是不能解决这个问题，但是如果可以解决，那么我还没有找到答案，我将不胜感激任何人对此具有的专业知识或经验。

这实际上与敏捷甚至软件工程没有太大关系。任何公司的任何业务都是如此：您需要预留时间进行培训。期。

敏捷的想法是“可持续的步伐”，这意味着，团队在任何时候都应该比在无限的时间内可以承受的努力更加努力。即没有“启动时间”。这也需要通过培训来实现。因此，对于您的团队来说，一个可持续的步调是“连续不超过5个小时，每天不超过9个小时，每周不超过40个小时”，而您想提供10％的培训时间，那么您需要在36小时的周内计划您的项目。

但是，这又与敏捷无关，这只是常识和小学数学。

我个人认为，每天允许有半小时，每周有半天，每季度有整整一周的时间，这样的团队就可以使团队快速，稳定地获取不同大小的知识。

还有一些敏捷实践可帮助知识转移，即消除各个团队之间知识水平的差异：

• 每日回顾
• 冲刺回顾
• 每个项目的回顾
• 配对编程
• 乒乓球配对（在红绿重构周期的每一步之后交换驱动程序和导航器）
• 混杂配对（没有固定的配对，配对是随机分配的，每天早晨和午餐都会更改）
• 团队成员的数量为奇数（如果您进行配对编程，则一个团队成员可以自由学习）
• 暴民编程（成对编程的一种变体，整个团队使用一台计算机和一台屏幕，指定的团队成员只是“打字员”，其他人告诉他该写些什么）
• 混杂的团队（开发人员每天/每次冲刺都随机分配给团队）

结对编程和mob编程不仅提供连续的代码审查，而且还提供连续的知识共享。乒乓球配对可防止一个人“踩键盘”。混杂配对在整个团队中传播知识，混杂团队在整个公司中传播知识，并确保每个开发人员都知道每个项目和每个代码库；这也将导致代码库的高度标准化。回顾的主要重点是提供有关开发过程的反馈并做出相应调整，但它也可以用于传达一个罕见的问题以及如何解决它。

毋庸置疑，雇主应提供广泛的图书馆，ACM，Springer，IEEE等的付费订阅，以及用于学习的安静房间和用于教学的更大房间。许多白板和活动白板，以及当然，到处都是放映机，而不仅仅是培训。

我将同意JörgW Mittag所说的大部分内容，但不同意“这与敏捷性并没有多大关系”的说法。许多敏捷技术支持个人和团队的学习和发展。

敏捷方法倾向于基于增量或连续流。无论哪种情况，工作都是根据优先级，价值和依赖性等因素进行排序的。由于重点放在短期工作上，因此团队可以确定交付所需的知识，如果知识不足是问题，则计划及时获取该知识。可见性和透明度也往往是各种敏捷方法的关键方面，因此利益相关者可以看到团队正在做什么以及他们如何努力提高其交付价值的能力。当需要广泛学习时，可以计划在不久的将来或当前的迭代中进行。

团队中的每个人获得知识后，就会有围绕配对和围攻的技术。结对编程是“极限编程”中的一项关键实践，该实践也已应用于其他方法，并旨在促进学习。围攻正在将此应用到两个以上的人。团队之间的紧密协作和跨功能性意味着没有孤岛，并且可以传播这些信息。

即使能够计划和执行学习立即工作所需的内容，拥有知识渊博的团队成员也非常重要。使人们对工具，技术和领域有一定程度的了解，这将使他们在执行学习任务时更加了解情况，并在向其他团队成员传播知识时更加有效。

为您想要预算时间来学习技能的Sprint计划概念验证任务。使其专注于非常具体的内容，例如学习如何创建可访问的HTML表。不断安排概念验证任务的进度，直到您了解故事所需的技能为止。给每个POC任务一些故事点和截止日期，以便您可以适当地设定时间范围，并在冲刺结束时显示进度。

那么，对于一个经验丰富的开发人员来说，一个故事应该只有5分怎么办？也许每3点需要3-4个任务。在完成这些POC任务之后，故事可能仍然只有5分，但是至少您要花时间学习新技能，以便5分故事不是40分-即使故事和POC任务加起来为40分。

Scrum有一个“尖峰”的想法。如果团队采用的是新技术或新功能，那么峰值就是封装该工作的故事。因此，尽管敏捷故事是一个以用户为中心的功能，但是峰值的输出是所学内容的文档，以及在实际应用中将其付诸实践的工作分解。

在实践中，我发现这是管理至少小型培训的好方法-足以使开发人员在使用新系统或框架的同时加快进度，同时仍要对进度表负责。

我在其他答案中没有看到这一点，因此我想补充一下，许多组织围绕技能领域开始了行会，章或卓越中心。这些可以是诸如技术之类的广泛主题，也可以是诸如React Native Development之类的特定主题。这完全取决于参与的兴趣是否在您的公司中。

无论如何，这些小组通常承担着帮助小组成员专业成长的任务。这为工作之外的人创造了一个独立的空间，以加强和扩展每天使用这些技能的人，甚至是那些对交叉培训感兴趣的人。这不是解决此问题的唯一方法，但似乎正在变得越来越普遍。

其他一些人已经提到过方面，但是我只想分享我如何在敏捷环境中适应个人发展。

1.持续发展

这是最简单的方法，请减少每个sprint中的容量，直到您有足够的时间进行正在进行的开发为止。困难的部分通常是坚持您的计划，并且如果还有更多其他任务需要进行，则还要进行开发。如果您有紧急情况，可以不时地牺牲这一时间，但否则就不做。

由于您减少了工作量，因此您在此类别中所做的一切都超出了其他团队成员的直接关注范围，并且他们可能没有太多理由担心它或专门针对每个单独的sprint更新计划。

2.在冲刺阶段付出更大的努力

我发现，如果您计划了一些具有较大影响力的事情（例如，在冲刺中进行了为期2天的培训），则应更新冲刺以反映这一点。我不确定这是什么理论上的解决方案，但是我经常看到人们只是将培训任务任务放在董事会上，以确保可以看到有人正忙于此。

或者，您可以校正特定冲刺的冲刺容量，但是除非人们非常仔细地查看您测得的性能/效率，否则我将避免这样做。尤其是在一个新团队中，稳定性可能比准确性更有价值。

敏捷是一套哲学，看看宣言，这就是敏捷的全部内容，因此，当您说敏捷如何解决我的问题时，我建议（更多）学习敏捷。让我们来具体实现一下敏捷：SCRUM。在SCRUM中，我们具有冲刺和尖峰的概念。通过这两个工件，可以完成创建学习预算的工作。

如果将冲刺看成饼图，则可以根据主题划分优先级，其中一个主题可以是……学习新技能！

峰值是冲刺上的一项研究任务，通常涉及通过学习来评估某些事物的可行性。

最后，您一直在做的事情仍然存在，您可以在做任何事情的同时学习WHILE，然后您可以尝试增加故事点/能力以应对技术挑战。

引用敏捷宣言本身：

通过流程和工具进行个人和交互通过
综合文档的工作软件
通过合同谈判的客户协作
响应计划变更

重点是我的，重点介绍了最适合您的部分。

从根本上讲，训练有素的敏捷开发人员对变化的环境的响应要比使他们的技能石化的开发人员更好。

如果我可以添加自己对敏捷的定义，那么我们也可以将“客户协作”纳入其中。我发现敏捷的最佳定义是基于敏捷思想的定义-如果客户（或环境）发生根本性变化，您将如何应对？如果您要营造客户协作环境，那么他们会知道您在做什么，因此他们会对您的团队产生既得利益。