Agile Project Management

Loading...

來自 Indian School of Business 的課程

IT Project Management

220 個評分

Explore Related Videos

At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you

Indian School of Business

IT Project Management

220 個評分

課程 4（共 6 門，Specialization Business Technology Management）

The concepts and use of project management tools, techniques and methodologies are becoming all pervasive. This course addresses project management in the context of IT projects, including software projects. Using the framework of project life cycle, the course covers various aspects pertaining to (i) project initiation, (ii) project planning and scheduling, (iii) project monitoring and control, and (iv) project termination. For planning and scheduling of projects, the use of project network and estimation of time and cost are covered in detail. Scheduling of projects with resource limitations is covered next. Risk assessment methods including simulation and risk reduction approaches are also be covered. The students will be required to use the software @risk to simulate project completion times. The use of Earned Value Analysis for Project Monitoring and Control is emphasized. For Software Project Management, the Waterfall Model and Agile Project Management are covered in detail.

從本節課中

Agile Project Management, Monitoring and Control

The first topic in this module is Agile Project Management which is useful in software development projects where the requirements are not well defined and the client is not able to articulate them clearly. The traditional sequential plan driven project is covered first followed by the agile project development cycle. The manifesto and agenda for agile project management are also covered.The next topic in this module is Monitoring and Control. The projects in progress should be reviewed at pre-specified intervals. The process of monitoring and control including the analysis of the status of the project are covered. The last two topics to be covered are Audit and Closure of projects. The audit may be of an ongoing project or of a completed project. The various steps involved in the audit process including the staffing of the audit team, functioning of the team, data collection, analysis and reports are covered in detail.The closure of a project may be a normal closure or a premature closure. The various tasks involved including the delivery of the output of the project, evaluation of the team as well as the project manager are spelt out. Towards the end of this module, we present some practical aspects pertaining to the concepts covered. This is done through a Q & A format with Mr. Prashun Dutta, Advisor - Gaiga Smart Cities

Agile Project Management7:39

Monitoring and Control - Part 18:11

Monitoring and Control - Part 213:57

Audit of Projects9:31

Closure of Projects6:07

(Optional Learning) Interview with Prashun Dutta, Gaiga Smart Cities29:34

與講師見面

M Rammohan Rao
Professor Emeritus
Operations Management

[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]

探索我們的目錄

免費加入並獲得個性化推薦、更新和優惠。

Coursera 致力於普及全世界最好的教育，它與全球一流大學和機構合作提供在線課程。

© 2019 Coursera Inc. 保留所有權利。

通過 App Store 下載

通過 Google Play 獲取