The International Association of Outsourcing Professionals (IAOP) published the results of the annual rating “The Global Outsourcing 100″. In 2011 four Belarusian IT software development companies appeared in the rating. How have they managed to do it? What is the result of such success?

One of the main reasons is using new effective technologies in the sphere of management, agile being one of them.
Recently agile software development is considered to be panacea for all woes turning any IT project into successful. Many western clients give preference to the companies working with agile.

The main peculiarities of agile are:

•    risk sharing – at present there are two main types of interaction with a client – fixed-priced and time-and-material contracts. In the first case all the risks on the project fall on the contractor, while in the second type the client pays for the actual work, which works little on the final result;
•    predictability – the refusal from long-term planning as well as the absence of figures on schedule and cost of the product in general;
•    regular feedback – the customer can introduce comments and alterations practically from the beginning of the project;
•    easy and quick reaction to changes in functional requirements as well as priorities;
•    selforganization – which allows escaping from the excessive management structure.

Why don’t companies want to switch to Agile?

The first reason is conventionalism: many companies think it’s not a good idea to change the familiar scheme which works and bring profit. The second reason is lack of experience in using the new system and the fear of failure in getting non-achieving immediate results. The third reason is additional resources for creating the working team and supporting its highly productive state.

Thus, in order to minimize the risk one a software development company should ope the ground for implementing Аgile on various levels: management level and development level.  This process can take from 3 to 6 months but the effect in the long term is worth doing it.

February 11 – 13, 2001, can be called the day of The Manifesto for Agile Software Development forthcoming. It declares that from then on people who deal with any software should strive for finding better ways of developing software by doing it and helping others do it.

Through this work we should come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiations
• Responding to changes over following the plan.

This Manifesto hasn’t been recognized as the answer to all problems, but it has given a push to real software development process improvement and elaboration.

The first value statement recognizes the importance of processes and tools but stresses that the interaction of talented individuals is of far more importance. Rigorous methodologies and their business process reengineering brethren place more emphasis on the process itself than people. Agile development reverses this trend. If individuals are unique, then processes should be melded to individuals and teams, not the other way around.

Similarly, while comprehensive documentation is not necessarily harmful, the primary focus must remain on the final product–working software. This means that every project team needs to determine, for itself, what documentation is absolutely essential for delivering working software.
No one can argue that following a plan is a good idea. No matter how carefully a plan is crafted, it becomes dangerous if it blinds you to change. And yet it is successful because the development team can be Agile enough to respond again and again to external changes.

The Agile movement is not anti-methodology; in fact, the authors sought to restore credibility to the concept of methodology. They wanted to restore a balance. They accepted modeling, but not in order to file some diagram in a dusty corporate repository. They accepted documentation, but not hundreds of pages of never-maintained and rarely used tomes. They planned, but recognized the limits of planning in a turbulent environment. Agile Software Development incorporates proven software engineering techniques, but without the overhead of traditional methodologies.

Great designs emerge from zero anticipatory design and continuous refactoring. Thus, we have to understand the limits before we can understand the balance points.
There are three fundamental questions to answer: (1) What kinds of problems does agility solve best? (2) What is agility? and (3) What are Agile Software Development Ecosystems (ASDEs)?

Problems characterized by change, speed, and turbulence are best solved by agility. Some people argue that good practices are good practices (pair programming, customer focus groups, or feature planning, for example) and therefore ASDEs should not be “limited” to a particular problem type. While true in part, the question is what problems Agile practices solve best, not just solve.
Agility is the ability to create as well as to respond to changes in order to profit in a turbulent business environment.

Agile organizations are nimble and flexible. An Agile organization also knows how to balance the structure and flexibility.

In closing, the heart of ASDEs is a core belief in people–their individuality and their interactions. It’s impossible to discuss people and their ways of working together (ecosystem) without discussing values and principles. It’s impossible to discuss values and principles without also discussing assumptions about how organizations work, or should, work. It’s impossible to compare Agile approaches with non-Agile approaches using a “methodology” as the only mechanism for comparison.

Many times you and I have heard about advantages of Agile development techniques and drawbacks of traditional “hard” techniques like RUP, MSF and so on. I think, sometimes we are mixing them up.

A lot of software engineers, project architects and even PMs prefer the Agile approach because of the anarchy it allows in the outsourcing development. I mean the absence of specifications (even when they are really needed), merge of project roles and responsibilities (when no one can say who is responsible for low quality level and specification), and the sacred belief in users’ stories without any additional analysis of business goals. The situation can become worse if a customer hasn’t got a clear vision what he wants to get at the end of the project, if the requirements weren’t completely described and verified by him and finally they were implemented according to the developers’ point of view. Most probably the client’s expectations will not be satisfied, and it will lead to hours of overtime, release date shifting and other symptoms of an unsuccessful project.

