Accomplishing an IT project successfully is not an easy task. There are plenty of objective and subjective reasons why a project might fail. When the project fails, it is no longer important whose fault was it. It counts that lots of efforts, time and money were spent in vain. Both sides are dissatisfied in this case. The situation when the customer is partially guilty of the failure hardly ever happens, but anyway the situation results in the customer loss. This is what the law “the customer is always right” is about. It means that the customer no matter what kind of customer he is has the right to get the result that he has been expecting. So, we should organize the development process in the way leading to the successful project accomplishment.

Attitude to the mistakes

To err is human. We all sometimes make mistakes and it is natural. The one who does not do anything does not make mistakes, but isn’t it his biggest mistake. That is why we have the following attitude to the mistakes: if a team member makes a mistake, nobody will punish him, we will analyze it, and we will work out a solution allowing us to avoid such mistakes in the future. All the team members will be informed of the solution. And only in the case when a team member keeps making same mistakes, then some punishment will take place. It is important to make a person speak about his mistakes without being afraid; this will allow others to avoid such mistakes in the future. In general, this is how our development process has been created. So, we dare say that our development process is a sequence of operations, that was experimentally found and it considerably increases likeliness of a successful project accomplishment. Our conception is also theory-based, the whole process is based on Agile-methodologies, which are very popular nowadays.

Project success evaluation criteria:

Evaluation of the results is usually subjective. Nevertheless, there is a number of parameters that help define a project success or failure and understand if the sides are satisfied with the results. They are the following:

1. Project deadline
2. Cost
3. A number of implemented requirements
4. Quality of implemented features.

The order the parameters are ranged does not show the degree of their importance. Moreover, the degree of their importance will vary for every particular project.

There are projects when the most important factors are the strict deadline and best quality of implemented features, and the customer agrees to reduce requirements to meet the deadline and the budget. Sometimes, on the contrary, it is important to implement all the requirements fully and precisely, besides during the project implementation there might appear many additional requirements, but the deadline is not so strict unlike the first example, the deadline can be postponed. The second example is typical for so-called start-ups.
Software development process

This article will describe software development process organized in the way to make the achieved result meet the customer’s expectations at most. It will also describe a process for small projects. Small projects imply the team size up to 7-8 people. There is a special reason why the article is devoted to this particular type of projects. Larger projects normally do not make anybody wonder why we should follow certain development technology to accomplish the project successfully, because it is obvious. But at small size projects, and especially smaller projects we are often asked why the manager, some roles or processes are necessary when there are only one or two developers working on them. It is a common belief among most customers and even developers that it is enough to assign a task for a developer to merely implement it. But in reality such project is more likely to fail than be accomplished. This article is aimed for explaining the necessity and essence of software development process at small and medium size projects.

Roles in the team

Mentioned above there are project success criteria. It often happens that it is difficult to meet all the four criteria at once. It is necessary to look for a compromise solution making all the criteria reach acceptable value.

Let’s consider the following example: there is a project estimated as three man-months. But it has to be accomplished two months after the start. Possible solutions depend on other criteria. If the customer’s budget allows it is possible to add two more developers. Two developers are necessary, because deadline reduction is in logarithmic interdependence with additional developers number, since there might be overhead expenses on developers’ interaction. A third developer may be hired for just a phase of the project to meet the deadline. If the customer is ready to postpone the deadline, one developer might remain to implement the project in the estimated time. If the customer cannot postpone the deadline, besides his budget is limited, then the project can be implemented only in case that secondary, non-crucial requirements are left out.

The given example shows that certain decisions that will influence the above mentioned criteria should be made throughout the project. If the developer is responsible for all the four criteria, then as rule the project fails. It often happens so, because a person cannot adequately evaluate the decisions made.

A good professional might think that he is able to cope with the task alone without any help. Not every person can notice in time the fact that he needs a helper, especially when he performs familiar kind of work. This may result in deadline break.

There is another example when a developer is concerned about code well-organized and well-extended, he will spend too much time refactoring. Paying much attention to the code quality is good, but only when it corresponds to the current task. This may influence budget and deadline.

