Introduction
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.