[MUSIC] This module is about Agile project management. In terms of the presentation today, we'll first talk about the use of critical path method, use of Program Evaluation Review Technique, or as it is called, PERT, and then get into Agile project management. We'll talk about the traditional sequential plan driven software project lifecycle, and then get into the Agile project development cycle. We'll close with the Agile Manifesto, which is often referred to as Agile agenda. The cartoon called Dilbert is a creation of Scott Adams. Dilbert says, we need three more programmers. His boss says, use Agile programming methods. Dilbert then says, Agile programming does not mean doing more work with less people. His boss says, find some other words that mean the same. Same thing and doing more work with less people, and then ask again. This cartoon is essentially saying that some people think that the deeper coming things can do more work with less people. This is definitely not the idea for the program. If the project management and duration of task are more or less certain, then the use of critical path method resources section will be fine. If there is some uncertainty regarding the duration of that task but we know the probability distribution of the duration for each task. Then the program evaluation review technique, with resources, sections, and our critical chain approach, will be the techniques that one would use. But if is very difficult or impossible to find out all the requirements, and the duration of the various activities at the start of a project, Agile project management is useful. This approach is useful in software development projects where the requirements are not well defined, and the client is not able to articulate the requirements that need to be addressed in the project. Agile project management is typically not appropriate for project where high reliability is required. This statement from Alistair Cockburn is useful. Almost any methodology can be made to work on some project, and any methodology can be shown to fail on some other project. Heavy processes may be successful on some projects, but light processes are more often successful, and more importantly, people working on those projects credit the success of the project to the lightness of the methodology. Let's first define Agile. Agile is the ability to respond to change in a turbulent environment. Agility is able to balance stability and flexibility. Agile Project Management involves the management of small teams working collectively and collaboratively with the mission to deliver frequent incremental releases of innovative functions and features prioritized for need and affordability. It is evolved iteratively from a vision according to a user reflection and feedback to produce the final product with the best possible value. The user is involved with the team that is developing the software. The traditional sequential plan to project life cycle is to gather and evaluate the requirements until you have identified all the requirements. The next stage, which is the design stage of the product, it is to be undertaken only when most if not all the requirements are identified. There will some overlap between the two faces, namely the requirements identification and design, but the overlap is typically minimal. After you design, you implement the design. Test and verify compliance before getting into production. And finally, validate the implementation and defects. So basically the plan go sequentially if some overlap from getting the requirements designing, implementing, testing, validation and correcting the defects. In the Agile Project Development Cycle you have a Product Vision and you come up with some scope, boundaries and schedule. Then you release the plan that is used to develop the software which is released to the customer. The customer client will review the software and come up with new requirements. Then you go back to the plan, change the plan and develop again. You go through this iterative process of modifying the plan, developing and releasing the newer versions of the product, getting feedback from the client, and so on until the customer is satisfied and the final product is accepted. In between, in some instances, you may have to change the product vision and scope as well. So, Agile Project Development cycle involves a client who's very much part of the development team. The client is constantly giving feedback as to how the product is, and what changes are required. In Agile Project Development life cycle, you start with the product goal, requirements, milestones, scope budget and schedule which are set at the top level. But the details will emerge as the project progresses. Not all details are available at the beginning. The outcomes are incrementally planned and specified. You have to build a project software iteratively and deliver it in frequent releases customers are allowed their change their mind from one release to the next. The client may change the requirements and typically incorporate those changes. The value accrues incrementally as outcomes of portions are released. The manifesto of Agile Project Management is that we are uncovering better based of developing software by doing it and helping others to do it. Throughout this work, we have come to value individuals and interactions of processes and tools. So the team working together becomes very important. Working software is developed instead of comprehensive software. And the working software is modified as we go along. The customer collaborates over the contract and it is part of the changes instead of simply following a plan that was what I wrote earlier. The agenda is that we place trust on individuals in the team and the team has to work together, emphasis on real time face-to-face communication among the team members. Emphasis is on real time face-to-face communication among the team members rather than the command and control processes and documentation. So typically this means that the team has to be located in one place rather than be dispersed. Because face-to-face communication is always better in these so called stand up meetings. The project activities are directed towards value added outcomes. And customers are allowed to modify the specifications as when the versions of the software are dealing with. [MUSIC]
