The CodeCoda Software Development Process!
CodeCoda focuses the Digital Product design process around our clients specific needs. We built CodeCoda, to solve a major problem in the Software Industry; Client focus.
Our processes are perfectly designed and implemented to meet our partners requirements, while still staying personal on the communications level. We believe in a deep agile software development process, and our philosophy is tightly integrated around delivering incrementally fast, innovative software products and services.
While we base our software delivery process on the Agile Manifesto, we use several methodologies, based on our clients’ needs, to switch to. We use the Scrum, Kanban, or Waterfall methodology and frameworks, always identifying the most appropriate agile solution for our clients. Our experience in Software development has shown us that approaching the delivery process in an agile manner, is the only way to deliver added value to our customers.
The Process
Development kick-offAny project undergoes a predefined collaborative stage, in which we involve the client and the whole designated development team, led by the respective project manager.
The first stages are:
- Team Meeting
- Product / Project discovery
- Release Planning
Depending on the selected agile development methodology, our development teams are organized to frequently release updates to branches. This might either be: Staging, or Live branches, at later stages in a project
Every development cycle includes:
- Planning
- Daily Meetings
- Cycle Reviews
- Retrospective Reviews
- Project Management
Scope, change management and Budget
The type of innovative projects we deliver, include by nature, that certain changes and additions can be introduced in the cause of development. A backlog is used for this purpose, and the items in the backlog influence the planning of the next development cycle, always depending on the priority and importance of the task/feature at hand.
How are Development Scope and Budget linked?
- Development Teams, Project Managers and Project Owners are accountable for recommending, or the decisions taken thereafter affecting the budget of the development process.
- Development Teams are responsible for continuously estimating the respective Backlog and tracking the work in the pipeline. This process allows accurately tracking actual work, as well as the speed works are executed.
- Product owners are responsible for mainly non-technical changes in scope, setting priorities or defining the objectives of the current development cycle or the objectives overall.
- Project Managers and/or Scrum Masters together with development teams are responsible for timely deliverables and predicting release dates.
- Continuous evaluation of predicted delivery dates and scope helps to establish structure and size of development teams, but also the budget.
Compared to a top-down, or in other words management centric approach, we give our clients full control over scope and cost-control.Managing Project Risk
We tend to identify risk early in the product development cycle, and most of the times, the main factors are discovered during the “Product Development kick-off”. If for any reason and risk is identified at a later stage, we set up meetings with the stakeholders and work out a plan to bypass the identified situation.
When Risk is discovered during product development, we hold a Risk Management Session, including Project Managers, Product Owners and all other stakeholders. This way we, together with Product Owners, can react quickly and disperse risk before it arises.
Most importantly, we communicate risk with proposals and concrete action plans, including summaries of Backlogs, burndown charts and key decisions taken.
Product Owners receive weekly, bi-weekly or monthly development reports with summaries of executed tasks, backlog burndown charts and taken key decisions.
Development Process Standards
Coding rules and StandardsOur teams follow respected coding standards to provide a consistent, easy to understand, and maintainable codebase. Independent of the technology used, we choose the standard which reflects best practices for the technology at hand. We implement the best and most reliable new technologies for our products, and we use reliable and tested frameworks, tools, and follow the trends in technology.
Definition of DoneEvery functionality or change in the final code we deliver meets pre-set criteria listed in our definition of done, which assures quality and consistency in deliverables.
When starting a new collaboration with a client, we always agree what the status ‘done’ represents. Our standard definition of done states, that a user story, epic, task or bug from either the Product Backlog or assigned tasks is done when it is…
| Defined | There is a common understanding between Developers and Product Owners how the product should look and behave |
| Implemented | The task is developed, going along with unit- and functional tests. Graphical User Interfaces are fully implemented |
| Integrated | All tests are automatically passed |
| Checked | A developer has manually tested the task / functionality |
| Reviewed | Code has passed Code Review and is accepted by another 2 developers (4 eye principle). |
| Accepted | Code is tested, and accepted by QA, or another Developer, and is accepted by the Product Owner |
| Delivered | The code is committed to a repository, and delivered to a proper application environment (preview, QA, Staging or Live) |
Our Code Review process ensures that every piece of code is reviewed and approved by 2 different developers than the one who developed it. Our approach of Continuous Integration (CI), baked in Unit Testing, Automated Functional Testing, testing the graphical user interface, and other best practices allow only the best of breed code to pass into real life code bases. We thrive to focus around 5% of our time on reviewing and ensuring our work is conform with our own, and best quality delivered for our clients!
Code MetricsAutomated test tools like Sonar, Jenkins or Travis CI are used to check our code bases regularly. Fixed procedures ensure and prevent cyclomatic complexity and repeated code. With the outcome of tests we aim at improving codebases and avoiding bottlenecks which can arise during development. We also achieve outstanding test coverage by allowing automation to deliver reports.
Continuous Integration (CI) / Continuous Development (CD)CodeCoda uses CI/CD as a development practise. Codebases are merged frequently which helps avoiding integration problems. Also we leverage Jenkins CI for automated quality reports and automated tests in the deployment pipeline. This process ensures that only quality code which passes deployment criteria and relevant automated tests is delivered into production code-branches.
CI tools also allow schedule- or event based automated tests, providing feedback to the development team about code and quality standards. These tools and regular time-based regression tests significantly improve the quality of code written by Software Engineers and work as a primary level of code verification.
QA - Quality Assurance
To ensure the best level of code quality and usability comprehensive tests are carried out by Quality Assurance Engineers. Depending on our clients needs, we prepare individual quality assurance guidelines on a per project basis.
Scope of QA testing- Unit Tests - small pieces of code, so called units or methods are tested on whether their functionality in- or outputs the correct values. Various patterns are tested, which can be either: Result Tests, State Tests, Fluent Builder tests, database tests, database builder tests or integration tests.
- Functional Tests - Software Modules are tested as a group.
- Smoke Tests - This type of tests are used to test that the most important functions work, and is used to decide if a build is stable and whether other tests can proceed.
- User Interface Tests - The UI is tested for compliance with design guidelines and it’s compliance to previous mock-ups.
- User Experience Tests (UX) - Usability from a user’s perspective is extensively tested and measured.
- Regression Tests - Testing that any new implemented code does not break any previous implementation.
- Security Tests - Data Security is tested and measured.
- Performance Tests - Testing responsiveness, performance and stability of an application under a simulated workload.
- Manual Acceptance Tests - The application is checked against initial specification requirements.
A dedicated QA Engineer supports individual teams and helps to set up automation tests and the integration of regression tests, executes manual tests, and performs test scenarios. In most cases it is crucial for development teams to have QA support to maintain high quality and stable products.
Automated TestingIn development a certain rule set of best practices is essential to guarantee maintainable code bases. Find below some of the techniques we use:
- BDD - Behaviour Driven Development. We use Gherkin to abstract behaviour and provide a clearly understandable language to both, software engineers and stakeholders.
- TDD - Test Driven Development. A process to cover written code with tests. This helps in the early stage of development to have bug free code.
- Automation Tools - a large variety of tools are used, always depending on the target of an application.
Delivering Excellence
The above process describes several years of experience we gained by tuning and fine-tuning development teams and processes. Our processes help us to create long lasting relationships with businesses and deliver first class software products to start-ups and large scale enterprises alike.
At CodeCoda we value people, and the relation between them first. This is why communication and collaboration is the main asset we deliver when working with our clients. We love it to help our business partners and clients achieve their goals. This is what the Agile process means to us!
