Advantages of Black Box Testing

 Black box tests are reproducible.

 The environment the program is running is also tested.
 The invested effort can be used multiple times.
 More effective on larger units of code than glass box testing
 Tester needs no knowledge of implementation, including specific programming languages
 Tests are done from a user's point of view
 Will help to expose any ambiguities or inconsistencies in the specifications
 Efficient when used on Larger systems
 As the tester and developer are independent of each other, test is balanced and unprejudiced
 Tester can be non-technical.
 There is no need of having detailed functional knowledge of system to the tester.
 Tests will be done from an end user's point of view. Because end user should accept the system. (This is
reason, sometimes this testing technique is also called as Acceptance testing)
 Testing helps to identify the vagueness and contradiction in functional specifications.
 Test cases can be designed as soon as the functional specifications are complete

Disadvantages of Black Box Testing

 The results are often overestimated.

 Not all properties of a software product can be tested
 The reason for a failure is not found.
 Only a small number of possible inputs can actually be tested, to test every possible input stream would take
nearly forever
 Without clear and concise specifications, test cases are hard to design
 There may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer
has already tried
 May leave many program paths untested
 Cannot be directed toward specific segments of code which may be very complex (and therefore more error
prone)
 Most testing related research has been directed toward glass box testing
 Test cases are tough and challenging to design, without having clear functional specifications
 It is difficult to identify tricky inputs, if the test cases are not developed based on specifications.
 It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult
 Chances of having unidentified paths during this testing
 Chances of having repetition of tests that are already done by programmer.

Advantages of white box testing

 Forces test developer to reason carefully about implementation

 Approximates the partitioning done by execution equivalence
 Reveals errors in "hidden" code:
 Beneficent side-effects
 Optimizations (e.g. chartable that changes reps when size > 100)
 As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type of
input/data can help in testing the application effectively.
  The other advantage of white box testing is that it helps in optimizing the code.
 It helps in removing the extra lines of code, which can bring in hidden defects.

Disadvantages of white box testing

 Expensive
 Miss cases omitted in the code
 As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this type of
testing, which increases the cost.
 And it is nearly impossible to look into every bit of code to find out hidden errors, which may create problems,
resulting in failure of the application.
 Not looking at the code in a runtime environment. That's important for a number of reasons. Exploitation of
vulnerability is dependent upon all aspects of the platform being targeted and source code is just of those
components. The underlying operating system, the backend database being used, third party security tools,
dependent libraries, etc. must all be taken into account when determining exploitability. A source code review is
not able to take these factors into account.
 Very few white-box tests can be done without modifying the program, changing values to force different
execution paths, or to generate a full range of inputs to test a particular function.

Advantages of Black-box testing

 Since tester does not have to focus on the inner working of an application, creating test cases is easier.
 Test case development is faster as tester need not to spend time on identifying the inner processes; his
only focus is on the various paths that a user may take through GUI.
 It is simple to use as it focuses only on valid and invalid inputs and ensures that correct outputs are
obtained.
Drawbacks of Black-box testing

 Constantly changing GUI makes script maintenance difficult as the input may also be changing.
 Interacting with GUI may result in making the test script fragile and it may not properly execute
consistently.
Advantages of White-box testing

 Since the focus is on the inner working the tester can identify objects pro grammatically. This can be useful
when the GUI is frequently changing.
 It can improve stability and re usability of test cases provided the object of an application remains the
same.
 By testing each path completely it is possible for a tester to achieve thoroughness.
Drawbacks of White-box testing

 Developing test cases for white-box testing involves high degree of complexity therefore it requires highly
skilled people to develop the test cases.
 Although to a great extent fragility is overcome in white-box testing BUT change in the objects name may
lead to breaking of the test script.
Agile Software Development Methodology
Agile software development is a conceptual framework for undertaking software engineering projects. There are a number of
agilesoftware development methodologies e.g. Crystal Methods, Dynamic Systems Development Model (DSDM), and Scrum.

Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which typically last one to
four weeks. Each iteration is like a miniature software project of its own, and includes all the tasks necessary to release the mini-
increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While iteration may not
add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software
at the end of every iteration. At the end of each iteration, the team reevaluates project priorities.

