Your final team report will be provided to the next team. You may repeat some things from your presentations or sprint reports if they are important for the next team to know about. This report is a place to record the last bits of knowledge that did not belong in a public presentation and that will hopefully help the next team get up to speed in the new term. Some of these items are mentioned in the wrap up page. Write the report that you wish you had gotten!
Project Introduction for the Next Team
In an ideal world, or the real world, you would sit down with a new developer and walk them through the project to help them get started. Instead of doing that in person, please write down that introduction. You can make it take the form of a letter to the next group. You can write a narrative. You may do a video walk through instead!
- Discuss the high level view of your project. The next team will talk with the client just like you did, but getting an overview of the project from your perspective will be very helpful. At this point, no one knows the code better than you do!
- Explain the major parts of your project and how they fit together. What gems does your project use and why? If there are multiple gems, how do they fit together?
- Explain the workflow that your team used. If you tried different things and found some of them didn’t work as well as you had hoped, include that analysis.
- If you structured your project differently than how we discussed in class (i.e. Scrum-based sprints), please explain those differences and why you decided to do it that way.
- If you feel like it, include some words of encouragement or support :).
Remaining Tasks for Next Semester
- Where is your team’s to do list? Please provide a link to it and arrange to make your instructor an administrator or member of the team so that I can access it next term.
- Be sure – double check – that the GitHub repo has accurate instructions for how to access and install your code.
- Is there anything hiding in the code that should be addressed? Any lingering technical issues or concerns? Should gems be updated or changed? Did you fix a particular problem but know that it has weaknesses that should be addressed? Is there a better way to do something that you just didn’t have time to research or implement? Do you suspect a piece of code could be more efficient but didn’t get to refactoring?
- Did you add gems or change the structure of project significantly? Please document those decisions and provide instructions or educational resources to help the next team get up to speed.
Retrospective
- You don’t have to give a list, but was there something that your team is most proud to have accomplished?
- What tools or learning resources did you find most valuable and recommend to the next team that will work on your project?
- What are the success tips you would like to share with future students?
