Absolute Prerequisite for Learning DevOps

00:42:12
https://www.youtube.com/watch?v=neG2MFVFji0

概要

TLDRIn this video, Abhishek explains the day-to-day tasks of a DevOps engineer and how they fit into the larger organizational structure. He discusses the various roles involved in gathering requirements, including business analysts, product managers, and product owners, and how these roles interact to define and prioritize tasks. The video also covers the software development lifecycle (SDLC) and emphasizes the importance of collaboration among different teams. Additionally, Abhishek introduces Jira as a project management tool, demonstrating how to create an account and manage tasks effectively. By the end of the video, viewers will have a comprehensive understanding of the DevOps workflow and the significance of each role in the software development process.

収穫

  • 👨‍💻 DevOps engineers work collaboratively with various roles in an organization.
  • 📊 Requirements are gathered through business analysts and product managers.
  • 📝 Jira is a popular tool for project management and task tracking.
  • 🔄 The software development lifecycle (SDLC) involves multiple stages and roles.
  • 📅 Sprints are used in Agile methodology to manage work in defined time frames.
  • 📋 Backlog refinement ensures that the most important tasks are prioritized.
  • 🔍 Understanding the roles in an organization helps in interviews and job performance.
  • 💡 Continuous integration and delivery (CI/CD) improve efficiency in development.
  • 📈 Product managers prioritize tasks based on business needs and customer feedback.
  • 📚 Learning tools like Jira can enhance your project management skills.

タイムライン

  • 00:00:00 - 00:05:00

    Abhishek introduces the video, focusing on the day-to-day tasks of a DevOps engineer and the importance of understanding organizational roles and the software development life cycle (SDLC). He emphasizes that DevOps engineers do not directly interact with customers but receive requirements through various roles within the organization.

  • 00:05:00 - 00:10:00

    The video uses Amazon Fresh as an example to explain the importance of customer feedback in gathering requirements. Business analysts play a crucial role in collecting these requirements and preparing Business Requirement Documents (BRD). Abhishek highlights the need for DevOps engineers to have a high-level understanding of this process.

  • 00:10:00 - 00:15:00

    Abhishek discusses the role of the product manager (PM) in prioritizing requirements based on input from business analysts. The product owner (PO) then breaks down these requirements into actionable items, known as epics, which are essential for the development process.

  • 00:15:00 - 00:20:00

    The video explains how the development team, led by a development lead, takes the requirements from the solutions architect and identifies the necessary infrastructure and resources needed for implementation, which is where DevOps engineers come into play.

  • 00:20:00 - 00:25:00

    Abhishek outlines the collaborative nature of the development process, where developers, QA engineers, and DevOps engineers work together to complete tasks. He emphasizes the importance of teamwork in achieving project goals and the role of site reliability engineers (SRE) in maintaining product reliability post-launch.

  • 00:25:00 - 00:30:00

    The video introduces the concept of technical writers who document features and processes, ensuring that information is accessible and clear for users. Abhishek summarizes the flow of requirements from customers to various roles within the organization, highlighting the complexity of the software development life cycle.

  • 00:30:00 - 00:35:00

    Abhishek provides a synopsis of the roles involved in the requirement gathering process, from customers to business analysts, product managers, product owners, and solutions architects, leading to the development team and ultimately the DevOps engineers.

  • 00:35:00 - 00:42:12

    The video transitions to project management tools, specifically Jira, explaining its significance in tracking project progress and managing tasks. Abhishek demonstrates how to create a Jira account and set up a project, emphasizing the importance of using such tools for effective communication and management in a DevOps environment.

もっと見る

マインドマップ

ビデオQ&A

  • What is the role of a DevOps engineer?

    A DevOps engineer is responsible for managing the infrastructure and deployment processes, ensuring smooth collaboration between development and operations teams.

  • How do DevOps engineers get their tasks?

    DevOps engineers receive tasks from developers or solutions architects based on the requirements defined by business analysts and product managers.

  • What is Jira used for?

    Jira is a project management tool used to track tasks, manage workflows, and facilitate communication among team members.

  • What are the key roles involved in the software development lifecycle?

    Key roles include business analysts, product managers, product owners, solutions architects, developers, QA engineers, and DevOps engineers.

  • What is the significance of the software development lifecycle (SDLC)?

    The SDLC outlines the stages of software development, helping teams manage requirements, design, implementation, testing, and maintenance.

  • How does a product manager prioritize tasks?

    A product manager prioritizes tasks based on business needs, customer feedback, and competitive analysis.

  • What is an epic in Jira?

    An epic in Jira is a large body of work that can be broken down into smaller tasks or stories.

  • What is a sprint in Agile methodology?

    A sprint is a set period during which specific work has to be completed and made ready for review.

  • What is the purpose of backlog refinement?

    Backlog refinement is the process of reviewing and prioritizing tasks in the backlog to ensure the team is working on the most important items.

  • How can I learn to use Jira effectively?

    Atlassian provides resources like 'Learn Jira in 5 minutes' to help users get acquainted with the tool.

ビデオをもっと見る

