Kanban Boards - tstorrnetnz/teaching2025 GitHub Wiki
Learning Aim: Be able to plan and manage your project
Once you have had your project topic written up as a brief and approved by your teacher, you are ready to plan, make and manage your project. Software projects can often be very complex and often over run on time. Managing them well is important. The following strategies will help you.
Be Agile
The key idea here is to break your project down into very small parts, make a single part, test it with your stakeholder, get their feedback, act on it, make some more and improve, test again, get feedback, make & improve…. Until the project is completed.
Note how you DO NOT finish your project and then give it to your stakeholder for the first time.
You should aim to have at least 4 cycles of development with your stakeholder - and meet with them every 2 weeks. This is called an agile development method, (agile because it responds to the stakeholder feedback right through the development process).
Use Kanban
The kanban board (explained below) is a really good way to help you manage the development process. It can be done using Github projects (GHP). Using project management tools is required for the project standard.
Use issues to track problems and manage your Kanban board
There is a particularly useful feature of Github called issues. When you find a problem with your code that needs fixing, create a issue for it. This is create a new item in your Kanban board. The use of issues in Github as part of Kanban is explained well here.
Think things through
Programming involves a lot of thinking. Designing GUI's is reasonably straightforward. A paper GUI will help you think about your data, what is stored, what calculations need to be done and what variables are required. Changing a GUI is easy. Changing your data structure and how the different classes, files and variable interact is very difficult once you have committed to a particular way of solving your problem. Discuss and explain how you will store your data with me and your classmates.
Commit your code regularly to Github
This is the big one - it takes a while to understand this. Github will store your code once you push it to your remote repository (ie on the web). Github Desktop does the same as Gihub, but on your desktop (which is not as useful or safe). You need to commit (i.e. save) your work using Github Desktop and then push it to the remote repository (Github web site) at least at the end of every coding session or even before if you complete a small section of work. Your commits (in Github web site) will look like this - there should many of them (eventually).
Create a log of your work
The assessment requires you to create a log of your work. This will work best if you create one wiki page (call it log) and regularly update it with:
- Screenshots from your commits
- Screenshots from your Kanban board
- Screenshots from your issue tracker
- Notes from meeting your stakeholder
- Thoughts about problems and solutions
- What programming you did
- What testing you did
Screenshots should be accompanied with an explanation of what the screenshot is showing.
Organise your log by data - horizontal rules will be useful here, as well as headings (h1,2,3).
Your log will show the story of your project - warts and all!
For you to do:
- Check that you created a wiki for your project (last week) - this will be your log
- Create an automated Kanban board for your project
- Set up your repl to work with Github (separate page)
- Once you have the go ahead from me - that your project is OK - meet with your stakeholder and start your project. The first item will probably be a write up of your meeting in your log,listing the essential and nice to have features, and then on to thinking about your data structure - put this in your log as well. If you want to draw a data structure then taking a photo and adding that as an image to your wiki is fine. The image may need to be re-sized.