We use Agile methodologies every day and on almost everything we do. For software development, we have our own flavor of Agile that combines a few practices from Extreme Programming and some others from Scrum.
This methodology helps carry out projects successfully by providing tools and metrics to organize and measure performance of teams.
Roles are one of the three most important things to have clear during development. We identify two roles with different responsibilities: The product owner, or just the client, is the one responsible of putting together and prioritizing the functional requirements, also called user stories The development team is the people accountable for creating the features in timely fashion.
From this methodology we take the concepts of Pair programming and Test-driven development. Test-driven development means that for every piece of code we write, we write another that makes sure the previous one does what it’s meant to do. We’ll always provide a proper test suite along with server side code.
Sprints represent one cycle in the development process, where one or more user stories are worked on. Sprints start with a planning meeting and end with a review meeting one week later. Scrum meetings take place every day in between. Both the product owner and the development team must attend to all meetings.
User stories are short, simple description of a feature told from the perspective of the person who will be using that feature. They typically follow this method:
As a “type of user”, I want “some goal” so that “some benefit”.
You’ll potentially see 100’s of stories for your product, and we establish them in a compounding and chronological order during the initial setup. They are assigned to sprints by the product owner during planning meetings, then reviewed at the end of the week
The development team will estimate the ‘effort’ of completing user stories, this way determining how many fit into the sprint. During sprint planning meetings, user stories are given numbers based on difficulty, based on the fibonacci scale:
- 1: Very easy
- 2: Easy
- 3: Normal
- 5: Hard
- 8: Very hard
Test-Driven Development (TDD)
Test-Driven Development (TDD) is the most important discipline that we’ve implemented. Besides being required in any software development process, there’s a myriad of benefits. Thoughtbot summed them up quite nicely here:
Business benefits of TDD: 1) Deliver more value, faster 2) Always ship working software 3) Adapt to change quickly
Code benefits of TDD: 1) Readable specs and code 2) Clean public interfaces 3) Decoupled modules
Process benefits of TDD: 1) Regression safety net 2) Fearless refactoring 3) Team trust
At a high level, how to test is very simple: 1) Write test first. 2) Run code against the test 3) If test still works, commit!
Code Reviews are a very necessary step in proper web and mobile development. Think of it like peer editing a paper or something you wrote. Even if you’re a terric writer, it’s still good to have someone else review what you wrote to make sure it’s grammatically correct and makes sense.
Here are our Pull Request Steps:
- Create a local feature branch based off master.
- When feature is complete and tests pass, stage the changes.
- When you’ve staged the changes, commit them.
- Write a good commit message.
- Share your branch.
- Submit a pull request.
- Ask for a code review.
- A team member other than the author reviews the pull request. They follow our code review guidelines to avoid miscommunication.
- Reviewer makes comments and asks questions.
- When satisfied, they comment on the pull request “Ready to merge”.
- Merge and deliver.