Recently I updated
eldarion-ajax to have more robust tests along with 100% test coverage. I wanted to get to this point before I venture into some potentially aggressive refactoring.
For a long time, we used TravisCI and Coveralls for executing lint checkers and tests and tracking our code coverage. These are fine tools but we’ve recently switched to CircleCI and CodeCov. This is our default setup for projects.
It can be fairly common to have situations where your users need to quickly add
items to a list, edit those items, and perhaps even sort them. Ideally,
we can keep the user focused on their data and tasks rather than how to
navigate the software facilitating the work.
Code coverage is an important aspect of good engineering practice. Without it, you are flying a bit blind writing tests.
In the previous parts we have learned how to write stories, groom and point them. Everything up until now has been done to prepare us to be able to plan a sprint.
Before you add a story to a sprint it should be pointed. Pointing a story means
assigning a number that represents complexity to it. Metrics like velocity are
driven by these points.
It is important to constantly be refining your backlog. This is accomplished through time-boxed meetings where the team performs an activity called grooming.
Every successful Scrum project starts with a solid backlog of items. Developing a good backlog requires discipline and vision.
We have run a lot of successful projects with Trello following a rough
Kanban-style approach that focuses on continuous delivery. However, as we have
taken on projects that involve more people and have longer timelines, the process
and tooling left us wanting more.
In building wine.study, we quickly got to the point where we were experiencing a development bottleneck in the construction of components. This bottleneck occurred due to a number of reasons. We solved it with a live style guide.