Agile Practices #

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

Test-Driven Development #

According to Wikipedia, "Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before the software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is opposed to software being developed first and test cases created 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, ...)

Continuous Integration & Delivery #

Continuous Integration (CI) is a software development practice where developers integrate code into a shared repository frequently, ideally several times a day! Among the benefits of this practice is that you can detect errors quickly and resolve them more easily.

Continuous delivery (CD) is a software development practice in which teams produce software in short cycles. CD goes hand in hand with CI.

In modern software development, the build pipeline is often automated. That means, for instance, when you commit and push your code into the repository, a cascade of actions will be triggered that include "compiling the code," "executing tests," etc., which eventually result in deploying (software) artifacts. Automated build pipelines are great for integrating CI with CD.

Daily Stand-up Meeting #

Daily stand-up meetings are common practice in the software industry, in particular among Agile practitioners. Every day, at about the same time, the team gathers to discuss their project's progress. In these meetings, each developer take turns and answers 3 questions:

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

Standup meeting is typically time-boxed to a 15 minutes time slot, though this may need adjusting for larger teams.

In OOSE, you will meet three times per week during which your team will have a "stand-up" meeting. You should aim to spend the remaining time on pair programming and group debugging sessions. Your advisor and/or instructor will be present during (at least one of those) 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 a team to inspect itself and create a plan for improvements to be enacted during the next iteration. We will have you document your retrospective. You must review what you had done in an iteration; note things that you have and have not delivered, note the challenges you had, and reflect on how you shall proceed in the next iteration to do a better job.

Individual Retrospective #

In addition to the team retrospective, each team member must submit a confidential personal retrospective. In this retrospective, you shall reflect on your learning and contribution to the team. In addition, you will report the contribution of other team members in contrast to yours (e.g., member-1 worked twice/half as much as me).

Please use the personal retrospective to bring any issues or concerns that you would wish to share in confidence with the instructor. For example, you may be overstressed, too busy, or under a lot of pressure to keep up with the work required to deliver each iteration. You may be having a difficult time working with others in your group (e.g. some members are not responsive, or not doing their fair share).