When our class was being introduced to GitLab, and how to post topics on an issue board there were a couple of terms present within the menus that we didn’t go over in class. These terms are story, epic, and initiative, all of which relate to each other. Conveniently all of these terms build off the formers’ progress, and can easily be slotted into a DevOps-esque working environment.

The first of these terms, a story, is what we are most familiar with as it’s another term for an item selected from the Sprint Backlog. A story is a unit of work that can be completed in a one to two-week span. These often come from user feedback, meaning that the product has seen some use outside of development, however stories can originate internally (just like items on a Sprint Backlog). Stories are supposed to be smaller so developers can take multiple during one sprint with the goal being a handful of stories contributing to an epic.

The next term, an epic, is composed of several stories and aims to explain something larger during the development cycle. For example, if you are developing an app that doesn’t have features such as colorblind compatibility, text zoom, and a narrator, then each of these additions could be a story (can be an epic itself depending on the workload). The epic here would be ‘Improving accessibility’.

The final term, an initiative, similar to the former is composed of the prior terms, in this case an initiative is formed of several epics. These run for a minimum of half a year and can continue well past one. These serve to highlight the direction in which the project is aiming to head towards. Continuing the example from the previous term, if we add epics such as ‘Marketing towards non-likely users’ and ‘sign-on bonuses’ it can fit into an initiative that may be ‘increasing user engagement’.

For the purpose of this class, stories are going to be what we encounter the most, with maybe an epic or two depending on the scale of a project. What I’m curious about is whether these terms can be applied to the capstone project course. That course specifically will focus on working on a much larger scale project, so keeping track of tasks via stories/epics/and initiatives could prove to be effective. A reason why I understand these terms not being taught within the course is due to scaling. We focus on learning agile development as it is much more flexible for both smaller and larger projects, meanwhile an epic-based development process may only see great benefits from working on a larger project.

-AG

Source:

https://www.atlassian.com/agile/project-management/epics-stories-themes

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

While searching for a first topic to write about, the question in mind I wanted to answer was “What is the formal definition of the processes we have been following” and “How does it all relate to what we’ve learned”. This question was answered by the following article which introduced me to the term DevOps, which is abbreviated for Development and Operations.

The following article grants a brief definition of what DevOps is, but most importantly shows the core values that all tie this subject together. Most of these core values we went over in great detail within our class, such as Continuous Integration and Deployment, while others were completely new to me such as Infrastructure As Code (IaC). This simply put focuses on how we interact with Infrastructure and looking at areas in which it can increase efficiency through automation.

Beyond showing the core values, this article speaks on the best ways these are applied. Some of these topics are implied such as collaboration through Agile Development and Continuous Integration and Development, but there was one I did want more clarity on and that is automation. Fundamentally I understand that teams can use automation to increase efficiency, however it does seem counterintuitive in an environment that promotes teamwork. On one hand, you can increase efficiency by letting automation ‘do its thing’ with little supervision, but that may create future errors. These errors and subsequent corrections will reduce efficiency later in development. If you allocate one (or more people) to frequently supervise the automated process, then there’s less of a risk of something going wrong, but you lose the efficiency that one (or more) people could’ve provided. By arguing this I’m not stating that automation does not have a place within DevOps, but that it may be a dangerous inclusion if not accounted for correctly.

Overall I found this article useful in expanding my knowledge of what we’ve learned throughout the semester, the visual(s) provided showing each component of the DevOps processes did help too. One thing that I would suggest for future semesters is maybe looking into how automation can be integrated into DevOps and appending it to your current lectures/activities? I think the curriculum for CS-348 is very good as of now, but adding a unit about automation could maybe help answer some of the questions I asked and potentially could help future students be ready for what they may see in the workforce (beyond college). Lastly, the source in which I retrieved this information seems to be a post on LinkedIn by a company named Quality Matrix Group, so there seems to be plenty of credible information within the post.

(Bonus points for them being based locally in Westborough MA!)

-AG

Source:

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.