Jump to:
Overview:
Terrestrial Origin uses SCRUM methodology in its development. Sprint length is usually 1 week but can vary depending on the needs of the project.
- There is a software release to the test environment at the end of each sprint. The purpose of the release is this:
1) Show the client how the features that are being worked on that week are implemented so that they can try them out and give feedback. This allows for rapid improvement that cuts development costs.
2) Allows my QA team to run a test on the codeset to make sure nothing got accidentally broken by the new changes. This keeps the bugs down and cuts costs associated with releasing buggy code to production. - Once the software being worked in is also in production, there is usually a second code release at the end of the sprint: the version that was tested in the test environment the previous week gets released into production.
- Every development task, whether it is a new feature, a bug fix, or a non-coding task goes into a JIRA backlog where it gets prioritized and assigned a level of effort.
- Every sprint the tickets are worked in order of priority.
- Software versions are also tracked in JIRA. A ticket associated with code is assigned to a release that’s tracked in JIRA. This keeps track of which code changes are put in which release.
- Non-coding tasks like QA testing and Graphic Design are done by professionals in that field. This both cuts costs and improves quality because it takes a professional less time to do a task and it’s done better. These services are included in the regular price of development.
- Code quality is important. All efforts are made to make the code self-documenting, modular, and re-usable.
Communication with clients:
- At the end of each sprint, there is an email that goes out that contains the following:
1) Which code release was just released to the test environment and which code release (if any) was released into production.
2) The list of tickets (new features, bug fixes, etc) that are part of each release.
3) If new features were implemented and released into the test environment for the client to take a look at and provide feedback, and if those features have to do with UI functionality, a demonstration video is created on where those features are located and how to use them. This can optionally be replaced with a live meeting where the features are demonstrated in the meeting itself. That takes more time, though, so the clients usually prefer a video they can watch at their convenience, re-watch it as needed, and save the video for training later if they want. It’s really up to the client which they prefer: a video demo, a meeting demo, or both.
Version control:
- Usually done in Bitbucket Git repository, but other repository systems can be used upon client’s request.
- Code is tracked in feature branches and release branches that allows flexibility.
All of the above processes are just the default and if the client has their own processes that they need us to follow, that can be done instead.