How to Have More Productive Projects Using Agile and Git
We present a series of 6 steps to integrate some useful tools like Kanban and Git and have more productive projects.
In this post you will find:
- An introduction to collaborative project issues,
- What is Agile and a Repository are,
- How Kanban & Git Work, and
- A series of 6 steps to have more productive projects.
Collaborative Projects
When we work on projects of any size that involve the collaboration of multiple developers it is vitally important to ensure the project’s success:
- Having the control to plan what will be built,
- Coordinating tasks with the team and
- Being able to deliver.
Teamwork methodologies like Agile and workflows like Gitflow for repositories are useful tools in scenarios where we need to interact with more contributors.
Agile
Agile was set in motion in Europe in the 1970s and it was finally formalized in a manifesto in 2001. Agile entailed a shift from predictive waterfall models to adaptive models, adding value frequently, iteratively, and incrementally.
Today, Agile is considered a working philosophy expressed with a series of methods, practices, and techniques. It has a positive impact on different types of improvements such as productivity and time management.
Some of the best-known methods under the Agile umbrella are Scrum and Kanban.
Kanban
You’ve likely only heard about Kanban boards, which are an incredibly useful tool because these boards help visualize and manage the workflow with cards that move around the board, and their simplicity is their greatest strength.
A Kanban board is generally divided into three columns: to do, doing, and done. Some of its advantages are:
- Better visualization tasks,
- Shows what is being worked on at a glance,
- Allows the list of tasks to be put in order, and
- Simple and intuitive to organize and manage the progress of tasks and activities.
Some tools we can adapt these Kanban boards to are Trello, Planner, Jira, MeisterTask, Asana, or KanbanFlow.
Repository
Repository or Version Control is a data structure that stores metadata for a set of files or directory structure.
There are two types of repositories:
- Distributed such as Git or Mercurial, or
- Centralized such as Subversion, CVS, or Perforce.
GIT
Git is a distributed version control system, created by Linus Torvalds in 2005. Git is practical, simple, fast, efficient, free, and open source.
Branching management
There are different methodologies to manage the branches in a repository, such as, single-branch or multi-branch.
Here, we will use per-feature-branching for repository management, which is inspired by GitFlow, a branching model for Git created by Vincent Driessen.
Gitflow defines a strict branching model designed around the project release, but in this example, we’re going to focus on a more basic branching version, performed in 6 steps (This will be described below in How Kanban & Git Works).
How Kanban & Git Works
Below we present a series of 6 steps to integrate Kanban and Git and have more productive projects.
Our Kanban board will be divided into five columns: backlog, to do, doing, review, and done.
The goal is to work in parallel between the Kanban board and the git repository.
1. Tasks in the ‘backlog’ column — Develop and Main branches
To get started, in the Kanban board:
backlog: List of tasks defined in the project to be developed.
In parallel, in the local/server repository we have two main branches:
main: Contains already tested code, working version, no errors, clean code. It is usually convenient to tag all commits with a version number.develop: Interaction flow will occur before merging tomain. It should always have the most current version because it will be the basis for the nextfeatures.
mainanddevelopshould be usually blocked for direct commits.
2. Task in the ‘to do’ column — Creating a feature branch
Then, in the Kanban board:
to do: Abacklogtask is assigned to a team member. This task is moved to theto docolumn.
In parallel, in the local repository we create a new branch:
feature: For each task into do, afeaturebranch is created.
featurebranches are created off to the latestdevelopbranch, andfeaturebranches should never interact directly withmain.
3. Task in the ‘doing’ column — Working on a feature branch
Next, in the Kanban board:
doing: The task assigned to the team member is moved to thedoingcolumn. The team member solves the task.
In parallel, in the local repository:
feature: On this newfeaturebranch the development of the task is implemented.
When a task is complete in the
featurebranch, it gets pushed to the server.
4. Task in the ‘review’ column — Review a feature branch
Later, in the Kanban board:
review: The task finished by the team member is moved to thereviewcolumn. Other team member reviews/evaluates the task.
In parallel, in the server repository:
feature: When a task was completed and pushed to the server, the team member creates a new Merge Request or Pull Request for review.
For this review, your project can implement some tools with specific purposes to check your codes and automate those processes.
5. Task in the ‘review’ column — Approve a feature branch
After, in the Kanban board:
review: The reviewer finishes evaluating the task.
In parallel, in the server repository:
merge/pull request: When a task was reviewed, the team member approves the Merge Request or Pull Request.
If the assignment is not approved, the reviewer may request some changes or improvements.
6. Task in the ‘done’ column — Merge and finishing a feature branch
Finally, in the Kanban board:
done: The task is finished.
In parallel, in the local/server repository:
develop: When a task is approved in Merge/Pull Request, thefeaturebranch gets merged intodevelop.
The
featurebranch is deleted after merged.
Summary
How Kanban & Git Work — 6 steps:
More interesting links
References
- ESADE Soft Skills Innovation and Personal Management
- Principles behind the Agile Manifesto
- Scrum Checklist
- Gitflow Workflow
- git-flow cheatsheet
made with 💙 by mafda.
