数字敏捷采用-以及一些问题

我那段时间做了一些敏捷的介绍，实际上，我开始觉得自己几乎可以写一本名为“数字敏捷”的书。 因此，昨天，当这个问题出现在某个LinkedIn网站上时，我想我可以快速介绍一下：

“我正在与一个希望探索敏捷采用的组织合作。 启动该过程的最佳方法是什么？ 是从敏捷培训开始，然后帮助建立敏捷敏捷教练来推动它前进吗？ 或者首先进行评估，以了解他们为什么要采用敏捷，然后提出最佳方法：建议使用Scrum，看板或XP。

我的回答是这样的：

首先，不要被研究者的选择分散注意力，不要担心Scrum诉Kanban诉XP诉What-Ever。 只是去做。 （当然，我应该插上自己的书，说：“ 做Xanpan！ ”）

1. 找到一个您可以信任的人，知道这些知识（也许我应该说像我这样的人 ！）
2. 让他们与感兴趣的人进行1或2小时（最多）的交谈
3. 询问团队负责人是否愿意招募自己的团队或即将开展的工作，然后与参与人员交谈，选择/组建一个独立的小团队（例如，编码人员，测试人员，产品人员）（ 注意 ：如果您只有一个团队，则可以跳过步骤2和3，因为您正在与该团队合作。）
4. 当您发现豚鼠时，请给他们排一两天的排练（即训练课程，让他们练习自己的工作）
5. 立即开始每周进行一次迭代：无需等待“正确的时间”，在新鲜的时候开始
6. 安排参加培训的人员每周回来一次，然后在适当的时候减少调门次数
7. 聘请技术教练/培训师，经过几次迭代，再进行一些技术培训（TDD或BDD，请选择）。 让这个人回来进行一对一的辅导（即配对编程），让每个编码器有一天的时间，如果有的话，可以和测试人员在一起
8. 看看会发生什么，回顾，继续前进，扩展

我确实注意到，其他一些建议的建议团队则从教练而不是培训开始。 我就是这样做的，事实上，这就是所有早期团队的做法。 我还要说，根据我的经验-是的，我有偏见，我出售培训-为人们提供一些最有效的前期培训。 也许那是因为我的培训方式是让人们有机会在教室的敏捷环境中体验工作，所以也许我在说的是：所有培训都不平等。

这个小菜谱带您走了这么远。 我已经停止使用技术资料了。 流程方面可以帮助您到此为止，但是如果您不做技术方面的工作，则会进行大量的自动化测试！ –那么您只会走得那么远。

我在这里完全没有说的另一件事是：此配方仅适用于供应方，一旦供应方开始形成重点，就需要转移到需求方，这些人就是您所谓的产品负责人，业务分析师，产品经理或类似的人。 那就是困难所在，这不是因为这些人本身也更加困难，而是因为您现在正在与更广泛的组织进行搏斗并改变更大的心态。

这里出现的另一个问题是公司可以放宽变更的意愿。 我曾与一些使用此处方的公司合作，但是他们得到了很大的改善，立即的痛苦消失了，他们失去了进一步改变的动力。

这个处方可以很快使病情好转。 但是，如果您想获得全部利益，则需要继续服用技术药物，并补充需求方药物。 这些更改需要较长的时间来进行改进，它们是缓慢的工作。

翻译自: https://www.javacodegeeks.com/2016/01/agile-adoption-numbers-problems.html