How We Build Software: Development Process at Cleveroad

1705 Views
|
21 Mar 2020
|
12 min
author avatar
Maria D.
Copywriter
author avatar
Denis B.
Project Manager

Software development process may seem tricky, especially if you're working with a remote team. That’s why we’ve created this brief guide that walks you through the development process.

In it, we give answers to the following questions:

  • How do we start the process?
  • How many people do we need? What are they responsible for?
  • What tools do we use for design, development, testing, and communication?
  • What will you get at the end of each stage?

So, here’s how we create software – from Sprint Zero to product release.

What’s a Sprint in Software Development?

But first things first.

In Agile development methodology (which we follow), Sprint is a period when a team has to complete a set amount of work.

Here’s how a Sprint works:

Each sprint lasts for two weeks (ten working days) and starts with a planning meeting. In that meeting, the product owner (client) and the development team agree on what work will be done during the Sprint.

A Sprint starts on any given working day, depending on the Project Manager's (PM) workload. Together with the client, they negotiate the starting day to prevent any mix-ups, and this date must be specified in the contract.

Now, let’s move to the actual Sprints and what happens at the beginning and the end of each.

BA Stage: Sprint 0

Sprint Zero is mainly about planning – it’s a preparation period before development starts.

!

Here we give a brief description of the planning stage. We’ve got everything covered in 'What’s a Project Planning Phase For?' guide, see it for more details.

First, Business Analysts (BA) prepare the list of features, work on the communication plan, and estimate how long the planning stage will go for.

Next, they define the scope of work (clarify the client's requirements) and document these requirements in a Project Specification.

The Design Team then creates wireframes, a schematic layout of the future UI design based on user stories.

How design wireframes look like

Wireframes we prepared for one of our projects, RetailOps

Quality Assurance (QA) team checks the specification and wireframes. Next, developers (web, iOS, Android – depending on the platform) together with the UI/UX designer and PM start working on a detailed project estimate.

The client then looks through the estimate and, if everything works for them, signs the contract.

After that, PM starts writing a Project Plan based on the number of devs who will be working on the project. This plan, just like everything else on this stage, should be approved by the product owner.

Sprint Zero members and their responsibilities
Team member Responsible for

Sales Manager

Organizing the team, preparing the contract

Business Analyst

Preparing user stories, validating wireframes

Project Manager

Validating user stories, wireframes, preparing a Project Plan

QA Engineer

Validating user stories

UI/UX Designer

Creating wireframes

Developers

Preparing a detailed estimate

Deliverables during Sprint Zero:

  • Specification
  • Wireframes
  • Detailed project estimate

BA team and Project Manager stay in touch with the client during this Sprint, updating them on the work status.

Design Sprint

Now, let’s see what happens with the product UI/UX design.

As soon as the client approves the wireframes, designers start working on visual concepts (2-3). The owner then approves one of the concepts, and the team designs the screens showing what happens after a user clicks on each UI element.

RetailOps design by Cleveroad

RetailOps app, designed screen by screen

If the owner approves the work, UI/UX designer handles the project to developers (using Zeplin) and switches to a supporting role. From now on, if anything – icons, fonts, other graphic elements – gets lost or any design-related question arises, they take care of it.

?

Want more details? See how we go about UI/UX designing in our extensive guide.

What designers do
Team member Responsible for

UI/UX designers

making 1-2 visual concepts (pick colors, fonts, create a mood board, design 3 main screens), style guide, preparing all the screens and their possible conditions, making a clickable prototype

Deliverables:

  • Visual concepts
  • Design for a few Development Sprints

First Day of Sprint 1-N.

And we’re getting back to the software development services. Sprint N means any Sprint following Sprint 1 – Sprint 2, Sprint 3, and so on. If you want to know how long it'll take to build your software (and how much it'll cost), use our app cost calculator.

Sprint 1 starts with:

  1. Project setup.
  2. Setup for test environments.
  3. Continuous Integration/Continuous Delivery (CI/CD).

Let's break these steps down a little bit.

Project setup

A Workplace Admin creates repositories and gives access credentials to the team.

Test environments setup

