Then the next approach that we're going to talk about is what we call Agile. For Agile process, we focus on the items on the left-hand side. We focus less on the items on the right-hand side. For example, we focus more on individuals and interactions and also a working software and also client involvement, and also collaborations, and also responsiveness to changes. Right at hand processes and tools or documentation, or contract negotiation, or following a plan. Now, you can see that instead of coming up with documentation or a client. We try to focus more on implementation. This is what we focus when we talk about Agile processes. But this does not imply that there is no value in the items on the right-hand side, just that we focus less on those items. These are the Agile processes that I'm to cover in this lecture. They are Extreme Programming, Continuous Integration, and also Scrum. There are some common practices used by this Agile processes. For example, planning poker to estimate the resources and the number of people or the time, the schedule needed for a project. Pair programming to avoid making mistakes. What is pair programming? That means when you are programming, another guy will be sitting beside you, watching you typing in source code. Why do we want to do pair programming? Because we try to avoid making mistakes. Just because another guy is double-checking your source code then we can avoid making mistake. Also, Test Driven Development. That means before, even before we implement, we think about what are the possible test cases for the system. The first one that we're going to cover is what we call extreme programming. In extreme programming, we have to get the requirements and perform analysis. Developers, they will determine the features required for the system.They will also provide a time and cost estimation for each feature. The client will select features to be included in a particular iteration of the development. Then, when we implement, the developer will break each iteration into some task. Different people in different teams, they will be responsible for different task. For each task that developer has to design the test cases. That means we're going to use test driven development. We have to think about the test cases before we implement a particular task. Then we implement a task using pair programming. Again, when you're programming another guy is going to double-check your program to make sure that there's no mistakes. Finally, we would integrate a task together as the final product. This is what we do in Extreme Programming. The next one that we're going to talk about is Continuous Integration. Notice that Continuous Integration is an agile software development process, where developers they will integrate source codes into a shared repository on a daily basis. That means once the developer gets something done, they will immediately integrate a code into a shared repository. Why do we want to do that? Because if we are just talking about integrating a small part of the source code into the repository, then the effort that we need to spend for integration and also testing is going to be minimal. That's why we want to perform integration quickly and also testing quickly to identify any errors and also any integration errors immediately. These are the advantages of using Continuous Integration. It allows developers to integrate and test their code early. Once they get a little part done, then they will integrate and test their code immediately. Also quick catches and also exposes off any bug that may break the build. Also reduce integration conflicts by doing integration continuously. It helps developers to check the progress of their development. Because now you can see the work under this shared repository. Building and testing out done automatically using scripts on the CI server. The clauses said you will need a CI server to compile the code periodically, and also reports the results to the developer. Also, you have to prepare all the scripts on the server to the building and also testing automatically on the server. This is the architecture that we use in Continuous Integration. Developers, they will commit changes to a Version Control Repository. Then this CI server will poll the most updated version from the Version Control Repository and try to build and task the most updated version. If there's any mistakes with the most updated version, then that will be some feedback to the developers. We assume that testing and building they are done automatically using some scripts on the CI server. The next process then, I'm going to talk about is what we call Scrum. Is a very common process being used in the industry. I will show you a little video about Scrum. Hi, this is me. My name is Hamid Shojaee and I've been involved with a number of software development projects over the years at a number of different companies and I have come to recognize scrum as one of the best agile development practices in use today. In this fast-paced video, I want to show you why scrum is so great and how you can get started with scrum in under 10 minutes. I'll cover all the core scrum concepts like product backlogs, Team roles, sprints, burndown charts, and more. Get ready to be bombarded with information. Let's say this is the product we want to build. For this product, we get all kinds of feature requests from users, customers, executives or even other team members. In scrum, the collection of all these features is called the product backlog. Another way to think of the product backlog is to think of it as a wish-list of all the things that would make this product great. Once we have our wish-list or the product backlog, we need to start planning which specific features we're going to put into a particular release of our product. But we're getting ahead of ourselves. Let's back up a bit. To build this product, we need to have one or more people in our team who are going to play a variety of roles. First, we need her. She plays the role of product owner and helps make sure the right features make it into the product backlog representing the users and customers of the product. She helps set the direction of the product. Then we need this guy. He's the scrum master and his job is to make sure the project is progressing smoothly and that every team member has the tools they need to get their job done. He sets up meetings, monitors the work being done, and facilitates release planning. He is essentially a project manager, but that's such a boring title. So we'll call him a scrum master to imply he knows some Jujitsu. The rest of the team has similar roles to other development processes. These guys build the product while these guys test it to make sure it works right, these guys use it and hopefully pay for it, and these guys generally get in the way. But it turns out, you can't build many products without them. But let's get back to this, release planning. To plan a release, the team starts with this, the product backlog and they identify the features they want to put into this release. These features then become part of the release backlog. The team then prioritizes the features and estimates the amount of work involved for each feature, providing a rough idea of the total amount of work involved to complete the entire release. A quick side note about estimates. There are a lot of techniques for creating estimates, from poker games to basing estimates on historical trends, to using story points instead of hours. But no matter what technique you use, you'll want to make sure you involve at least two or three subject matter experts. There is simply no replacement for what a subject matter expert brings to the table. Keep that in mind as you do your estimates. Let's get back to this. The release backlog. With a prioritized release backlog in hand, we're now ready to plan out several sprints to get the work done. Sprints are short duration milestones that allow teams to tackle a manageable chunk of the project and get it to a ship ready state. Sprints generally range from a couple of days to as much as 30 days in length, depending on the product's release cycles. The shorter the product's release cycles, the shorter each sprint should be. You'll want to have at least four to as many as a dozen sprints in a given release. At this point, we can take our release backlog and split it up into several of these sprint backlogs. One of the most important things to remember about sprints is that the goal of each sprint is to get a subset of the product backlog to a ship ready state. At the end of each sprint, you should have a fully tested product with all the features of that spread 100 percent complete. Since sprints are a very short but a realistic representation of part of the product, a late finish of the sprint is a great indicator that the project is not on schedule and something needs to be done. Therefore, it's extremely important to monitor the progress of each sprint with this, a burndown chart. The burndown chart is the number one reason for scrum's popularity and one of the best project visibility tools to ensure a project is progressing smoothly. The burndown chart provides a day-by-day measure of the amount of work that remains in a given sprint or release. In this graph, you can see that the amount of work remaining bounces up and down from day to day, but it's generally trending down towards zero because historical information is provided in the burndown chart, it's easy to see if the team is on the right track. Using the burndown chart, the team can quickly calculate this, the slope of the graph, which is also called the burndown velocity. This is the average rate of productivity for each day. For example, a team's rate of productivity might be that on a typical day they finish approximately 50 hours of work. Knowing that, it's possible to calculate an estimated completion date for the sprint or even for the entire release based on the amount of work remaining. What's great about the burndown chart is that we can compare our actual velocity and projected completion date to what the team needs to do in order to finish on time. We can use that to see if it's a realistic time-frame. This is perhaps the most useful piece of knowledge that any team member, product owner, or product executive can have about the project because knowing whether or not the project is on track early in the schedule can help teams make the proper adjustments necessary to get the project on track. The burndown chart provides empirical proof that the project is on track or if it's going to be late. Let's talk a little about where the data for this incredibly useful burndown chart comes from. As you recall, part of the release planning process was to create an estimate for each feature in the product backlog. The collection of these estimates for a given sprint represents the total amount of work that must be done to complete that sprint. As each team member goes through and makes progress on one or more of the features, they simply update the amount of time remaining for each of their own items. The total amount of time remaining on the group of features that make up a sprint changes on a day-by-day basis, hopefully going downward until it hits zero when the sprint is complete. The burndown chart aggregates the remaining work data and shows it visually. It's brilliant because it communicates a massive amount of information in just a few seconds. At this point, one question you might have is what do we do about these little guys? Bugs come up during the development of every product. While there is no way to avoid them altogether, there are some best practices on how to deal with them. First, it's a good idea to track bugs separately from features in their own defect backlog, and during a feature sprint, any bugs that are found relating to a feature in development should be dealt with immediately before marking the feature complete. You'll also want to plan at least one or two sprints that focus only on your defect backlog. That brings us to this, the daily Scrum. Scrum proponents often insist on short, daily standing meetings. The idea behind a standing meeting is that if everyone is standing, nobody will waste time, and therefore, meetings will be short. By meeting daily, we can feel confident that everyone is on top of their tasks. The daily Scrum is a great idea and especially useful in less experienced teams, but I wouldn't call it a core or essential part of Scrum, insisting on these meetings in an already efficient and experienced team, especially teams that work in close proximity with one another, could actually backfire by lowering team morale. Keep that in mind when deciding on having daily Scrums. There you have it, scrum in under 10 minutes. You now know all the essential concepts to start implementing Scrum inside of your organization. Let's quickly review them. In Scrum, you work with this, a product backlog, which is nothing more than a list of features. We then break down the product backlog into one or more release backlogs. For a given release, you further break up the release backlog into a number of sprint backlogs, which are essentially short duration milestones throughout your project. You then monitor the progress of each sprint using these burndown charts. Depending on your team, you might want to have daily Scrum meetings to ensure everything is on track. That's all there is to it. I hope you like this video as much as I enjoyed making it. Now after watching the video, you will know that a Scrum is an agile software development process that mainly specifies what you should do to develop a software product. There's no specific software engineering practices prescribed it for developing the product. The team needs to decide how to work on it. The requirements are captured as items in a product backlog. A list of features required by the software system. The product owner, the client, sets the priority for the items. The software product is developed in a series of iterations called sprints. Teams self-organize to determine the best way to deliver the product in this other things that we have to do within Scrum. Now you should know what is a sprint within Scrum after you watched the video. The product backlog contains all the features required by the system. Then we're going to pick a subset of the features and then put it in a sprint. Then within the sprint, usually two or four weeks time, we're going to focus on the implementation of those features within a sprint. That's why we say the software product is decided, coded, and tested during sprints. The requirements are not allowed it to change during a sprint. Also after watching the video, you should recognize all these keywords in Scrum. The product owner is your client, the Scrum master is usually the manager. Also we may have different meetings, for example, sprint planning meeting to plan exactly what are the features required within a sprint. Also daily Scrum meeting to keep track of the progress of development. Also there may be different artifacts. For example, the product backlog, which contains all the features required by the system. Also sprint backlog which is the features required by a sprint. Also burndown charts to keep track the progress of development. Now you know that if we are talking about product owner, we are talking about our client, it's usually the key stakeholder and it's going to define and prioritizes the requirements of the product. Also adjust requirements and priority of every iteration as needed. Also decides on the release date and content and also accept and reject work results, etc. A Scrum master is usually the manager of the project. He or she is responsible for enacting Scrum values and practices, and also ensure that the team is fully functional and also productive. Also enable close corporation across all roles and functions. Finally, remove impediments to progress and shields the teams from external inferences. In a sprint planning meeting, we have to decide from the product backlog, from the order features, pick a subset of the features in a sprint so that we're going to focus on those features in a sprint. Then if we're talking about daily Scrum meeting, these are the questions that you may ask in the meeting. What did you do yesterday? What will you do today? Is there anything in your way, etc.? Again, asking this question is just going to help you track the progress of the development. These are the artifacts of Scrum. Somehow you still have some documentation to keep track all the features required by the system. It's called product backlog. Then within a sprint, we are going to choose some of the features from the product backlog to develop within a sprint. Then we will use burndown chart to keep correct the progress of development. These are the pros and cons of agile. The pros are that the development is adaptable to changing requirements and immediate feedback is provided by the client or users. Also result in fast speed to market. There are fewer defects in the final product because if we have defects within a sprint, we should clean up all the defects before we move to another sprint. The cons are that active user involvement and close collaboration are required. Also there is often a lack off documentation. There can be scope creep as the client or users add requirements. Finally, daily stand-up meetings can take a toll.