In addition, unskilled key project persons frequently use this fashionable term to clear themselves when they fail, the project deadline is out-of-date and the customer is not satisfied. They say “We create software using modern flexible approaches, we don’t need all these hundreds of specifications and process descriptions! This is Agile, baby, so relax!”, but usually they forget one important thing.

Agile practice is not the universal magic wand that allows you to make any project no matter if it’s low-sized or estimated in 10 thousand man*days, with minimum of documentation, absence of project roadmap, detailed architecture and so on. Of course, it could be so in small/medium projects and on the assumption of all project-members already have agile experience and the Project Manager keeps all working activities and plans in his head. But you have to keep in mind that it’s rather risky to rely on this.

I strongly believe that Agile development process should be used only by highly-experienced web developers – because they already know the weak points of this methodology and they will not addle with the seeming simplicity and easiness of this approach.

Extreme Programming (XP) is a Methodology (software engineering) for the development of software projects. It prescribes a set of day-to-day Extreme_Programming Practices for developers and managers; the practices are meant to embody and encourage particular Extreme_Programming Values . Proponents believe that exercising these practices, which are software engineering best practices taken to “extreme” levels, leads to a development process with the qualities prized by Agile Manifesto signatories. This makes Extreme Programming the most prominent of several agile software development methodologies used to create software. Agile methodologies prioritize adaptability for changing requirements over the project predictability valued by more traditional methodologies. Some elements of the Extreme Programming methodology are Extreme Programming Controversial aspects.

Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

In Extreme Programming, every contributor to the project is an integral part of the “Whole Team”. The team forms around a business representative called “the Customer”, who sits with the team and works with them daily.
Extreme Programming teams use a simple form of planning and tracking to decide what should be done next and to predict when the project will be done. Focused on business process value, the team produces the software in a series of small fully-integrated releases that pass all the tests the Customer has defined.

Extreme Programmers work together in pairs and as a group, with the simple design and the obsessively tested code, improving the design continually to keep it always just right for the current needs.

The XP Programming team keeps the system integrated and running all the time. The programmers write all production code in pairs, and all work together all the time. They code in a consistent style so that everyone can understand and improve all the code as needed.

The XP Programming team shares a common and simple picture of what the system looks like. Everyone works at a pace that can be sustained indefinitely.

The Heads of all IT outsourcing enterprises understand that to be competitive in the computer programming market one has to deal with software development methodologies. Here comes the question:

• What is a software development methodology?
• What for do we need to use software development methodologies?

A software development methodology is a complex of processes, rules and procedures executed by a development team and the whole outsourcing enterprise employees to achieve the main goal of web development: high-quality software.

Here are the benefits of using software development methodologies:

• Number of defects is reduced;
• The project is ready in less time;
• Improves created software quality.

And now it’s time to tell what software development methodologies exist. I guess the best way not to waste time of the web developers (and all other readers of the following article) and list only up to date methodologies. They can be divided into two groups:

• Engineering methodologies (plan-driven methodologies is another name of the group)
• Agile methodologies

Engineering methodologies

The core of these methodologies is software production based on non changing specification. Rational Unified Process (RUP) is the most often used engineering methodology .

Agile methodologies
The main core of the agile software development is in adapting the process of product construction throughout its life cycle. During agile software development the project can be easily adjusted to custom changes throughout its development.
Extreme Programming (XP programming) and Scrum are the most often used methods of agile development.

As a conclusion I have to admit that that it’s up to you to decide whether invent a new software development methodology or use an existing one. But there is no doubt that a software development methodology should be used.

It’s difficult to find a person engaged in creating software business who has never heard about Scrum. Scrum is an agile software development methodology widely used all over the world. A scrum process is divided into 3 phrases:
1. Planning (a web developer learns about custom preferences to the project);
2. Sprint cycle: a phrase when the web development is done. This phrase begins with scrum meeting, where the feature that will be developed is chosen. The sprint cycle will take place until all features of the project are implemented.
3. Closure: on this phrase the product is delivered to the customer.

So that not to lack behind the times and have Agile, high – quality software, use agile management and Scrum as a means of it!

Nowadays software testing is a rapidly growing up sphere. And software testing engineers may be found employed in different sectors. Lots of methodologies are widely known:
-Agile testing;
-Extreme testing;
-Scrum testing;
-White Box testing;
-Traditional Black Box testing and others.

The Black Box testing is the most popular and called for in many companies around the world. For years experts had been developing different costly commercial tools to lessen testing efforts and to increase the efficiency and quality of software testing, but lots of them were nonviable in practice. Later in 2001, some testing experts offered to create the software utilities for their manual-and tool-automated testing efforts.