Agile methods emphasize realtime communication, preferably face-to-face, over written documents. Most agile teams are located in a
bullpen and include all the people necessary to finish the software. At a minimum, this includes programmers and the people who
define the product such as product managers, business analysts, or actual customers. The bullpen may also include testers, interface
designers, technical writers, and management .

Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face
communication, agile methods produce very little written documentation relative to other methods.

Crystal Methods Methodology

Alistair Cockburn developed the Crystal Methods approach. His focus is on the people, interaction, community, skills, talents, and
communications with the belief that these are what have the first-order effect on performance. Process, he says, is important, but
secondary.

Cockburn's philosophy translate into a recognition that each team has a different set of talents and skills and therefore each team
should use a process uniquely tailored to it. And it means that the process should be minimized - barely significant.

The use of the word “crystal” refers to the various facets of a gemstone - each a different face on an underlying core. The underlying
core represents values and principles, while each facet represents a specific set of elements such as techniques, roles, tools, and
standards. Cockburn also differentiates between methodology, techniques, and policies. A methodology is a set of elements
(practices, tools); techniques are skill areas such as developing use cases; and policies dictate organizational “musts”.

Dynamic Systems Development Model Methodology

The Dynamic Systems Development Model was developed in the U.K. in the mid-1990s. It is the evolution of rapid application
development (RAD) practices. DSDM boasts the best-supported training and documentation of any of the agile software development
techniques, at least in Europe. DSDM favors the philosophy that nothing is built perfectly the first time and looks tosoftware
development as an exploratory endeavor.

The nine principles of DSDM are:

 Active user involvement.
 Empowered teams that the authority to can make decisions.
 A focus on frequent delivery of products.
 Using fitness for business purpose as the essential criterion for acceptance of deliverables.
 Iterative and incremental development to ensure convergence on an accurate business solution.
 Reversible changes during development.
 Requirements that is baselined at a high level.
 Integrated testing throughout the life cycle.
 Collaboration and cooperation between all stakeholders.

Extreme Programming (XP) Methodology

XP is a methodology for creating software within a very unstable environment. It allows flexibility within the modelling process.

The main goal of XP is to lower the cost of change in software requirements. With traditional system development methodologies, like
the Waterfall Methodology, the requirements for the system are determined and often “frozen” at the beginning of
thedevelopment project. This means that the cost of changing the requirements at a later stage in the project - something that is very
common in the real-world can be very high.

XP Core Practices
The core practices of Extreme Programming, as described in the first edition of “Extreme Programming Explained” can be grouped
into four areas (12 practices) as follows:
Fine scale feedback
 Test driven development
 Planning game
 Whole team
 Pair programming

Continuous process rather than batch

 Continuous Integration
 Design Improvement
 Small Releases

Shared understanding
 Simple design
 System metaphor
 Collective code ownership
 Coding standards or coding conventions

Programmer welfare
 Sustainable pace (i.e. forty hour week)

In the second edition of “Extreme Erogramming Explained” a set of corollary practices are listed in addition to the primary practices.

The core practices are derived from generally accepted best practices, and are taken to extremes:
 Interaction between developers and customers is good. Therefore, an XP team is supposed to have a customer on site,
who specifies and prioritizes work for the team, and who can answer questions as soon as they arise. (In practice, this role
is sometimes fulfilled by a customer proxy.)
 If learning is good, take it to extremes: Reduce the length of development and feedback cycles. Test early.
 Simple code is more likely to work. Therefore, extreme programmers only write code to meet actual needs at the present
time in a project, and go to some lengths to reduce complexity and duplication in their code.
 If simple code is good, re-write code when it becomes complex.
 Code reviews are good. Therefore XP programmers work in pairs, sharing one screen and keyboard (which also improves
communication) so that all code is reviewed as it is written.
 Testing code is good. Therefore, in XP, tests are written before the code is written. The code is considered complete when
it passes the tests (but then it needs refactoring to remove complexity). The system is periodically, or immediately tested
using all pre-existing automated tests to assure that it works. See test-driven development.

It used to be thought that Extreme Programming could only work in small teams of fewer than 12 persons. However, XP has been
used successfully on teams of over a hundred developers.

Feature Driven Development Methodology

Jeff De Luca and Peter Coad were both greatly involved in developing the Feature Driven Development methodology. Peter
describes FDD as having just enough process to ensure scalability and repeatability while encouraging creativity and innovation.

