Another methodology: Stakhanov

General principles

1. Tasks are created and written for the convenience of performers.
2. The result of the game dizaners are complete and understandable even for beginners job.
3. Artists read assignments and change their status. (they write code, not assignments)
4. Long hanging tasks are deleted (it will be necessary - we will get it again)

General description style

1. Command: what, to whom and when you need to do. There should be no ambiguity or conjecture.
2. Only complete phrases. With a detailed (step by step) description of actions.
3. Phrase taken out of context should remain meaningful.
4. All parameters must have digital values ​​(the number of elements, the size of the image, the length of the line)
5. All lists should be numbered (easier to check list)
6. Long lists should be divided into groups of 3 elements
7. The inscriptions in the figures and in the text should coincide verbatim. If they do not match, then these are different inscriptions.
8. Careful attention is paid to errors and extreme situations (invalid characters, long lines, loss of communication, wrong time, fast and erratic tapas)

Description of the functional

1. how to start / call it?
2. complete list of all answer choices
3. full list of reactions to each course of action
4. detailed list of all errors that may occur
5. description of extreme situations (long lines, loss of communication, etc.)
6. how to close it, where to go after it?

Types of tasks

The introduction of new functionality

1. It creates a big task, which is assigned to the game designer (responsible for the introduction of the functional)
2. Game Designer breaks the functional into subtasks and lists each of them.
3. Any subtask must be performed by one person in less than one day.
4. This includes tasks such as timing, list making, technology research, etc.

Short task:

1. reference to a common (big task)
2. if the task contains elements or references to other tasks - they must be specified
3. any list must be numbered
4. long lists should be divided into triples (grouping of elements by meaning)
5. a short task should not contain references to external documents or images: everything necessary should be indicated in the task itself (external sources may disappear)

Correction task:

1. How to play (fast way) - you may need a test level or something else.
2. What exactly works wrong
3. How it should work correctly (how to check that the bug is fixed)

Members

Producer

1. assigns tasks to the game designer (in the status of Design Notes)
2. looks through and makes comments in the tasks designed by the game designer
3. Subscribes to tasks written by game designer to track them.
4. checks the task list Waiting Other and intervenes if help is needed

Game designer

1. draws up tasks (short tasks of not more than one day in the form of subtasks) set by the producer
2. coordinates the painted design with the producer and the main programmer.
3. finally forming the task and agreeing, it changes the status of Design Notes -> Tech task
4. selects the task Resolved and checks its execution
5. if the conditions of the task are not fulfilled - the task is rediscovered
6. if the conditions are met - the task is closed Resolved -> Closed
7. in the case of new conditions (and now the arrow to the right, then quickly) - a new task is created with reference to the previous one.
8. If all subtasks (painted by game designer) are closed - you can close the global task set by the producer.

Programmer

1. when the current task is complete, it closes it and starts to select a new one.
2. you must first check the pending Waiting Other tasks - can they be continued?
3. if it was not possible to find among the deferred ones, we select new ones only among the Tech Task with the highest priority assigned to the programmer.
4. if there are more than 3 such tasks - he asks the game designer to rank the tasks by priority (High - not more than 3)
5. selected task is being studied
6. if the task is incomplete or incomprehensibly written - it is sent back to the game designer
7. if everything is clear, it changes the status in In Progress and starts performing the task
8. when the task becomes impossible - the status is Waiting Other
9. The task is postponed - this is a signal for game designers and producer to help.
10. if the task is finished, set the status to Resolved (can be changed via a comment in the commit repository)