Usually when you are working for someone you will be required to report progress in some manner. Bosses and customers are obsessed with knowing that stuff is getting done for some reason. There are a myriad ways to do this. I prefer it being as lightweight a process as meets the needs of my employer or customer.
Some people insist on having gantt charts and all kinds of planning diagrams and such. I’ve not found them all that helpful and especially when working alone this is some pretty heavy weight process just to create a chess program. So no, not going to do that.
Most of my agile experience is with Scrum. This also can get pretty heavy weight and so in the last few years people have been tearing away at the time sinks in this process to create Lean, with one of the more common being KanBan.
Project management isn’t going to be a huge part of this blog series but since the object is to provide a view of what working on real C++ projects is like, there will be some. At this time I’ve decided to use the github issues system with waffle.io on top. This is a fairly feature starved setup but sometimes that’s a good thing–the more features you have in your tools the more your process tends to turn into a slog fest where you spend more time ticking off little process requirements rather than simply write code and tests.
At this point there are very few issues in the queue. This doesn’t mean there isn’t much to do in order to get to our first release milestone. At this point they represent a very rough outline of the things to do. As we move forward we also need to look at these issues (‘epic’ issues of a sort) and split them up into possibly smaller tasks.
On the other hand we may find that they don’t really split down any further. In agile a development task should represent the smallest grain of a complete feature and no further. You don’t want to create tasks that take months to resolve and result in massive changesets, but you want to limit the measure of completion at every level to something that is actually complete. At any time in the process the customer or employer may decide to release–they should be able to do so.
We use a rather liberal definition of “complete feature” though in order to make this possible. In this case we have a general idea that the first release is going to be a rather simple chess playing program. To create releasable features that can be completed in short time we need to split that down a bit. So I have planned the following sort of roadmap toward that end, and at each stage in the process we’ll have something that could potentially be released as a product–even if a rather pointless one.
- A program that prints out an ASCII drawing of a chessboard with pieces on it. Takes a position from the user and makes the drawing.
- A program that takes a starting position and who’s turn it is, and enters a read loop that requests moves from the user and alters the position and game state based on those moves.
- A computer opponent that’s rather dumb–doesn’t know that the game has ended nor some of the other complex rules. Just finds good moves and makes them.
- A complete set of rules the computer opponent will use in its analysis–it should never try to make an illegal move.
- Enforcing those rules on the human opponent so that any attempt to make an illegal move results in error and re-request.
It is preferable to have a more parallel set of issues so that multiple developers can work on different things at the same time. It’s not unusual though for that parallelism to require some ramping up time, as we see here. At around stage 3 we begin to see opportunity for it though, someone could work on the computer opponent while someone else works on the complex rules and maybe someone else enforces those rules on the human opponent.
With that in place we can begin development. To begin that process I have assigned the first issue to myself and moved it into the ‘In Progress’ state. I will create a new branch to work on as you would in a production environment. The process of work will be:
- Grab an issue, assign it to myself, and begin progress.
- Create a branch to work on the issue–named in a way to reflect what’s being worked on.
- Do work, committing changes on the way.
- When finished do a pull request to start the code review process–I will be involving the community in this.
- Upon receiving input and finishing any changes that may be needed merge that pull into master.
- Observe the CI server to ensure I didn’t screw up somewhere and break the build
- Close the issue as complete.