More specifically, Feature Driven Development asserts that:

 A system for building systems is necessary in order to scale to larger projects.
 A simple, but well-define process will work best.
 Process steps should be logical and their worth immediately obvious to each team member.
 “Process pride” can keep the real work from happening.
 Good processes move to the background so team members can focus on results.
 Short, iterative, feature-driven life cycles are best.

FDD proceeds to address the items above with this simple process (numbers in brackets indicate the project time spent):

1. Develop an overall model (10 percent initial, 4 percent ongoing)

2. Build a features list (4 percent initial, 1 percent ongoing)
3. Plan by feature (2 percent initial, 2 percent ongoing)
4. Design by feature
5. Build by feature (77 percent for design and build combined)

Joint Application Development (JAD) Methodology

JAD is a requirements-definition and user-interface design methodology in which end-users, executives, and developers attend
intense off-site meetings to work out a system's details. So the Joint Application Development (JAD) methodology aims to involve the
client in the design and development of an application. This is accomplished through a series of collaborative workshops called JAD
sessions. Two employees of IBM, Chuck Morris and Tony Crawford, developed the JAD methodology in the late 1970s and began
teaching the approach in to the 1980s.

JAD focuses on the business problem rather than technical details. It is most applicable to the development of business systems, but
it can be used successfully for systems software. It produces its savings by shortening the elapsed time required to gather a system's
requirements and by gathering requirements better, thus reducing the number of costly, downstream requirements changes. Its
success depends on effective leadership of the JAD sessions; on participation by key end-users, executives, and developers; and on
achieving group synergy during JAD sessions.

In contrast to the Waterfall approach, JAD is thought to lead to shorter development times and greater client satisfaction, both of
which stem from the constant involvement of the client throughout the development process. On the other hand, with the traditional
approach to systems development, the developer investigates the system requirements and develops an application, with client input
consisting of a series of interviews.

Rapid application development (RAD), a variation on JAD, attempts to create an application more quickly through strategies that
include fewer formal methodologies and reusing software components.

Lean Development (LD) Methodology

Lean Development focuses on the creation of change-tolerant software. This methodology embodies the notion of dynamic stability
which can be thought of as similar to how Scrum embraces controlled chaos. Bob Charette, the originator, writes that the measurable
goal of LD is to build software with one-third the human effort, one-third the development hours and one-third the investment as
compared to what SEI (Software Engineering Institute) CMM Level 3 organization would achieve.

There are 12 principles of Lean Development:

1. Satisfying the customer is the highest priority.
2. Always provide the best value for the money.
3. Success depends on active customer participation.
4. Every LD project is a team effort.
5. Everything is changeable.
6. Domain, not point, solutions.
7. Complete, don't construct.
8. An 80 percent solution today instead of 100 percent solution tomorrow.
9. Minimalism is essential.
10. Needs determine technology.
11. Product growth is feature growth, not size growth.
12. Never push LD beyond its limits.

Rapid Application Development (RAD) Methodology

“Rapid-development language” is a general term that refers to any programming language that offers speedier implementation than
do traditional third-generation languages such as C/C++, Pascal, or Fortran. Rapid-Development Languages (RDLs) produce their
savings by reducing the amount of construction needed to build a product. Although the savings are realized during construction, the
ability to shorten the construction cycle has projectwide implications: shorter construction cycles make incremental lifecycles such as
Evolutionary Prototyping practical. Because RDLs often lack first-rate performance, constrain flexibility, and are limited to specific
kinds of problems, they are usually better suited to the development of in-house business software and limited-distribution custom
software than systems software.

RAD (rapid application development) proposes that products can be developed faster and of higher quality by:
 Using workshops or focus groups to gather requirements.
 Prototyping and user testing of designs.
 Re-using software components.
 Following a schedule that defers design improvements to the next product version.
 Keeping review meetings and other team communication informal.

