1.0 Responsibilities

1.1 Technical Product Manager Responsibilities:

• Gain a deep understanding of customer experience, identify and fill product gaps and generate new ideas that grow market share, improve customer experience and drive growth

• Create buy-in for the product vision both internally and with key external partners

• Ability to work well with internal teams, including developers, engineers, architects, quality assurance, and operations. Ensure requirements are fully understood and that implementation plans match expectations.

• Translate product strategy into detailed requirements and prototypes

• Scope and prioritize activities based on business and customer impact

• Understand, research, and follow technology trends in the industry and in general. Able to assess emerging products and companies to measure their potential value or threat to the company and its products, as well as make recommendations on which new technologies to invest in or leverage.

• Implement beta tests.

• Work with data pipelines, algorithms, and automated systems.

1.2 Associate Product Manager Responsibilities:

• Managing each project’s scope and timeline

• Facilitate all Scrum events, including sprint planning, daily stand-ups, sprint reviews, and sprint retrospectives.

• Work closely with the product owner to prioritize and refine the product backlog, ensuring that user stories are well-defined, estimated, and ready for development.

• Remove impediments and roadblocks that hinder the progress of the Scrum teams, fostering a collaborative and problem-solving environment.

• Monitor team metrics and key performance indicators to track progress, identify bottlenecks, and drive continuous improvement.

• Coach team members in Agile frameworks.

• Facilitate internal communication and effective collaboration.

• Help teams implement changes effectively.

• Promote a culture of transparency, trust,and open communication within and across teams.

• Stay up-to-date with industry trends and developments in Agile and Scrum methodologies, and contribute to the continuous evolution of Agile practices at Teamapt.

1.3 Engineers Responsibilities:

• Work with developers to design algorithms and flowcharts

• Produce clean, efficient code based on specifications

• Integrate software components and third-party programs

• Verify and deploy programs and systems

• Troubleshoot, debug and upgrade existing software

• Gather and evaluate user feedback

• Recommend and execute improvements

• Create technical documentation for reference and reporting

1.4. QA Engineer Responsibilities

2.0 Development Processes

2.1 Release Management Process

• Scrum Master documents future releases on JIRA before the commencement of a sprint. Each release should include;

  • Release Version

    • This follows the semantic versioning principle

      • Ex. v1.3.2 increment 1 - if there is a Major Feature, 3 - for Minor Feature and 2 - for Patch/Fix (see for detailed explanation: Semantic Versioning 2.0.0 )

      • Releases on DCIR would be tagged according to the components affected e.g. if the frontend component is affected, the release would be tagged U.I v1.x.x. Tagging will be done by the engineer with the purview of the scrum master

      • For patches and fixes, the tagging would be done automatically by attaching the build number on Jenkins

  • Summary: 

    • Major and Minor features included in the release

    • Fixes and Patches

    • Components Affected

    • Compatible version: UI and Services

  • Description: A description of what is to be accomplished with the release

  • Approvers: 

    • QA Engineers

    • Product Managers

  • Epics, Tasks, and Bug Tickets are covered in the release.

  • Release start date: Usually sprint start date

  • Release end date: date when the binary (jar) is packaged and put on standby for onward deployment to banks.

  • Hofit fix Release process: In the situation where a hotfix needs to be released, the hotfix and any development feature or fix that is ready to be released will be added to the hotfix and released in the next release (already documented on JIRA). A new release version will be created for features/fixes still under development. 

• Environments used in the release process

  • Environments

    • Playground Environment 

      • Engineers can test their builds at this level before confirming functionality is working as expected. 

      • At this level trial and error, rnd and tinkering take place.

    • Development Environment 

      •  Quality assurance reviews for new features are undertaken within this environment.

      • It contains the latest build version of the application after QA  sign-off.  

      • Hotfixes and Platform patches are reviewed within this environment.

      • Load testing and platform optimization take place within this environment. 

    • Staging Environment

      • Replica of Production environment

      • Runs same database as bank’s live environment (MsSQL)

    • Production Environment

      • Live environment

      • Controlled access - Banks and TeamApt personnel.

    • Demo Environment

      • Ideal environment for training and presentations.

      • Depending on the release cycle, it may contain a replica of the production version.

      • Runs the most stable version of the application. 

      • Periodically updated with new features after stability.

      • May not contain the latest version.

      • To save on resources, it can be brought up or down with ease on demand.

• Repository Branching Structure in relation to environments and releases

  • Playground Environment - Any feature branch

  • Development Environment - Review-Dev

  • Demo Environment - Binary from stable release

  • Staging Environment - Main

  • Production Environment - Main

    • DD & DCIR - Bank Env

    • TPP & Switch - TeamApt Cloud

  • Each JIRA ticket should detail the respective Gitlab branch/repository - The engineer’s responsibility with Scrum Master Review. 

