When you’re ready to start cutting code, you’re going to want to commit to source control. As a hobbyist, you can do this locally of course, but you’re business now and that means creating redundancy in the event of failure. The simplest answer to this problem is of course cloud storage.
There are lots of options here, Jira, Github and Azure DevOps are all big names that will all do a great job but I will be using Azure DevOps for this demo.
For those who don’t know why we are picking Azure DevOps, it’s simply because it is a one stop shop. You might be thinking, ‘I know a great tool for x, a great tool for y and a great tool for z’ but for a start up, do you really want the overhead of a bunch of logins, users and licences as well as different ui and training for each tool? Having a one stop shop for our product team, devs and devops is incredibly useful and helps build a single team mentality. I’ve covered it a little more in an old post – here.
So head over to Azure DevOps and click on ‘Start for free’. You’ll be prompted to sign in with your Microsoft account (if you don’t have one get one free here).
This will create you a new Organisation (this is what Microsoft calls the business entity you are working with) and it will prompt you to create a new Project. Give it a meaningful name and description then choose if you want the project to be public or private. Personally, I would go for Private if it is for a business start up!
Under advanced you can pick your version control type (I opted for Git as it is industry standard) as well as the Work Item type (I opted for Agile, which is basically a Scrum board workflow).
From here, you will be greeter with the main page
The main bits you care about are
- Boards, great for dashboards and reporting. It’s also customisable, so if you want a view of how close you are to completing an epic, or your teams velocity, look here.
- Repos , Git repos! Keep you code safe and version controlled.
- Pipelines, CICD, DevOps, all on one place. Great for connecting to Azure but with connectors for other cloud as well.
- Test Plans, make sure your code works by linking Test Plans for each and every acceptance criteria.
- Artifacts, expose your shared code as Packages for use across your software estate
Making your first story
So before we can start writing code, we need our stories. We will just move over our simple stories from our other post for now and I will go through basic story construction.
So go to your boards and select ‘Work Items’ in the left hand menu, then ‘New Work Item’ (circled in blue for you). This will open up the Create Story page.
So one of our stories was ‘Customers must be able to find parking locations close to them’, let’s turn it into a story.
The first point, is that stories are typically simple sentences like ‘As a {user}, I want to {action}, so that {benefit}’. So our story would be ‘As an App User I want to see a map of car parks, so I can find a car park close to me’. Or ‘As an App User, I want to be able to use GPS, so I can see a list of car parks near me’. You can probably tell why we describe our stories this way, as it forces you to being explicit about the core requirement. Ultimately, both of those example sentences are valid but represent very different type of effort (maps vs lists).
Once you’ve got your story, you need to define Acceptance Criteria (A/C). So think simple points that follow MoSCoW (Must, Should, Could, Would) that you want to happen to be able to close the story. I’ve put an example page below.
So, crack on a make your stories! There’s a lot more to story planning, but I wont be covering too much here. If you want to read more, check out Atlassians pages here, they’re good and informative. I won’t cover the other sections here either, but feel free to click around and explore.
Masters Development 