User stories are a brief description of the tasks, from the user's point of view. They add value to the business.
- As a 'user'
- I want to 'do something'
- So that 'i can accomplish this task'
- Each story should be deployable in and of itself, and may include work required by different specialists (e.g. 1 story may include design, back end and front end components - a finished story is deployable).
Chore are work to be done but add no tangible benefit to the business. They are not pointed. Examples would be 'need to research impact of upgrading rails to 4.1' or 'need to import csv of new users'
Bugs are not pointed, but are treated very similarly to stories.
This is the process of getting stories into the icebox. Anyone can add stories to the icebox.
- All stories enter via the icebox as ideas.
- Are rarely pointed before they are prioritized or groomed; if an icebox story has points it will generally mean it was moved from the backlog.
- Need to be groomed (reviewed, broken down, perhaps split up, tasks assigned).
- Icebox will be reviewed regularly and re-prioritized.
This is the process of stories getting prioritized to the point where we will work on them and they are to be included in a sprint.
- Review all stories, if necessary encapsulate into an Epic
- Break stories down, make sure everyone understands requirements, add tasks etc. Everyone should understand the requirements, if you don't understand, then ask questions - everyone needs to be involved in the story pointing process, so needs to understand the work required. QA should be involved at this stage so they are aware of what is coming down the pipeline, the aims and goals and can prepare to test the functionality. Experience has shown that involving QA at this point will often help the process by having a better end user understanding of the stories we review.
- Determine story owner - this is the person that will confirm the user story has been addressed. It can potentially be anyone within the business, but that person must be available to mark the story as delivered.
- Do story pointing. 5 Point stories should be rare, if possible break down further.
These are very fluid and will vary team to team. This is the basis of the process I've found successful in the past.
Define what the status of a ticket means
- Clicking 'Start' means you are beginning work on a ticket and it is 'in progress'. It should be very rare that a developer would ever have 2 stories in progress at the same time - as the developer of the story, it is your responsibility to get that story through the process.
- Clicking 'Finish' means that the story is complete, and ready to be shown to the story owner.
- The developer should then take it to the story owner and show them the work. It is the story owner's responsibility to hit the 'delivered' button once they can see the story has been answered. Note that this is not intended to be QA - this is just making sure the solution meets the expectations.
- At this stage it is ready for QA; QA will Accept or Reject based on their testing.
If multiple users are required on a story (e.g. design work, then backend work, then front end work), there needs to be good and clear communication between the developers as part of the transfer, just changing the owner of the ticket is not good enough. Communication is King.
All commits on a ticket need to have the ticket number included. e.g. to make a commit against ticket number 1234
git commit -am "[#1234] rasta-fied by 15%"
Low quality is just a way to postpone costs that later will be much higher -- Maciej Mensfeld
To work as a team, we need to all be on the same page with regards to conventions, latest and best practices, variable naming, etc. The actual standard isn't important, but it is very important that it exists - we should all be able to pick up each other's code and run with it, being relatively confident that it is solid and familiar. There are several tools available to help us on this path.
Rubocop is a highly configurable ruby linter that will painlessly make sure we are following a very similar coding style. All good text editors have the ability to include this as a plugin and it needs to be part of our toolbox. If we as a team decide that some of the rules it tries to enforce don't fit into our ideal flow, then we can easily modify or remove them via a rubocop.yml file in the project root.
Code climate is a code sniffer and will hunt down smells for us, making sure we're in keeping with best practices, and give our code base an overall grade. This grade (from 1 - 4) is similar to a test coverage figure; while a very low figure indicates we probably have issues that need addressing, and very high figure probably indicates that we've spent too much time on it. It is an indication, not a pass/fail grade. Code climate will email the team whenever there is a significant change in the grade of our code base.
Code climate does also handle test coverage, which will be touched on later.
Continual Integration of our code base is a mandatory requirement - every time you push to the central repository, CircleCI will run our test suite across your code. If it fails, Agnes is notified, everyone is emailed and you will be pointed at and ridiculed with great abandon.
CircleCI only hits it's maximum benefit when we have a solid test platform. A solid test suite also allows us to implement continuous deployment, which is a Very Good Thing.
Proper commenting will lend itself to generating good documentation of the system. There are several standards and options available, and hybrids of those accepted standards - similarly to coding standards, which tool you choose doesn't matter as much as the fact that you choose one. The current code base is infinitely more difficult to traverse because there is almost no commenting done at all, and this is something that needs to change immediately. One of the points that all code reviews should include (see pull requests, below) is whether or not the code has been sufficiently commented.
We should regularly participate in paired programming; studies show extensively that when done correctly paired programming is a long term time saver. It enables stronger code, better structure, less revisits and debugging, and is a great opportunity for shared knowledge.
- Any new commits should get into a new branch
git checkout -b fix-bug-123
- When the developer wants feedback on its code, he creates a pull request.
- If the pull request is not ready to merge, he prepends
[WIP]to its name. - The developer adds more commits to the pull request as he gets feedback.
- When the other developers are happy with the code, and the tests are all passing, they can merge the pull request into
master. - If the pull request can't be merged because of conflicts issue, the developer rebases it against master (for simple merge conflicts) or merges master into it (complex merge conflicts that you want to keep a trace of).
- Github, CodeClimate, CircleCi, Coveralls assumes that the development branch is master and show comparisons based on this.
- You should have one branch per environment (
staging,production...) - Fast-forward merge
masterintostagingto ensure that there is nothing onstagingthat's not onmaster. Note that in this example,stagingis the branch that is being used for QA. - Deploy...
- And tag the current commit with a timestamp
staging-20140305- this then creates a historical, easily understood record of the code that was live at any point in time.
There should never be straight commit and push to master. All code must be done in a separate branch, and be submitted via a pull request (see above, git flow). Another senior developer will review the code - you should be on the look out for all the coding standards, best practices, commenting, etc. Any issues should be marked in the pull request - git hub has a great tool for feedback. There is nothing wrong will having your code marked for review or being asked to rework something - it will happen to everyone, repeatedly, especially while we get used to new coding standards.
The benefits of a solid test suite are manifold and varied; I'm only going to outline some basic maxims and tools to open the discussion.
Having a solid test, reliable and robust test suite is aim; a test suite that when it passes we can be relatively comfortable that our application is in good shape. It will never replace a QA team, but it should give us the confidence that our app is functional. To this end, TDD is unimportant - it doesn't matter if you write test before, during or after your code, as long as they are there when the code is committed, and they are solid.
Important points to note:
- All tests must fail at some stage. TDD tests will fail at inception, but if you write your test during or after coding functionality, it is very tempting to write tests that show what you did is working and leave it at that. This is a very dangerous practice, it is important to see your test fail, even if it requires changing code to make it happen.
- Every method will have more than 1 test, no matter how simple. At the very minimum there will be a responds_to test, and a input/output test. Most methods will have many more.
- Unit specs are the bricks and mortar of any good test suite. Making certain our building blocks and architecture are solid gives us the confidence to be able to build solid and robust applications.
- Controller and views specs can be covered by request specs.
- Request specs test pockets of functionality in isolation.
- Feature specs are the final layer of tests, where we test actual user paths through the site using a browser. We shouldn't get bogged down with these, they are intended as a last test to make sure everything is actually functional. We can use cucumber or spec for this layer (unimportant now, but food for thought).
Tests need to be kept light. We will be running these things over and over and over again, we need the test suite to be snappy so we're not help up needlessly every time the test suite runs. There are several concepts to keep in mind when writing tests.
- Don't hit the database unless you absolutely have to. This means building objects but not saving them. Very often you can mock and stub to stop a database hit also. If you are using Factory Girl then make sure you use FactoryGirl.build_stubbed over it's other model generation methods.
- Don't use Factory Girl unnecessarily. It is slowwww. It's main use it to quickly create complex model relationships.
- Mocks and stubs are your friend.
- Never make calls to external services, they can be mocked or recorded.
- Only set up the data you need for any given test at any time. The database should be empty except for data you actually need for that test or scenario.
- There are many other options and possibilities. Read and research.
Every bug needs to have a test written to reproduce it before it is fixed.
Code climate will report test coverage for us, as well as the rest of it's toolset. Test coverage is a great indicator, but has no value in and of itself. A very low value here (e.g. 60%) is a good indicator that we have a problem. A value of 100% is also an indicator that we probably have a problem.
All pushes to github will have the test suite run against them by CircleCI, so it's important that we run our tests regularly locally also. Guard is a fantastic tool for doing this, especially if you are practicing TDD.