One more example: a developer is an expert in two technologies, but because of some reasons he prefers one of them. It is highly probable that starting a new project he will choose the technology according to his personal preference if he is allowed such choice, but he will leave out its appropriateness. This may affect the project budget.

One could avoid such problems if two roles were separate: one employee would be responsible for the deadline and budget, the other one for the implementation quality. The team member in charge of the deadline and the budget is the Project Manager. Strictly speaking, the Project Manager is responsible for the project on the whole. It is implied that the manager controls the work quality and requirements implementation by means of other two parameters, the budget and deadline.

The manager’s vote is decisive while making decisions. We are going to describe manager’s quality control and requirements implementation procedure in the following articles.

The Project Manager is free from ambitions of a developer, that is why he can easily make a decision of adding one developer to the project team. He is concerned about the deadline, that is why he will not do unnecessary refactoring. He is concerned about the budget, that is why he is motivated to consider all the possible opportunities and choose the best technology. On the other hand, the developer is concerned about the quality, that is why he will explain the manager why certain refactoring should be done and certain technology should be chosen. Eventually, the decisions will be more considered and well-grounded.

That is why even if there is only one programmer working on the project we will assign a project manager. All the issues that might influence the deadline and the budget should be discussed with him only.

To monitor the requirements implementation, the first thing that should be done is to make the requirements available to all the project participants. Task tracking systems should be used for that. Task tracking systems allow not only fixing customer’s requirements but also showing each task and developer’s status. xPlanner is a standard tracking system used in our company (http:\\www.xplanner.org).

At a project with 1-2 developers, depending on the project peculiarities, the task acceptance can be done by the customer or the manager or the developers themselves. The fact of the task acceptance should be displayed in the task tracking system. The person who does the acceptance is responsible for changing the task status in the task tracking system. The developers can do customer’s requirements specification themselves. All the details are stored in the task tracking system. At the projects with more than three developers one employee with a special role should be added. This role is called Product Owner in SCRUM methodology. This team member does higher level requirements specification and acceptance tests. The Product Owner is a role that appears in the project because much attention should be paid to units interaction testing, since different units are written by different developers. Additional testers are nevertheless necessary even when there is a Product Owner. The latter is responsible for test plan and test cases development. The test cases will be later used by testers. Developers working on a particular unit usually know their unit requirements, but are slightly aware of other system parts requirements. In general there is no developer aware of total system requirements. The solution to this problem is adding Product Owner Role. So, the Product Owner is a team member who knows the customer’s requirements better than any other team member. At that, developers only have to specify technical details for their particular tasks with the customer.

When the developers have to specify the requirements with the customer, they sometimes forget to inform the testers know about the changes. It is unclear who to inform in case there are several testers. It is good if the developer has fixed the changes in task tracking system, but in case he forgets about it, then nobody of the team will learn about the changes. The situation is out of control. Testers do test cases. In order to check if the test case is still relevant, a tester has to check test case correspondence to test case requirements each time he does testing. These operations are tiresome and lead to large overhead expenses, besides they decrease testing speed. The Product Owner solves this problem.

If we draw an analogy with roles at larger projects, we can say that the Product Owner alone performs the roles of an analyst, a tests designer and a tester.

We currently single out three roles within a project according to their responsibilities:

1. The Developer is in charge of implementation quality.
2. The Project Manager controls the project deadline and budget.
3. The Product Owner does customer’s requirements collection and specification and tasks acceptance according to those requirements.

Further we are going to describe these roles interaction at the project.

Iteration

The whole project is divided into phases (in case the project is small it can be considered to consist of one phase). Each phase consists of several iterations. Iteration is a part of a project, having accomplished it a team receives feedback from the customer. Feedback from the customer is necessary throughout the whole project in order to guarantee the result correspondence to the customer’s requirements. If we step aside from this rule the customer is very likely to be finally disappointed. On the other hand, if the customer changes his requirements every day, the project will never be accomplished because of large overhead expenses on constant requirements changes and re-estimation. We need to find a compromise. Project division into phases is the compromise. On one hand the customer cannot make changes in the current iteration requirements, but on the other hand he can make changes at the end of any iteration.