If, according to the specification, the team needs to develop a server-side backend or frontend, DevOps prepare two servers:

  • Dev server (AWS) for the team to work on functionality, bugs, optimization, etc.
  • Stage server (AWS) used to show results to the client.
CI/CD

On the first day of First Sprint, DevOps configure Continuous Integration (CI) and Continued Delivery (CD) processes for the project.

Tools DevOps use for environment setup

DevOps tools

That’s what happens on the first day of the very first Sprint. The rest of the process is pretty the same for all the Sprints. We're describing what is going on days 2-10 of any Sprint in the next part.

What the team does on the first day of any sprint:

  1. Holds a planning meeting
  2. Development
  3. Design for the next sprints
  4. Prepares test documentation

After the planning meeting, QA starts working on the Test Plan of the current Sprint using Sprint Backlog.

Test Plan includes:

  • Acceptance tests for checking positive/negative scenarios, permissions of user roles.
  • Testbed configuration (includes OS name and version, browsers, mobile devices)

And here’s what the team members do:

Responsibilities on 1st day of Sprint
Team member Responsible for

Project Manager

Up-to-date JIRA tasks

Designers

Supporting developers

QA engineers

Writing the Test Plan

Developers

Development according to guidelines for specific platforms

DevOps engineer (1st sprint)

Environment setup (dev, stage server)

Deliverables of the first day of Sprint 1:

  • Email, notifying about the Sprint start
  • Plan for this Sprint

Second – Penultimate Day of Sprint 1-N

Now, what happens every day during Sprint N:

  1. The team holds daily meetings
  2. Continues development on the scope of this Sprint
  3. Continues design for the next Sprint
  4. Prepares backlog for the next Sprint
  5. QA checking tasks

Each new day starts with the meeting where the Project Manager checks the status of tasks – what has been done yesterday, what’s going to be done today, and what gets in the way.

One more thing: when a team member starts working on any task, they turn on a timer. They stop it once they complete the task.

Every time a developer finishes working on a feature, they must test it. These checks include not only functional testing but also platform acceptance criteria.

Once the devs change task status to "Ready to Test," the QA team starts checking on the feature according to tasks, sub-tasks, and user stories.

If they find out that:

  • Main functionality doesn’t match specifications
  • UI doesn’t fit design
  • No dev testing has been done
  • Negative cases aren’t passed
  • Small UI issues

…they reopen the task adding a comment that describes the issue, steps to reproduce it, a crash log, and/or screenshots. Or create a new task with a Bug label.

!

Bugs don't stand a chance. Find out what types of software tests we run and what for.

What team members do on day 2-10
Team member Responsible for

Project Manager

Holding daily meetings, preparing backlog for the next sprint

UI/UX designer

Supporting developers

QA engineer

Ad hoc testing, acceptance testing

Developers

Writing code, dev testing, keeping code documentation up-to-date

Last Days of Sprint N

In the middle of the Sprint, the PM initiates a planning meeting with the client to pick features from the project backlog and move them to the next Sprint backlog. Also, the PM starts working on a specification for the next Sprint.

What else happens in the last few days of Sprint 1-N:

  1. Daily meetings
  2. Code freeze (day 9)
  3. Preparing of Sprint and test reports
  4. Product Demo (day 10)
  5. Retrospective

At the end of the Sprint, the Project Manager prepares a Sprint Report with information about the time spent and time initially planned. Sprint Report also includes:

  • List of completed features
  • Not completed features (and why)
  • Change requests (if any) implemented during the sprint
  • Change requests not implemented during the Sprint (and why)
  • Bugs
  • Time spent, including bug fixes and change requests

Finally, the team works on the Product Demo. This process may take from 24 up to 150+ hours per Sprint. Before the Demo, QA team checks features added in the current Sprint as well as goes over the whole app making sure new functionality doesn't break the old.

Product owners test Demo for some time (for example, till the end of the working day). If the clients find any issues, they should list them. These issues must be added to Project Backlog and fixed at no additional cost.

Sprint 1-N deliverables:

  • Builds on the stage (testing) server
  • Checklists
  • Sprint report

At the end of the Sprint, the team gathers for a Sprint Retrospective. It goes after the owners accept the Demo but prior to the next Sprint planning meeting.

