Banco Itaú - Iti
#The Challenge: Developing a feature of millions users and dollars
DISCLAIMER: To comply with my non-disclosure agreement. I have obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of Banco Itaú.
The company
Banco Itaú is one of the biggest banks in Brazil, offering a wide range of financial services, including personal banking, corporate banking, and asset management.
My position
I worked on this project for almost 3 years as Senior Android Developer. During this time, I faced some very interesting challenges, such as developing a feature for a loan MVP, deploying it for more than 10 million users, bringing in a monthly value of around 5 million dollars for the company after deploying the feature and creating an app that is 90% accessible to People with Disabilities (PwD) who can use it with talkback. I was responsible to mentoring others developers, release new versions using the process of gitflow, CI/CD and following some quality measures.
The methodolody and the time
The methodoly used to the MVP considering the software engineering was the agile/scrum model and the deadline proposed was 6 months of development. So, as the model was based in scrum I will describe how was the evolution considering the following steps: Analysis, Planning, Backlog, Progress, Done, Analysis and Retrospect.
Analyse
The project started with the PO (Product Owner), APO (Assistant of Product Owner) and the Designer obtaining the requirements and the bank necessities for Loan Feature. The requirement analyst, some managers and lawyers met with product owners, and supervisors to collect everything necessary to be in the feature. After the analyst brought the requirements, there were some brainstorm meetings using Miro as a tool to register the suggestions and to sharpy the ideas to the designer create a concept of mockup screens. With the concept in hands the designer and the PO and APO have a meeting to design the features, some rules and user experiences for the final users and created a version initial of the MVP.
Planning
When the proccess of the planning starts, a meeting is created containing developers from mobile and backend, designer, product owner and their assistant, transformation lead and tech lead. All of them will discuss the viability of to develop the app and how it should be.
Development
The development proccess start with the developers getting some tasks, stories and bugs from the 'backlog' column from the scrum board and moving then to the 'in progress' column. The developers will code the feature requested or solve bugs following the app architecture (MVVM + Clean Arch) and adaptating/creating unit or instrumentation tests if necessary. After have wrote the codes, its necessary to submit an pull request to the others developers review if there are some vulnerabilities, code smells, warnings, wrong business rules, transgressions of SOLID principles. So, this is an interesting opportunity to get feedbacks about the code and know good practices with experienced developers that worked in another companies. If everything is ok with the pull request and the pipeline passed in all the steps, such as: SONAR (measure the code quality), LINT (verify if the code is formatted using the code style), UNIT TEST AND INSTRUMENTED TEST passing without errors and BUILD to signing the apk with a private key, OBFUSCATING the final code and generated a version to the Q&A validate if everything is ok to deploy in the store.
Retrospective The proccess of retrospective is to identify situations during the sprint that were: 'good', 'need to improve' and 'bad'. The final purpose of the discussion is to elaborate and identify points and issues which ocurrend during the sprint and create action plans to avoid these situations happen again.
Deploy
The proccess of deploy a new version in production is determined by the Q&A, PO and Tech Lead. The keywords here are: QUALITY and VALUE to the final customer! If the Q&A says a version contain a critical bug and can affect the user experience or bring issues for the company, the release of the version is automatically cancelled.
Monitorying
With the app in production and published in the store a senior developer and the tech lead are responsible to monitor if there are some bugs or crashes happening with the users. If something happen is necessary to identify the criticitity of bug and depending solve it as fast as possible.
