- Iteration 3 did not provide an interaction pattern. How did you approach designing this iteration? If you did not get to Iteration 3, reflect on how you think you would’ve approached the design and problem solving process.
We initially developed methods directly in the runner script to quickly prototype and test our code. Once we verified that the core functionality was working correctly, we refactored our code by organizing these methods into a game class for better structure and reusability. Now that we understand the structure of a game, we might have begun with the class and methods in our game file instead of the runner file.
-
If you had one more day to work on this project, what would you work on? We would break up the #begin and #run methods in Game class as those are fairly extensive. We can also look to implement a smoother and more UI friendly game interface.
-
Describe the pairing techniques you used while working on this project.
Tuple was our predominant communication method to screen share and grant remote keyboard access to the other member of the project. We also utilized driver navigator roles for method blocks and test suites. A couple of times we separated to figure out a problem and came back together with solutions. For the future group project we know there will be more work done separately. This will likely lead to shorter but more intensive pairing sessions. Also there would be a chance for group pairing, which sounds like an interesting endeavor.
- Describe how feedback was shared over the course of this project.
Feedback was offered verbally and in real time. This worked well as it was both of our preference and almost all work was done paired. If we were in a more varied group setting, we might have utilized a pre-set forum for feedback or even one on one calls.