best practices of project management for small teams
Post on 17-Jul-2015
189 Views
Preview:
TRANSCRIPT
I'm afraiding the quality of
our programs...
But can not touch
until the test phase...
not kept clean code in spite of
the small team...
I'm afraiding the quality of
our programs...
But can not touch
until the test phase...
not kept clean code in spite of
the small team...
But, have to prepare
a “coding style guide”...?
Program bugs also much less!
could technical exchange
between members?!
♪
Code quality has improved!
Automatic test &
Code review by
Merge-Request*(Pull-Request)
in GitLab(GitHub)
* ... hereinafter also referred to as “MR”.
Tools • Redmine: issue tracking tool
• Git: version control tool
• GitLab: git management tool => You can use GitHub instead of GitLab when your project is open source.
• Jenkins: CI tool (Using `jenkins-gitlab-merge-request-builder-plugin` to connect Gitlab.)
=> You can use Travis CI instead of Jenkins when your project is open source.
Icons
Project Manager
Developer A
Issue Branch
Merge- Request
Developer B
Automatic Test
Manual process
Automatic process
Redm
ine G
it G
itLab Jenkins
Time
New In Progress
Development in the branch named “<The issue number>-<Slug>”. (ex. 123-add-foo-bar-feature)
In Progress (20%)
Redm
ine G
it G
itLab Jenkins
In Progress (80%)
Development
New In Progress In Progress (40%)
In Progress (20%)
Time
Redm
ine G
it G
itLab Jenkins
Time
In Progress (80%)
Merge- Request
Testing… NG!
Automatic testing & Notfy the result
!
Merge- Request
Redm
ine G
it G
itLab Jenkins
Time
In Progress (80%)
Merge- Request
Testing… NG!
Fix & git push
Merge- Request
Redm
ine G
it G
itLab Jenkins
Time
In Progress (80%)
Merge- Request
Testing… NG!
Testing… OK!
Automatic testing & Notify the result
! Merge-
Request Merge-
Request
Redm
ine G
it G
itLab Jenkins
Time
Merge- Request
Assign the MR to B
Resolved (100%)
Assign the issue to B
In Progress (80%)
Developer B
Redm
ine G
it G
itLab Jenkins
Time
Merge- Request
Resolved (100%)
In Progress (80%)
git pull <target branch>
Redm
ine G
it G
itLab Jenkins
Time
Merge- Request
Resolved (100%)
In Progress (80%)
Manual testing & Code review
Redm
ine G
it G
itLab Jenkins
Time
Merge- Request
Resolved (100%)
In Progress (80%) Feedback
NG
Assign the issue to A
with failure reasons !
Redm
ine G
it G
itLab Jenkins
Time
Feedback
Testing… OK!
Automatic testing & Notify the result
! Merge-
Request
Redm
ine G
it G
itLab Jenkins
Time
Feedback
Testing… OK!
Merge- Request
Resolved
Assign the issue to B
Redm
ine G
it G
itLab Jenkins
Time
Resolved
Assign the issue to project manager
Merge- Request
Project manager
Redm
ine G
it G
itLab Jenkins
Time
Resolved
Close the issue by the author of the issue
Merge- Request
Closed
OK
This flow is useful as follows: • Consistency in source code
(without “code style guide”)
• Bugs reduced • Technical exchanged between
developers • Transparency of progress
You may think to take time for code review is nonsense.
But
By reducing the bad code within early, you will be able to avoid
wasting time at later.
top related