Operation length can influence customer’s evaluation frequency of the current project state. This is a very important parameter of the whole development process. It is convenient to make iterations length fixed. We recommend you to make it two weeks long, if the project duration is more than two months and one week long in case the project duration is less than two months.

Iteration inside

We are going to describe main steps that the team does during each iteration:

1. Higher level requirements for the following iteration should be confirmed.
2. The following iteration should be planned and approved by the customer.
3. The planned tasks should be realized.
4. Realized tasks should be tested.
5. The result should be shown to the customer.

While organizing works we should keep in mind that the customer and the project team are far away from each other, in different time zones, that is why it is sometimes difficult to quickly solve an issue that might arise. Settling certain points may sometimes take several days.

At the moment when the developers have started realizing tasks of a new iteration, the Product Owner can discuss and specify the requirements for the following iteration with the customer. Doing that, he can also be involved in designing test cases for the defined use cases. If the project is rather small and there are no assigned testers, then enough time should be left for checking the realized tasks by test cases. Besides, if the customer leaves time for writing automatic tests, then the Product Owner can write acceptance tests.

After the requirements for the highest priority tasks have been specified, they are to be estimated. Estimation is a very important part of the software development. Keeping within the deadline and budget depends on preciseness of the estimation. Estimation is done by developers. When they need to clarify some technical details they consult the customer. They consult the Product Owner about higher level requirements. The estimation performed should be approved by all the team members.

This is important, because this makes the developer of a particular task be responsible for the deadline as well even if he did not do the estimation himself. It is normal to spend 10-15% of the estimated time on the estimation itself.

Having estimated enough tasks we can proceed with the next iteration planning. Total hours number for the next iteration should be calculated. This may vary because additional developers can be hired for some phases which should be confirmed by the customer in advance.

After that we should also add hours necessary for communication with the customer between the developers and the following iteration estimation. The time left is divided between the highest priority tasks.

Having planned the iteration, the Project Manager requires the customer for the next iteration confirmation. The customer is also a participant of the development so his opinion is important. It sometimes happens that the customer seeing the estimate, realizes that his requirements are not interpreted correctly, then there is a chance to clear up the misunderstanding before the developers start work, otherwise the customer may suggest another task solution, which will allow to reduce the time or leave this task out in case the price becomes too high for this requirement. The next iteration is not to start until it is confirmed by the customer. The customer needs enough time to look through the estimate, that is why we recommend you to start the following iteration planning at the moment when the current one is half done.

The developers do their particular tasks the rest of the time. The task is considered to be accomplished when it has undergone all the pre-planned tests. We should distinguish two types of tests: acceptance tests and unit tests. Unit tests are done by the developer himself, and acceptance tests are done by the Product Owner. If there has been found a mistake in a certain unit, then we create a task of “deffect” type, and the developer who was responsible for that part starts working on it.

It is important at the end of each iteration to show the customer the result to let him see the working functional personally. This demonstration is done at a special team meeting with the customer participation by means of special software. Such demonstration is aimed at:

* making sure that we understand and realize the requirements correctly, and the customer is satisfied with the quality.
* making all the team members understand what stage the project is at, what is being realized at the moment, what corrections are made by the customer.

Such meeting should be organized on one of the last days of the current iteration.

Conclusion

Main points of software development process used in our company were covered in this article. It is based on our experience in outsource projects. Following the process is impossible without special tools supporting it. Such tools are used in our company as well. They will be described in the following article.

Requirements management process is meant to solve the following tasks:

1. Document customer’s requirements.
There is no need to repeat that all the customer’s requirements should be documented. Depending on the project size specification degree may change. The only fact remains that everything should be documented, discussed in details with the customer and confirmed by him.
2. Achieve requirements comprehension before the realization start.
This will allow reducing risks for the customer to receive something different from what he is expecting.

3. Help to define discrepancies between the requirements and results.
The better the requirements are documented the easier are the results to test. This also reduced the risk of the customer to be disappointed with the result.

4. Define the developers’ obligations.Requirements realization is connected with time and money expenses. The process of the requirements management allows controlling these parameters.