There are commercial products that include requirements gathering tools, prototyping tools, software development environments
such as those for the Java platform, groupware for communication among development members, and testing tools. RAD usually
embraces object-oriented programming methodology, which inherently fosters software re-use. The most popular object-oriented
programming languages, C++ and Java, are offered in visual programming packages often described as providing rapid application
development.
Rational Unified Process (RUP) Methodology
The Rational Unified Process attempts to capture many of modern software development's best practices in a form suitable for a
wide range of projects and organizations. This process recognizes that the traditional waterfall approach can be inefficient because it
idles key team members for extended periods of time. Many feel that the waterfall approach also introduces a lot of risk because it
defers testing and integration until the end of the project lifecycle. Problems found at this stage are very expense to fix.

By contrast, RUP represents an iterative approach that is superior for a number of reasons:
 It lets you take into account changing requirements which despite the best efforts of all project managers are still a reality on
just about every project.
 Integration is not one “big bang” at the end; instead, elements are integrated progressively.
 Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate risks earlier.
 Iterative development provides management with a means of making tactical changes to the product. It allows you to
release a product early with reduced functionality to counter a move by a competitor, or to adopt another vendor for a given
technology.
 Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented than to
recognize them during planning.
 When you can correct errors over several iterations, the result is a more robust architecture. Performance bottlenecks are
discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery.
 Developers can learn along the way, and their various abilities and specialties are more fully employed during the entire
lifecycle. Testers start testing early, technical writers begin writing early, and so on.
 The development process itself can be improved and refined along the way. The assessment at the end of iteration not only
looks at the status of the project from a product or schedule perspective, but also analyzes what should be changed in the
organization and in the process to make it perform better in the next iteration.

Scrum Methodology
Scrum is an agile method for project management developed by Ken Schwaber. Its goal is to dramatically improve productivity in
teams previously paralyzed by heavier, process-laden methodologies.

Scrum is characterized by:

 A living backlog of prioritized work to be done.
 Completion of a largely fixed set of backlog items in a series of short iterations or sprints.
 A brief daily meeting (called a scrum), at which progress is explained, upcoming work is described, and obstacles are raised.
 A brief planning session in which the backlog items for the sprint will be defined.
 A brief heartbeat retrospective, at which all team members reflect about the past sprint.

Scrum is facilitated by a scrum master, whose primary job is to remove impediments to the ability of the team to deliver the sprint
goal. The scrum master is not the leader of the team (as they are self-organizing) but acts as a productivity buffer between the team
and any destabilizing influences.

Scrum enables the creation of self-organizing teams by encouraging verbal communication across all team members and across all
disciplines that are involved in the project. A key principle of scrum is its recognition that fundamentally empirical challenges cannot
be addressed successfully in a traditional “process control” manner. As such, scrum adopts an empirical approach - accepting that
the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to respond in an agile manner to
emerging challenges.

Spiral Methodology
The Spiral Lifecycle Model is a sophisticated lifecycle model that focuses on early identification and reduction of project risks. A spiral
project starts on a small scale, explores risks, makes a plan to handle the risks, and then decides whether to take the next step of the
project - to do the next iteration of the spiral. It derives its rapiddevelopment benefit not from an increase in project speed, but from
continuously reducing the projects risk level - which has an effect on the time required to deliver it. Success at using the Spiral
Lifecycle Model depends on conscientious, attentive, and knowledgeable management .It can be used on most kinds of projects, and
its risk-reduction focus is always beneficial.

The spiral methodology extends the waterfall model by introducing prototyping. It is generally chosen over the waterfall approach for
large, expensive, and complicated projects.

At a high-level, the steps in the spiral model are as follows:

1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users
representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and
represents an approximation of the characteristics of the final product.
4. A second prototype is evolved using four steps:
  Evaluate the first prototype and identify its strengths, weaknesses, and risks.
 Define the requirements of the second prototype.
 Plan and design the second prototype.
 Construct and test the second prototype.

5. At the project sponsor's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve
development cost overruns, operating-cost miscalculation, or any other factor that could result in a less-than-satisfactory final
product.
6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is
developed from it according to the fourfold procedure outlined above.
7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
8. The final system is constructed, based on the refined prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-
scale failures and to minimize downtime.

Systems Development Life Cycle (SDLC) Methodology

The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in
an information system development project, from an initial feasibility study through maintenance of the completed application. Various
SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original
SDLC method); rapid application development (RAD); joint application development (JAD); the fountain model; the spiral model; build
and fix; and synchronize-and-stabilize.

Often, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model
chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for
specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the
particular plan was followed.

