From a project management perspective, we use a custom workflow that we built based on our experience in the FinTech industry. It’s a combination of best practices from the PMI workflow and Agile frameworks.
Stage 1. Initiation
- Product Owner prepares a high-level vision of the end product with a description of business processes and expected use cases, provides mockups if available, and references to competitors if they already exist.
- Business Analyst, CTO, PM, UI/UX Designer from SDK.finance analyze the provided information, forming a list of questions related to the product.
- Business Analyst, CTO, PM, UI/UX Designer meet with the Product Owner and discuss the high-level product vision in detail.
- Project Charter is created to make a direct link between the strategic objectives and the project.
The project charter should disclose:
- project purpose
- measurable project objectives
- high-level requirements
- high-level description, boundaries, and key deliverables
The Project Charter should be signed off by the Product Owner.
Stage 2. Planning
- Product Specification: Business Analyst, UX designer, and CTO convert a high-level vision into a fully-detailed document with text, schemes, diagrams, UI mockups, dataflow, use cases, etc. It could be files, mockup screens or shared Confluence space. As a result, all articles should be approved by the Product Owner.
- Resource planning: SDK.finance team examines the scope of work and the expected delivery timeline and estimates the capacity of the team dedicated to a project.
- Project Manager prepares WBS (Work Breakdown Structure) for developers based on the Product Documentation. All tasks should be estimated by the Team Leader or Senior Software Developer and PM.
Schedule baseline, scope baseline, and resources plan will be prepared based on SoW (Scope of Work).
All acceptance criteria and definitions of done should be identified and documented in this phase.
Stage 3. Software Development & Quality Assurance
- The agile software development process is characterized by iterative sprints (Scrum model). Sprint is a predefined increment of the time. Within this time frame, the team works on the delivery of an agreed increment of work to provide the Client with certain business value. Each system release differs from the previous one by small changes. At each sprint, the system is tested. This model works best if you want to detect issues before they appear or mature into more significant challenges.
- The development of each new feature is followed up by code review of Senior/Lead Developer and manual Quality Assurance (QA) procedures as well as using the different types of QA software. QA creates the test documentation (use cases, test scripts) as a part of the development based on specification agreed by the Product Owner. Each new module is documented in the code, covered by integration tests and unit tests (optional).
- For passive code analysis, we use Spotbugs, PMD, and CheckStyle. For active code analysis, we use SonarQube, which is highly recommended by the OWASP community.
- PM and CTO agree to the “code freeze” periods with the Product Owner beforehand that should happen not less than once per 3 months. The time frame for the “code freeze” should take 1-2 weeks or a period needed with regard to the scope of work done before. Within this period the team is not working on the development of the new features and only concentrated on the code cleanup, performance tests, system optimization and bug fixing to create the stable version and remove the possible bottlenecks for the further system growth.
- PM, BA, CTO and Tech Lead and Product Owner should have scheduled weekly meetings for management purposes and discussion of the new features specification (the same procedure as was done during the Planning stage). As an option, the PM and Product Owner can have a daily sync up call to track the progress. Each Sprint ending is followed up by Release notes, Use cases. Each month is recapped with a Monthly Report.
Stage 4. User Acceptance Testing (UAT)
The Product Owner and a team of the Client should go through the UAT checklist created by SDK.finance QA and PM. UAT list is followed up by Use Cases and Test Cases to help the Client’s team confirm the completeness of the UAT list according to correct conditions and pre-conditions on Pre-production servers. Pre-production servers should be equal to the Production Environment infrastructure.
Stage 5. Go live
After the UAT list is checked and confirmed by the Client, the code is deployed on the Production Infrastructure which allows the Client to sell/provide their service to the live end-users/clients/partners.
We use a simple check-list that enables us to control the system behaviour in live mode:
- Resource monitoring and telemetry analysis
- Application Performance Monitor
- Databases Performance Monitor
- Security incidents monitor
- Clients behaviour analysis
- Log data analysis
- Anomaly detection