|
Knowledge should not be limited to those who can afford it or those willing to pay for it.
If you found this course useful and are financially stable please consider supporting the creators by buying the course :)
Tech Recruiting Foundations: 5 Waterfall, Agile, and DevOps for Recruiters
Course Beginner
Course details
Tech is one of those rare places where demand for jobs is higher than the supply. With that in mind, how can recruiters and hiring managers get the best candidates for the job into the jobs they’re trying to fill? One way is by understanding the tech well enough to know exactly what you need. In this series of courses, instructor Ayub Shaikh goes over high-level IT concepts and breaks them into related, easy-to-remember groupings. This course focuses specifically on waterfall, agile, and DevOps. First, Ayub explains the waterfall model, its strengths, its drawbacks, and how those drawbacks led to the development of the agile model. Next, he introduces you to the agile manifesto, key principles of agile development, and how you can identify and recruit agile candidates. Ayub concludes with a discussion of devops, including how it combines two separate silos of IT skills and how you can find and recruit devops candidates.
Recruiting the IT project lifecycle
“
- And so here it is. It's a beautiful, very easy to understand model created by W.W. Royce, as I said, in 1970. And as you can see, the classic waterfall has six stages to it. And we'll highlight the key points in these six stages because of course they are showing us the narrative of creating a new IT system. It shows us how IT roles interact with each other, so this is, as I said, critical for IT recruiters to have a good grasp of this. Let's take a look at how all of these come into play now. The great thing about Royce was that when he laid down this original IT project model, he wanted a situation where instead of IT being chaotic, he could put forward a model where all the questions that needed to be answered could be answered. And so he would go through all of these problems stage by stage and eventually come out with a solution. And the initial stage of any project life cycle is what we call the feasibility stage. Now, this is the stage where we ask the question should we even go ahead? That's an important question. We could waste a whole load of money if we actually don't understand whether or not the software is at fault. Maybe the users who are complaining about this system aren't actually using it properly or weren't trained properly, in which case it's a training issue and the software might be fine. So it's well worth investing a bit of time going around speaking to people, understanding what they don't like about the current system and what they might need from a new software. Now, we need someone who can go around and do that, be it at the desk side or in classroom format in a formalized sense or through online surveys. So this person has to be a very good people person and someone who's able to answer the critical question, should we really go ahead? And this role in IT is known as a business analyst. So a business analyst is someone who has a good understanding of the industry that they're working in, but also a good portion for IT as well. They will come in at the feasibility stage and when they say, "Yes, I think we should go ahead, "there is definitely something wrong "with the system in place now," then we have a project, and then we need a project manager. So a project manager then comes in and essentially starts putting everything together once there is a green light for the project. They'll get involved in the hiring process of the other roles. The next person to come on board, as I mentioned, was classically known as a systems analyst. So in the past they were called a systems analyst. It's still a term that's being used around the world, but actually a more common term now is technical business analyst because we've understood that the second stage known as the analysis stage is actually one where a similar sort of person comes along to the business analyst, but they're just a bit more technical. They are going to define the problems in a much more technical way, and thus set it up for the next person who is going to tell us how to solve the problems. So again, the analyst shouldn't really be involved in the problem solving to a nut and bolt level, but they will give you an overview as to the sort of solutions that might be good for this particular situation. So, the next stage in our waterfall model is the analysis stage, and the person who comes on here is the technical business analyst. Now they might even be, if you're lucky, the same person who did the feasibility. So there is a lot of worth today in business analysts becoming more technical so that they can get involved in two layers of the project. So that makes sense. And for you as an IT recruiter, it means that you are able to sell in someone who's got two for the price of one, essentially, because they've got more technical skills as well as just the original people skills. So just to summarize, any of these analysts are people who have good technical fluency, but they need to be very personable. They're tech savvy, but not overly technical. The analysts tend to have some background in IT, but they won't have to have a deep knowledge of technology in terms of hands on implementation. It's really important for the analyst to have an understanding of the industry they're dealing with as well. So this is very sector specific. You wouldn't propose a business analyst who's been specialist in the pharmaceutical industry to then go and do analysis for maybe the recruitment sector or maybe the financial industry sector because they wouldn't understand the terms. They will spend time speaking to the end user and they will be able to document all their findings in a clear and concise way so they need to understand the industry. Now, what are the deliverables of these two stages? Well, the first stage after the BA has gone around and spoken to the users and understood what they've said, they will put all their findings into a document, and that document will be called the user requirements document. It has other names as well. But generally, here's a document that has collated all the information they found. Now, it's a document that you and I could read, it's written in prose, not too much technology in there. The next analyst who comes on board, the technical business analyst, will make that document more technical. And so the document name will change and it will become a functional specification. So suddenly it's getting a bit more techie. It's getting nicely set up to be viewed by the technical architect. And once we've given it over to the technical architect, they themselves will suddenly do all the wizardry with technology in order to solve the problem. So the technical architect comes in at the design phase of your project life cycle, and they will tell us how to actually solve this problem, which technologies to use, and the blueprint of how to create this new system. The document that they will end up with is the technical specification. So the technical spec will have enough detail in there to be able to tell programmers and database developers and network engineers exactly how to lay down the new system. There's a real analogy with building a house. So the architect right down to the nuts and bolts level, the blueprint level, will tell you exactly which brick to go where, but they don't get involved in laying the bricks. The programmers and the engineers within IT do what is required in accordance with what the technical architect has laid down in that technical spec. Now, if it's an application, the technical architect will pass their technical specification over to the developers, and the developers, as we've understood from an earlier session, can be split into front end, backend database and full stack developers. And they will look at the technical spec and everyone will know exactly what they're about to do. So you can see it's a lovely logical flow as you go down the waterfall model. The developers get everything ready for you and me, the user. But of course, just before we use it and deploy it into the user base, we need to test it. Enter the software testers.
Contents
1. How to Build IT Systems
2. Recruiting Agile and DevOps |