In general, an SDLC methodology follows these steps:

1. If there is an existing system, its deficiencies are identified. This is accomplished by interviewing users and consulting with support
personnel.
2. The new system requirements are defined including addressing any deficiencies in the existing system with specific proposals for
improvement.
3. The proposed system is designed. Plans are created detailing the hardware, operating systems, programming, and security
issues.
4. The new system is developed. The new components and programs must be obtained and installed. Users of the system must be
trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.
5. The system is put into use. This can be done in various ways. The new system can phased in, according to application or location,
and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the
new system all at once.
6. Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at
all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.

Waterfall (a.k.a. Traditional) Methodology

The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the
classic approach to the systems development life cycle, the waterfall model describes a development method that is rigid and linear.
Waterfall development has distinct goals for each phase of development where each phase is completed for the next one is started
and there is no turning back.

The perceived advantages of the waterfall process are that it allows for departmentalization and managerial control. A schedule is
typically set with deadlines for each stage of development and a product can proceed through the development process. In theory,
this process leads to the project being delivered on time because each phase has been planned in detail.

In practice, waterfall development often falls short of expectations as it does not embrace the inevitable changes and revisions that
become necessary with most projects. Once an application is in the testing stage, it is very difficult to go back and change something
that was not thought of in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid
application development (RAD), sync and stabilize, build and fix, and the spiral model.

Introduction
This article is about basic introduction to Agile software development methodologies and how to apply them. It is
about how to work together to achieve a common goal. This is not only suitable for the Software Developers but
also for Team Leaders, Project Managers, Product Managers, Development Managers, Testers, QA Managers,
QA Engineers, Technical Writers, UX Designers, anyone involves in the delivering of software. This article focus
on how technology team work together well to plan, build and deliver software. It does not talk about code or not
focus on specific technology or not only about Microsoft tools. Hope this will improve your professional life and
the effectiveness of your team.

The need for professional behave. Does our industry knows what it means to behave? The definition of a software
developer, who sits in a room spend some time and code comes out. We get very confuse about deadlines, date,
estimates and all of the things we are suppose to be doing, we do them badly. Now thats not unusual. Our
industry is still young.

Background
Winston Royce's Waterfall Model
"From the 1970 IEE paper "Managing the Development of Large Software Systems"

There are two essential steps common to all computer program developments, regardless of size or complexity.
There is first an analysis step, followed second by a coding step. Then he introduced most five important steps:

Step 1: PROGRAM DESIGN COMES FIRST

Allocate processing, functions, design the data base, define data base processing, allocate execution time, define
interfaces and processing modes with the operating system, describe input and output processing, and define
preliminary operating procedures. Write an overview document that is understandable, informative and current.

Step2: Document the Design

The first rule of managing software development is ruthless enforcement of documentation requirements.

Step 3: Do It Twice

The second most important criterion for success revolves around whether the product is totally original. If the
computer program in question is being developed for the first time, arrange matters so that the version finally
 delivered to the customer for operational deployment is actually the second version insofar as critical
design/operations areas are concerned.

Step 4: Plan, Control, and Monitor Testing

It is the phase of greatest risk in terms of dollars and schedule. It occurs at the latest point in the schedule when
backup alternatives are least available, if at all.

Step 5: Involve the Customer

It is important to involve the customer in a formal way so that he has committed himself at earlier points before
final delivery.

A careful reading of Royce's paper reveals:

 Each phase should pass iteratively to the next
 The entire process should be exercised twice before release
 Royce knew that a single pass will fail

Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps.

What are all this stuff ?

The answer is :
 Agile development is not a methodology in itself. It is an umbrella term that describes several agile methodologies.
At the signing of the Agile Manifesto in 2001, these methodologies included Scrum, XP, Crystal, FDD, and DSDM.
Since then, Lean practices have also emerged as a valuable agile methodology and so are included under the
agile development umbrella in the illustration later.

To learn more read Agile Principles and Values, by Jeff Sutherland

Original Signatories

Ref: agilemanifesto.org

Manifesto for Agile Software Development

Ref: agilemanifesto.org

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we
have come to value:

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Twelve Principles behind the Agile Manifesto

 Ref: agilemanifesto.org
