+Docs Plusteam

# Development Flow

  1. Planning:
    1. Requirements Gathering (Project Management)
    2. Creation of artifacts (Project Management)
    3. Creation of issues (Project Management)
    4. Poker Planning (Everybody)
  2. Development and QA:
    1. 10AM: Development workflow (development)
    2. 1PM: Code Review workflow (Development)
    3. 6PM: QA workflow (QA + TeaM)
  3. Analysis:
    1. Sprint restrospective

# Code review workflow

After development is completed, developers must create a pull request with the tag Ready for test and assign the Chief Development Officer who is responsible for evaluation and acceptance.

All pull request done before 10 AM must be reviewed before 1 PM, Chief Development Officer must list all the corrections for every pull request, each correction must be explicit, avoiding ambiguity or unstructured suggestions, Don't make me think

If the code reviewer has an improvement opportunity which was not planned for the issue, he must talk to the project manager to decide if it should be included as a new issue for the current milestone, if the improvement requires the user approval or the issue can be planned for next milestone, but the current pull request has priority because it is a task which was previously analyzed and defined.

If the corrections are not clear or the developer doesn't fully understand them, he has a chance to ask questions during the code review time, so he must fully understand the corrections before 1 PM.

The developer is responsible to make those corrections in the afternoon or night, but they must be ready before 10 AM for the next code review cycle, if a pull request was already reviewed, the code reviewer cannot make any corrections of the main code, only on the new changes. If the code reviewer, see the issue requirements missed any details, he must update the issue requirements with a comment (Not update the issue description) and notify the project manager so he can be aware of the missing specifications and learn for the next milestone planning.

The code reviewer must write all the corrections in Gitlab, the history of requested changes are mandatory, avoid using Telegram as code review tool.

# Bug workflow

If the code reviewer notice a bug from the developer, he must add the tag bug and remove the Ready for test tag to the current issue and pull request, and comment in the merge request.

Any bug report must follow this format:


### Steps to reproduce the issue *

1.  Step 1

2.  Step 2

    .
    .

    .

 N. Step N

### Screenshots (optional)

1.  **Title of the screenshot** (optional)
    Screenshot.jpg

    .

    .

    .

 N. Title N of the screenshot
      ScreenshotN.jpg

### Browser (only for web pages)

-   [ ] Firefox
-   [ ] ...
-   [ ] Browser X

### Additional observations (optional)

The text description to explain extra observations from the `code reviewer` if there is any.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

The developer must check all pending pull request after 1 PM, if he sees any of the pending issues with a Bug tag, he must fix the issue ASAP (He has time until the next code review cycle, push the fix, and change the issue state from Bug to Ready for test.

In the pull request, he must comment on the cause of the issue if it is relevant and mark the discussion as solved.

# After merge request acceptance

The code reviewer must mark the merge request as Reviewed and delete the source branch, and notify the developer so he can update the issue spent time.

# Issue structure

Each issue must have the following sections:

Description: Description of what is requested to do

Benefit: Why is this issue needed

Structure: Technical specification of the requested feature. This section is only used for issues which must follow a certain structure, like RESTFUL API endpoints that should accept certain parameters and retrieve the information with a specific format.

Example (Optional): In this section, you can provide any examples to make the issue easier to understand.

Tasks: Here you define an ordered list of tasks to complete the issue.

Acceptance Criteria: This section is a critical one. Here you should define all the needed validations to consider the issue as Completed. All small details must be listed here. The project management is responsible to analyze the issue during its creation and provide the necessary details to complete it.

To fill this section consider the following possible :

  • Error handling: Which error should be returned, when the should be returned.
  • Any static information from the user: Like colors for the generated legends of Rank Country, remember to ask all the small details because they will be needed later, form labels, titles, notification messages.
  • Validation: List of rules which your feature must follow, like form validations, endpoint validations, database triggers, etc.
  • Data ordering

WIP: (This section probably needs more examples).

Note: This section must be planned carefully to avoid last-minute changes, the code reviewer must consider this section in order to decide if an issue has a bug of it was incorrectly defined.


: Roy Calderon
:

← Challenges →