I recently got interested in financial board games and saw how they can be very useful in educating children about certain concepts.
It got me thinking whether it was also possible to represent certain aspects of executing a software project via a boardgame and make it fun.
Here are a few things that I have come up so far:
• Human resources and tools / techniques are represented as cards.
• Requirements are also represented as cards, which are dealt equally to each player, and the objective is to move all requirement cards through an “SDLC” board (one per player) that represent a series of squares grouped according to phases (design all the way to deployment)
• The passage of time is represented in a main square board like monopoly, and completing a trip around the board (passing “Go”) allows the player to move each of the requirement cards a number of steps through the SDLC board depending on the capability of the resource cards (senior programmer allows one requirement to move two squares in the dev phase, junior programmer only one, etc.)
• Players will start with play money representing the project budget, and at every pass at “Go” is payday. The player is out of the game if he runs out of funds.
• The main board also has “chance” / “risk” cards, which represent things that can mess up a project. damage is applied at the roll of a die, and chance modifiers depend on whether the user has “bought” tools / techniques.
I haven’t implemented this idea yet as I’m still looking at more play elements that can make the game more engaging, as well as soliciting for more ideas.
I am planning to release this under Creative Commons license but haven’t decided on the exact license yet.
Any more game play suggestions are welcome.
UPDATE: There is now an active thread about this in BoardGameGeek. http://www.boardgamegeek.com/article/4448368
[...] See original here: SDLC Board Game « A Clockwork Durian [...]
Nice concept. Instead of a Monopoly style board game, how about a RTS (Real Time Strategy) game instead? You battle other software vendors over market share which means getting good releases to market quicker than your opponents. You decide on what mix of tools, infrastructure, and people to spend your allotted resources on.
I do like the idea of chance cards, though. The hard disk containing your source code repository dies, lose 20% of your code quality if you have not been doing regular backups. One of your senior developers starts dating, lose 10% of your code quality if you have not been doing peer review or continuous integration. Most of your developers attend a one day event hosted by a deep pockets tool vendor and start incorporating the new technology into your product. Lose 5% of your code quality if you don’t have a strong architect or practice TDD methodology.
I’ve played a game similar to what you describe and it was pretty fun. The main point was teaching software risk management concepts, a little more advanced than what kids could probably handle with an introduction game.
My advice is to be careful when representing lifecycles in your game. For example, you don’t want to force players into a waterfall lifecycle and want to keep things open so they can choose spiral, incremental, v-model, and so on. That way players can compare and contrast lifecycles as a result of playing.
Let me know if I can help out. http://www.linkedin.com/pub/jason-evans/19/a19/462
Thanks for all the comments. I am currently exploring various boardgames to get a better understanding of the different kind of gameplay mechanics available. It seems that roll-and-move gameplay is not a hit with many boardgamers.
Oh and by the way, there’s a similar cardgame that was released in 2003. Problems and Programmers. http://www.boardgamegeek.com/boardgame/21999/problems-and-programmers I haven’t tried playing it yet but it’s worth a look. It’s a print-and-play game meant for a software engineering class.