We follow these principles:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the
customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to
the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals.Give them the environment and support they need, and trust
them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.
Please click here for further detail on Agile Manifesto .

Many developers have lived through the nightmare of a project with no practices to guide it. The lack of effective
practices leads to unpredictability, repeated error, and wasted effort. Customers are disappointed by slipping
schedules, growing budgets, and poor quality. Developers are disheartened by working ever-longer hours to
produce ever-poorer software.

DSDM
The DSDM (Dynamic Software Development Method) was developed to fill in some of the gaps in the RAD
method by providing a framework which takes into account the entire development cycle. The main features of the
DSDM method are as follows:

1. User involvement
2. Iterative and incremental development
3. Increased delivery frequency
4. Integrated tests at each phase
5. The acceptance of delivered products depends directly on fulfilling requirements.

FDD
 FDD is a wrapper methodology, in that it allows you to apply a method to manage projects at a very high level, but
it still allows you to use other methodologies at a lower level. FDD's focus is on being able to set estimates and
schedules and to report on the status of a project as a whole, or at a very granular level, but it doesn't prescribe a
specific method to apply in order to create the schedule, leaving that up to you to decide. The idea is that you can
look at your project and state with some certainty what the project status is, whether you are on time, slipping,
early and so on.

Lean
Lean Thinking is a way of approaching system optimization focusing on reducing waste and improving overall flow
of value through a system. Lean has a rich history in manufacturing and has gained popularity in software
development circles in recent years.

Lean comes from Lean Manufacturing and is a set of principles for achieving quality, speed & customer alignment.
There are 7 Principles of Lean Software Development:

1. Eliminate Waste
2. Build Quality In
3. Create Knowledge
4. Defer Commitment
5. Deliver Fast
6. Respect People
7. Optimize the Whole
Applying these principles to the work of delivering a software product is not an end goal. One is not said to "Do
Lean"; rather one uses Lean principles to guide decision making and to choose techniques that will improve a
system overall. For example, the practice of TDD (Test-Driven Development) builds integrity in to software by
inspecting it at the point of creation, thus supporting the Lean principle of building integrity in during the creation
process.

Plan
In Plan driven development a project is successful if it goes according to plan, so in software development it
depends on requirements stability, on having clear and fixed requirements. As you probably know, that is a luxury
most software projects don’t have.

The plan-driven methodologies, it is less costly to change requirements during the design stage and it is more
expensive to adapt to changes when construction has already started. So,lot of energy is put into the planning
phase.But software development is different. There is no guarantee that a good design will make construction
predictable.

"Walking on water and developing software from a specification are easy if both are
frozen."- Edward V. Berard

The Agile approach is to break the dependency on requirements stability and come up with a process that takes
into account changes. It does that by using Adaptive Planning and Evolutionary Design.

Adaptive planning implies going through the project cycle many times, re-planning and re-adapting often.

Evolutionary design can be achieved with the help of practices like Self Testing Code, Continuous Integration,
Refactoring and Simple Design.

One is value-driven (agile) and another is plan-driven (traditional). This is not to say that plan-driven approaches
have no values; it is to say that in agile, we make them explicit and discuss them often.

Both agile and plan-driven approaches have situation-dependent shortcomings that, if not addressed, can lead to
project failure. The challenge is to balance the two approaches to take advantage of their strengths in a given
situation while compensating for their weaknesses.
 Plan vs. Agile
Fundamental difference between Plan driven development and Agile driven development lies between two
significant differences. First one in the Plan driven model the team will deploy one increment of software at the
end of the project. But in Agile we will deploy very small change of the software or more frequently. The second
one is sequential verses concurrent activity. In Plan driven development one process starts after successful
completion of another. But in Agile we plan all the time.

“Plan your work, then work your Plan” by Martin Fowler and Neal Ford

 Both provide processes, tools and techniques

 Both require disciplined approach to software development
 Each has strengths and weaknesses
 Agile methodologies address many situations for which Plan-driven methodologies are not well suited
 Agile is still a disciplined approach to software development but with an emphasis on different aspects of
the process!
 Plan driven emphasizes formal communications and control
 Agile emphasizes continual communications and ability to changes and uncertainty
 Highly iterative to achieve quality over Lots of gates to control quality
 Inspect work as it is being done over Inspect product when it is complete
 Start with a goal of filling a need over Start by predicting what will be delivered

