Process of an app development
You can read it as “Process of software development” also, but as we are building an app here, let’s be specific!
This post is 2nd in the series of “Making an Instagram iOS clone app”. You can read the first one here: https://link.medium.com/mhuYgboyiX
Let’s say you found an iOS developer who can start writing the code right away, Isn’t that amazing? NO. Either they don’t know the proper process, or they don’t want to go through it. Having a solidified process means your app has a higher quality, and it is reliable and does not break when you add new features!
Below are the different phases of the app development process. Each step is a repetitive one, meaning, any of the steps you can come back to at a later point of time in the app development lifecycle. Which make sure the app has incremental changes and is capable of incorporating the user/testers feedback.
So, the game plan ♟
1. Requirement gathering — Clients describes the features and their priorities in order. Many developers believe that this is just a one-time thing, but it’s simply not true. The requirements may change throughout the life cycle of an app. So, it’s better to make it iterative. Personally, I like to be involved with the clients even in this phase, providing my expert opinions to give them more clarity on things.
2. Defining Product Backlog Items (PBI) — Divide and Rule. If there is a “Change of Requirements (C.R.)” then we have to establish new PBIs. We can categorize PBI into the following
- User stories — Written in the format: As a Type of User, I Want to do something, So that why do I want it. User stories are not complete without Acceptance Criteria and a discussion with the team to gain the full requirements of the story. [Retreived from ccpace.com]
- Technical stories — This represents any technical work the team must undertake during a sprint. For example, upgrade test tool or upgrade Swift 4.2 to Swift 5.
- Spikes — Spikes are done for knowledge acquisition. Spikes should be time-boxed and have specific acceptance criteria. A team member may ask for a spike to do some research, proof-of-concept, or prototyping to gain knowledge before working on a set of user stories. [Retreived from ccpace.com]
- Defects — As users work with the system, and testers test the system, bugs or other errors may be found.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.
3. Sprint Planning — This is to plan which features from the Product Backlog to work on for the next 2/4 weeks. Two weeks is a widely used sprint duration. Mind, that sprints are not ideal for research projects or creative thinking projects. Once a sprint is planned, the scope of the work does not change for the said sprint duration, unless it’s a very important one.
Sprints make projects more manageable, allow teams to ship high-quality work faster and more frequently, and gives them more flexibility to adapt to change.
4. UI Designing — This is where the User Interface (UI) is designed considering what the best User Experience (UX) would be. I am not an expert in this area, but I do know what a good or bad design is, and I try to use and incorporate what I have learned since 2008. UI Designing is part of the sprint and designers work alongside the other team members.
5. App Development — Finally, we are in the development phase. I love this phase the most. It is where developers put together UI designs and user stories, write the real code to create the “feature.” It is also a part of the sprint, and it goes hand in hand with designing and testing.
6. QA & Testing — This is a vital process. Ideally, automated testing (Unit testing and UI testing) should cover most of the code. However, it’s impossible to achieve 100% code coverage with any automation tool. Thus, we have to do some amount of manual testing before we can be sure that the app works as we expect it. If the QA passes all the tests (automatic and manual), then Bingo! We have a stable app release. Which can be distributed to the various testers via TestFlight (provided by Apple) for more feedback.
7. Retrospective meeting — This is where the team gathers and discuss what we can improve in the next sprint, which can make the process more productive.
During the retrospective, the team self-identifies elements of the process that did or did not work during the sprint, along with potential solutions. It aims to continuously improve the processes.
It’s been two articles and yet, nothing related to the app we are going to build. Please don’t get upset. We’re getting started with the app in the next article.
Pinky promise!
Hint: Next one will be about which cool features we are going to include in our Instagram clone app! Feeling excited? Have a question? Drop a comment below and smash the clap button multiple times.
Connect with me
Upwork: upwork.com/o/profiles/users/_~0194f1d4674802efaa/
LinkedIn: linkedin.com/in/akshitzaveri/
GitHub: github.com/akshitzaveri
Skype: akshit.zaveri
Stack Overflow: stackoverflow.com/users/2859764/akshit-zaveri
