Test

[arcturas1]

• Initial in-person meeting
  • Introductions
  • Determined that future discussions would need to take place mostly online, as our group members' schedules did not permit meetings in person.
    • Chose Slack as our informal communications medium
    • Chose GitHub as our code repository
    • Chose to use an open-source-like process model to accommodate our members' schedules
  • Discussed algorithm and options for the selection thereof 2.Created
• Created
  • Added team members as collaborators to GitHub project
  • Decided to use GitHub as our formal communications medium
  • Began implementing process model through GitHub:
    • Continuous integration is used to ensure that all code is tested against the current standards prior to merge.
    • Issues are raised to answer questions, make major product decisions (such as process changes and application design decisions), and track progress on tasks necessary to implement the application design
    • Issues related to implementation tasks are assigned to team members, possibly by the assignee, to show ownership; joint ownership is possible.
    • Any discussion related to a task, such as how to implement it, should be added to that task's issue
    • A pull request is made to resolve an implementation task-issue
      • The pull request is reviewed by the team, and merged after achieving consensus
      • Merging the pull request closes the issue.
      • Changes to enhance or fix code are addressed by opening a new task-issue
• Provided short bio's to get to know one another better and build the team
• Second in-person meeting
  • Discussed build tool options: narrowed to Maven, Gradle, or Ant
  • Chose initial approach to the algorithm: brute force heuristic. Due to time constraints and having a need to have Something done, this seemed like the best option to start with. Once a working product was tested and ready to release, We could then augment or change the way that we approached the problem.
  • Decide that our project
• : Gradle
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

[arcturas1]

Process Description:

• Initial Class Meeting:
  • We initially got together in class to discuss how we were going to communicate and the conventions we would use going forward. After brief introductions we realized that our schedules were going to make in-person meetings difficult, and we would need to work out remote solutions. We decided on hosting our code on GitHub as some of our members were familiar with it. For team communication Slack seemed like the best fit as most of us had used it and its team based structure was well suited for our needs. Given our schedules and the need for us to do most of the work remotely we chose a process model based on open-source development where coding is mostly done individually. As we would come across problems or need to consult with the other members we would raise an issue on GitHub. After the other members have weighed in and we had come to a consensus the issue would be closed and we would go back to our respective work. This allowed us to not only stay on the same page but also to make sure that if a member got stuck on a problem it would be quickly and easily addressable. We wrapped up the initial meeting by discussing a few ideas for the algorithm, but we did not reach a consensus at that time.
• Early Stages:
  • Shortly after the meeting we created the Slack channel and the GitHub repository. During this time we also formalized our process model and began implementing it through GitHub. On Slack we provided short bios to help us get to know each other better and bond as team. The process model we ended with was as follows:
    • Continuous integration is used to ensure that all code is tested against the current standards prior to merge.
    • Issues are raised to answer questions, make major product decisions (such as process changes and application design decisions), and track progress on tasks necessary to implement the application design
    • Issues related to implementation tasks are assigned to team members, possibly by the assignee, to show ownership; joint ownership is possible.
    • Any discussion related to a task, such as how to implement it, should be added to that task's issue
    • A pull request is made to resolve an implementation task-issue
      • The pull request is reviewed by the team, and merged after achieving consensus
      • Merging the pull request closes the issue.
      • Changes to enhance or fix code are addressed by opening a new task-issue
    • Each team member should check slack at least once a day to contribute to ongoing informal team discussion
• Second in-person meeting
  • In our second class meeting we decided to solidify the big picture elements we had not figured out yet, namely the build tool we would use and our overall approach to the algorithm. We narrowed our build tool options to Maven, Gradle, or Ant and opened an issue on GitHub for discussion. For our algorithm we prioritized making progress over finding the best solution and so decided that, at least for the short term, we would go with the simple solution of a brute force algorithm.
  • We also decided that our project
• Development Process: *The first issue addressed was our build tool. We decided on Gradle as some of our members have worked with it before. We also did some initial commits for the Gradle file, the device jar, and the requirements document.
  • We next had a pair of issues opened around our specific implementation. The first one was discussing the format of the showTrace() output. It went up and was accepted very quickly, with members suggesting small tweaks to the original proposal that was ultimately accepted. The other issue was us deciding on our final algorithm. We batted around a few ideas while making sure we all understood the spec correctly. After a day of discussion, we again decided to keep it simple and stay with a brute force approach, but we did think of a few ways to possibly improve it given time as well. We also decided to integrate continuous integration into the project by way of circleci. It especially made sense given the distributed nature of our process.
  • As we started splitting off to code either the unlocker or the tests to run it against, we continued to discuss possible improvements to be made if we needed to or felt we had time to. As the code started coming in and passing tests we were roughly down to polishing and assessing the quality of the final product and making sure it matches the spec.
• Submit the product
  • On Saturday, 8/16, we began worring about product submission: What if a team member can't click submit?" We decided that our recourse would be to contact Dr. Paul to notify him that n/5 team members were unavailable to submit the product. On Sunday, 8/17, we realized our fear: Travis wasn't available to submit the product. We then begin panicking about being able to submit the product. All available members clicked the submit button, and then we contacted Dr. Paul to notify him of the submission problem

Process Assessment:

• How well it worked Overall: we feel that our open-source-like process worked fairly well, given the time constraints of our group. On a 10-point scale with 10 being the highest, we give it a 7.5.
• What worked well:
  • Handling development tasks via issues on GitHub allowed us to track our progress effectively, deliver iteratively, provide constructive feedback, and obtain group consensus, for product changes.
  • Our in-person meetings were very productive, and we came to decisions relatively rapidly during them
• What aspects we would change:
  • We had some issues with communication, and our process should have included more focus on encouraging better, more iterative communication among team members.
  • Attempting to hold ourselves to committing to more in-person meetings, or adopting a tool to share screens and hold conference calls (e.g.: TeamViewer, Skype, etc.) if that proved too burdensome would have improved our process.
  • We should have started work sooner, to allow more time to refine our code and further improve its quality
  • We should have added a mechanism to involve our client in our development process

Reflection:

• We found that we enjoyed working on things on GitHub with people we'd just met. There were bumps, but that comes with the being on a new team. We also think, given the short length of time we've worked together, and limited in-person interaction, that the team formed pretty well. The process of development kind of guided itself. Pick an issue and work on it. Slack made it easy to discuss things quickly, while GitHub issues gave the issues more formal documentation to accompany decisions.