Ability to changes
Visibility
Customer satisfaction by rapid, continuous delivery of useful software.
People and interactions are emphasized rather than process and tools. Customers, developers and testers
constantly interact with each other.
Working software is delivered frequently (weeks rather than months).
Face-to-face conversation is the best form of communication.
Close, daily cooperation between business people and developers.
Continuous attention to technical excellence and good design.
Regular adaptation to changing circumstances.
Even late changes in requirements are welcomed

Management teams that work well with Plan-driven approaches also tend to work well with Agile
approaches
However, management teams that lack the ability to work well with Plan-driven approaches may lack the
focus required of Agile

Agile
The principles and values of agile software development were formed as a way to help teams to break the cycle of
process inflation and mainly focus on simple techniques for achieving their goals. The GOAL ?? What is the the
GOAL?

OK, the main goal of every software developer and every development team is to deliver the highest possible
value to employers and customers. Yet our projects fail, or fail to deliver value.

The key is in the Agile technique compressing the five sequences of the conventional software development
method - called the Waterfall method - to a one-week cycle. It manages to do this by developing a system through
repeated cycles (iterative) and in smaller portions (incremental), allowing developers to test and review during
development. Speed, lower cost and flexibility are key benefits.

"Adoption rates among IT departments are accelerating," says Phil Murphy, vice president and research director at
Forrester in a 2011 report.
The participants in an agile process are not afraid of change. They view changes to the requirements as good
things, because those changes mean that the team has learned more about what it will take to satisfy the
customer. Agile team members work together on all aspects of the project. Each member is allowed input into the
whole. No single team member is solely responsible for the architecture or the requirements or the tests. The
team shares those responsibilities, and each team member has influence over them.

There are many agile processes : SCRUM, Crystal, Behavior-Driven Development (BDD), Test-Driven
Development (TDD), Feature-Driven Development (FDD), Adaptive Software Development (ADP), Extreme
Programming (XP) and more... However, the vast majority of successful agile teams have drawn from all these
processes to tune their own particular flavor of agility. These adaptations appear to be come together with the
combination of SCRUM and XP, in which SCRUM practices are used to manage multiple teams that use XP.

Extreme Programming (XP)

As developers we need to remember that XP is not the only game in town.- Pete McBreen

Extreme Programming emphasizes teamwork. Managers, customers, and developers.It improves a software
project in five essential ways; communication, simplicity, feedback, respect, and courage.

So according to Wiki definition "Extreme Programming (XP) is a software development methodology which is
intended to improve software quality and responsiveness to changing customer requirements. As a type of agile
software development, it advocates frequent "releases" in short development cycles, which is intended to improve
productivity and introduce checkpoints where new customer requirements can be adopted."

Extreme Programming is a set of simple and concrete practices that combine into an agile development process.
XP is a good general-purpose method for developing software. Many project teams will be able to adopt it as is.
 Many others will be able to adapt it by adding or modifying
practices.

 The ancestor of most Agile methodologies

 Kent Beck created quite a buzz in the late 1990s and early 2000s
 Blends processes and practices

Kent Beck’s basic idea

 Take observed effective team practices
 Push them to extreme level
What does that mean "Push them to extreme level"? Is that mean something like the following images ??

OR

No, that doesn't mean XP. Lets us see what does that mean.

XP is a set of practices that conform to the values and principles of Agile. XP is a discrete method, whereas Agile
is a classification. There are many Agile methods, XP is just one of them.

Having said that, none of the other Agile methods are as well defined, or as broad in scope as XP. Scrum, for
example, is roughly equivalent to XP’s Planning game practice, with elements of Whole Team. While there are
 differences in the details, it is fair to say that Scrum is a subset of XP. Indeed, many Scrum teams augment their
process by adding in many of the XP practices such as Acceptance Testing, Pair Programming, Continuous
Integration, and especially Test Driven Development.

Of all the Agile methods, XP is the only method that provides deep and profound disciplines for the way
developers do their daily work. Of those disciplines, Test Driven Development is the most revolutionary. Following
are some good XP practices. I will try to write detail on each next time.