See Screenshot below

Open

See flow chart below for the branching process.

Procedures in blue are performed by the Scrum Masters, while those in red are performed by the engineers. 

See flow chart below for the QA process.

Open

2.1.1 Release Cycle

DCIR is moving to a quarterly release cycle to deliver regular updates to our banking partners.

Here's what you can expect:

Monthly Releases: New features and bug fixes will be rolled out on a monthly basis.

DCIR Suite Versioning: Each release will introduce a new DCIR Suite version number. This version will reflect the updated versions of all components included in the suite.

Benefits:

Faster Innovation: Monthly releases allow us to deliver new features and improvements more frequently.

Improved Stability: Regular updates help address bugs and potential issues proactively.

Simplified Tracking: Clear versioning simplifies tracking changes and managing deployments for banks.

Here's a breakdown of the steps involved in the new DCIR monthly release cycle:

1. Release Preparation

• Jar Compilation: Updated JAR (Java Archive) files for all services included in the release will be compiled and stored within the designated product version folder on the DCIR Google Drive: https://drive.google.com/drive/folders/1lGUeegdrP6bNqIlvn5eIMWqO8jSW3VGB?usp=drive_link

2. Release Documentation

• Release Notes: A detailed document outlining the features, enhancements, and bug fixes included in the release will be created and shared with the banks: https://docs.google.com/document/d/1VgdmxLSda5oTtxvNa6zfgCsTBlBw-q9Ym2OH1LufLbo/edit?usp=drive_link

• Deployment Notes: Internal documentation detailing deployment steps, updated configuration files, component diagrams, and relevant application properties will be created. This will be shared with the tech support team and provided to banks on demand. https://docs.google.com/document/d/1e_4bS2nGhHz6KBj4nqPzR2rDJ7T-Fqi2U3cIpY0hEzw/edit?usp=sharing

3. Change Approval

• Change Advisory Board (CAB) Review: All changes and product releases must be approved by the CAB. This approval will be granted following a successful demonstration and walkthrough of the intended changes by the Technical Product Manager (TPM), Quality Assurance (QA), or Enterprise Architect (EA) responsible for the release.

For increased transparency, the DCIR portal landing page will now prominently display the current DCIR Suite version.

2.2 Sprint Management Process

• Weekly Sprint Planning/Task Prioritization Sessions. 

  • Input:

    • Project Backlog

  • Objective:

    • To discuss priority tickets to be worked on during the sprint

  • Stakeholders: 

    • Project Managers 

    • Scrum Masters

  • Deliverables:

    • List of tasks to be completed for the sprint

    • Tickets assigned to engineers for completion

• Daily Bug Triage Sessions (15 mins) to review priority after stand up sessions. 

  • Input:

    • Newly identified issues

  • Objective:

    • To reevaluate priorities based on new discoveries

  • Stakeholders: 

    • Project Managers

    •  Scrum Masters 

    • Tech Support

  • Deliverables:

    • Updated priorities 

    • New tickets assigned to engineers for completion

• Prioritization Formula

  • High: (Added to SPRINT)

    • Production issues that impact core product function. E.g transaction processing and settlement issues. 

  • Medium (Tracked via Bank EPICS)

    • Bank customizations and integrations

  • Low (Added to SPRINT)

    • New features that provide business value and improve product usability

Notes:

If an engineer for any reason has to halt a lower priority task to focus on another task of higher priority, the engineer should indicate the task ticket the reason for pausing development and also update the block start and end dates on the ticket. 

2.3 Jira task documentation guide

• Product Management Process: Refer to Product Management Process Document

• Scrum Master Dev Task Documentation Process :The following links should serve as a guide on how to document development tasks by the Scrum master

  • Frontend Task Sample: https://teamapt.atlassian.net/browse/ADD-457

  • Backend API/Job Task Sample: https://teamapt.atlassian.net/browse/ADD-455

  • Database Task Sample: https://teamapt.atlassian.net/browse/ADD-458  

• QA Bug Reporting Process: Bugs discovered during testing should be reported on JIRA with the

  • A summary of the bug

  • Steps to reproduce the bug

  • Screenshot or video recording 

  • Link to affected user story

  • Link to test case 

  • Engineer, PM, and SM should be tagged in the comments after logging the bug

2.4 Post-Production JAR Build Process

Files for deployment to include:

• Jar File

• Cosmos JSON (If Management Service Change)

• Release Notes