What ‘s the essential difference between agile developing and plan based developing?

In agile process, the product owner put the unformal ideas/user story/backlog items to the sprint/iteration. Sprint/iteration is like a plan for a short term and it is drived by daily meeting. Planning is made in both processes. So what’s the difference between agile and the old plan based developing?

Planned vs. agile processes for software can be quickly characterized by some pairs.

Waterfall vs. iterative/incremental
Watts Humphrey vs. Kent Beck.
Management driven vs. team driven.
SEI CMM vs. Agile manifesto.
Microsoft project vs. burn down lists.
Interim xyz review vs. scrum stand up meeting.
Annual release vs. daily build.
Code inspection vs. pair programming.
Planning schedules vs. planning game.
Committees vs. visionaries.

In someways, this question is already answered by the Agile Manifesto, but instead of reading left to right, read right to left.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Some of the comparisons above may be a little harsh, because certainly there is a lot of feature driven development that is practices with planned, and releases may be quarterly (but probably not monthly).

The best thinkers behind planned process were influenced by problems with ad-hoc or poorly suited approaches to software such as were described in Mythical Man-Month. As early as 1968, NATO had a conference on Software Engineering to try to solve the crisis and at that point. I think they had some great innovations. Page 12 of their conference report has a remarkable drawing describing waterfall but with curves instead of boxes. It also includes material about the challenges of estimating software projects. Later, planned software process experts borrowed and stole from QA pioneers like Demming and the many Japanese experts who proved its worth in manufacturing cars and electronics.

I think the best agile thinkers were extremely familiar with planned process, and reacted against its limitations, while retaining some of its strong points. Planned process has not lost all of its relevance, and some would argue it is essential for large projects. Planned is still widely used, particularly in large organizations, but many try to hybrid with agile techniques. Perhaps System of Systems design approaches are planned, but they have a good characteristic of creating small teams which is a more practical place for agile. Planned was sensitive to the need for local tailoring, but expected it would be facilitated by meetings and committees.

Great references on this topic include Watts Humphries books, articles, and technical reports on organizational, team, and personal software process. Contrast those with Kent Beck’s introductory sections from eXtreme Programming Explained.

One of my professors described the history of software development something like this:

1970s : Tools – a Cambrian explosion of operating systems, programming languages, and tool
evolution.
1980s : Process – don’t blame the people, blame (and fix) the process.
1990s : People – empower decision making and communications and interactions among people.

Theoretically @JVXR is is right. Waterfall means you get requirements, plan the work, set the price and delivery schedule an off you go. At the end, it all comes together, often the requirements were wrong or changed, the work was more than expected and it turns to a big ball of mud. Agile promises to solve all the problems of waterfall by doing small bits of work in response to changing needs and increase knowledge, regularly delivering something that value to the customer, and stopping when the customer decides the job is done (in reality – when the money runs out).

Waterfalls problems are well known and documented, and therefore easy to suggest solutions to. Agile has it’s problems also, however they are less well known and even less well documented – we, as an industry, tried waterfall and failed miserably. Now were are trying Agile, and failing (slightly less miserably, but still failing), and no one wants to suggest it’s not working until they can see/sell a better solution.

As a result, for every 100 software houses, there are probably 200 claimed ‘agile’ processes in use (Many shops have more than one team, and part of agile is a team can do it however they like. Maybe 10 of these processes are truly Agile, the rest are best described as waterfall in drag (i.e. Waterfall without the documentation)

By “Old planning” I presume that you mean waterfall, There is no customer feedback until the product is developed and delivered, and usually thats when stuff hits the fan in the waterfall process. Waterfall heavily relies on “requirement docs” – which the customer will swear that he/she never said anything of that sort in a months time.

In agile, theoretically you produce small working increments and get the customer’s feedback and incorporate it in the next release. So chances of stuff hitting the fan is lowered.Overall the customer feels that he’s getting something out of what he’s paying you for.

Plan based developing focuses on creating a detailed upfront plan whereas agile, or more accurately scrum, defers detailed plans until the work is about to begin and allows the order or priority of work to change. This minimizes change impact and means decisions (i.e. plans) can be made when the most knowledge is available. Whereas plan based development requires the plan to be revisted when changes occur and requires most decisions to be made upfront when the team knows the least about the problem and solutions.

Filed under: softwareengineering - @ 06:55

Thẻ: agile, development-process, scrum

Thiết kế website giá rẻ

Danh mục

What ‘s the essential difference between agile developing and plan based developing?