The work for my Long Term app development and hosting project needs an effective method of tracking the work. I’m a single person, so I want something simple and light weight. Having studied Agile and SCRUM, that’s where I’m leaning. Give me a Kanban board where I can track a backlog, Work in progress, and done items, and I’ll be happy.

Choosing an Agile Task Tracker App

I looked into a few different products and I landed on Azure Boards. One of the biggest reasons was cost. While I’ve used both GitLab and Atlassian’s JIRA, they cost money. This is a passion project that’s being funded out of my back pocket. As such, I’m concerned about my budget. For me to go with a paid tool, it would have to be miles ahead of the competition.

My goal is to spend time learning to code instead of managing a lot of tools and infrastructure that supports those tools. I think that’s what a lot of projects would prefer to do - placing effort on the project, not the surrounding stuff. The tool I select must be cloud based. Nothing I’m doing is secret, so I don’t have concerns about keeping data onsite. Also, cloud hosting means I don’t have to install, manage, patch, and update tool servers and software.

Three products immediately come to mind as being close to the requirements. Jira, GitLab, and Azure DevOps all offer free versions. I’ve chosen Azure DevOps as it’s the most free of the three offerings. There are limitations in the other products that I’m not sure I’ll hit, but I would be bothered if I did. The pricing sheets from Jira and GitLab show the free versions as tiers, whereas Microsoft’s Azure DevOps products have no paid tier to offer as an upgrade.

Choosing a Version Control System

GitHub will be used as the version control system. Azure DevOps supports two options - TFS or GitHub. I’m using public GitHub because it’s free and also the point of this is to share what I’m doing. I’m going tp succeed or fail with this out in the open, so I won’t be hiding any code. This is also in keeping with my decision to run as few management / tooling servers as possible.

Even though I’m the only developer (so far) contributing to this, the idea of being able to branch and merge code is a typical process in modern app development. A Trunk-basd approach instead of GitFlow will be used, at least, at the the start. Trunk-based means I’ll be working the majority of the time on a single branch - master. I don’t expect to use release branches at this time, but that’s open to change as needed. The advantages of a GitFlow framework for branching and merging simply don’t apply to me as I don’t expect to have an army of developers at different coding levels working on the code. As I’m the only expected developer and reviewer, Trunk-based should be fine.

Ultimately, the choice to use Git with a Trunk Based Development approach is simplicity. The below graphic depicts how GitFlow can get pretty complicated pretty fast. Bouncing between development, feature, and release branches is a lot of overhead for 1 person.

Source : https://fpy.cz/pub/slides/git-workshop/#/step-21

GitHub repositories will be created for each configuration scenario. The GitHub Repository link is here (https://github.com/nathaniel-avery/Long_Term_Project_Run_Trackerv1)

Choosing a Work Item Process

Azure DevOps provides four options for Work Item Process tracking

Agile
Basic
SCRUM
CMMI

The style choices are sometimes subtle, but they do matter based on how you intend to work. Microsoft describes the differences in this document (https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/choose-process?view=azure-devops&tabs=basic-process). The most structured format is CMMI. The least formal is Basic. Agile and SCRUM are somewhere in between.

A legitimate challenge with this choice is knowing that none may perfectly align with how teams operate in the real world. Almost every team seams to work Agile frameworks a little differently. Sometimes the language is altered. Changes might happen due to an enterprise choosing to use a scaled approach to Agile such as Scaled Agile Framework (SAFe) which introduces more concepts, terminology and roles such as release trains with Release train engineers. As best I can tell, Azure DevOps doesn’t have an option that fits with SAFe. Fortunately, I’m a 1 man team, so scaling agile isn’t a concern.

Capability Maturity Model (CMMI) is a tempting choice, as it aligns closest to enterprise level processes. There are tracking mechanisms for change requests, issues, and risks. I’m both the customer and developer, so it formally tracking change requests and risks is a bit much at the start of this project. At worst, features describing change requests would be a workaround when using SCRUM.

SCRUM will be used initially. While it’s not as lightweight as basic, SCRUM would provide me a chance to keep up with the Certified SCRUM Master certification I earned a while back. A more strict adherence to the SCRUM framework would work as reinforcement of lessons I’ve forgotten due to working in other agile frameworks like SAFe over the years.

There are multiple work-item types supported such as Test, Feedback, and Code-review.

Source - https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/cmmi-process?view=azure-devops

Now that I’ve selected a work tracking methodology, I’ll create tasks and begin working on the infrastructure for hosting and testing code.

References

JIRA Pricing - https://www.atlassian.com/software/jira/pricing?tab=cloud

GitLab Pricing - https://about.gitlab.com/pricing/

Azure DevOps Pricing - https://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/

Choose a Process. (2019). Retrieved from https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/choose-process?view=azure-devops&tabs=basic-process

Gadzinowski, K. (2017, October 2). Trunk-based Development vs. Git Flow. Retrieved January 27, 2020, from https://www.toptal.com/software/trunk-based-development-git-flow

Mówiński, K., Mówiński, K., & Developer, F.-S. (2018, February 28). Escape from Merge Hell: Why I Prefer Trunk-Based Development Over Feature Branching and GitFlow. Retrieved January 27, 2020, from https://stxnext.com/blog/2018/02/28/escape-merge-hell-why-i-prefer-trunk-based-development-over-feature-branching-and-gitflow/