tP Week 9: MVP → v1.3tP Week 11: Release candidate → v1.5


tP Week 10: Alpha version → v1.4

  1. Do a postmortem of the previous iteration
  2. Plan the alpha version (v1.4)
  3. Deliver the alpha version (v1.4)
  4. Smoke-test CATcher COMPULSORY
  5. Start updating UML diagrams in the DG

Intro to tP Week 10

What's happening this week:

v1.4

  • Learning outcome: Able to tweak the product/project plan to match the available time/resources.
  • Product goal: Implement versions of all the features intended for final release.
  • Strategy: Add features based on priority, while maintaining a working product. It is OK if the features are slightly rough around the edges, as the next iteration can still tweak them features.

In this iteration, we learn from past iterations, and aim to better plan and better deliver another functional increment that would get you very very close to the final version in terms of raw functionality.
We call this the alpha version because this version is meant to be good enough for of the product.

First, in task 1 we look back at the previous iteration, to see what we can learn from it.
Then, in 2 we plan features to be implemented in this version, while aiming to reach very close to the final product's feature set.
Finally, in 3 we implement those features to deliver the v1.4.

Things to note:

FAQ How much code/features is enough to get full marks?


1 Do a postmortem of the previous iteration

  • Discuss with the team how the iteration went (i.e., what worked well, what didn't), and your plans to improve the process (not the product) in the next iteration.
  • Submission: Keep notes about the discussion in your shared project notes document so that the tutor can check them later.

Like to try a new Git workflow? If you feel you are now comfortable with the forking workflow, and now you would like to practice another one, your team can choose to follow the feature branch workflow from now on.

2 Plan the alpha version (v1.4)

-- [more details to be added] --

  • What features would you include if you had only one more week?
  • Aim to reach a fully-fledged (albeit unpolished) version of the features
  • Decide the order/timeline, create issues, assign devs
  • Tackle tasks based on priority, while staying breadth-first.

3 Deliver the alpha version (v1.4)

-- [more details to be added] --

  • As before, manage the iteration and release v1.4
  • Smaller steps encouraged. Don't be tempted to do the full feature in one PR.
Ways to level up your tP game:
  1. Use parallel PRs: We encourage you to try sending parallel PRs (i.e., send another PR while the previous PR you sent is waiting to be merged) if you haven't done that yet. Reason: It's important to learn how to do that, because in most real projects it is common to have multiple open PRs from the same author.
  2. Maintain the defensiveness of the code: Use assertions, exceptions, and logging in your code, as well as other defensive programming measures (refer this week's topic on defensive programming for more details) when appropriate. This will be considered when grading your tP code quality.
    Remember to enable assertions in your IDEA run configurations and in the gradle file.

4 Smoke-test CATcher COMPULSORY

  • This activity is compulsory and counts for 3 participation points. Please do it before the weekly deadline.

Some background: As you know, our includes peer-testing tP products under exam conditions. In the past, we used GitHub as the platform for that -- which was not optimal (e.g., it was hard to ensure the compulsory labels have been applied). As a remedy, some ex-students have been developing an app called that we'll be using for the PE this semester.

This week, we would like you to smoke-test the CATcher app to ensure it can work with your OS, Browser, GitHub account, by following the steps given in the panel below.

  • [Heads up] Load-testing CATcher will be done during the upcoming weekly briefing (Fri, Oct 25th ), during the first 15 minutes of briefing. This is different from smoke-testing you did above, and this will count for participation separately.
    Therefore, remember to attend the briefing (via Zoom or F2F) at least for the first 15 minutes (this activity cannot be done any other time).

5 Start updating UML diagrams in the DG

This is a good time to get familiar with the diagramming tools used by the tP.

  • Each member is recommended to update at least one UML diagram in the DG, to match the changes you've done so far v1.4. You may do this towards the end of v1.4, or soon after you finish it.
  • Updating the DG text to match the diagrams is optional (it can be done later).
  • FYI, the panel below has some DG tips, some of which are related to drawing diagrams.

FAQ Why not wait till the end to add/update the DG diagrams?


End of tP Week 10

Have any suggestions to improve AB3?

Now that you have worked with AB3 codebase for a while, if you have any suggestions on how to improve AB3 (for future batches), feel free to post in the AB3 upstream issue tracker.
Examples: places where the design/code can be simplified, hard to understand parts of the code, tips you can share with future batches, ...


tP Week 9: MVP → v1.3tP Week 11: Release candidate → v1.5