The team discusses:

  • What went well
  • What could be improved
  • How they're going to improve it in the next Sprint

Finally, let’s see how the release process goes.

Product Release

Once the team finishes all Sprints, QA starts the regression testing process. They run tests on all platforms and all features and, if requested, perform Stress testing. That means they check how the software works under a heavy load to find it's breaking points.

During this stage, QA engineers use previously written checklists. In some cases, they need to modify them, testing only the main features of the product.

Deliverables of Regression testing stage:

  • Regression checklists
  • Backlog of defects
Testing tools used at Cleveroad

Tools used for Performance/Stress testing

After the regression testing, the team is ready to start the Release process.

First, the QA team runs Smoke testing to detect simple failures enough to reject a software release. They perform:

  • Smoke testing of Dev builds
  • Smoke testing of Stage builds
  • Smoke testing of Product builds

If they detect any major issues, devs have to make hotfixes. And do it fast, before releasing the app to Google Play, App Store, or moving it to the production server. That’s why the team doesn’t leave their workplaces until the owner accepts the work.

Once the owner is satisfied with the result, the team hands project materials over to a client.

Responsibilities during product release
Team member Responsible for

Project Manager

Planning & meeting with the client, preparing specification for the next Sprint

QA engineer

Regression testing, stress testing

Developers

Making hotfixes

DevOps

Automatic build deployment and delivery

Deliverables:

  • Deployment into production environment
  • Source code
  • Apps (if any) published on Apple Store or Google Play

Development Process by 3 Types of Contracts

We work with three types of contracts–Time and Material, Fixed Price, and Dedicated Team. And our approach to development is a little different for each of them.

?

Which contract type is right for you? Find out in our ' IT Outsourcing Pricing Models and How They Differ' guide.

Time and Material

Time and Material (TM) allows us to give an approximate scope estimation, and start a project without having an exact scope of work in hand. TM is a flexible model–we plan each Sprint and agree all the Sprint and test plans with our clients.

Here's how development goes under TM. We deliver a Demo, test it, send checklists, and Sprint reports to the client – they confirm it – give their feedback – we take their feedback into account when planning the next Sprint.

Time and material pricing model

Software development process under TM pricing

If there are any changes in Sprint 1, we’ll apply them in Sprint 2, and so on. We list the changes our owners want us to make, document them, and estimate how much hours each of these changes takes.

It’s easier to manage the requirements under TM–we can slightly change the scope even in the middle of the dev process.

Now, what's the case we miss a deadline? Then we send a bill only for the scope of work we've finished. Such situations are rare and usually happen because some critical information wasn't provided to us, or the scope wasn't appropriately estimated.

Fixed Price

Fixed Price has a fixed scope of work, estimated in detail, well-defined requirements, and strict deadlines. Everything is planned and estimated beforehand, and there's no room for changes.

Still, if our client insists on making some changes, we can write them down as 'out-of-scope tasks' and implement these changes after we finish the confirmed scope.

Fixed price type of contract

Fixed price model flow

We pay great attention to the deadlines, especially when it comes to fixed price contacts, and strive to deliver the work in time. But if any delay happens, the team works in their free time to finish the work asap. Of course, we don't charge any extra money in this situation.

Dedicated Team

In most cases, our clients sign this contract when it comes to large-scale complex projects. Our job here is to provide skilled software engineers and agree on cooperation terms. Developers become full members of our client's team and follow it's corporate culture.

The development process and it's management go entirely on our client's side. We can only help with some organizational moments.

Dedicated team pricing model

How development process goes under Dedicated team pricing

Wrapping Up

That’s it! That was a brief description of how the software development process goes at Cleveroad. Want to see the projects we’ve developed this way? Take a look at our portfolio!

Any questions left?
Feel free to ask, and we’ll walk you through the process.

Bonus: We've made an infographic that ties all the detail together.

Software development process

How software development goes at Cleveroad

Rate this article!
An image
An image
An image
An image
An image
(1384 ratings, average: 4.61 out of 5)
Leave a comment
An image
Your message is checked by the moderator and
will add to the site ASAP
Latest articles
Back to top