AIを活用したYouTubeの無料動画要約に即アクセス！
字幕
en
オートスクロール:
  • 00:00:00
    Hello everyone, my name is Abhishek and
  • 00:00:03
    welcome back to my channel. I'm sure
  • 00:00:06
    many of you must be learning DevOps at
  • 00:00:09
    this point of time. But have you ever
  • 00:00:11
    wondered if you join an organization as
  • 00:00:14
    a DevOps engineer, what would be your
  • 00:00:17
    day-to-day task or where would you get
  • 00:00:20
    the requirements from? In today's video,
  • 00:00:23
    I'm going to explain everything that is
  • 00:00:26
    required. So to explain this I will
  • 00:00:29
    cover multiple topics in today's video.
  • 00:00:31
    The first one is going to be what are
  • 00:00:34
    different roles in an
  • 00:00:37
    organization. Now this is very important
  • 00:00:39
    because as a DevOps engineer you do not
  • 00:00:43
    directly interact with the customers.
  • 00:00:46
    You do not talk to the clients. So you
  • 00:00:48
    don't directly get the requirements from
  • 00:00:50
    them. there are many other people within
  • 00:00:53
    the organization or there are many other
  • 00:00:56
    roles within the organization which get
  • 00:00:59
    the requirements for you and they try to
  • 00:01:02
    break down those requirements as your
  • 00:01:05
    task. So that's why we need to
  • 00:01:07
    understand what are different roles in
  • 00:01:09
    an organization and this will greatly
  • 00:01:12
    help you within your interviews as well.
  • 00:01:15
    Now once we understand this I will also
  • 00:01:18
    provide a very quick synopsis of what
  • 00:01:21
    exactly each and every role does and
  • 00:01:24
    then we will focus a bit on software
  • 00:01:26
    development life cycle because software
  • 00:01:30
    development life cycle is very important
  • 00:01:32
    for anything that you do in IT. Of
  • 00:01:34
    course, I did a detailed video on SDLC
  • 00:01:37
    before, but still it is relevant for
  • 00:01:40
    today's video and I will make it
  • 00:01:42
    extremely simple and tell you how a
  • 00:01:45
    DevOps engineer fits in
  • 00:01:47
    SDLC. Finally, we will also explore a
  • 00:01:51
    very popular project management tool
  • 00:01:54
    that is Jira. Now, why do we need this?
  • 00:01:57
    We need this because end of the day the
  • 00:02:00
    entire project management is done in
  • 00:02:03
    software systems like Jira. There are
  • 00:02:05
    alternatives as well but Jira is very
  • 00:02:08
    popular. So we will try to understand
  • 00:02:11
    how to create an account with Jira so
  • 00:02:13
    that you can also use Jira. Then I will
  • 00:02:16
    explain you how the requirements are put
  • 00:02:19
    in Jira by other roles and how you get
  • 00:02:23
    the day-to-day task and how you can see
  • 00:02:25
    the day-to-day tasks. how you can update
  • 00:02:28
    your day-to-day task progress to your
  • 00:02:30
    project manager or maybe to other peers
  • 00:02:33
    in your organization and we will see
  • 00:02:35
    completion status, updation status,
  • 00:02:38
    everything that you do within your
  • 00:02:41
    organization. So by watching this video
  • 00:02:43
    you will get a feel of how a DevOps
  • 00:02:45
    engineer works in an organization. So
  • 00:02:48
    just make sure you watch it till the
  • 00:02:51
    end.
  • 00:02:53
    Perfect. So let's start with taking a
  • 00:02:57
    example
  • 00:02:59
    organization. So I mean we will just
  • 00:03:01
    assume that you got placed as a DevOps
  • 00:03:05
    engineer within
  • 00:03:07
    Amazon. Now
  • 00:03:09
    whenever I say that you got placed as
  • 00:03:12
    DevOps engineer within an organization,
  • 00:03:14
    one thing to understand within an
  • 00:03:17
    organization there are multiple
  • 00:03:18
    projects. Although your offer letter
  • 00:03:21
    might be from Amazon but within Amazon
  • 00:03:25
    they have Amazon Fresh right they have
  • 00:03:29
    Amazon Prime so these are different
  • 00:03:32
    projects or verticals within Amazon
  • 00:03:34
    right they also have Amazon e-commerce
  • 00:03:38
    Amazon home
  • 00:03:40
    services so you got placed with Amazon
  • 00:03:43
    but you might end up working in one of
  • 00:03:46
    the projects let's assume you got
  • 00:03:49
    opportunity Unity to work with Amazon
  • 00:03:52
    fresh and let's assume there are
  • 00:03:54
    multiple other DevOps engineers and you
  • 00:03:57
    will be one of the DevOps engineers
  • 00:03:59
    working with Amazon fresh by making this
  • 00:04:02
    assumption let's try to understand what
  • 00:04:05
    are the different roles and we will also
  • 00:04:07
    understand software development life
  • 00:04:09
    cycle so for today's video this is the
  • 00:04:12
    assumption that we are going to make
  • 00:04:15
    perfect now let's try to understand what
  • 00:04:18
    can be different roles
  • 00:04:19
    within Amazon fresh right of course the
  • 00:04:23
    same roles will be across different
  • 00:04:26
    projects of the company but we will take
  • 00:04:28
    one example to understand the
  • 00:04:33
    requirements. So we will start with top
  • 00:04:36
    to bottom for any business what is the
  • 00:04:39
    most important thing the most important
  • 00:04:42
    thing for any business is the
  • 00:04:45
    customers. Imagine Amazon Fresh does not
  • 00:04:48
    have any customer. Instantly you will
  • 00:04:50
    see Amazon with an announcement saying
  • 00:04:52
    we don't have customers using Amazon
  • 00:04:55
    Fresh. So we are going to discontinue
  • 00:04:57
    this product or we are going to
  • 00:04:58
    discontinue this application. Right? So
  • 00:05:01
    it is always important for any business
  • 00:05:05
    to gather the feedback from the
  • 00:05:07
    customers. It can be good feedback, it
  • 00:05:10
    can be bad feedback. And most of the
  • 00:05:12
    times customers are the ones from where
  • 00:05:16
    businesses get the requirements. Right?
  • 00:05:19
    Of course business also drives
  • 00:05:22
    requirements by looking at competitors
  • 00:05:24
    by understanding the market but most of
  • 00:05:27
    the times businesses get the
  • 00:05:29
    requirements from customers. Let's say
  • 00:05:32
    one of the customers of Amazon Fresh,
  • 00:05:34
    which can be a company or it can be a
  • 00:05:38
    group of people, they have shared a
  • 00:05:39
    feedback that it would be great if
  • 00:05:43
    Amazon Fresh can deliver groceries
  • 00:05:47
    within 15 minutes across all the zip
  • 00:05:50
    codes or across all the pin codes. And
  • 00:05:54
    you know it is really a great idea
  • 00:05:57
    because if Amazon Fresh can do it
  • 00:05:59
    probably it can beat all the other
  • 00:06:01
    competitors and it can reach wide range
  • 00:06:04
    of audience. But whom will the customer
  • 00:06:07
    share this feedback to? There should be
  • 00:06:10
    someone within the business or there
  • 00:06:12
    should be someone within the software
  • 00:06:14
    engineering as well. So there is someone
  • 00:06:17
    called as business analyst.
  • 00:06:21
    So business analysts are not completely
  • 00:06:24
    at the software engineering side. They
  • 00:06:26
    also interact with Amazon fresh business
  • 00:06:30
    that is basically the marketing people,
  • 00:06:32
    sales people and they also interact with
  • 00:06:35
    the customers. So business analyst is
  • 00:06:37
    the one who interacts with customers and
  • 00:06:40
    gets the
  • 00:06:42
    requirements. So one of these
  • 00:06:44
    requirement business analyst really
  • 00:06:45
    liked it. So what business analysts do?
  • 00:06:48
    They prepare something called as a BRD
  • 00:06:52
    document. Abishek, do I need to know all
  • 00:06:54
    this as a DevOps
  • 00:06:56
    engineer? You know, if you're working in
  • 00:06:58
    an organization, you should definitely
  • 00:07:00
    understand at a high level. You don't
  • 00:07:02
    need to understand how business analyst
  • 00:07:05
    writes this BR document. You don't need
  • 00:07:07
    to understand how business analyst set
  • 00:07:09
    up calls with these customers. But at
  • 00:07:12
    least you need to know how the entire
  • 00:07:14
    software development life cycle
  • 00:07:17
    works. Okay. So assume this is one cool
  • 00:07:20
    idea 15 minutes grocery delivery
  • 00:07:22
    service. Business unlist prepared a BRD.
  • 00:07:26
    Similarly business unlist prepared BRD
  • 00:07:29
    for another requirement from the
  • 00:07:32
    customer. Let's say another requirement
  • 00:07:34
    is that you know Amazon
  • 00:07:38
    fresh payment gateway. So, one of the
  • 00:07:41
    customers said, "How about adding UPI as
  • 00:07:44
    a payment gateway or maybe how about
  • 00:07:47
    adding Stripe as a payment gateway?"
  • 00:07:51
    Right? Again, business analyst said,
  • 00:07:53
    "Okay, it can be a great idea. Uh,
  • 00:07:55
    probably competitors are not supporting
  • 00:07:57
    it, so we can give it a try." And
  • 00:07:59
    business analyst prepares BR document
  • 00:08:01
    for that as well. Now, who is going to
  • 00:08:04
    prioritize these documents or who is
  • 00:08:07
    going to prioritize these items? So
  • 00:08:09
    there is a designated role in the
  • 00:08:11
    organization which is product
  • 00:08:15
    manager. So what does a product manager
  • 00:08:17
    do? Product manager interacts with the
  • 00:08:20
    business analyst gets all the
  • 00:08:22
    requirements from the business analyst
  • 00:08:24
    but prioritizes them according to the
  • 00:08:28
    product and also sometimes according to
  • 00:08:31
    the skill within the organization or you
  • 00:08:34
    know the capability of the organization.
  • 00:08:36
    Anyways, PM prioritizes the requirement.
  • 00:08:40
    Probably PM says that okay um you know I
  • 00:08:44
    really like this BD for 15 minutes
  • 00:08:48
    grocery delivery service. So I will ask
  • 00:08:51
    the team to complete this in Jan Feb or
  • 00:08:54
    maybe
  • 00:08:56
    Q1. Now PM is not completely technical.
  • 00:09:00
    So PM can prioritize the items but end
  • 00:09:03
    of the day this should be implemented by
  • 00:09:06
    the developers right. Of course PM do
  • 00:09:10
    not directly interact with the
  • 00:09:11
    developers but PM interacts with product
  • 00:09:16
    owner which is also called PO. So what
  • 00:09:20
    does a product owner do? So product
  • 00:09:22
    owner deeps dive little bit more
  • 00:09:25
    technical and takes this requirement
  • 00:09:28
    that 15 minutes grocery delivery service
  • 00:09:31
    and breaks them down into actionable
  • 00:09:35
    items and these actionable items are
  • 00:09:38
    usually called as epics.
  • 00:09:41
    Some people also call it as features and
  • 00:09:43
    further they break down into epics. But
  • 00:09:45
    for the purpose of
  • 00:09:47
    simplicity understand product owner
  • 00:09:50
    takes the requirement from PM and breaks
  • 00:09:53
    that down into the actionable item. What
  • 00:09:56
    is an actionable item? Actionable item
  • 00:09:59
    is nothing but says that okay probably a
  • 00:10:03
    UI is required for it. Probably a
  • 00:10:05
    particular backend implementation is
  • 00:10:08
    required for it. probably you know a
  • 00:10:10
    particular DB setup is important for it
  • 00:10:13
    and once all of these things are done
  • 00:10:16
    now only then I will mark this
  • 00:10:19
    particular requirement as
  • 00:10:21
    done. So for each of this actionable
  • 00:10:25
    item is usually called as epic. So
  • 00:10:28
    product owner takes the requirement from
  • 00:10:30
    PM and breaks that down into actionable
  • 00:10:33
    items which are usually called as epics.
  • 00:10:38
    Okay.
  • 00:10:40
    Then product owner directly interacts
  • 00:10:43
    with solution architects. Most of the
  • 00:10:46
    times product owner do not directly
  • 00:10:48
    interact with the developers. Of course
  • 00:10:50
    PO is accessible but major interaction
  • 00:10:53
    of PO is with solutions architect or
  • 00:10:56
    software architect because software
  • 00:10:59
    architect really deeps dive into
  • 00:11:01
    technical part of this requirement. All
  • 00:11:04
    that PO says is okay this might be
  • 00:11:06
    required this might be required this
  • 00:11:08
    might be required and for that these are
  • 00:11:10
    the actionable items but PO interacts
  • 00:11:14
    with solutions architect to confirm that
  • 00:11:17
    and also solutions architect defines a
  • 00:11:21
    LLD or HLD for it low-level design and
  • 00:11:25
    highle design implementation for the
  • 00:11:29
    requirement and also a lot of times you
  • 00:11:32
    know PM might commit this particular
  • 00:11:34
    thing talks to PO that hey I'm thinking
  • 00:11:37
    of getting this done in January and
  • 00:11:41
    February PO interacts with solutions
  • 00:11:45
    architect and solution architects might
  • 00:11:47
    come back and say right now we don't
  • 00:11:49
    have skill for it or you know for the
  • 00:11:51
    payment gateway let's say we don't have
  • 00:11:53
    person who can do it we don't have the
  • 00:11:55
    expertise then this communication goes
  • 00:11:58
    back to PM and PM might also dep
  • 00:12:00
    prioritize the item Overall just
  • 00:12:03
    remember there are four parties,
  • 00:12:06
    business
  • 00:12:08
    analyst, product manager, product owner,
  • 00:12:12
    solutions architect where PA, PM and PO
  • 00:12:16
    are not very technical but solutions
  • 00:12:19
    architect is the technical person. What
  • 00:12:22
    does business analyst, product manager,
  • 00:12:24
    product owner do? So they help in taking
  • 00:12:28
    the requirements, fine-tuning the
  • 00:12:30
    requirements and breaking down that
  • 00:12:32
    requirements into actionable items. Then
  • 00:12:36
    it comes to the software architect or
  • 00:12:38
    solutions architect to prepare a
  • 00:12:41
    low-level design and highle design
  • 00:12:42
    implementation for the developers. And
  • 00:12:45
    this is where the actual game starts if
  • 00:12:47
    you are a DevOps
  • 00:12:49
    engineer. Now who will take this
  • 00:12:51
    requirement?
  • 00:12:53
    So this requirement is taken care by the
  • 00:12:56
    development teams. So let's say there is
  • 00:12:58
    a development lead. No just for example
  • 00:13:01
    there is a development lead got this
  • 00:13:03
    requirement from solutions architect got
  • 00:13:06
    the low-level design got the highle
  • 00:13:08
    design.
  • 00:13:10
    Now the development team says that okay
  • 00:13:13
    you know to complete this entire thing
  • 00:13:15
    we might need some
  • 00:13:17
    infra we might need a Kubernetes cluster
  • 00:13:21
    we might need you know strong expertise
  • 00:13:24
    with docker so somebody who can write
  • 00:13:26
    docker files for us we need couple of
  • 00:13:29
    git
  • 00:13:30
    repositories all of these operations
  • 00:13:34
    right developer looks at the requirement
  • 00:13:36
    or multiple developers look at the
  • 00:13:39
    requirement ment in our case 15 minutes
  • 00:13:41
    grocery delivery service or maybe a new
  • 00:13:44
    payment gateway implementation and these
  • 00:13:48
    developers says we need these operations
  • 00:13:51
    or we need infrastructure kubernetes
  • 00:13:54
    cluster docker file help git repository
  • 00:13:56
    only then we can complete this task and
  • 00:13:58
    these are performed by devops engineers.
  • 00:14:03
    So see how interesting it is. DevOps
  • 00:14:06
    engineers do not directly get the
  • 00:14:08
    requirement but requirement comes from
  • 00:14:11
    various levels. Finally it reaches the
  • 00:14:14
    developers and from developers DevOps
  • 00:14:17
    engineers get the requirement or maybe
  • 00:14:19
    solution architect as well. Right? It's
  • 00:14:22
    in the same way that you know while
  • 00:14:24
    developers are performing this uh task
  • 00:14:26
    or while developer is working on
  • 00:14:29
    developing this feature, QA
  • 00:14:32
    engineers work on testing the task or
  • 00:14:35
    testing the requirement. Similarly, a
  • 00:14:38
    database administrator might set up a
  • 00:14:41
    database and administer the database or
  • 00:14:43
    database is set up by DevOps engineers.
  • 00:14:46
    Administration is taken care by the DBS.
  • 00:14:50
    Now everything is done. The product is
  • 00:14:52
    also live. U all the epics that are
  • 00:14:56
    created by PO or all the actionable
  • 00:14:58
    items that are created by PO are
  • 00:15:00
    completed by developers with the help of
  • 00:15:02
    QE and DevOps engineers. Usually they
  • 00:15:06
    are one
  • 00:15:08
    team. So within a company there are
  • 00:15:11
    usually teams right? So you say that I
  • 00:15:13
    work for X team, I work for Y team. What
  • 00:15:15
    does that team mean? So usually PAS,
  • 00:15:19
    PMs, POS and solution architects they
  • 00:15:22
    are also part of the team but they are
  • 00:15:25
    passive part of the team. They might
  • 00:15:27
    work with multiple other teams as well.
  • 00:15:30
    Right? But one of the development teams
  • 00:15:33
    or one of the scrum teams when we get
  • 00:15:37
    more into Jira you will understand this
  • 00:15:39
    but assume this term understands this
  • 00:15:42
    term called scrum where within a scrum
  • 00:15:44
    team you usually have developers, devops
  • 00:15:48
    engineers, QE engineers, database
  • 00:15:52
    administrator all of them together work
  • 00:15:55
    to complete the
  • 00:15:58
    requirement because as As a DevOps
  • 00:16:01
    engineer, you cannot complete the
  • 00:16:02
    require s complete the requirement on
  • 00:16:04
    your own or as a developer you cannot
  • 00:16:07
    complete the requirement on your own.
  • 00:16:09
    All of these parties have to work
  • 00:16:11
    together only then the requirement is
  • 00:16:13
    done. Perfect. Now once this entire
  • 00:16:17
    thing is done, once the product is live,
  • 00:16:19
    then SR engineers come into picture
  • 00:16:22
    because S sur engineers are usually
  • 00:16:25
    responsible for checking the reliability
  • 00:16:28
    of the feature, availability of the
  • 00:16:30
    feature. They might create some
  • 00:16:32
    dashboards, they create some metrics and
  • 00:16:34
    if something goes wrong, they create
  • 00:16:36
    notifiers to notify the development team
  • 00:16:38
    or the required party. Right? So this is
  • 00:16:42
    how all the teams within an organization
  • 00:16:46
    or all the different roles within a
  • 00:16:48
    organization work to complete the
  • 00:16:51
    requirement. Abishek there is also
  • 00:16:54
    something called technical writer. So
  • 00:16:56
    technical writers are
  • 00:16:58
    usually people who document this entire
  • 00:17:01
    thing. I'll give you a basic
  • 00:17:04
    example. Take example of
  • 00:17:06
    Kubernetes. Imagine Kubernetes came up
  • 00:17:09
    with a new feature, right? Or imagine
  • 00:17:12
    Android came up with a new
  • 00:17:14
    feature and what if Android do not
  • 00:17:18
    document the information right so today
  • 00:17:21
    if you go to a latest version of Android
  • 00:17:23
    you know what are the things that you
  • 00:17:25
    get in the latest version so these
  • 00:17:28
    things are documented by the technical
  • 00:17:29
    writers what if Android does not do not
  • 00:17:32
    document that
  • 00:17:33
    information you will never know what is
  • 00:17:36
    that feature how that feature works if
  • 00:17:38
    you add that feature to your mobile or
  • 00:17:40
    if to enable that feature? No. Is it
  • 00:17:43
    going to help you in any way or you can
  • 00:17:46
    completely ignore that feature? So
  • 00:17:48
    technical writers are the ones who take
  • 00:17:50
    care of writing or documenting this
  • 00:17:53
    particular thing. Again, they are also
  • 00:17:55
    part of a development team or sometimes
  • 00:17:58
    they are outside the team because they
  • 00:18:00
    work for various scrum teams at
  • 00:18:02
    once. Clear? So this is
  • 00:18:06
    how the entire requirement flow looks
  • 00:18:09
    like.
  • 00:18:10
    I have also you know tried to make it
  • 00:18:13
    easy for you. So I have provided
  • 00:18:16
    oneliner synopsis. I'll try to put this
  • 00:18:19
    in the description but you can also take
  • 00:18:21
    a screenshot at this point of time if
  • 00:18:23
    you're
  • 00:18:24
    interested. So just as a synopsis you
  • 00:18:27
    know I'll quickly repeat this entire
  • 00:18:29
    thing. Of course I'm not going to
  • 00:18:31
    explain everything in detail but just a
  • 00:18:34
    very quick synopsis.
  • 00:18:36
    You have
  • 00:18:38
    customers from
  • 00:18:41
    customers. Business analysts are the one
  • 00:18:43
    who are going to get the requirements.
  • 00:18:45
    Or to put it in a better way, business
  • 00:18:47
    analysts interact with the customers and
  • 00:18:50
    they get the requirements. What do they
  • 00:18:53
    do once they get the requirements? They
  • 00:18:55
    are going to create something called as
  • 00:18:56
    BRD
  • 00:18:59
    document. Now it comes to product
  • 00:19:02
    managers.
  • 00:19:04
    So product managers define the vision
  • 00:19:07
    and they define the priority of the
  • 00:19:09
    items. So PM might say out of payment
  • 00:19:13
    gateway
  • 00:19:14
    requirement and 15 minutes Amazon fresh
  • 00:19:19
    grocery delivery requirement I believe
  • 00:19:22
    because PM has more idea of the product
  • 00:19:25
    and PM also usually looks at various
  • 00:19:28
    other products how they are doing. If
  • 00:19:30
    let's say there is a company called XY Z
  • 00:19:33
    is competitor of Amazon fresh. So PM
  • 00:19:36
    also looks at XY Z tries to understand
  • 00:19:39
    okay where are they what are they
  • 00:19:40
    implementing can we you know kind of
  • 00:19:44
    steal a feature from them. So PM says
  • 00:19:46
    out of the payment gateway and 15
  • 00:19:48
    minutes uh delivery service quick
  • 00:19:51
    delivery service I really like it. So PM
  • 00:19:54
    says okay we will go with it in Q1 that
  • 00:19:58
    is in Jan, February and March and PM
  • 00:20:00
    communicates this information to product
  • 00:20:03
    owner. Product owner tries to go more in
  • 00:20:06
    depth of it from product point of view
  • 00:20:08
    right from product side and PO says
  • 00:20:12
    okay these are the things that we need
  • 00:20:14
    to
  • 00:20:15
    complete to achieve this or to mark this
  • 00:20:18
    as done. Same is available here as well.
  • 00:20:20
    Product owner manages the backlog,
  • 00:20:23
    converts vision into actionable items or
  • 00:20:26
    actionable
  • 00:20:27
    stories. Great. And then the requirement
  • 00:20:31
    goes to solutions architect, software
  • 00:20:33
    architect, design technical system
  • 00:20:36
    structure and frameworks that is HLD and
  • 00:20:39
    LLD. Then there is a team there is a
  • 00:20:42
    whole team which is working together to
  • 00:20:45
    complete this task.
  • 00:20:47
    This particular team is usually called
  • 00:20:48
    as a scrum team. So what does this scrum
  • 00:20:51
    team do? It is part of
  • 00:20:54
    developers, devops
  • 00:20:56
    engineers, QA engineers, database
  • 00:20:59
    administrator, if required a technical
  • 00:21:02
    writer. All of them together are going
  • 00:21:04
    to decide how the requirement can be
  • 00:21:07
    completed. But majorly this is driven by
  • 00:21:10
    a development team or a group of
  • 00:21:12
    developers because once group of
  • 00:21:15
    developers analyze that okay I need to
  • 00:21:17
    complete these tasks for that I need a
  • 00:21:20
    particular framework I need a particular
  • 00:21:22
    database I
  • 00:21:23
    need few resources on AWS I need some
  • 00:21:27
    infrastructure for it from there
  • 00:21:29
    development team is going to get the
  • 00:21:30
    requirements or they are going to get
  • 00:21:32
    the day-to-day task from there QA
  • 00:21:34
    engineers are going to get the
  • 00:21:35
    day-to-day task right similarly
  • 00:21:38
    technical writers are also going to get
  • 00:21:40
    the day-to-day tasks. Now I hope it is
  • 00:21:43
    clear and if you understand this
  • 00:21:46
    software development life cycle is a
  • 00:21:48
    piece of cake right because what we
  • 00:21:52
    learned here is basically software
  • 00:21:54
    development life cycle but we went
  • 00:21:57
    detail into it instead of discussing at
  • 00:22:00
    a high level that there is a planning
  • 00:22:02
    stage there is analysis stage there is
  • 00:22:05
    design
  • 00:22:06
    implementation we further went deep into
  • 00:22:09
    it to understand what exactly happens in
  • 00:22:12
    each of the stage. So that's why when
  • 00:22:14
    you see this diagram you know it it
  • 00:22:16
    looks very simple but in real time
  • 00:22:19
    software development life cycle is very
  • 00:22:21
    very complex. There are so many parties
  • 00:22:24
    that is there are so many roles from
  • 00:22:26
    each role the requirement comes to the
  • 00:22:28
    other role and you know a simple
  • 00:22:31
    requirement from the customer takes
  • 00:22:32
    months together because of all of these
  • 00:22:35
    parties. I mean in a positive way from
  • 00:22:38
    the customer the requirement looks very
  • 00:22:41
    simple but
  • 00:22:42
    as each and every role gets technical
  • 00:22:46
    into it the requirement becomes very
  • 00:22:48
    complex and multiple engineers in the
  • 00:22:52
    company are needed to work on it.
  • 00:22:55
    Okay. So in a nutshell software
  • 00:22:58
    development life cycle has these phases.
  • 00:23:00
    The first phase is the planning phase
  • 00:23:03
    where requirements are taken. Then there
  • 00:23:06
    is analysis phase where the requirements
  • 00:23:10
    are analyzed. Is it possible to complete
  • 00:23:12
    this requirement? Is it a good
  • 00:23:14
    requirement? Is it important for the
  • 00:23:16
    organization or can we do it later? Then
  • 00:23:19
    the design phase solutions architect
  • 00:23:21
    takes care of HLD LLD.
  • 00:23:24
    Implementation, developers, DevOps
  • 00:23:26
    engineers, Q engineers, everybody are
  • 00:23:29
    going to work in the implementation
  • 00:23:31
    phase, testing and integration, finally
  • 00:23:35
    maintenance, which is taken care by SR
  • 00:23:37
    engineers mostly. Now, Abishek, is this
  • 00:23:40
    the only thing that DevOps engineers do?
  • 00:23:45
    Right? Will DevOps engineers only take
  • 00:23:47
    the requirements from developers and you
  • 00:23:50
    know create the required things for the
  • 00:23:51
    developers? No. Now that is where I have
  • 00:23:55
    this slide as well for today's video. On
  • 00:23:58
    top of that, what DevOps engineers also
  • 00:24:00
    do, they try to identify the gaps in
  • 00:24:04
    software development life cycle or they
  • 00:24:07
    try to see where the software
  • 00:24:09
    development life cycle if this entire
  • 00:24:11
    thing that we discussed if it is going
  • 00:24:14
    to take 3 months from Jan to March. A
  • 00:24:18
    DevOps engineer tries to understand how
  • 00:24:21
    this can be completed in 2 months.
  • 00:24:23
    Right? Of course at this level DevOps
  • 00:24:26
    engineer cannot do a lot of things when
  • 00:24:28
    it comes to BAS uh PM PO but from this
  • 00:24:33
    phase where the
  • 00:24:35
    requirement comes into the development
  • 00:24:38
    team or the scrum team DevOps engineer
  • 00:24:40
    tries to identify how this can be
  • 00:24:42
    completed fast. For example, QE is
  • 00:24:46
    working manually on testing the dev task
  • 00:24:49
    or they have written some automation
  • 00:24:51
    scripts. Now, DevOps engineer can put
  • 00:24:54
    that in a CI/CD pipeline. If you don't
  • 00:24:56
    know what is CI/CD, that's okay. You can
  • 00:24:59
    watch the videos on the channel where
  • 00:25:01
    I've clearly explained. But DevOps
  • 00:25:03
    engineer tries to create an automation
  • 00:25:05
    to unify the efforts of dev plus QE.
  • 00:25:11
    Right? So that whenever developer makes
  • 00:25:13
    a change the tests written by QE are
  • 00:25:16
    automatically executed. This is run as
  • 00:25:19
    part of a pipeline which is usually
  • 00:25:21
    called as CI/CD. Also developer tries to
  • 00:25:24
    uh sorry DevOps engineer tries to look
  • 00:25:26
    at the security integrate security into
  • 00:25:28
    the
  • 00:25:29
    pipeline. All of this is apart from
  • 00:25:33
    working on the requirements from the
  • 00:25:34
    developers.
  • 00:25:36
    Developers requirement can be
  • 00:25:37
    infrastructure creation, Kubernetes
  • 00:25:39
    cluster creation, but this is outside to
  • 00:25:42
    improve the efficiency of the
  • 00:25:43
    organization or to improve the
  • 00:25:45
    efficiency of the software development
  • 00:25:47
    life
  • 00:25:48
    cycle.
  • 00:25:50
    Perfect. Now that this is clear, let's
  • 00:25:53
    proceed with project
  • 00:25:56
    management. Where are we going to
  • 00:25:58
    perform all of these activities? There
  • 00:26:01
    should be a platform, right? So we have
  • 00:26:03
    been talking that okay PM talks to PO,
  • 00:26:05
    PO talks to SA, SA talks to developers.
  • 00:26:09
    But how can management track Amazon as a
  • 00:26:12
    company or Amazon fresh as a uh project?
  • 00:26:16
    If somebody wants to understand what is
  • 00:26:19
    the status of a particular thing, how
  • 00:26:21
    would someone know that a DevOps
  • 00:26:23
    engineer somewhere in this entire ladder
  • 00:26:26
    is working on creating a Kubernetes
  • 00:26:29
    cluster or how would someone know that
  • 00:26:32
    QA engineer is working on a particular
  • 00:26:33
    thing and if this Kubernetes cluster
  • 00:26:36
    creation is blocked for some reason
  • 00:26:38
    because of budget issue or because of
  • 00:26:40
    you know the VPC issues or because of
  • 00:26:42
    lack of expertise if this particular
  • 00:26:45
    thing is blocked
  • 00:26:46
    developers are blocked. If developers
  • 00:26:49
    are blocked, the requirement is blocked.
  • 00:26:51
    Then PA has to tell that to BA. PA B PA
  • 00:26:54
    has to tell that to the customers.
  • 00:26:56
    Overall, everyone is interconnected,
  • 00:26:58
    right? All of them are interconnected. A
  • 00:27:01
    simple Kubernetes cluster creation which
  • 00:27:04
    is blocked for some reason. DevOps
  • 00:27:06
    engineer is working on it for last 3
  • 00:27:08
    weeks. Now this will impact the entire
  • 00:27:11
    organization and this has to be notified
  • 00:27:14
    across multiple layers stakeholders and
  • 00:27:17
    finally to the customer. So there has to
  • 00:27:19
    be a platform where the work is
  • 00:27:21
    completely
  • 00:27:22
    visible for the management. They need to
  • 00:27:25
    know who is accountable for something.
  • 00:27:28
    Where is somebody blogged? Where is
  • 00:27:30
    someone working very fast so that they
  • 00:27:32
    can appreciate they can take the
  • 00:27:33
    feedback and that is where Jira as a
  • 00:27:37
    project management tool
  • 00:27:39
    evolved. Of course there are other tools
  • 00:27:42
    you know just like Jira there are other
  • 00:27:44
    softwares as well but Jira is a very
  • 00:27:48
    popular one and it's used in most of the
  • 00:27:51
    organizations. We will see how to create
  • 00:27:53
    a free account with Jira. They support a
  • 00:27:56
    cloud offering where you can create a
  • 00:27:58
    free account and you can also practice
  • 00:28:01
    later once watching this video. So we
  • 00:28:04
    will create a free account with Jira.
  • 00:28:06
    Then I will try to create organization
  • 00:28:09
    in Jira something like Amazon. Then I'll
  • 00:28:12
    create a project in Jira something like
  • 00:28:15
    Amazon
  • 00:28:17
    fresh
  • 00:28:20
    and as a PO you know just I'll try to
  • 00:28:24
    create an
  • 00:28:27
    epic right then I'll create some stories
  • 00:28:31
    then I'll show you how DevOps engineers
  • 00:28:34
    are assigned with these stories right so
  • 00:28:38
    we will see all of this on the Jira
  • 00:28:40
    platform
  • 00:28:41
    Again, it's going to be interesting. I
  • 00:28:44
    really recommend you to go ahead and try
  • 00:28:46
    it. This will help you during your
  • 00:28:48
    interviews. This experience on working
  • 00:28:50
    with Jira, understanding this entire
  • 00:28:52
    thing, you can communicate better during
  • 00:28:54
    your interviews. It will also make you
  • 00:28:56
    more confident, right? So, let's head to
  • 00:28:59
    the Jira part now. So, just take a new
  • 00:29:02
    tab and search for Jira cloud login. And
  • 00:29:06
    you just need to create an account with
  • 00:29:08
    Atlashian. So once you just click on
  • 00:29:11
    this it will ask you to sign up using
  • 00:29:13
    your Google account. So just provide
  • 00:29:16
    your Google account and you have an
  • 00:29:18
    account created with Atlashian. So you
  • 00:29:21
    can access all the Atlashian services
  • 00:29:23
    such as Jira Conflence. I'll go with
  • 00:29:26
    Jira. Now it's very simple. The same
  • 00:29:30
    account with which you created Atlashian
  • 00:29:32
    account. So you can use it as your work
  • 00:29:35
    email. Although it says work email, you
  • 00:29:37
    can uh still go ahead and use your
  • 00:29:39
    Google account. So perfect. I use my
  • 00:29:42
    Google account and uh I will call this
  • 00:29:44
    site name as Amazon
  • 00:29:49
    demo
  • 00:29:51
    Vala. Okay. So I'll just call this as I
  • 00:29:55
    cannot use Amazon because obviously it
  • 00:29:57
    might have been used. So Amazon demo
  • 00:30:00
    vala is name of my
  • 00:30:03
    organization to be honest in real time
  • 00:30:06
    you won't be creating this because you
  • 00:30:08
    know
  • 00:30:09
    Jira licensing and creating a Jira
  • 00:30:12
    account is taken care by your management
  • 00:30:15
    but anyways uh for our demo purpose we
  • 00:30:18
    need this account so you can select any
  • 00:30:21
    of these options and click on the
  • 00:30:22
    continue button. So right now what we
  • 00:30:25
    have done we have just set up a zero
  • 00:30:28
    organization. Now it's time to set up
  • 00:30:30
    our project in the organization. So I'll
  • 00:30:33
    choose Amazon
  • 00:30:38
    fresh. Perfect. Click on next. And
  • 00:30:41
    within few minutes you will have your
  • 00:30:44
    Jira organization as well as your Jira
  • 00:30:47
    board
  • 00:30:48
    setup. Now what do we do in this right?
  • 00:30:51
    Okay. Now that we have created this
  • 00:30:54
    account as well as project. So we will
  • 00:30:56
    start with our usual
  • 00:30:58
    workflow. So what I explained you during
  • 00:31:00
    the theory part. So product owner is
  • 00:31:04
    going to create epic for us and within
  • 00:31:07
    the
  • 00:31:09
    epic or developers are going to take
  • 00:31:11
    this epic and they are going to break
  • 00:31:13
    this down into stories. Okay. So let's
  • 00:31:16
    see how is it done. So first of all
  • 00:31:19
    product owner comes to this board clicks
  • 00:31:22
    on the create
  • 00:31:23
    button. Let me just maximize it. And in
  • 00:31:27
    the work type product owners usually
  • 00:31:29
    create epics. So what is the epic? 15
  • 00:31:35
    minutes delivery
  • 00:31:37
    service. Right? Of course that can be
  • 00:31:40
    elaborated but 15 minutes delivery
  • 00:31:42
    service is the epic. In this product
  • 00:31:45
    owner defines the epic. As I told you,
  • 00:31:48
    product owner writes the acceptance
  • 00:31:50
    criteria or definition of done. In a
  • 00:31:53
    nutshell, defines the
  • 00:31:56
    epic. For example, to mark this epic as
  • 00:32:02
    done, following
  • 00:32:04
    things needs to be
  • 00:32:08
    completed. Right? For
  • 00:32:12
    example, one of the items that needs to
  • 00:32:15
    be complete is maybe add
  • 00:32:19
    feature in
  • 00:32:21
    the mobile app with a good
  • 00:32:27
    interactive UI.
  • 00:32:31
    Another thing can
  • 00:32:33
    be
  • 00:32:36
    provide an option to the customer to
  • 00:32:44
    disable 15minut service anytime. You
  • 00:32:49
    know this can be uh because that 15
  • 00:32:51
    minutes delivery service might not be
  • 00:32:53
    available in the uh customer's uh zip
  • 00:32:57
    code area or maybe it is costing more
  • 00:32:59
    for the customer. So they should have an
  • 00:33:01
    option to disable it. Similarly enable
  • 00:33:06
    15 minutes service in the desktop
  • 00:33:09
    application. So product owner will
  • 00:33:12
    define such uh things and once these
  • 00:33:14
    things are completed by the development
  • 00:33:16
    team or completed by the scrum team then
  • 00:33:19
    this epic can be marked as done. Till
  • 00:33:22
    then it will be in the todo then it will
  • 00:33:24
    be in progress in review finally the
  • 00:33:27
    done state again. Why are we doing this?
  • 00:33:31
    Why are we creating this Jira epic?
  • 00:33:33
    Because management can use it as a point
  • 00:33:36
    of tracking the work. Somebody at the
  • 00:33:40
    high level in the management maybe your
  • 00:33:42
    VP or maybe uh the director how will
  • 00:33:45
    they know what is the current status of
  • 00:33:47
    the epic they can simply come to the
  • 00:33:49
    Jira board they can look at this epic
  • 00:33:52
    and they can track the current status of
  • 00:33:54
    this epic so you need to change it from
  • 00:33:57
    in progress in review to done when I say
  • 00:33:59
    you it should be the person working on
  • 00:34:01
    this
  • 00:34:02
    epic now how will as a devops engineer
  • 00:34:06
    you get the work now this is important
  • 00:34:08
    Right. So what happens in the scrum
  • 00:34:12
    method? So I told
  • 00:34:14
    you we follow something called scrum. So
  • 00:34:18
    scrum is a methodology in
  • 00:34:20
    agile. Right? Within agile a framework
  • 00:34:24
    called scrum is followed
  • 00:34:26
    where teams work in sprints. Now I'll
  • 00:34:31
    explain this in a very simple way. So
  • 00:34:33
    scrum is basically referred to as a
  • 00:34:36
    scrum team or it's a framework in
  • 00:34:39
    general and within this sprints are
  • 00:34:42
    followed. What is sprints? Sprints are
  • 00:34:44
    nothing but two weeks or 3 weeks work
  • 00:34:49
    tracked as part of sprint. For example,
  • 00:34:53
    as part of your Amazon Fresh project
  • 00:34:55
    team, you know, every two weeks or every
  • 00:34:58
    3 weeks, you define we are going to
  • 00:35:01
    complete these
  • 00:35:02
    activities. Okay? And by the end of this
  • 00:35:06
    3 weeks, you will conduct a sprint
  • 00:35:10
    retrospective meeting where you can
  • 00:35:13
    track how much percentage of work is
  • 00:35:15
    done and how much percentage of work is
  • 00:35:18
    left over. This is also a way for
  • 00:35:21
    management to track your team's effort
  • 00:35:24
    or you know to trans track your team's
  • 00:35:26
    work. So you have committed to 100%age
  • 00:35:30
    of items maybe some 10 items but you
  • 00:35:33
    were only able to deliver six items by
  • 00:35:35
    the end of 3 week this is together I
  • 00:35:38
    mean this is dev team QA team devops
  • 00:35:42
    engineer team
  • 00:35:43
    together right sometimes it can be only
  • 00:35:46
    dev team only QA team only devops team
  • 00:35:50
    but in general all of them work in a
  • 00:35:53
    sprint and within the
  • 00:35:55
    sprint You start with sprint planning
  • 00:35:58
    where you plan two to three weeks of
  • 00:36:01
    activities and by the end of this week
  • 00:36:04
    end of the sprint as a scrum team you
  • 00:36:07
    perform a sprint retrospective where you
  • 00:36:10
    can track how much amount of work is
  • 00:36:12
    done right so as part of this sprint
  • 00:36:15
    planning every 2 3 weeks the scrum team
  • 00:36:19
    meets and they will look at the
  • 00:36:22
    backlog right if we go back to our Jira
  • 00:36:25
    code. So every 2 to 3 weeks all the team
  • 00:36:29
    members meet, they go through the
  • 00:36:31
    backlog. If I just
  • 00:36:34
    refresh, right? So there is one epic
  • 00:36:37
    that was created and this epic will be
  • 00:36:42
    looked at by the development team all
  • 00:36:45
    the scrum team and they will
  • 00:36:47
    create small stories in it. Right? The
  • 00:36:50
    epic will be broken down into stories,
  • 00:36:53
    right? one of the developers maybe dev
  • 00:36:55
    lead creates a
  • 00:36:58
    story. I'll just create one development
  • 00:37:01
    story first probably something like
  • 00:37:03
    identify the
  • 00:37:08
    framework
  • 00:37:10
    required to implement let's
  • 00:37:15
    say
  • 00:37:17
    mobile
  • 00:37:19
    advanced user interface. Okay. So this
  • 00:37:22
    is one story that developer creates
  • 00:37:24
    according to the epic and this story
  • 00:37:27
    will be made as part of the epic. So in
  • 00:37:30
    the parent they will just select 15
  • 00:37:33
    minutes delivery
  • 00:37:34
    service and it will be marked as done.
  • 00:37:38
    Now this will be assigned to one of the
  • 00:37:39
    developers. Right? Right now it is in
  • 00:37:41
    backlog. Once the sprint is started they
  • 00:37:44
    will take this into the sprint and it
  • 00:37:46
    will be assigned to one of the
  • 00:37:47
    developers. Now while they are
  • 00:37:49
    discussing this one of the developers
  • 00:37:51
    says right okay if I have to uh create
  • 00:37:55
    this mobile application I need a
  • 00:37:57
    Kubernetes cluster. So during the sprint
  • 00:38:00
    planning or even before the sprint
  • 00:38:02
    planning when this epic comes into
  • 00:38:05
    discussion right a story is created
  • 00:38:09
    kubernetes cluster creation using
  • 00:38:13
    terraform or maybe just they'll say
  • 00:38:16
    create a kubernetes cluster now this
  • 00:38:19
    will be assigned to the devops engineer
  • 00:38:21
    so this is how work comes to the devops
  • 00:38:24
    engineer so initially the requirement
  • 00:38:27
    was only with business analyst But then
  • 00:38:29
    it came to development team and while
  • 00:38:31
    development team and the whole scrum
  • 00:38:33
    team are planning for the next two to
  • 00:38:35
    three weeks of work that is when you
  • 00:38:38
    know one of the developer says okay I
  • 00:38:40
    might need a kubernetes
  • 00:38:42
    cluster. Now if the devops engineer has
  • 00:38:45
    bandwidth during this sprint yeah it
  • 00:38:48
    will be taken up during the next 2 to 3
  • 00:38:50
    weeks. If devops engineers are already
  • 00:38:54
    occupied then this item will remain in
  • 00:38:56
    the backlog. Now in the next 2 to 3
  • 00:38:59
    weeks or after that this item will be
  • 00:39:02
    picked up by the developer DevOps
  • 00:39:03
    engineers right. So backlog keeps on
  • 00:39:07
    creating because product owner keeps on
  • 00:39:10
    creating the epics. Product owner keeps
  • 00:39:13
    on getting requirements from the
  • 00:39:14
    customers. As those epics are created
  • 00:39:17
    backlog is populated. As the backlog is
  • 00:39:20
    populated DevOps engineers keep getting
  • 00:39:23
    the work. Right? So this time DevOps
  • 00:39:26
    inner are assigned or got a work for
  • 00:39:29
    creating Kubernetes cluster.
  • 00:39:32
    Maybe while discussing other epics,
  • 00:39:35
    right? One of the story was to create
  • 00:39:38
    mobile U user interface. Similarly,
  • 00:39:41
    other story may be to create a desktop
  • 00:39:45
    user interface for 15 minutes delivery.
  • 00:39:47
    And while doing this one of the develop
  • 00:39:50
    developers said okay we need AWS RDS for
  • 00:39:55
    it. So AWS RDS creation will become
  • 00:39:59
    another story and this will also go to
  • 00:40:02
    the
  • 00:40:02
    backlog right and similarly if DevOps
  • 00:40:06
    engineer has the bandwidth we'll take up
  • 00:40:08
    this or will take up in the next sprint.
  • 00:40:11
    So this way backlog refinement is done
  • 00:40:15
    right. So backlog refinement is a
  • 00:40:17
    continuous
  • 00:40:19
    activity where new stories keep coming
  • 00:40:22
    they go to the backlog if DevOps
  • 00:40:24
    engineer has time they will take it
  • 00:40:26
    otherwise they will spill over now I'm
  • 00:40:29
    not going into the agile I'm not going
  • 00:40:32
    in depth of the agile because it's a
  • 00:40:33
    huge concept and different companies
  • 00:40:36
    follow different methodologies some
  • 00:40:38
    people follow scrum some people follow
  • 00:40:40
    canban so you know it becomes too much
  • 00:40:43
    out of context of this video But I
  • 00:40:46
    wanted to tell you this is how Jira is
  • 00:40:49
    used and as a DevOps engineer it is your
  • 00:40:51
    responsibility. Let's say you're working
  • 00:40:53
    on this particular task. So you will
  • 00:40:55
    just go into particular task right and
  • 00:40:59
    you will keep updating the comment
  • 00:41:00
    section. Today if you're working on
  • 00:41:02
    Kubernetes cluster creation right you
  • 00:41:04
    can say what is your status for today.
  • 00:41:07
    Tomorrow you can update the status
  • 00:41:08
    again. So this way your Jira Kubernetes
  • 00:41:11
    cluster creation is tracked by the
  • 00:41:14
    entire management or at least by your
  • 00:41:16
    scrum team. Right? So this is how Jira
  • 00:41:19
    is used. I would highly recommend to
  • 00:41:22
    explore Jira because once you get to
  • 00:41:24
    your organization you will keep
  • 00:41:26
    following Jira dashboards. You will keep
  • 00:41:29
    using it on day-to-day basis. One good
  • 00:41:32
    resource Atlashian provides is learn
  • 00:41:34
    Jira in 5 minutes. So just if you scroll
  • 00:41:38
    down you will find this section learn
  • 00:41:39
    Jira in 5 minutes. So you can take the
  • 00:41:42
    examples provided by Atlashian and
  • 00:41:44
    understand it to some
  • 00:41:46
    extent. If you have any questions
  • 00:41:48
    related to this I would be more than
  • 00:41:51
    happy to help you. Please post the
  • 00:41:52
    questions in the comment section or I'll
  • 00:41:54
    make another detailed video related to
  • 00:41:57
    any questions that you
  • 00:41:58
    have. Thank you so much for watching
  • 00:42:00
    today's video. I hope your questions
  • 00:42:03
    related to bark allocation or
  • 00:42:05
    requirement gathering is cleared. See
  • 00:42:08
    you all in the next video. Take care.
  • 00:42:10
    Bye-bye.
タグ
  • DevOps
  • Software Development
  • Jira
  • Project Management
  • SDLC
  • Agile
  • Roles
  • Collaboration
  • Requirements Gathering
  • Backlog Refinement