Speak about the “easy” process: the development process in the Larian Studios toolkit department
Passing an interview for the position of development manager in some companies, the author had to listen to the same story during the conversation:
The strangeness of the situation lies in the fact that seemingly intelligent and experienced company executives think about organizing the development process not at the beginning of the project, but only when the recruited team fails. Meanwhile, the process should be thought at the very beginning.
In this article, the author shares the successful experience of organizing the development process in the Larian Studios toolbox department.
Larian Studios is a small company with a staff of just over 100 people developing the Divinity role-playing game series. The company consists of several studios located in different countries. One of the studios is located in St. Petersburg. The games are available for various platforms, including Windows, Linux, Mac OS X, Xbox ONE and PlayStation 4.
')
For game development, the company uses its 3D engine and its integrated development environment. Despite the fact that the engine is ported to different platforms, development is carried out on the Windows platform. This is due to the fact that the development environment is written using WinForms and WPF technologies and works under the control of the .NET Framework.
An integrated development environment is an application within which you can run a game, either as a whole or as a separate game mode or level. We can say that this is a kind of container for launching the game, which is equipped with various tools for creating levels, editing the surface, arranging objects, creating and editing scripts, dialogues between characters, etc. etc.
Despite the fact that the development environment looks impressive, and the multitude of UI elements provides access to extensive functionality, however, its usability leaves much to be desired both due to the congestion of the interface itself and because its individual parts are not consistent together. This is the main problem.
The basic requirements for the tool can be expressed in 3 conditions:
Tools are developed for internal customers. These include all those people who directly make the game. These are visual effects designers, 3D animators, game designers, and scripters, etc. etc.
The tool development department is small. Its composition is:
To organize the work of the department, you must put the development process. Delivered process will help to deliver projects on time and with a given quality. Since the team is small and everyone knows each other, we are not using ponderous and regulated by all sorts of rules, but an easy development process. Many things in it are not formalized, and others are based on verbal agreements. However, there are clearly structured things that I want to tell about.
The development process in the toolkit can be divided into 4 stages:
Work on a new tool begins with the development of a concept. This is done by our internal customers such as visual effects designers, 3D animators, game scripters, etc.
The process of creating a concept consists of several stages:
During planning, it is important for the team to do three things:
At this step, it is important to understand what the alpha version of the product will be. In our case, the alpha version is the version of the program that is obtained at the end of the third stage - development, which we will discuss in more detail below. The alpha version may include far from all the requirements that Customers have formulated in the concept, but only a certain subset. Why?
The fact is that the concept includes many "Wishlist" of Customers. Some of them are not tested by practice, and may not be useful in reality. And, on the contrary, it may be necessary to implement something else that the Customers did not think about when they wrote the concept.
Therefore, we try to ensure that Customers start using our program as quickly as possible. Let not in the working, but at least test mode. Only real experience of use can show which requirements are important and which ones are insignificant.
To achieve this goal, we are trying to understand what the minimum working version should include. And from all the requirements - in coordination with the Customers - we select only those, the implementation of which is really impossible to do.
The minimum working version is the alpha version. At its release ends the development phase.
After our Customers begin to use our program, bugs and various rough edges are revealed. In addition, the experience of using appears first in test conditions, and then in “combat” conditions. This experience allows us to assess the remaining requirements: which of them are important and which ones are insignificant.
We eliminate roughness, implement revalued requirements and fix bugs at the maintenance stage.
To make a project plan, you need:
In my opinion, there are two types of project evaluation:
The preliminary estimate is rather rough. It uses simplified decomposition, but for this reason it does not require too much time.
Detailed evaluation is more accurate. But in order to get it, you must perform the design and make the decomposition of the work.
To save time, we make a rough assessment of the project. However, using the “coarse models” you can get an accurate result. How do we achieve this? For project evaluation, instead of one model, we use three:
The functional model represents the program being developed as a set of useful functions. It reflects the user's point of view.
The component model represents an application as a set of modules. It reflects the look of the engineer.
A process model is a view of a program as a project that has a certain length in time and consists of a sequence of steps. Each stage has its own tasks (often organizational or managerial) and, as a result, its duration can be estimated as a superposition of the time required to complete each of the tasks. Process model reflects the point of view of the manager.
Being combined, these three points of view represent a comprehensive view of the same product. Some things are better evaluated through functions, some through modules, some through a process. As a result, a balanced score is obtained.
Perhaps in more detail this topic will be disclosed in a separate article.
In order to properly take into account the available resources, you need to understand that no employee spends 100% of his time on completing tasks. Be sure, the programmer will spend some part of his time on communication with colleagues and a little rest.
Of course, if there are only 2 people in a team, and they work with approximately the same productivity, then the waste of time can be neglected and assume that one working man-day is 8 hours. In fact, with this team size, the time to agree on some issues will not be too significant.
However, if the team already has 4 people, then you should consider both the time for communication and the different labor productivity of different people.
In assessing the available resources, we use the following table of labor productivity:
In addition to programming, the lead engineer spends part of his time on planning, assigning tasks, communicating with Customers, introducing new ones, if there are any, and training inexperienced ones. Therefore, we believe that he can spend on programming only half of his time.
An ordinary engineer should work with an 85% productivity. He spends the remaining 15% of his time communicating with the rest of the team, communicating with Customers and writing reports.
As you know, connecting new people to the project at first does not speed up, but slows down the development. This is due to the fact that team members are forced to distract from work to train a new employee. Even for a beginner, labor productivity at first is low: we believe that he spends on training up to half of his working time. Over time, productivity should increase. If it does not grow, then this is a reason to think about the appropriateness of his stay in the team.
An inexperienced beginner is initially forced to spend more time on training than just a beginner. Therefore, the performance of 25% at the very beginning should not look like something scary. However, over time, it should also grow.
Using these figures, you can estimate the actual productivity of the entire team.
Suppose a team consists of 4 people:
Then the performance of the whole team will be equal to:
1 * 50% + 1 * 85% + 1 * 50% + 1 * 25% = 210% = 2.1 man-days
This is two times less than with a simple approach, when it is believed that each person works with a 100% productivity.
When planning you need to distribute the entire work in several stages. Each stage ends with Mylustone. Milestone is a point in time when the results of the work done are evaluated.
When planning for the Mylustones, it is necessary to solve two problems. First, you need to distribute user requirements across milestones. Secondly, it is necessary to estimate the duration of each milestone. At the same time, it is important to ensure that the duration of the Milestone was approximately the same.
To distribute work across Milesstones, we use several criteria:
In order for the project to progress successfully, it is necessary to think about how communication within the team will be built between individual developers, as well as between the team and Customers.
We in our company use several practices that turned out to be - in our case! - very successful.
When starting a new project, we create a project space in the “cloud”. We use Google Drive as cloud storage. But you can use other services: Yandex Disk, Mail.Ru, One Drive from Microsoft, and others.
If privacy requirements or personal preferences do not allow using a cloud service, you can install Sharepoint on a local server, or use a version control system like svn, git or perforce, or create a project folder on a regular file server. Options - from simple to exotic - weight.
A single project space allows you to concentrate all the documents related to the project in one place. And the use of the “cloud” allows you to open access to all members of the team: everyone from your workplace.
What is the project space? This is a regular folder in the cloud storage, to which access rights are configured. Inside it contains other folders, each of which concentrates the documents related to a particular discipline.
For example, in our case, the project folder usually contains 4 such subfolders:
The contact list is a document that contains the names of all people connected in one way or another to the project, as well as ways to contact them: phones, email addresses, Skype accounts, etc.
The contact list allows you to quickly find the right person. Managers who neglect the creation of such a list, then waste their time and nerves to find a leading programmer, designer or engineer for quality in any emergency.
The list of contacts is best done in the form of approximately the following table:
Every day our small team (4 programmers and 1 QA-engineer) gathers for a short meeting to discuss the current progress of the project. Typically, such a meeting takes 10 to 15 minutes and allows all team members to stay informed.
The meeting format for a long time remains unchanged and consists of three parts:
In the first part, the project manager (or the lead programmer who performs managerial functions) informs the team about any news related to the project. These could be some managerial decisions of the project curators, requests from internal customers, positive or negative feedback on the application being developed or on the team’s work.
Then comes the turn of the reports. At this stage, each team member reports on his work by answering the following three questions:
This report format allows the project manager (or the lead engineer who performs part of the managerial functions) to be aware of how the project is moving and what progress the team has made. And since each team member should tell about the task he is working on at the moment and identify the existing problems, this helps other team members to learn in time about the dependencies between their task and their colleague's task and, if necessary, to resolve these dependencies by adjusting their actions. .
Another plus of public reports is that the work of each team member is in sight. Unable to hide the lack of results. This is an additional stimulating factor for both the person who failed to advance in his task, and for the team: someone can give a hint or offer to take part of the work on the task.
After the reports comes the turn of the discussion. If there are any problems, they are briefly discussed and approaches are developed to solve them.
The practice of our team has confirmed the high usefulness of such meetings. And that the benefits continue in the future, it is important that the meetings do not develop into long and fruitless discussions of all the existing problems.
Before starting work on the project, we also create a “discussion” in the communicator program. Our company uses slack for this purpose. But you can use other programs such as HipChat, skype, etc.
Such a “discussion” (“conversation”, “group” or “conference”) allows you to dock a team with people who work on a project remotely, for example, with internal Customers who may be in another office or even in another country, or with some remote employees.
In our company, “discussion” in the communicator is actively used by both developers and customers. The developers use it to ask short questions to customers and to inform them about the new features of the released version of the application. Customers leave in the "discussion" of their feedback and requests to correct any critical bug, if it needs to be done urgently.
The development process consists of a sequence of milestones. Each mailstone ends with the release of a version of the application that supports the planned functionality. The last mailstone development stage ends with the release of an alpha version.
An alpha version is an application that can be used, although it contains bugs.
During each Milestone the following work is performed:
While planning for Milestone, the work that needs to be done by the end of Milestone is broken down into tasks. The tasks are evaluated, and the tasks themselves are entered into the task control system. We use JIRA as such a system, but this is not significant. Instead, you can use any other task control system: from free Redmine to expensive DevTrack.
All tasks can be divided into two categories, each of which reflects a certain view on the planned work. In our case it is:
User tasks are determined by the final result to be achieved. This result is clearly visible to the end user, and therefore user tasks are easily verified by the QA engineer: the result is either there or there is none.
Examples of such tasks:
However, along with the advantages, user tasks have disadvantages: they are difficult to assess, they may have cyclic dependencies (for example, to perform task B, you must first perform task A, and to accomplish task A, in turn, you must perform task B).
Custom tasks can be divided into two categories:
Criteria tasks are sort of checklist items. QA-engineer can go through it, conditionally tick (if the items are executed) and close the parent task, if all the “ticks” are checked.
Note: It should be noted that the tasks-criteria are arranged in the form of subtasks for tasks of the first category.
There are 3 types of criteria:
Technical tasks reflect the programmer’s view of work related to the implementation of a particular requirement or a particular group of requirements. They are elements of an action plan and are expressed in technical terms, or at least the lexicon of a programmer.
EXAMPLES of technical tasks:
Technical tasks are easier to evaluate, and the resulting estimate is more accurate. Also of them it is possible to form a work flow, and it is easier to take into account and resolve the dependencies between them.
However, they are more difficult to verify. Often the result of a technical task is not visible to the end user. To be noticeable, it is necessary to perform a series of technical tasks.
The simultaneous use of technical and user tasks is justified when the team consists of more than 6 people. In this case, the timeframe and time spent are assessed by technical tasks, and the result - by user tasks. However, such an approach requires a dedicated full-time manager, whose responsibilities include the distribution of both technical and user tasks among team members and the determination of correspondence between user and technical tasks.
In our case, the team is not so big. Therefore, we use only custom tasks, sincethey can be easily checked by a QA engineer. We discuss all technical subtleties and approaches to implementation in words. Similarly, we resolve dependencies between various user tasks, if any.
When entering a task in JIRA, we label it with tags. Tags allow you to customize various filters, as well as collect and analyze statistics.
As labels we use:
Before sending the written code to the general repository, you must go through the review procedure. At first, more experienced developers make a review of the code. But newcomers should be brought to the review of other people's changes as early as possible. This will allow them to familiarize themselves with the application code and better understand the style adopted in the team.
The most common errors that occur during the code review procedure are:
Testing of the application occurs in parallel with the development. For this, the department has a QA-engineer who is only engaged in testing the developed tools.
Every morning, the QA-engineer takes the updated source code from the version control system and assembles it independently. This is his responsibility. Thus, the QA-engineer always works with the updated version and does not ask the programmer to build another build for him. The programmer is only involved if an error has occurred during the build or during the launch.
QA- , . - , . — -. , , QA- , , . Why is it important?
-, QA- , , .
-, - , “” .
. :
Such tags allow you to analyze the statistics on bugs properly.
The maintenance process, like the development process, consists of a sequence of milestones. Each mailstone ends with the release of the next version of the program. Only, unlike the versions released at the development stage, the application versions delivered at the maintenance stage can be fully used in the work.
-, -, — .
. , , . , , .
The duration of the Mailstone at the maintenance stage is usually 3-4 weeks. This is less than the average Milestone duration during the development phase. This is explained by the decrease in the number of tasks that need to be implemented. This is understandable, because The main functionality was implemented during development.
Tasks that are performed during the maintenance phase can be conventionally attributed to one of two types:
One of the important goals that we pursue during the maintenance phase is to make the tool extremely easy to use. To achieve this goal, we try to eliminate all obstacles that prevent normal use.
How do we identify such obstacles? Just give the version of the application to customers and ask to work with it in the field. According to the results of work we ask:
Received answers are analyzed and we develop solutions that solve problems.
. , , , features, - , , , — .
.
. . . “” , .
2 : — , — 3D-. . , , . .
2 : 1- , , 4- 1- . 6 — 7 . , , , .
.
“We have 3 to 4 programmers who for half a year already (or a year - the period of time has depended on the company) are“ sawing ”one project. Nevertheless, despite the efforts, a workable “demo”, which can be launched and demonstrated to the Customer, still does not exist. We are looking for a leader who could organize the work. ”
The strangeness of the situation lies in the fact that seemingly intelligent and experienced company executives think about organizing the development process not at the beginning of the project, but only when the recruited team fails. Meanwhile, the process should be thought at the very beginning.
In this article, the author shares the successful experience of organizing the development process in the Larian Studios toolbox department.
About company
Larian Studios is a small company with a staff of just over 100 people developing the Divinity role-playing game series. The company consists of several studios located in different countries. One of the studios is located in St. Petersburg. The games are available for various platforms, including Windows, Linux, Mac OS X, Xbox ONE and PlayStation 4.
')
About technology
For game development, the company uses its 3D engine and its integrated development environment. Despite the fact that the engine is ported to different platforms, development is carried out on the Windows platform. This is due to the fact that the development environment is written using WinForms and WPF technologies and works under the control of the .NET Framework.
An integrated development environment is an application within which you can run a game, either as a whole or as a separate game mode or level. We can say that this is a kind of container for launching the game, which is equipped with various tools for creating levels, editing the surface, arranging objects, creating and editing scripts, dialogues between characters, etc. etc.
The Larian Editor is used to create the game Divinity: Original Sin 2.
Despite the fact that the development environment looks impressive, and the multitude of UI elements provides access to extensive functionality, however, its usability leaves much to be desired both due to the congestion of the interface itself and because its individual parts are not consistent together. This is the main problem.
About requirements
The basic requirements for the tool can be expressed in 3 conditions:
- It should look professional, and not as “knee-based” software.
- Must have the specified functionality and be convenient to use.
- The time and cost of development should not exceed reasonable limits.
The All Spark editor, developed by the toolkit, is used to create visual effects.
About customers
Tools are developed for internal customers. These include all those people who directly make the game. These are visual effects designers, 3D animators, game designers, and scripters, etc. etc.
About the department
The tool development department is small. Its composition is:
- 1 lead programmer (he's a manager)
- 3 programmers
- 1 quality engineer
About the process
Overview
To organize the work of the department, you must put the development process. Delivered process will help to deliver projects on time and with a given quality. Since the team is small and everyone knows each other, we are not using ponderous and regulated by all sorts of rules, but an easy development process. Many things in it are not formalized, and others are based on verbal agreements. However, there are clearly structured things that I want to tell about.
Stages and stages of development
The development process in the toolkit can be divided into 4 stages:
- Concept development
At this stage, our internal customers prepare the concept of the developed program and formulate the basic requirements. - Planning
At this stage we make an assessment of the project and create its plan. - Development
At this stage, the program is being developed. - Escort
The program makes improvements, fixes bugs.
Stage 1. Concept development
Work on a new tool begins with the development of a concept. This is done by our internal customers such as visual effects designers, 3D animators, game scripters, etc.
The process of creating a concept consists of several stages:
- Awareness of needs
At this stage, stakeholders are aware of their need for the instrument and the reasons that push them to ensure that such a tool is developed inside the studio. Such reasons may be:- Financial
Until recently, a tool that was licensed from a third party was used. But the price for a license has grown so much that it is cheaper to develop your tool. - Technological
The existing tool does not support the new platform for which the game is being developed, or it cannot be used to implement the requirement, which should be one of the key in the new game. - Ergonomic
The existing tool is inconvenient to use, which significantly affects the productivity and, consequently, the speed of game development.
- Financial
- Formulation of requirements
At this stage, stakeholders formulate requirements for the new instrument. These requirements include both the functional part (what the tool should do) and the ergonomic component (as far as the tool should be convenient to use). - Search for solutions-analogues
The search for solutions to the problems formulated in the previous step should be started from the study of similar programs. In our case, such analogues are Unreal Editor, Unity 3D, FxStudio Designer and other programs. Deep knowledge of such tools allows you to peep successful solutions and use them in your own application. - Drawing layouts
Layouts allow developers to create a visual representation of how the developed tool will look. First, it is enough to draw several key screens, such as the main application window, the main data editing window, the toolbar. As you develop, you can add layouts for other windows. - Document preparation
The final document is formed by combining the mocaps with the requirements. The document is divided into chapters on a screen basis: each screen is a separate chapter. At the beginning of the chapter, the layout of the corresponding screen is given, and below it the corresponding requirements in text form.
Stage 2. Planning
During planning, it is important for the team to do three things:
- Agree on a result with interested parties.
- Make a project plan.
- Make a communication plan.
Step 2.1. Agree on the result
At this step, it is important to understand what the alpha version of the product will be. In our case, the alpha version is the version of the program that is obtained at the end of the third stage - development, which we will discuss in more detail below. The alpha version may include far from all the requirements that Customers have formulated in the concept, but only a certain subset. Why?
The fact is that the concept includes many "Wishlist" of Customers. Some of them are not tested by practice, and may not be useful in reality. And, on the contrary, it may be necessary to implement something else that the Customers did not think about when they wrote the concept.
Therefore, we try to ensure that Customers start using our program as quickly as possible. Let not in the working, but at least test mode. Only real experience of use can show which requirements are important and which ones are insignificant.
To achieve this goal, we are trying to understand what the minimum working version should include. And from all the requirements - in coordination with the Customers - we select only those, the implementation of which is really impossible to do.
The minimum working version is the alpha version. At its release ends the development phase.
Our own editor, Genome, allows 3D animators to visually program a character.
After our Customers begin to use our program, bugs and various rough edges are revealed. In addition, the experience of using appears first in test conditions, and then in “combat” conditions. This experience allows us to assess the remaining requirements: which of them are important and which ones are insignificant.
We eliminate roughness, implement revalued requirements and fix bugs at the maintenance stage.
Step 2.2. Make a project plan
To make a project plan, you need:
- Make a project assessment
- Rate available resources
- Plan Milestone
Step 2.2.1. Make a project assessment
In my opinion, there are two types of project evaluation:
- Preliminary estimate
- Detailed assessment
The preliminary estimate is rather rough. It uses simplified decomposition, but for this reason it does not require too much time.
Detailed evaluation is more accurate. But in order to get it, you must perform the design and make the decomposition of the work.
To save time, we make a rough assessment of the project. However, using the “coarse models” you can get an accurate result. How do we achieve this? For project evaluation, instead of one model, we use three:
- Functional model
- Component model
- Process model
The functional model represents the program being developed as a set of useful functions. It reflects the user's point of view.
The component model represents an application as a set of modules. It reflects the look of the engineer.
A process model is a view of a program as a project that has a certain length in time and consists of a sequence of steps. Each stage has its own tasks (often organizational or managerial) and, as a result, its duration can be estimated as a superposition of the time required to complete each of the tasks. Process model reflects the point of view of the manager.
Being combined, these three points of view represent a comprehensive view of the same product. Some things are better evaluated through functions, some through modules, some through a process. As a result, a balanced score is obtained.
Perhaps in more detail this topic will be disclosed in a separate article.
Step 2.2.2. Rate available resources
In order to properly take into account the available resources, you need to understand that no employee spends 100% of his time on completing tasks. Be sure, the programmer will spend some part of his time on communication with colleagues and a little rest.
Of course, if there are only 2 people in a team, and they work with approximately the same productivity, then the waste of time can be neglected and assume that one working man-day is 8 hours. In fact, with this team size, the time to agree on some issues will not be too significant.
However, if the team already has 4 people, then you should consider both the time for communication and the different labor productivity of different people.
In assessing the available resources, we use the following table of labor productivity:
| Worker | Performance |
| Lead Engineer | 50% |
| Engineer | 85% |
| Newbie | 50% |
| Inexperienced newcomer | 25% |
In addition to programming, the lead engineer spends part of his time on planning, assigning tasks, communicating with Customers, introducing new ones, if there are any, and training inexperienced ones. Therefore, we believe that he can spend on programming only half of his time.
An ordinary engineer should work with an 85% productivity. He spends the remaining 15% of his time communicating with the rest of the team, communicating with Customers and writing reports.
As you know, connecting new people to the project at first does not speed up, but slows down the development. This is due to the fact that team members are forced to distract from work to train a new employee. Even for a beginner, labor productivity at first is low: we believe that he spends on training up to half of his working time. Over time, productivity should increase. If it does not grow, then this is a reason to think about the appropriateness of his stay in the team.
An inexperienced beginner is initially forced to spend more time on training than just a beginner. Therefore, the performance of 25% at the very beginning should not look like something scary. However, over time, it should also grow.
Using these figures, you can estimate the actual productivity of the entire team.
Suppose a team consists of 4 people:
- Lead Engineer;
- engineer;
- newcomer;
- inexperienced newcomer
Then the performance of the whole team will be equal to:
1 * 50% + 1 * 85% + 1 * 50% + 1 * 25% = 210% = 2.1 man-days
This is two times less than with a simple approach, when it is believed that each person works with a 100% productivity.
Step 2.2.3. Plan Milestone
When planning you need to distribute the entire work in several stages. Each stage ends with Mylustone. Milestone is a point in time when the results of the work done are evaluated.
When planning for the Mylustones, it is necessary to solve two problems. First, you need to distribute user requirements across milestones. Secondly, it is necessary to estimate the duration of each milestone. At the same time, it is important to ensure that the duration of the Milestone was approximately the same.
To distribute work across Milesstones, we use several criteria:
- Theme
Every mailstone should be dedicated to a specific topic. This allows the team to concentrate on something specific and avoid scattering and throwing.
Examples of topics: data model, toolbars, graph editing window, etc. - Addiction
It is necessary to consider the dependencies between the works It is necessary to distribute the work in such a way that the dependent works would be located later than those works on the results of which they depend. - Duration
It is necessary to withstand about the same duration of all milestones. We try to ensure that the duration of each milestone was 5-6 weeks.
Step 2.3. Make a communication plan
In order for the project to progress successfully, it is necessary to think about how communication within the team will be built between individual developers, as well as between the team and Customers.
We in our company use several practices that turned out to be - in our case! - very successful.
Project space in the “cloud”
When starting a new project, we create a project space in the “cloud”. We use Google Drive as cloud storage. But you can use other services: Yandex Disk, Mail.Ru, One Drive from Microsoft, and others.
If privacy requirements or personal preferences do not allow using a cloud service, you can install Sharepoint on a local server, or use a version control system like svn, git or perforce, or create a project folder on a regular file server. Options - from simple to exotic - weight.
A single project space allows you to concentrate all the documents related to the project in one place. And the use of the “cloud” allows you to open access to all members of the team: everyone from your workplace.
What is the project space? This is a regular folder in the cloud storage, to which access rights are configured. Inside it contains other folders, each of which concentrates the documents related to a particular discipline.
For example, in our case, the project folder usually contains 4 such subfolders:
- Concept
It contains documents describing the requirements of customers and the design of the developed application. - Technical project
Documents describing the technical design of the program, class diagrams, existing technical limitations, etc. are placed in this folder. - Project management
This folder contains everything related to project management issues: project evaluation, team composition, project schedule, vacation schedule, etc. - Quality control
This includes descriptions of test cases, reports on the results of milestone, rules for processing bugs, a list of problem areas in the program, methods for finding bugs.
List of contacts
The contact list is a document that contains the names of all people connected in one way or another to the project, as well as ways to contact them: phones, email addresses, Skype accounts, etc.
The contact list allows you to quickly find the right person. Managers who neglect the creation of such a list, then waste their time and nerves to find a leading programmer, designer or engineer for quality in any emergency.
The list of contacts is best done in the form of approximately the following table:
| FULL NAME. | Position | Mob Tel. | Skype | |
| Ivanov P.I. | Lead coder | +7 (XXX) XXX-XX-XX | pivanov@company.com | pivanov |
| Petrov I.S. | Programmer | +7 (XXX) YYY-YY-YY | ipetrov@company.com | ipetrov |
Daily meetings (stand-ups)
Every day our small team (4 programmers and 1 QA-engineer) gathers for a short meeting to discuss the current progress of the project. Typically, such a meeting takes 10 to 15 minutes and allows all team members to stay informed.
The meeting format for a long time remains unchanged and consists of three parts:
- General announcements
- Report of each team member
- Discussion of problems and suggestions
In the first part, the project manager (or the lead programmer who performs managerial functions) informs the team about any news related to the project. These could be some managerial decisions of the project curators, requests from internal customers, positive or negative feedback on the application being developed or on the team’s work.
Then comes the turn of the reports. At this stage, each team member reports on his work by answering the following three questions:
- What did I do yesterday?
- What am I going to do today?
- Do I have any obstacles that prevent me from carrying out current tasks?
This report format allows the project manager (or the lead engineer who performs part of the managerial functions) to be aware of how the project is moving and what progress the team has made. And since each team member should tell about the task he is working on at the moment and identify the existing problems, this helps other team members to learn in time about the dependencies between their task and their colleague's task and, if necessary, to resolve these dependencies by adjusting their actions. .
Another plus of public reports is that the work of each team member is in sight. Unable to hide the lack of results. This is an additional stimulating factor for both the person who failed to advance in his task, and for the team: someone can give a hint or offer to take part of the work on the task.
After the reports comes the turn of the discussion. If there are any problems, they are briefly discussed and approaches are developed to solve them.
The practice of our team has confirmed the high usefulness of such meetings. And that the benefits continue in the future, it is important that the meetings do not develop into long and fruitless discussions of all the existing problems.
“Discussion” in the communicator program
Before starting work on the project, we also create a “discussion” in the communicator program. Our company uses slack for this purpose. But you can use other programs such as HipChat, skype, etc.
Such a “discussion” (“conversation”, “group” or “conference”) allows you to dock a team with people who work on a project remotely, for example, with internal Customers who may be in another office or even in another country, or with some remote employees.
In our company, “discussion” in the communicator is actively used by both developers and customers. The developers use it to ask short questions to customers and to inform them about the new features of the released version of the application. Customers leave in the "discussion" of their feedback and requests to correct any critical bug, if it needs to be done urgently.
Stage 3. Development
Overview
The development process consists of a sequence of milestones. Each mailstone ends with the release of a version of the application that supports the planned functionality. The last mailstone development stage ends with the release of an alpha version.
An alpha version is an application that can be used, although it contains bugs.
Milestone
During each Milestone the following work is performed:
- Work planning
- takes from 2 man-days to 1 man-week
- executed by the lead programmer
- sometimes requires intensive discussion with the customer of individual requirements
- Development (takes 4 - 5 weeks)
- Bug fixes (takes 1 week)
Tasks
While planning for Milestone, the work that needs to be done by the end of Milestone is broken down into tasks. The tasks are evaluated, and the tasks themselves are entered into the task control system. We use JIRA as such a system, but this is not significant. Instead, you can use any other task control system: from free Redmine to expensive DevTrack.
All tasks can be divided into two categories, each of which reflects a certain view on the planned work. In our case it is:
- Custom Tasks
- Technical tasks
Custom Tasks
User tasks are determined by the final result to be achieved. This result is clearly visible to the end user, and therefore user tasks are easily verified by the QA engineer: the result is either there or there is none.
Examples of such tasks:
- Create a drop-down panel for texture selection.
- Add a shape to choose color
However, along with the advantages, user tasks have disadvantages: they are difficult to assess, they may have cyclic dependencies (for example, to perform task B, you must first perform task A, and to accomplish task A, in turn, you must perform task B).
Custom tasks can be divided into two categories:
- Tasks that characterize some observable part of the program, for example, a separate window, a complex control element, or some service function (for example, exporting a document to a specific format).
- Tasks that set the criteria for performing tasks from the first category.
Criteria tasks are sort of checklist items. QA-engineer can go through it, conditionally tick (if the items are executed) and close the parent task, if all the “ticks” are checked.
Note: It should be noted that the tasks-criteria are arranged in the form of subtasks for tasks of the first category.
There are 3 types of criteria:
- Criteria that describe the composition of the component (separate form, separate control)
When formulating such criteria, you should ask yourself questions:- What does the component consist of?
- What elements include?
- Criteria that characterize key visual characteristics of a component
In formulating such criteria, questions should be asked:- What is the background color of the component?
- What color is the text?
- What font is used?
Note: Do not list all the visual characteristics to the smallest detail. This is too laborious and not necessary. Attention should be paid only to the key characteristics or only those characteristics that differ from the standard.
The purpose of formulating the criteria is not to create a detailed description of the component in the smallest details, but to pay attention to the QA-engineer so that he does not forget to check certain characteristics before he “closes” the task.
EXAMPLE. If the background color, text color and window font does not differ from the standard ones, then all these checks can be formulated as one task:
Check that the background color, text color, typeface and font size match the manual. - Criteria that describe the behavior
When formulating such criteria one should ask questions:- What does the item do?
- How will he react to a particular user exposure?
- What should the user do to make the element behave in a certain way?
- Does the behavior of an element depend on time?
- Can a user cancel this or that action?
EXAMPLES:- As a user, I can control the display of the grid by clicking on the Grid button.
- Make sure that the list can be expanded or collapsed by clicking the arrow on the left side of the title.
Technical tasks
Technical tasks reflect the programmer’s view of work related to the implementation of a particular requirement or a particular group of requirements. They are elements of an action plan and are expressed in technical terms, or at least the lexicon of a programmer.
EXAMPLES of technical tasks:
- Develop a class that does ... or is responsible for ...
- Write a function that ...
- Improve search algorithm ...
Technical tasks are easier to evaluate, and the resulting estimate is more accurate. Also of them it is possible to form a work flow, and it is easier to take into account and resolve the dependencies between them.
However, they are more difficult to verify. Often the result of a technical task is not visible to the end user. To be noticeable, it is necessary to perform a series of technical tasks.
The simultaneous use of technical and user tasks is justified when the team consists of more than 6 people. In this case, the timeframe and time spent are assessed by technical tasks, and the result - by user tasks. However, such an approach requires a dedicated full-time manager, whose responsibilities include the distribution of both technical and user tasks among team members and the determination of correspondence between user and technical tasks.
In our case, the team is not so big. Therefore, we use only custom tasks, sincethey can be easily checked by a QA engineer. We discuss all technical subtleties and approaches to implementation in words. Similarly, we resolve dependencies between various user tasks, if any.
Tags
When entering a task in JIRA, we label it with tags. Tags allow you to customize various filters, as well as collect and analyze statistics.
As labels we use:
- Milestone Identifier
It makes it easy to find all tasks related to a particular mailstone. - Task type
This is either a task-feature (in English, “feature”) or a criterion. - The identifier of the component or part of the program to which the
Filtering task by this criterion subsequently makes it possible to easily evaluate the laboriousness of a particular part of the program.
Code Review
Before sending the written code to the general repository, you must go through the review procedure. At first, more experienced developers make a review of the code. But newcomers should be brought to the review of other people's changes as early as possible. This will allow them to familiarize themselves with the application code and better understand the style adopted in the team.
The most common errors that occur during the code review procedure are:
- -
— . ( ) . . - . . , - .
— change list. , .
: ( ) , , . . .
— . . .
Testing of the application occurs in parallel with the development. For this, the department has a QA-engineer who is only engaged in testing the developed tools.
Every morning, the QA-engineer takes the updated source code from the version control system and assembles it independently. This is his responsibility. Thus, the QA-engineer always works with the updated version and does not ask the programmer to build another build for him. The programmer is only involved if an error has occurred during the build or during the launch.
QA- , . - , . — -. , , QA- , , . Why is it important?
-, QA- , , .
-, - , “” .
. :
- Milestone ID
- ID of the subsystem of the program in which the bug appears
Such tags allow you to analyze the statistics on bugs properly.
Escort
Overview
The maintenance process, like the development process, consists of a sequence of milestones. Each mailstone ends with the release of the next version of the program. Only, unlike the versions released at the development stage, the application versions delivered at the maintenance stage can be fully used in the work.
-, -, — .
. , , . , , .
The duration of the Mailstone at the maintenance stage is usually 3-4 weeks. This is less than the average Milestone duration during the development phase. This is explained by the decrease in the number of tasks that need to be implemented. This is understandable, because The main functionality was implemented during development.
Tasks that are performed during the maintenance phase can be conventionally attributed to one of two types:
- Barrier removal
- Expansion of functionality
Barrier removal
One of the important goals that we pursue during the maintenance phase is to make the tool extremely easy to use. To achieve this goal, we try to eliminate all obstacles that prevent normal use.
How do we identify such obstacles? Just give the version of the application to customers and ask to work with it in the field. According to the results of work we ask:
- What prevents?
- What annoying?
- What is missing?
Received answers are analyzed and we develop solutions that solve problems.
Expansion of functionality
. , , , features, - , , , — .
.
Conclusion
. . . “” , .
2 : — , — 3D-. . , , . .
2 : 1- , , 4- 1- . 6 — 7 . , , , .
.
Source: https://habr.com/ru/post/315514/
All Articles