精心设计的群体编程练习


武士刀很棒,但还不够。在过去的一年里,我一直试图找到方法来教我们的工匠和学徒如何设计软件。虽然我们可以讨论好的设计原则,但是很难找到实践它们的方法。武士刀非常适合学习时分双工、微设计、单步执行以及一些处理遗留代码的技术,但是我们还需要更多。我们希望将需求收集、领域建模和精心设计的代码结合在一起进行实践,就像我们在练习武打时得到的快速反馈一样。问题是我们需要一个更大的重叠规则问题,这样我们才能体验增量软件设计。受到一次会议的启发,我们进行了一次Socrates Germany 2015,我们正在开发一个经过深思熟虑的练习会话,使我们能够实现这一目标。

会议

目标是选择一个游戏(纸牌、棋盘、骰子),并以代码清楚描述游戏规则的方式实现代码。任何不属于编写代码的团队的人都应该能够查看代码,并且非常快地理解游戏是如何工作的。

设置

该会话作为一个群控程序运行。确保你有一个投影仪和一个白板或活动挂图。

格式

第一步:暴民中的人选择一个游戏,选出一个领域专家,这个人要么很了解这个游戏,要么在没有人知道这个游戏的情况下,负责找出这个游戏是如何工作的。

第二步:暴徒选择一个司机作为暴徒的手下。

第三步:领域专家给出一个非常简单的游戏描述。最多5分钟。可以使用白板/挂图。

第四步:开发人员开始编码,并需要依靠他们提出正确问题的能力,以便从领域专家那里提取他们需要的信息。

第五步:组织一次回顾会,讨论在会议中学到了什么。

留出至少会议持续两小时——编码部分100分钟,回顾部分20分钟。我参加的大部分课程都花了相当长的时间:2.5到5个小时。

基本规则

为了减轻情绪方面的影响(辩论可能会变得相当激烈),我们为会议制定了一些基本规则。

  • 给予优先权:不要强迫你的想法。总是优先考虑别人的想法。你知道如何编码,以后你可以自己做这个练习。
  • 不要大喊大叫或打断别人:让别人说话。该课程是一次愉快的学习经历。如果事情不顺心,冷静下来,坐下来,试着学习一种不同的做事方式。
  • 不要讨论太久:选择一个想法,并坚持下去。我们总是可以在以后重构。避免分析瘫痪。
  • 不断向前移动:如果群众没有决定,司机应该开始打字并向前移动。
  • 至少10分钟的一个想法:改变方向是可以的,但是一旦大多数人决定了一个方法,避免抛出许多不同的想法。在我们转向另一个想法之前,我们需要一些时间让一个想法成熟。
  • 异议被记录下来:如果有人真的很沮丧,但是团队仍然继续前进,那么对当前想法的异议就会被记录在代码或白板上。

在挂图或白板上写下基本规则以前会话开始并始终保持可见。如果争论变得激烈或有人行为不端,就指向他们。

运行会话的提示

我已经多次运行这个会话,每次都学到了不同的东西,包括如何以更好的方式运行会话。这里有一些提示。

暴民的规模

暴徒越少越好。我推荐一群3到5个开发者。

驾驶员

应该是一个为了捕捉暴徒的想法而快速敲击键盘的人。司机打字越快,群众得到反馈和决定下一步行动的速度就越快。由于暴民会不断改变他们对实现的想法(不同的人,不同的想法),所以他们获得代码外观的快速反馈是很重要的。

我建议只有一个人应该打字。我们不想浪费时间和试图熟悉不同的电脑、工具、键盘、快捷键等的人在一起。

领域专家

领域专家的作用仅仅是阐明游戏规则,并且可以根据要使用的领域语言来充当裁判。她对动词和名词的名称有最后发言权。领域专家不是产品所有者;她没有规定要构建哪些功能或者应该构建的顺序。领域专家也可以对代码做出贡献,但不能否决由mob做出的设计决策。

服务商

有一个辅导员可能是一个非常好的主意。主持人将负责确保讨论保持文明,每个人都有自己的说法。

我们尝试的游戏