Scrum
Scrum is an iterative and incremental agile software development framework for managing software projects and
product or application development. Its focus is on "a flexible, holistic product development strategy where a
development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach“.
Scrum asks why does it take so long, and so much effort to do stuff? And why do we are we so bad at figuring out
how long and how much effort things will take? Scrum embraces uncertainty and creativity. Because that is how
people work. It places a structure around the learning process, enabling teams to assess both what they’ve
created, and just as importantly, how they created it.

 Scrum was first defined as "a flexible, holistic product development strategy in 1986 by Hirotaka Takeuchi
and Ikujiro Nonaka.
 In 1995, Sutherland and Schwaber jointly presented a paper describing the Scrum methodology. First
public presentation.
 Scrum Roles
There are three core roles for producing the product.

1. Product Owner
2. Development Team
3. ScrumMaster
4. Stakeholders
5. Managers

Product Owner

 The Product Owner represents the stakeholders and is the voice of the customer.
 Accountable for ensuring value to the business.
 Writes (or the team) customer-centric items (user stories), prioritizes them, and adds them to the product
backlog.
 Scrum teams should have one, may also be a member of the development team
 Not be combined with that of the ScrumMaster.

Development Team
 Responsible for delivering potentially shippable product increments at the end of each Sprint.
 Made up of 3–9 people with cross-functional skills who do the actual work (analyze, design, develop, test,
technical communication, document, etc.).
 Self-organizing, even though they may interface with project management organizations (PMOs).

ScrumMaster

 Accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables.
 Is not the team leader, but acts as a buffer between the team and any distracting influences.
 Ensures that the Scrum process is used as intended.
 Enforcer of rules. Protector of the team and keep it focused on the tasks at hand.
 Also been referred to as a servant-leader to reinforce these dual perspectives.
 Differs from a Project Manager in that the latter may have people management responsibilities unrelated
to the role of ScrumMaster.
 Excludes any such additional people responsibilities.

Backlog
The product backlog is an ordered list of "requirements" that is maintained for a product. It consists of features,
bug fixes, non-functional requirements, etc. - whatever needs to be done in order to successfully deliver a working
software system. In Scrum, it is not required to start a project with a lengthy, upfront effort to document all
requirements. This agile product backlog is almost always more than enough for a first sprint. The Scrum product
backlog is then allowed to grow and change as more is learned about the product and its customers
The sprint backlog is the list of work the Development Team must address during the next sprint. The list is
derived by selecting stories/features from the top of the product backlog until the Development Team feels it has
enough work to fill the sprint. This is done by the Development Team asking "Can we also do this?" and adding
stories/features to the sprint backlog.

Conceptually, the team starts at the top of the prioritized Scrum backlog and draws a line after the lowest of the
high-priority items they feel they can complete. In practice, it is not unusual to see a team select, for example, the
top five items and then two items from lower on the list that are associated with the initial five.

Agile Development Survey

The survey was conducted between August 9th and November 1, 2012. Sponsored by VersionOne, The survey
polled 4,048 individuals from various channels in the software development communities. The data was analyzed
and prepared into a summary report by Analysis.Net Research, an independent survey consultancy.

Who Knows Agile ?

Cause Of Agile Failure

Barriers to Further Agile Adoption

Greatest Concerns about adopting Agile

Conclusion
A good agile team picks and chooses the management & technical practices that best work for them.When trying
to adopt Agile practices, there will be a ton of excuses as why it won’t work. Those who understand the real
benefits of the approach – and genuinely want to make the transition – will likely have success. Those who are
searching for reasons why it will fail – well, they will likely find them and either abandon the effort entirely or end
up practicing what Elisabeth Hendrickson calls “fake agile.”
In support of this conclusion, let me leave you with some words (Collected from Robert C. Martin):
"In preparing for battle I have always found that plans are useless, but planning is indispensable." -
General Dwight David Eisenhower
It is better not to fixate on any given methodology, because the needs/conditions of the company and project are
likely to change regularly, and you need to be flexible in how you approach managing projects if you want them to
be successful. No single methodology is a silver bullet , so the trick is to determine which methods
work for you and tune your methodology to suit your individual needs. This is what being "Agile" is fundamentally
about.

Not Agile. It’s important to remember that Scrum and Agile methodology are not a one-time look at a companies
process, it’s an on-going philosophy based on continuous improvement.