Two weeks ago, I shared my initial thoughts about splitting the two-week project up into two parts. To summarize, what had been a two-week JavaFX project with one set of requirements became a one-week CLI project followed by a one-week GUI project. My initial post was about how students reacted to having separate submissions for the first week and the second week. Today, I want to share a different perspective based on what has happened in the interim.
Last week, the students formed teams for the final project. They had to complete a pitch by Friday, and by Monday morning, turn in a project plan. The plan was to be in the form of user stories, akin to those that I modeled for them in the two-week project. There were some structural things that every team got wrong: for example, each plan included user stories broken down by iteration rather than what was required, which was to prioritize the stories and then separate the first iteration stories from the rest of the backlog. Keep in mind that the students do all of this work in a shared Google Drive folder, and so I suspect that some team finished their work early and incorrectly, and then every other team copied what they found there, assuming it to be correct. The fact that the documents themselves had similar structures gives evidence to support this hypothesis.
The more substantial problem was this: most of the teams set up their user stories so that the highest priority story involved creating a command-line application, and then a future story added a JavaFX GUI on top of this. That is, they seem have followed my approach to unfolding requirements in the two-week project and mistaken my cheeky turning-the-tables for a best practice. In retrospect, how could they not? They had never seen a GUI before, so my little embedded narrative about a client who asks for a CLI and then changes requirements could not have resonated as I intended: if you don't know that it's odd, then you assume that it's normal.
It's a good example of the unintended consequences of teaching, and it indicates to me that I should do something different next time I teach the course.
No comments:
Post a Comment