Skip to content

Latest commit

 

History

History
17 lines (9 loc) · 2.37 KB

Process.md

File metadata and controls

17 lines (9 loc) · 2.37 KB

Process

Things that worked well

We found that making extensive use of Github issues was helpful. We came up with an issue convention that allowed us to closely couple issues and branches, and a development process detailing when exactly branches and issues should be created. This allowed everyone to keep tabs on precisely what each other member was doing, and their progress so far. This made it a lot less necessary to maintain other lines of communication, such as in-person or Skype meetings.

We also found it very helpful to use a tool called Doodle to easily determine the availability of team members in the event that a team-wide meeting was necessary, either in-person or on Skype.

Things that did not work well:

Especially during the Scrum process in Phase 2, we found that in-person meetings were very difficult to pull off with our differing class schedules. Overall we felt that Scrum is a better model for development teams that share an office space, as we found it difficult to meet up with a mixture of commuters from different areas with conflicting class schedules.

Throughout the project, our lines of communication occasionally caused issues. Our initial choice of tools for group announcements and the like was Facebook - however, it was quickly evident that because a couple members of our group do not generally use Facebook that it was slow to disperse notifications among the team. There were a couple instances where a scheduled meeting was announced over Facebook, but a team member did not remember or did not have a chance to log on to Facebook between the announcement and the meeting, causing them to accidentally miss out.

Hypothetical process going forward:

Overall, assuming we were to continue working on this as a class project without a physical office space/regular time to work on this project, we would continue using the pseudo-Kanban process that we use now. Our project, by virtue of being based on the Model-View-Controller design pattern, is extremely modular, allowing all members of our group to work mostly independently. This makes it extremely rare that two people working on two different features/bugs will ever step on each other’s toes, meaning that large group meetings are unnecessary for small issues. That said, when it comes to large design decisions, we’d probably still find the time to meet up in-person.