专家库管理软件专家评审系统_重新考虑一般专家的需求

专家库管理软件专家评审系统

在我的敏捷实践的早期，我相信一般专家。 我什至写了《聘请通才专家的五个秘诀》 。 但是，如果团队变得协作，我不再认为我们需要概括专家。 这是因为团队团结协作并学习。 如果团队愿意成对，成群地或暴民地进行协作，那么您可能根本不需要一般化专家。

为什么要泛化专家

回到瀑布世界，许多人的专业很狭窄。 他们仅在平台上进行架构或设计。 或中间件。 或应用程序层。 或者，他们只是另一种的测试者。

概括专家的整体想法是人们将具有多种能力。 他们可以超越狭窄的界限来开展工作。

但是，有些人认为他们可以让开发人员成为系统测试人员，反之亦然。 我从未见过这种情况。 或者，他们可以让平台人员设计UI。 我也从未见过这项工作。 （我是一个旧的平台级程序员。您不希望我设计您的UI。我仍然喜欢命令行。不，您不喜欢。）

考虑换位思考而不是能力

如果团队中的每个人都对其他人需要做的事情有同感，该怎么办呢？ 如果每个人都以团队的方式学习和交付，该怎么办？ 我们不需要一般化专家。 我们需要协作团队。

这对您的敏捷团队可能如此。

团队讨论积压

团队以积压的形式进行工作。 即使您的团队以连续的单人流程工作，团队也要解决然后进行一件工作-他们的积压工作。 如果您的团队迭代工作，则您的团队可能要解决五到十项问题。

Scrum团队将“解决工作”部分称为待办事项细化或迭代计划。 团队会仔细研究工作，并讨论他们的顾虑，想法，验收标准（随便命名）。 团队就该工作是什么以及完成的工作对该工作达成一致。

实际上，只要整个团队都在讨论积压问题时就围攻。 他们可能没有按照“真正的”暴民的方式进行暴动，交出了驾驶员/主要导航员角色，但是他们在这一努力下实时地协同工作。

警告：如果您的整个团队没有一起讨论积压，那就是陷阱。 您没有敏捷的团队，因为他们没有在工作上进行协作。

团队成员共同努力，以选择并完成工作

当团队成员进行协作时，他们至少具有以下选择：

配对，两个人在一项工作上进行协作。 该图中的箭头应注意，人们在驾驶和导航时会关闭。

群居，整个团队在同一项目上工作，但是他们根据自己的专业工作。 我看到大群人运作良好的方式是当团队聚集讨论一个项目时。 然后，他们各自做自己的事。 他们每小时重新分组，以查看进度以及是否有人遇到麻烦。 当一个人完成“他们的”工作时，他们问：“我该如何帮助任何人？”

围攻，当整个团队一起处理一个项目时。 此图像中的箭头用于显示每个人如何在驾驶员/导航员位置轮流。

这三种做法是人们实时协作的主要方式。 您的团队可能需要三合会或其他方式工作。 我不排除这个。 我只是说这些是主要方法。 做您的团队需要的工作。

基于团队的协作导致基于团队的学习

当团队成员与至少一个其他人一起工作时，他们彼此学习。 他们不需要雇用泛化专家。

他们确实需要彼此同情。 这种同情可能会扩展到客户和用户。

当人们彼此同情时，他们倾向于学习如何做那些使一切都不同的小小的调适：

• API，以便测试人员可以在GUI下编写测试自动化
• 挂钩的日志和演示
• 使开发，测试，演示和发布更容易的其他任何事情

当团队合作进行工作时，他们往往会取得更好的成功。

因此，我不再相信一般专家。 我更相信一支强有力的协作团队（并拥有积极的经验）。 人们一次只能在一起工作较少的物品。 我的经验是，这些人倾向于更快地释放这些物品。

当团队作为一个团队进行协作时，他们可能不需要通用专家。

翻译自: https://www.javacodegeeks.com/2019/08/rethinking-need-generalizing-specialists.html

专家库管理软件专家评审系统