5. Set a two-way requirements tracking control.Within the development process these requirements may vary: some requirements will become more detailed, some requirements will be added, some will be excluded. These changes may influence the project deadline and the budget. That is why it is necessary for both sides to have a real image of the current requirements. Only in this case it is possible to accomplish the project successfully.

6. Manage the changes.The requirements change within the development process. We cannot resist this fact; we just have to manage this process effectively.
In this article we are going to describe the way of requirements management with the help of xPlanner (www.xplanner.org), which is to solve all the tasks mentioned above.

xPlanner is a task tracking system. In our previous articles we described in details main entities that xPlanner maintains, that is why we will only revise some main points that are necessary for the general understanding of this article. xPlanner maintains project division into iterations. Customer’s requirements placed in the xPlanner are called User Story. The task necessary for some User Story realization is called Task. Tasks set is defined by the developer. Every task has its estimation, which means the time planned for its implementation. Summary estimation on all the tasks necessary for User Story realization make estimation for this User Story.

At each particular moment there is only one iteration on which there is development in the process. This iteration is called a current iteration. In each project a fictitious Backlog iteration is created for storing all the User Stories which had not been implemented by the moment of the current iteration implementation. Actually, xPlanner was specially created for the development process based on extreme programming (XP) methodology, but it is also useful if your development process is based on any other Agile methodology, for example SCRUM methodology.

Every User Story has the attributes given below, each influencing the requirements management process:

* Priority is a number varying from 1 to 8 defining the importance degree of this requirement for the customer. 4 is a default value. This value can be understood as “normal” or “neutral”, 1 is the highest priority, 8 is the lowest priority.
* Status is the current state.
* Disposition is a means by which this User Story was added to the current iteration.

Any customer’s requirement is documented as User Story and is always stored in Backlog. You can place new requirements only in Backlog, because the current iteration is already planned and the requirements within the iteration are fixed, so any new requirements can be realized only when the current iteration is accomplished. In the Disposition field the value is set as Planned, which means that the requirement arose in the normal working conditions and is regulated by standard rules of requirements management. Standard rules here mean the rules that are described in this article.

There are two more possible values of this field, they are going to be explained at the end of this article. The Priority field shows the importance degree of a new requirement. Let’s remind that priority field equals 4 by default. The customer can change any requirement priority at any moment. It is important to note that priority change will by no means affect the current iteration and will count only while next iteration planning. There are some practical recommendations as to the User Story size, it should be such that it could be implemented within one iteration. It means that in case during estimation process we realize that the user story is too long we should divide it into smaller parts, fitting one iteration.

It is important to document any ideas that arise during the project since some of them may advantageously differ from similar products. Such ideas usually begin as follows: “it would be good for our program (website) to be able to …“, and they finish like this: “But I am not sure we really need this”. If you do not note them anywhere you will forget some useful ideas, and realize the things you could leave out while excluding useful functionality. Ideas are often forgotten to be included into xPlanner as a User Story because of the only reason – the customers are not sure that they need these requirements to be implemented and are afraid of spending extra time on the estimation and realization in vain. The customers should not worry about these things. xPlanner allows two values in the Status field letting to distinguish requirements that can be estimated and later realized and draft ideas that might later be accepted or rejected. These values are Defined – for the ready for estimation User Stories and Drafted – for draft ideas. So, while next iteration planning the developers will estimate only User Story with “Defined” status. That is why the requirements that are not finally defined in xPlanner do not cause extra expenses.

So, within the next iteration planning developers do only User Stories estimation marked as “Defined” choosing those with the highest priority. On estimation completion User Story is marked as “Estimated”. It is the customer who makes the next step: he will confirm that he agrees to realize the User Story at the done estimation and at the certain cost. It often happens that the customer agrees to realize something provided it will take not more than two hours, but the estimation shows that this functionality can be performed only within 16 hours. That is why the process of estimation confirmation allows the customer to manage the cost and product features within each iteration. For example some small useful features can be implemented within these 16 hours that otherwise would not be realized because of the tight budget. The customer shows his confirmation changing User Story status into “Planned”. Only those User Stories that have “Planned” status count while planning the next iteration. The User Stories which were planned to be implemented in the previous iteration will be transferred from the Backlog into this iteration.

