Teamwork

Much has been written about software development teams (starting with Mythical Man Month). How should they be organized? How do they communicate? How do they share work? In some ways working on a team is harder than working alone. In addition to programming skills, team members need collaboration skills such as communication, leadership, and being responsible. They may also need to overcome egoism and/or introversion.

For our project every team member will be in a programmer role. One team member will be designated as team leader.

Get Organized

During the first team meeting:

·        Introduce yourselves. (Name? Location? Major? Experience?)

·        Exchange contact information.

·        A new team leader should be selected if the appointed one doesn't want to do it.

·        Schedule the next meeting. (Who will host?)

·        Agree on what collaboration software will be used (see below).

Collaboration Software

Software development teams use many different applications for collaborating. For example:

·        Version Control (e.g. Git)

·        Bug Reporting (e.g. BugZilla)

·        Unit Testing (e.g. JUnit)

·        Scheduling (e.g. Gantt Charts)

·        Communication (e.g. Zoom,Wikis, Discord)

·        Documentation (e.g. Google Docs)

There are suites of tools that provide these types of apps (e.g. Asana, Slack, Jostle, Google).

Slackers and Ghosts

If a team member slacks or ghosts the team members (all of them) must decide if they should reassign some or all of the slacker's tasks, and the instructor should be informed. This will have an impact on everyone's grade. (See below.)

Grading

At the end of the project each team member will privately submit a form assessing the percentage of each team member's contribution to the project. For example: "we all contributed equally, 33% each", or "Larry and I did 50% each and Curly did 0%". Using this data, along with edit histories and the project score awarded by the grader, I will come up with a contribution score for each team member.

For example, if the project score was 40/50 and all team members contributed equally, then each member gets an individual score of 40/50. If Moe and Larry did all of the work, then their individual scores are 40/50 while Curly gets 0/50. If Moe does all of the work, then Larry and Curly get 0/50. Moe gets 40/50 but there may be a small deduction because of the lack of teamwork, which is the whole point of the project.

I'll use something like this for computing each team member's individual score:

The Tasks

Task 1: Create mvcApps version 0

The team leader creates an IntelliJ project called mvcApps. The project contains three packages:

Note that the dependency arrows indicate that stopLight and mineField use classes in mvc, but not vice versa. It is important that a framework remain totally independent of its customizations. (Why?)

The design of the mvc framework is given here. At the bottom of the page there are links to the code for stopLight and a few mvc files. The team leader should add these files to the appropriate packages in the framework.

Following the diagrams on this page, the team leader should create the required classes and interfaces and add them to the mvc package. These can be empty for now, but the top of each file should contain an edit history log. For example: AppPanel.java. Anyone who modifies these files should put their name, the date, and a brief description of what they did in the edit history. As mentioned above, this will be used to determine each students individual contribution score. (If GitHub or some other VCS is used, then this shouldn't be necessary.) This is version 0 of mvcApps.

Ideally, the team leader should select "Share Project on GitHub" under IntelliJ's VCS menu. (IntelliJ may prompt the team leader to set up a GitHub account.) Alternatively, export the project to a zip file. Make three copies, sending one to each teammate and placing the other in a folder called mvcApps/version0.

Task 2: Complete the mvc framework

Using the mvc web page as a guide, complete the mvc files in the following order:

Model.java

View.java

Command.java

AppFactory.java

AppPanel.java

I suggest assigning files to different team members. Team members add these files to their copy of version 0. If GitHub is used, a team member commits their files to their local version, then pushes their version to GitHub, where it becomes a branch of version 0. Otherwise, each team member exports their mvcApp to a zip file that they share with the team. These versions can be identified as 0.1A, 0.1B, and 0.1C (one version for each team member).

Task 3: Merge and test

At a team meeting the versions need to be carefully merged together to create mvcApps version 1. Version 1 can be tested by running the stoplight simulator. (Do not make changes to the stoplight simulator!) If it works and everyone is happy, then export the project to a zip file. Make three copies, sending one to each teammate and placing the other in a folder called mvcApps/version1. (This isn't necessary if GitHub is used.) If it doesn't work, then start debugging!

Task 4: Complete the Mine Field customization

Begin with MineField.java. This is the extension of Model, and if it doesn't work, then nothing else will. It might be a good idea to create a class called TestMineField containing a main method that tests the MineField code. You may also need to implement some supporting classes.

Next, complete the View and Command extensions.

Next, implement AppFactory.

Finally, complete the extension of AppPanel.

Task 5: Merge and test

At a team meeting the versions need to be carefully merged together to create mvcApps version 2. Version 2 should be carefully tested. The code should be clean and properly formatted. If everything works and everyone is happy, then the team leader should upload this version to Canvas. (It isn't necessary for each team member to upload something to Canvas.)

The Schedule

At the first or second meeting a team schedule should be agreed to and post a schedule (as a Google sheet perhaps). Here's Team-0's schedule:

In addition, regular meetings should be scheduled around each due date. Notice that Team-0 gives extra time to the Merge and Test tasks (T3 and T5). This is because merging everyone's code together is difficult and stressful. Things that work by themselves don't work when put together with the other bits. Having team members work on different files can simplify the merge. Also, version control systems like GitHub provide a nice tool that allows the team to step through each change to the project.