Mia,Oh Hell!,The Great Dalmuti,Monopoly,还有其他几个我不记得的名字。

奥运会的边界

确保游戏的边界被定义。例如,使用控制台作为游戏的界面。也许有些玩家可能是人工智能玩家,而其他人可能是通过控制台玩游戏的人。定义边界将有助于开发人员了解他们需要在哪个级别进行测试,以及如何构建游戏引擎。

变化和挑战

下面是我们也尝试过的一些事情Codurance,在Socrates Germany,和Socrates Belgium

限制

如果暴民中的开发者非常有经验,请随意添加constraints参加会议。请注意,这已经是一个相当困难的会议,约束可能会妨碍您实践增量设计。

更多的开发人员

如果运行这个有很多开发者的会话(社区事件),你可以把他们分成小的群体(每个群体3到5个人)。每个暴民会挑选一个游戏,并花大约90分钟来编码它。一旦时间到了,每一个暴徒将把他们的代码放在一个放映机里,让其他组试着猜他们编码的是什么游戏,规则是什么。当然,暴民应该避免用所选游戏的名字来命名他们的项目或主要职业。

选择一个没人知道如何玩的游戏

这是一次非常有趣的会议。我们必须阅读维基百科上的游戏说明,理解它,并在很短的时间内将其编码。这种方法迫使我们锻炼理解需求并快速建模的能力。很多时候,当我们发现新的需求时,我们不得不显著地改变代码,这给了我们许多有趣的设计见解。

在实施之前玩游戏

一些开发人员提到,在尝试实现它之前,我们应该玩几分钟游戏。这是一件非常明智的事情:我们都会更好地理解这个游戏,并希望能产生一个更好的代码。这样做可以使会话更容易。然而,在我们的日常工作中,并不总是能够“玩”我们从产品所有者(或任何负责需求的人)那里得到的需求。在编码之前不玩游戏将使会话更接近现实,这意味着,我们需要依靠我们的能力向领域专家提出正确的问题,以便获得我们需要的信息。弄清楚什么时候写什么代码也是一个很好的练习技巧。

与真正的团队和领域专家/产品所有者一起尝试

我们还没有这样做,但是我们认为和一个真正的团队一起进行这个练习会是一个非常有趣的想法。产品所有者(或任何负责需求的人)将扮演领域专家的角色。我相信这将有助于团队凝聚在一起,也有助于产品所有者更好地理解需求和编码的努力。

随着领域专家(由产品所有者扮演)引入新规则,开发人员将需要重构代码,甚至扔掉大部分代码。产品所有者将会看到新特性对代码的影响,以及开发人员必须经历什么才能使事情正常工作。领域专家使用的语言也会显著影响代码的复杂性。

我们在这里预见的问题是,如果团队不是非常有经验和快速,领域专家将很快感到非常无聊。非常重要的一点是,开发人员要保持讨论的重点,并保持流程的连续性。

如果有人尝试与一个真正的团队和一个真正的产品拥有者进行这种对话,请给我一个电话。我很想知道更多关于你的经历。

为什么是游戏?

棋盘、纸牌和骰子游戏的规则通常彼此紧密相关,为我们提供了一个非常丰富的领域。实现新的规则总是会迫使我们重构或者完全重写已经存在的东西。这些规则通常很容易理解,但是实现起来很复杂,这意味着我们可以专注于建模/编码方面,而不是在编写任何代码之前浪费时间试图理解一个复杂的领域。

摘要

这是一个高级的实践环节。这不是一个应该用来学习TDD基础知识的课程,TDD是一种新的语言,或者软件设计。这也不是每个人都可以在键盘上玩一会儿的会议。mob中的开发人员必须非常熟悉不同的TDD风格和许多设计原则,这样才能让这次会议顺利进行。

创建这个会话是为了让我们能够练习如何快速而良好地设计软件,这包括不断地与业务对话、理解需求、定义一种无处不在的语言,当然还有编写代表问题领域的精心编制的代码。

感谢所有人Codurance,Socrates Germany,和Socrates Belgium,参与了mob会议,并提出了改进会议的想法。

这篇文章首次发表在Codurance blog