MVC Maintenance Sprint Project aka "The Level Up Project"

Learning Goals

• Utilize the skills for building a high quality .NET applications in a more open ended environment
• Build familiarity with the maintenance phase of the SDLC
• Handle navigating a new team and codebase

Output Goal

• An even better project to add to your professional portfolio!

Overview

Over the past week you’ve all learned many tools to improve the quality of your applications and level up your .NET skills!

These tools include:

• Error Handling and Validation
• Logging
• Refactoring
• Writing Good Documentation

This week you’ll have the opportunity to return to your MVC group project from Mod 4 and level up your application by working on a sprint fully focused on “Maintenance”!

What is maintenance, with regards to the Software Development Life Cycle (SDLC)?

I really like this explanation from this post on Geeks for Geeks:

“Software Maintenance refers to the process of modifying and updating a software system after it has been delivered to the customer. This can include fixing bugs, adding new features, improving performance, or updating the software to work with new hardware or software systems. The goal of software maintenance is to keep the software system working correctly, efficiently, and securely, and to ensure that it continues to meet the needs of the users.

Software maintenance is a continuous process that occurs throughout the entire life cycle of the software system.”

On your future teams, you will probably not spend an entire sprint only on maintenance. Your sprint will probably be a combination of new features and maintenance. Here is further explanation on how that might look like.

But in a class setting, we mainly focus on new features, so for this project we’re going all in on maintenance. You will be adding no new features only leveling up what’s already there.

Project Requirements

Each team is responsible for implementing each of the following topics at least once:

• Error Handling and Validation
• Logging
• Refactoring
• Documentation Improvement

You can also work on tasks related to:

• Fixing bugs
• Making small improvements to the user experience

Each team must follow a git workflow and create pull requests instead of coding directly on the main branch. Each change must go through code review before merging unless it was built entirely with pair programming.

Working on a New Team and Codebase

For days 2, 3 and 4 of the project one team member (or two one day for a group of 4!) will swap to a new team for the day. Joining a new team and codebase is HARD, but it’s something you will all need to do in your first job and a great learning experience to practice with this skill now. Having a new team member join can also be difficult for existing team members as they now have the additional responsibility of helping the new teammate onboard.

We will brainstorm as a class at the end of day 1 ways to make this successful. At each day’s stand down the team will gather and come up with a plan for welcoming the new member the next day and what would be a good ticket for the new team member to work on.

✅Deliverable✅: Each team is responsible for sending a plan for the new member joining the next day to their team Slack Channel by 4:00pm MT.

It is the groups responsibility to make sure that the new member feels welcomed and able to contribute.

✅Deliverable✅: By 4:00pm MT on the day you swapped teams, send your instructors your answers to the following reflection questions:

• How was this for you, jumping onto a new team and codebase and trying to contribute?
• What did you and/or your teammates do that made this easier than it could have been?
• What would you do differently next time?

Schedule

Day 1 (Everyone in original team):

• Sprint Planning
• Work Time
• Class discussion: Joining a New Team and Codebase
• Stand Down

Day 2 (One teammate swaps):

• PD: Resumes
• Stand Up
• Work Time
• Stand Down

Day 3 (One teammate swaps, or two if in a group of four):

• Weekly Assessment
• Stand Up
• Work Time
• Stand Down

Day 4 (One teammate swaps):

• Stand Up
• Work Time
• Stand Down
• Share Outs (back in original team)
  • 2 * numberOfGroupMembers minutes per group, then a couple minutes for questions
  • Not a formal presenation, no need to create a slideshow.
  • Each student will pick a commit they are proud of and share the commit in github with the class
  • You can also show the impact of that commit on your app
• All Class Retro