Rus
Contact Us
Задать вопрос

How we work

Mutual understanding between the customer and the developer is the key to the success of the project. Therefore, this page describes in detail how we work at each stage of the software life cycle

Full cycle: from idea to support in operation

To create a software product is difficult. Development is often compared to building a house. It is possible, but there is no guarantee that the walls will not crack in a year, and the roof will not fall. Is it possible to save on finishing? You can, but will have to live in a concrete box. What about finding cheaper builders? In this case, it is not surprising that the walls will be uneven and the wiring poses fire hazard.

Therefore, the construction of buildings is a regulated process that requires compliance. Man erects buildings for thousands of years, and our industry is not even a hundred. Despite its youth, the industry has developed an understanding of which actions increase the likelihood of a project’s success, and which, on the contrary, more often lead to a fiasco.

We use those techniques and processes that we tested ourselves in practice, and we were convinced by our own experience in the effectiveness of them. And we learn from mistakes and do not repeat them. If there are too many conflicting requirements in the initial conditions of the project, we may be forced to abandon the implementation. The success of the project is determined not only by the initial conditions. Attention is required at each stage:

  1. idea and consultation
  2. clarification of requirements, analytics
  3. preliminary assessment
  4. designing
  5. clarification of the assessment
  6. flexible development, work with changing requirements
  7. access to production
  8. revision and development of the project, release of new versions
  9. stabilization, support

Idea and consultation

At this stage, the client has an idea to put a new digital product on the market, to automate routine operations or to introduce end-to-end analytics. At this point, it is important to clearly understand the purpose of the project and how to achieve the goal. If there is no clear goal, it is impossible to assess the success of the project, so we suggest setting SMART goals.

The client often comes with a well-formed vision of achieving the goal. It is important to check whether the vision is fully or partially in order, if there are easier or faster ways to achieve the goal.

The designers of the F16 aircraft set a goal to develop an aircraft that is ahead of the speed of the ‘Sukhoi’. To create such an aircraft at that time was extremely difficult and expensive. In fact, it was necessary that the fighters "could safely leave the scene of hostilities in the event of the appearance of the enemy." The designer suggested replacing the “speed” parameter with “maneuverability”. So the goal was reached within the desired time limit and with a much smaller budget.

Clarification of requirements, analytics

Once the goal is set, it's time to clarify the requirements, the scope of the project and the means to achieve the goal. Usually this stage is called "writing a specification". Our experience suggests that a specification is outdated before the approval date and often conflicts with the objectives of the project. Development is 1001 parts, so writing a consistent specification can be more expensive than developing a product.

What if in the process of implementation the goal is no longer relevant or requires adjustment, and the contract specifies outdated acceptance criteria? We will have to either implement the project on obsolete requirements, or initiate a tedious process of negotiations on changing conditions. The modern world is dynamic and even banks introduce Agile. Therefore, instead of creating a mass of documents characteristic of a «cascade model» (also called a “waterfall”), we use tools for collaborative work in electronic form and interact with the customer on a daily basis.

Instead of a classic specification we use “live specifications”. We fix project goals, conduct Impact Mapping, highlight user stories, draw business processes, and provide test cases.

Live specifications represent information in the form of trees, not text, and evolve with the project. If, in the course of work, the requirements have to be changed,   we will change the impact map and change the priorities.

Preliminary estimate

Estimation is based only on the requirements of the “idea” level or even after drawing up the Impact Mapping is too inaccurate (according to Steve McConel to 400%)) to make commitments. Therefore, the assessment of labor costs is possible only after clarification of requirements. We will need interface prototypes and test cases.

After completion of this stage, you can make a roadmap of the project and make an assessment. Due to the risk of changing requirements, we prefer not to evaluate long-term projects with high accuracy. Evaluation is a complex, long, expensive process, the results of which lose relevance when requirements change, which always happens according to our observations. Therefore, we prefer to split projects into stages and evaluate them one or two steps ahead.

The only way to assess a long-term project in a reasonable time and not to work at a loss is to lay a huge stock and not accept requests for change in the process. As a result of this process, “a product of some kind” is obtained, but it does not fulfill the goals and is very expensive. Therefore, we do not work that way.

Fixed Price T&M

Fixed Price is a contract with a fixed deadline and cost of the project.

We are forced to adhere to a more rigorous project management process. The work will be divided into stages. We will pass the stages strictly sequentially. Changes in requirements in the process of work on the stage are not accepted. They fall into the list of change requests, are evaluated separately and transferred to the next stage. Each stage is accompanied by a formal acceptance and signing of the act.

The fact is that in the case of a Fixed Price contract, most of the risks go to the contractor. If the project’s margins are low, the performer is usually inclined to work with poor quality. We can not afford this, so we work with caution and at a higher rate.

Time and Materials is the best way to solve client's business problems in conditions of impermanence of the world.

The contract involves the payment for the actual working time spent by the contractor, as well as the provision of materials necessary for the development (requirements, information, access). Planning is carried out based on performer’s estimates, taking into account the requirements of the project.

The client receives a transparent process of working on the project and takes an active part in it, exchanging feedback with the contractor on a daily basis.

As a result, a trusting relationship develops between the client and the contractor, and it helps to make the best decisions, both from a business point of view and a technical implementation side.

Agile development

Regardless of the form of the contract, we will use flexible methods of project work: Scrum or Kanban.

The main difference for the client is that in the case of Scrum, a release occurs at the end of the sprint, and in Kanban, updates can get to production immediately after testing. Kanban is better suited for projects at the stage of development and support.

On all projects we automate the assembly and layout of the project, so the code in the repository is always assembled, and the actual version is laid out within a few minutes, just by pressing a button in CI.

Output in production

The software has been developed and soon the first users will begin operation. Unfortunately, this process is not always smooth. The development team is ready to make urgent changes or troubleshooting. We lay the time for the acceptance of the project and its release into commercial operation.

Revision and development of the project, the release of new versions

It is often more profitable to release a product in the minimum configuration and modify it in running mode. After checking on the test bench updates are sent to production. At this stage we set up backups in order to roll back to the previous version in case of faults. To do this, we use a standardized process for working with VCS and updating the database scheme through migrations. If necessary, we set up a “hot update” of combat servers without downtime.

Stabilization and support

When the project's backlog becomes empty, we begin to reduce the development team to the required minimum, or we transfer the project for support to the IT department of the client.

Tools

As you can see, there are enough details. In order not to forget anything and remain efficient, we use the following tools:

  1. git and gitlab for code review and code sharing
  2. YouTrack for project management and client communication, supporting flexible methodologies
  3. team chats in Skype or Telegram for daily communication
  4. GSuite for collaboration with documents and files
  5. Gitlab and TeamCity - CI / CD for automating the assembly and calculations
  6. Rider and R # - code analyzers and tools for refactoring (code improvement) and unit testing
  7. Force - lightweight corporate library to solve typical programming problems that are independent of the subject area
  8. Checklists and guidelines

Since 2012, I have been collecting and verifying information on effective development methods. The criteria were development speed, number of bugs, easiness in maintenance, easiness in learning and involving new team members. The result was our internal documentation in the corporate wiki and articles on Habr.

The most popular of them is Unit Testing for Dummies. Type in Google "how to write tests." The first result is the one. All our employees are trained and adhere to these approaches. This is how we achieve the interchangeability of specialists and high predictability of work results.

Maxim Arshinov
Co-founder of High-Tech Group, CTO