-
Notifications
You must be signed in to change notification settings - Fork 0
Process
| Tool | Main Purpose | Details |
|---|---|---|
| Primary/Logistics |
|
|
| Slack | Collaboration |
|
| Google Drive | Documentation |
|
- In the event that team members are not being responsive, other team members will contact the. After these initial attempts are made, the team member in question is responsible for contacting team members to catch up on progress and discussion missed.
- Team members will refer to meeting agendas and past project documentation (i.e, architecture specification, design specification) for clarification
- In the event of disagreement, primary owners of components and subsets of the project will make an executive decision to resolve any issues
- Thursday Meetings
- Time: Scheduled from 6 - 10 PM, 2 hours duration
- Location: On campus - either in a study room (specific location based on availability; generally Odegaard)
- Purpose: Thursday weekly meetings would allow all of us to receive updates from one another, getting feedback for everyone’s responsibilities, delegate tasks in a timely manner with realistic deadlines, and give us an opportunity to have open discussion of what we have currently completed. It is also an opportunity for us to assess whether we have met the previous week's goals and to determine steps to change our process if necessary.
- Monday Meetings
- Time: Scheduled from 6 - 10 PM (in special circumstances, depending on necessity)
- Location: Online, through Google Hangout or Slack coordination
- Purpose: Monday meetings would serves as a checkpoint for any assignment that is due for the week. It’s a quick sync meeting with everyone as an assurance that we are ready to complete our assignment. Monday meetings are optional and would be mutually agreed.
- Tasks are assigned on Thursday mornings:
- By assigning tasks early in the week, we can ensure that there is enough time for project members to plan accordingly and get feedback and help from other project members if needed.
- Tasks, regardless of quality, must be finished by the following week:
- This ensures that all group members will make progress on something, even if it is not perfect.
- Members provide an update on their progress by Monday.
- Provides opportunity for project manager to determine if any additional steps or changes need to be made in order to complete our necessary work for that week, and allows team members a delegated time to get help from other team members if necessary.
- Teammates must make their own branch
- Personal branch is a good way for members to explore coding challenges that we have without the concern of “breaking” the program. It gives additional room for members to learn, find defects, and debug their own code/assigned components.
- Must mutually agree among the team before pushing to master
- Master branch is and should be a sanctuary. Changes to the master branch should be viewed as final decisions and be given proper weight and consideration accordingly.
Overall, components are grouped and delegated based on level of technical ability to reasonably handle implementation of specific components, and the interconnectedness of the components.
For example, the behavior of RecipeBox and LevelRecipes necessitates heavy interaction and exchange of data between the two components, so it makes sense to implement them together.
| Category | Owner | Component | Why? |
|---|---|---|---|
| Recipe Construction and Storage |
Isabel Giang | RecipeBox |
|
| LevelRecipes | |||
| System Management and Structure |
Diana Griffing | IntroOutroHandler |
|
| StepDescription | |||
| SpellManager | |||
| Information Retrieval and Interface Formatting: |
Sopheak Neak | StepBuilder |
|
| ClippysInfo | |||
| PopUpBuilder |
Schedule is timed to complete before finals week of Spring 2017 in order to accommodate focus on other finals, and to give graduating students in the project time to focus on Capstone presentations and graduation. We want to aggressively approach this application, and make sure we have enough room for failures. We chose our release as the 26th to give us an extra week of cushion, which hopefully will not be necessary as it would encroach on other schedules of finals and graduation. We then worked our way back setting realistic steps so that we achieve a completed product on the 26th. Following these deadlines will be the practices that ensure our completion.
| Date | Goals |
|---|---|
| May 5th | Complete testable components for one Dungeons & Dragons class |
| May 12th | Complete application with behavior working to desired specifications for one Dungeons & Dragons class |
| May 19th | Complete application with behavior working to desired specifications for all three Dungeons & Dragons classes |
| May 26th | Complete application with defect-free behavior for all three supported Dungeons & Dragons classes |
During weekly Thursday meetings, we will assess our process and our level of progress, if our level of progress is not to the goals stated above, we will explicitly determine what needs to be finished in order to be caught up (i.e, a specific subset of code, a specific set of mockups, etc) and coordinate to create a plan that ensures this work is complete along with future tasks.
If this is a an issue that seems to result from a flaw in our process, we will reassess our current procedures and change them based on the specific areas where we have fallen behind and why. For example, if a team member is finding it difficult to complete their goals for a particular component, it may be because the work distribution and the level of fit in terms of skillset was poorly assessed. It may also be because we don't have sufficient avenues for team members to seek support with their implementation issues. Both scenarios illustrate ways in which our process could be clearly changed and reassessed.