Project Policies¶
Project Organization¶
In this project, you will be divided into teams of five students, and will work collaboratively (both within your team and between teams) on a complex software system, chiventure, that will involve improving existing code as well as designing and implementing new functionality. You will be using several tools to support the collaborative aspects of this project and, indeed, your collaborative skills will be as important as your coding skills to be successful in this project. The project will follow an agile process that resembles (but does not exactly follow) Scrum.
Each team will be assigned to work on an existing or new feature of chiventure (teams will have a chance to express a preference, although we can’t guarantee we’ll be able to assign each team to their preferred feature). In each team, a TA will act as Senior Developer.
Project Timeline¶
The project will span seven weeks (Weeks 3 - 9), with a final review and team presentations taking place during Finals Week. The seven weeks of the project will be divided into a project kick-off and four sprints, with sprint reviews happening on Mondays.
Week 3: Project kick-off. This week will be primarily used for you to familiarize yourself with project and the exact work your team will do.
Week 4: Sprint 1
Week 5: Sprint 2.
Weeks 6-7: Sprint 3
Weeks 8-9: Sprint 4
Project Evaluation¶
The project contributes the following scores to your final grade (please see our Grading page for details on how these scores are used to compute your final grade):
The “Project Points” you accrue by completing issues and pull requests.
1 ESNU score from the Project Design Warm-up
1 SNU score from the Peer Feedback
1 ESNU score from the Final Presentation
Unlike a traditional programming assignment or project, the exact final outcome of the project is not known in advance. Of course, we will set some high-level goals and requirements and, while those requirements will help us measure whether the project is “done”, they are not a strict rubric. As we’ll see in class, this is one of the strengths (and challenges) of agile software development: you can re-evaluate requirements and make design changes quickly, but there is no detailed requirements document that you can use to check whether you’ve contractually fulfilled your obligations to a customer.
Project Points¶
Because there is no “golden solution” to the project, you won’t be assessed on how close you come to some idealized version of the project, or on whether you’re meeting all the goals you set at the start of the quarter. Instead, you will be evaluated on how well you follow a software development process (in other words, we will not be assessing the final product but, rather, the process that led to that product).
The most important component of this assessment is the issues and pull requests you will be completing throughout the quarter. Each issue and pull request will be scored using the ESNU scale and you will accrue a certain number of points for a completed issue or pull request as long as you earn, at least, an S.
You can find a detailed description of this aspect of the project in the Issue/PR Grading page.
Design Warm-up¶
Before you start working on the project itself, you will work on a design warm-up exercise that will allow you to practice some basic software design skills. More details on this component of the project can be found in the Design Warm-Up page.
Peer feedback¶
Twice throughout the project, each student will provide feedback to two other students in their own team. This is similar to a peer evaluation/review (which are fairly common in large software projects), except the feedback you provide will have no effect on the recipient’s grade (whereas in a real project, these evaluations/reviews could affect whether you get a raise, a promotion, etc.). Instead, we will be assessing the feedback you provide to others.
At the end of Sprints 2 and 3, you will be assigned two peers who will be providing you with feedback (you will know each other’s identities). Before they provide you with feedback, you must think about what you would like to receive feedback on. At the end of Sprint 2, you should think about the following:
What is something I’d like to improve or do better in the next sprints?
After Sprint 3 (i.e., during the final Sprint 4), you should think about the following:
What is something I’d like to improve or do better the next time I work in a complex software project and/or the next time I work in a team?
Based on this, you should prepare prompts for specific feedback, which can range from organizational/teamwork aspects (e.g., wanting to improve how you communicate with the rest of the team) to technical aspects (e.g., wanting to improve your understanding of some programming concepts), as well as from concrete to high-level. You are also welcome to provide additional prompts that don’t originate from the above questions. Once you have your prompt(s), you should convey them to the students who will be providing you with feedback (you can communicate this directly to them, via Slack, e-mail, etc.; you do not need to include the instructor or TAs in this communication)
For example, you could provide prompts like the following (the first two are examples of relatively high-level prompts, while the latter three are more specific):
I feel like I’m using Slack and GitHub effectively, but I wonder if there are any ways in which I could be using them more effectively.
I always procrastinate on my tasks until the 1-2 days before they are due, and I’d like to make more steady progress throughout the sprint. Do you have any suggestions on how I could do this?
Sometimes I feel like I go off and work on one of my tasks, and when I touch base with everyone else after a few days, some of the work I’ve done turns out to be headed in the wrong direction, and it seems like that could’ve been avoided if I had known what everyone else was doing. How could I make sure I stay informed of everyone else’s progress?
I feel like I sometimes derail conversations by getting too lost in the weeds when talking about my work, even though I may have a valuable point to make. Do you also feel like I’m doing this? If so, what other ways do you think I could make this point instead of the way I’m doing it now?
I know we create tasks at the start of each sprint, and I know which ones I’m going to be working on but, if I’m working with other people on the task, sometimes I’m not sure what exactly I should be working on. How can I make sure this doesn’t happen?
After you convey these prompts to the students who will be giving you feedback, they must convey that feedback to you. Please give your feedback givers at least one day to think about your prompts; after that, we encourage you to meet synchronously in-person or via Zoom (ideally with both the feedback givers at the same time) to discuss your feedback (if synchronously is hard to arrange, they can also convey their feedback over Slack, e-mail, etc.)
In the end, you must write a brief report (at least 3-4 paragraphs, and ideally no more than 700 words) for each of the two pieces of feedback you provide (each to a separate student). This report must include the following:
The prompts you were given
How the feedback was conveyed. If you met in person, please specify when, for how long, and whether it was a one-on-one meeting, or whether the other feedback giver was there.
A summary of the feedback you conveyed.
For the second round of peer feedbacks, mention whether there was any follow-up on the feedback you provided in the first round of feedback (e.g., if the feedback recipient acted on some of your feedback, and told you the outcome).
We will provide submission instructions once we are closer to the peer feedback.
You will receive a single SNU score for the peer feedbacks, based on whether your reports include the information requested above. In general, if you provide the information requested above in the first round of peer feedbacks, you will receive a Satisfactory. As long as you provide the same information, at roughly the same level of detail, at the second round of peer feedbacks, you will receive a Satisfactory overall for the peer feedbacks.
On the other hand, if your first round of peer feedbacks is deficient in any way, you will receive a score of Needs Improvement, along with a list of things you will need to improve in the second round of peer feedbacks. If those issues are addressed in the second round, your score for the peer feedbacks will be a Satisfactory (otherwise, it will remain at Needs Improvement).
Final Report and Demo¶
Requirements for the final report and demo can be found here.
Team Composition and Mobility¶
You will be assigned to teams based on your answers to a team assignment survey. At the start of the project, the composition of these teams will be immovable: please do not ask us to change it.
However, it is not uncommon in software projects for developers to interest themselves in the work done by other teams. So, if you find another team’s work to be interesting, we encourage you to look through the code they’re writing, poke your head into their Slack channel, etc. You can even offer to help with some of their tasks (especially backlogged tasks), which will also earn you points. Just make sure you’re still completing the tasks for your team, and that you discuss with the other team before you do any work on one of their tasks (e.g., “Hey, I saw issue #XXX in your backlog and I may have some extra time to work on that. Is that ok?”)
Sometimes, these collaborations result in someone becoming so interested in another team’s work that they end up asking to be reassigned to that team. In this class, you will be allowed to switch to a different team after the 2nd sprint, as long as the following conditions are met:
You must have been doing some work for the other team already, and must be able to point to completed tasks related to that team.
The switch should be motivated by the work the other team is doing, and because you want to be involved in it. We will not allow you to switch just because you want to be in a team with a particular person from that team.
Both teams (including the senior developer for each team) must be ok with this switch.
No team can end up with less than 4 members, or with more than 6 members.