So, within the next iteration planning developers do only User Stories estimation marked as “Defined” choosing those with the highest priority. On estimation completion User Story is marked as “Estimated”. It is the customer who does the next step: he will confirm that he agrees to realize the User Story at the done estimation and at the certain cost. It often happens that the customer agrees to realize something on condition that it will take not more than two hours, but the estimation shows that this functionality can be performed only within 16 hours. That is why the process of estimation confirmation allows the customer to manage the cost and product features within each iteration. For example some very useful small features can be done within these 16 hours that otherwise would not be realized because of the tight budget. The customer shows his confirmation changer User Story status into “Planned”. Only those User Stories having “Planned” status count while planning the next iteration. The User Stories which were planned to implement in the previous iteration will be transferred from the Backlog into this iteration.

Further when the developer takes up the User Story implementation in the current iteration, it has the “Planned” status. Having implemented all the tasks in the User Story, he marks it as “Implemented”. This means that the task is ready to be tested by a tester or the customer’s representative (the Product Owner). Having implemented the testing, if all the tests are passed, the tester and the Product Owner change the status to “Verified”. This is not enough to be sure that the customer’s requirements are implemented. In case the customer’s requirement was not understood correctly, we might get the product perfectly functioning, (that has been realized and tested), but is not what the customer needs. That is why only the customer himself can confirm that his requirement was realized. In case of confirmation by the customer the User Story receives the “Accepted” status, and it means that the requirements within the current iteration have been implemented. It is recommended to organize a team meeting with the customer at the end of every iteration to show the implemented functionality to him, otherwise you can simply send the latest project version to him and ask him to confirm the status. If the customer does the testing himself he can change the status into “Accepted” or “Verified” by himself.

We have described the case when every stage is successfully accomplished. Now let’s consider the situation when for some reason the current stage cannot be implemented, for example tests showed some errors (it is impossible to change the status to “Verified”) or the customer does not approve of the estimation (it is impossible to change the status to “Planned”). In this case the team member (the customer is also considered to be a team member) who found the error should change the status of the User Story to the status that corresponds to the last successful stage of the User Story implementation. Let’s consider some examples illustrating this rule. If the User Story with “Implemented” status does not pass the set of tests, then the tester who found this error changes the status from “Implemented” to “Planned”.

In case the Customer does not agree with the estimation he changes the status of the User Story to “Defined”. If User Story re-estimation shows that it is impossible to implement it during a shorter period, then such User Story changes its status to “Drafted”. It means that the task cannot currently be implemented as it is within the desirable hours’ number; that is why the requirements have to be specified. We should note that the desirable hours’ number and development cost are a part of non-functional requirements. It sometimes happens that some requirement was implemented, tested, but the customer is not satisfied with the result. In this case the status of the particular User Story should be changed to “Drafted”, since the error happened while specifying the requirements.

The examples given above show that the development process of one User Story can be compared with the waterfall model when in case of an error found we have to return to the stage when the error was made. The main difference from the waterfall model is that the User Story is one small requirement implementation of which cannot be compared with the whole project size. That is why in iterative processes risks to receive the wrong result are mush lower than in the case of the waterfall model.

Let us return to the two values of Disposition Field for the User Story, “Added” and “Carried Over”. It should be reminded that at the beginning of the article we mentioned that for almost all the User Stories the value of the field is “Planned”. In some exceptional cases the customer can ask us to change requirements for the current iteration. Then new requirements are added as User Story marked as “Added” in the Disposition field. It is to be understood that if we add new requirements and at the same time the iteration length is fixed then we can do this only excluding some requirements from the current iteration and the development is transferred to the next one. It is for such requirements that we use the value “Carried Over”. We need to take into account that iteration rescheduling causes extra expenses on new User Stories estimation and estimation confirmation by the customer, which influences the total cost of the project.

This article was devoted to such an important constituent part of the development process as requirements management, besides we showed this activity procedure based on xPlanner. The approach described above has been successfully applied by ISS Art ltd for a long period of time. It has had good results and allowed improving the quality of the services provided for our customers.