Agile Practices

Here we briefly look at a few common practices among agile methods. We expect you to follow these practices

Test-Driven Development

Test-driven development (TDD) is a software development process where you write tests for the software requirements before fully developing the software. You then repeatedly test the software against these tests as you develop it, instead of developing the software first and creating tests later.

Test-driven development goes hand in hand with agile methodology. I encourage you to follow TDD. Whether you follow TDD or not, it is expected of you to write software tests (unit testing, endpoint testing, ...)

A portion of your project grade will be dedicated to "testing".

Continuous Integration & Delivery

Continuous Integration (CI) and Continuous Delivery (CD) are two key concepts in modern software development, especially in the context of Agile and DevOps practices. Here's a brief overview of each:

Continuous Integration (CI):
- Definition: Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily. This leads to multiple integrations per day.
- Purpose: The main aim is to detect and address conflicts early in the development cycle.
- Process: In CI, developers frequently commit their code to a shared repository using a version control system like Git. After each commit, automated builds and tests are run to ensure that the new code integrates well with the existing codebase and doesn't introduce bugs.
- Benefits: Early bug detection, reduced integration problems, and smoother, more rapid development cycles.
Continuous Delivery (CD):
- Definition: Continuous Delivery is an extension of Continuous Integration, designed to ensure that the software can be reliably released at any time.
- Purpose: It focuses on automating the software delivery process to enable frequent and reliable release of software.
- Process: In CD, the software is built, tested, and prepared for release automatically. It's about making deployments to production (or to the test environment) predictable, routine affairs that can be performed on demand.
- Benefits: Faster release rate, improved deployment quality, and the ability to quickly adapt to changes in the market or feedback from customers.

In summary, while CI focuses on the integration aspect of development (making sure the code works well together), CD extends this to ensure that the integrated code is always in a state that can be deployed to users. Together, CI/CD enables a more efficient, streamlined, and robust software development and release process.

You are expected to follow this practice when you are working on your project. Please use GitHub Actions to automate CI/CD.

Daily Stand-up Meeting

Daily stand-up meetings are a common practice in the software industry, especially among Agile practitioners. The team gathers every day, usually at the same time, to discuss the progress of their project. During these meetings, each developer takes turns answering three questions:

What did I work on yesterday?
What am I working on today?
What issues are blocking my progress?

The stand-up meeting is typically time-boxed to 15 minutes, although this may need to be adjusted for larger teams.

In OOSE, your team will have three weekly "stand-up" meetings. The remaining time should be dedicated to pair programming and group debugging sessions. Your advisor and/or instructor will be present during at least one of these weekly meetings.

Agile Retrospective

Another common industry practice among Agile practitioners is the retrospective meeting. This meeting is held at the end of an iteration. During the retrospective, the team reflects on what happened in the iteration and identifies actions for improvement going forward. Each member of the team answers the following questions:

What worked well for us?
What did not work well for us?
What actions can we take to improve our process going forward?

The retrospective is an opportunity for the team to reflect on their performance and create a plan for improvements to be implemented in the next iteration. You should document your retrospective, reviewing what was achieved and not achieved in the iteration, noting any challenges faced, and reflecting on how to proceed in the next iteration to improve.

Self and Peer Evaluation

In addition to the team retrospective, each team member will assess their own contribution to teamwork as well as the contributions of their peers. We will be using FeedbackFruit, a software solution for Group Member Evaluation that provides teachers with transparent insights into the collaborative process.

The peer feedback will be anonymous. Please use this opportunity to provide honest and constructive feedback to help your peers grow and improve.