And today at every seminar or training there are courses and lectures teaching testers more technical topics, including programming, networking, and databases. In the past and certainly today quick, efficient and profitable testing is in great demand. One of the ways to reach these goals is using .NET application software for testing projects. Although .NET languages are powerful enough to accomplish some useful testing tasks, testers and developers must have enough knowledge to write the code.

But first of all let’s discuss the automated software testing in general. At the beginning let’s look at some of the important management issues involved when starting automated testing, like guidelines for when and when not to automate testing, what kind of personnel requirements are needed to address and how to build an automated testing team. In later articles we will discuss the advantages and disadvantages of using two .NET languages, Visual Basic (VB) .NET and C#, for test projects and utilities.

Unfortunately there isn’t enough information out there yet to help test experts to use programming for testing purposes. Most of the publications are geared for software developers, not testers. Using .NET languages for testing requires a shift in the future. A tester may go to different courses, trainings (for example, standard Visual Basic course) to wonder how it could ever be used on a test project. These trainings and a lot of articles, books explain just how to use the controls and the ways to create a great application with user friendly interface. But the tester doesn’t care about that so much— actually he wants to know how to get to the system information and other testing-related data using code or how quickly develop a utility. But the reality is the following – a tester must know how to use .NET languages as soon as possible on a test project:
– How to get access to the DB easily and quickly;
– How to get access to the Windows Registry to return distinctive application data;
– How to create a front end with basic controls to view test information and results as soon as possible
– How to get access to the appropriate .NET Framework library functions that return relevant information about the platform, files, registry, operating system, and so on.

These questions are just the beginning, but they reflect some of the things the testers have used to accomplish their testing tasks.

Why are.Net languages a good choice for testing? Actually .NET languages are not testing tools. They are a set of languages used for developing software. And it’s required to answer why it is better to use C#, Visual basic to reach testing goals instead of C, Java, Perl and PHP.

Scripting languages (for example Python, Perl, Rexx, VBScript and others) have a large group of supporters. Why not use those? As an actual fact none of those scripting languages were invented with testing in mind. These languages can be a good advantage for testing software, particularly if they are already installed and a tester has quite good experience. But if there are testing engineers with skills in .NET languages, so they will be a great choice. Also if the application is being written in any of .NET programming languages, in that case it may be a reason for the testing engineers to use it for automation software testing. But it’s not absolutely required to use .Net languages for automation of .NET applications. It’s a delusion.
But for Windows platform it’s a perfect choice that will give the power to do whatever you need. The Framework libraries have a lot of things to provide the successful automation testing. For example, .NET programming can be used for a lot of hidden applications’ operations testing. Scripts can be developed to get access to the system environmental variables and performance counters. Automated scripts can check the correct loading and retrieval of the data from files. It’s obvious that the .NET programming languages are powerful development tools makes them showing promise of future success and able tools for software testing. So it’s very important for test engineers to study .NET languages and to begin use them in everyday working practice.

Agile web development is a model for developing web applications. Its concept is similar to Agile software development, but is limited to web applications. It is more efficient and powerful within a short timeline than other models; it incorporates face-to-face communication and includes technical personnel as well as customers as part of the team. Agile web development is used by project managers, business analysts, it is based on clear goals, planning, and iterative delivery. Agile web development ensures the successful completion of the product at the end of each iteration.

The agile web development model follows the stages of planning, requirement analysis, designing, coding, testing, and documentation developing parallel. Successful interaction reaches toward to successful completion of application because of customer involvement hence we never met with the condition where we have to change the product due to changes in requirements, correct decision has to be taken by keeping customers confidence and informed choice, minimizing delays of the product. All the tasks are performed within the given period, with just enough documentation to be effective.

• Small time line.
• Refined Team.
• Clear planning.
• Short Documentation.

Due to the regular involvement and feedback from the customer, the software tends to be more error free, more requirement oriented, and more user friendly. Also, such tasks as planning, development, design, coding, testing, etc. are performed simultaneously, driven by the customer’s demands. It also reduces the development cycle time. The application documentation is less formal, to reduce the time taken and to be more human friendly.

Agile methodology is similar to the iterative, RAD Prototype model, but it has its own principles of developing a web application and it has introduced the concepts that overcome the problems associated with the existing models.

For instance, the waterfall model frequently changes the requirements during the development life cycle, which means it fails whenever the requirements are changed at the end or not properly understood or implemented according to the customer’s current feedback. In the iterative incremental model, the development process moves according to the iterations. Requirements and business process analysis, designing, and functional modification must be added to each version or iteration of the system to satisfy the customer’s feedback, and at last it is integrated into the system. Agile development adopted the key points from an iterative model but differs from the iterative one in relation to the timeboxes. An agile development life cycle pays attention to a shorter time duration for completing the IT project. With the help of timeboxes, developers can easily estimate the problem and correct it within the given time, so that at the end of each iteration, it is modified.

Companies are moving towards Agile as it results in more Customer Satisfaction and hence there business.