将敏捷注入小组项目（第 2 部分）

根源于由丰田率先推出 表达了过去 30 多年来支撑软件开发的项目管理理念和价值观。在我看来，对该规范进行一些简单的更改即可使其同样适用于各种其他团体的努力，从以我为例，针对小组项目环境中的学生：

需要强调的是，我们的“左派”宣言的价值观既适用于小组流程（交付方式），也适用于分配的项目（交付内容）。第一个由学生控制，第二个由教师控制。

因此，作业的设计应最大限度地为学生提供体验左侧项目的机会。 某个流程或工具是否阻碍了团队互动？ 那么就应该修改或者更换。项目本身是否鼓励有意义的互动？学生是否需要应用所学知识，而不仅仅是复述事实和数据？是否清楚地传达了期望以及如何对可交付成果进行评分（例如评分标准）？ 最后，是否有些任务不够明确，需要进行分析并选择成功路径？ 学生是否有机会有效应对不断变化的优先事项，或者交付是否基于单一的、线性的分步计划？

让我们首先关注流程。从我们上一篇文章开始，怎么能董事会帮助团队将我们的敏捷宣言付诸实践？嗯，一方面，它非常直观。大脑糖果。 在本例中，我们的板是一张简单的 8-1/2" x 11" 纸，具有三列。每项任务都有自己的置顶任务，优先级较高的项目会放置在“待办事项”列的顶部。谁在做什么（每张卡片上都有姓名缩写）是显而易见的，因为只有在工作真正开始后，任务才会移至“正在执行”列。每个人都可以快速看到所有待完成的任务以及已经完成的任务。当出现不可预见的问题时（哦不！山姆生病了，他拿着痰盂！），可以移动便签以反映不断变化的优先事项。还有什么比看到“完成”栏增长（或者没有增长时令人担忧）而其他两栏缩小更令人欣慰的呢？整个过程不仅令人耳目一新、简单易懂，而且还支持敏捷的其他充满活力的功能之一，。成员不需要被告知要做什么。未完成的项目优先放在“待办事项”下，表面上是对任何闲着且有能力的人喊“抓住我”。

如此高度可见且清晰的工作流程很好地满足了我们宣言的第一条和最后一条原则，支持重点突出且高度自适应的交互。 团队成员首先以小组形式确认任务并确定优先级，然后分配责任，在项目的整个生命周期中将任务从“待办事项”转变为“正在执行”和“已完成”。通过在“待办事项”堆栈中上下移动任务，可以轻松地重新确定任务的优先级，甚至在必要时从“正在执行”中移回。也许更重要的是，新的意料之外但关键的任务可以随时注入流程中，进一步支持适应不断变化的需求。

虽然看板可以很好地促进团队工作的机制，但它对于不适合协作的项目几乎没有什么帮助。我们的下一篇文章将考虑将作业转变为合理的小组项目的要素。

<<上一篇文章    –    下一篇文章>>