How I Use the Atlassian Suite for Software Development
As a Software Engineer, I always resisted using management tools to perform my tasks. I did fight the process and worked to just get the job done to the best of my ability. I often succeeded and my reputation as a senior, 'Gets shit done' engineer benefited. This all worked fine when I worked on my own tasks, but when I started working with a larger team I dealt with system engineers and with program managers that were unqualified. These types would do drive-by tasking without realizing they were the problem. They did not understand the Software Process. It was embarrassing and they brought productivity to screeching halt and destroyed morale.
So, in order to manage these manager type, I quickly realized that software process tools were a benefit to me. So, to defeat a typical incoherent driveby, I would say, is it in JIRA? is it assigned? and better yet, has it been tested. Of which, the systems engineer would run away not knowing how to properly create test plans or test a system before deploying to operations. In the defense contracting world, they hire anyone with a pulse and the good ones leave or are forced out. But I digress.
Once I started playing with the Atlassian Suite of tools I quickly saw the benefit of these tools to the software development process. These tools are well thought out and improve the day-to-day workflow of the Software Engineer. First off, simply using Git/BitBucket is critical to any software development effort. I would create my project, upload my files into a Master branch or Gold Copy Branch. From here I would create a Development branch from which all JIRA issues would be branched. With this, I created a Release branch that was a place where resolved JIRA software issues were pushed for Integration and testing and combined with other issues to form a release. Once finalized and approved the release would be Tagged and pushed to the Master branch. The Tagging is critical since it allows you to pull from Git using the tag. With Atlassian, you can also view work history and control the merging of branches into the development branch once code/peer reviews were completed. You could also see a history of all commits and who performed them. I had the most commits and branches created since I was the most productive person at my last sad government contracting position. This was a place where mediocrity was deemed as awesome. Such a sad place and I hated it and the company I worked for, for many reasons. But that is another story about following your gut and who to trust.
So, having addressed the benefits of git for software source control management, I want to mention the next process of creating and tracking issues using JIRA. JIRA allows you to create new issues and categorizes them as new tasks, bug fixes, enhancements, etc. It allows you to establish a historical workflow of the issue so all can follow the progress. This removes all guessing as to what is being worked on and the status of the work. JIRA issues can be prioritized, assigned to team members and categorized into existing JIRA Epics for the project. You can organize this shit to death and it is a very powerful organizational tool for your software development process. This says alot coming from me that used to be a cowboy code slinger that just got shit done. The addition of this process was not oppressive. And as mentioned, helped me managed the idiots that thought the understood the software process.
Now enter the SPRINT planning. With JIRA issues created and placed on a queue, or backlog. The Sprint can be created. Typically done in two weeks spins. You pull the JIRA issues you want to be part of the sprint and assign, prioritize and estimate the work units or hours required to complete the issue. Bam, then you start the Sprint. During the sprint the team can update the status of the issues and move them from assigned to started and in progress to completed. At the end of the sprint you can see how well the team did with the number of issues completed and the metrics on their allocated work units. If you ware way off on the sprint and your progress, you can readjust for the next sprint or identify that you need more resources to meet the sprint deadlines. This process keeps the team marching in the same direction.
Now one of the coolest features is the Kanban board.
Kanban board swimlanes identify bottlenecks in your workflow.
Now to tie the entire software process together and to incorporate the overall project concept and requirements, we use Confluence.
Initially, I used Confluence for creating and organizing design documents and software development notes. I also created forms and templates to aid in my daily workflow. You can create process workflow templates and have these instantiated for each iteration or release. These then become a record of your testing, or lack thereof on my project and your deployments and collaboration efforts with other teams. As the team started to see the benefit of these Atlassian tools to aid in our daily workflow and program management, I decided we needed to capture the requirements as well. I know, what a concept. They were currently kept in an antiquated app on another system and the requirements keepers became combative when asked to add these to Confluence. So, being the resourceful engineer that I am. I took a new task, entered in the high-level requirement and derived sub-requirements. This was easy to do using the requirements plugin located in Confluence. Once I got the hang of this, I quickly learned that once I had the requirements defined, I could create use case and expectations on the confluence requirements. What was even better is that I could create tasks and link these to existing JIRA issues or create new JIRA issues from these tasks. Now you have a complete end-to-end software program management process. For me, I saw the light and it made me a better person.
Having said all this, I approached the Atlassian tools with an open mind and learned how to incorporate these tools for my personal career growth. I was fighting an antiquated government and management mindset that New Things Are Scary (NTAS). In the end the team adopted these tools and talked about implementing what I did without even recognized I already experimented with this entire process and was following the proper software development process. For some reason, I was excluded from the software process discussions. It was an odd feeling being a Principal Engineer and not being included in software process discussions. At this time I new it was time to save my soul and escape from both the horrible government IT environment and from the cult that was my payroll service. Whew, my advice is to do the opposite of what I have done and you will be fine when it comes to career choices. But going through horrible experiences sometimes gets you rewards. I am now doing what I love and making alot more money too. But I digress. Definitely take my advice and use tools in your software development process. It honestly will make your daily work life go easier and keep you organized and your team marching in the same direction.