Custom App Development Staff Augmentation for Salesforce Partners

• In this project, every developer worked with one or more clients to work in the front end as well as backend. They scoped tasks, provided data modeling, and collaborated with the company’s project managers and their clients to provide the best solution for each project. 

Communicating

• Team communication: To keep all projects on track, the team began each day with a virtual scrum meeting, reviewing any blockers. Throughout the day, the team would collaborate using Slack and Google Drive. This made things extremely easy for our nearshore team to always be on top of things.
• Client communication: When communicating with clients, the team adapted their communication to the tools the client was most comfortable with. That typically meant calls on GoToMeeting, Zoom, or Google Hangouts.

Scoping

• Analyzing: All work for these projects was tracked using a ticketing system. Each ticket would be assigned to the appropriate resource for that user story. In this phase, the team member would analyze how the solution should be implemented to meet the acceptance criteria. Often the work was related to external tools that integrate with Salesforce, external packages, and even Salesforce declarative tools. It is very important to know how the tools are going to solve and meet the client’s requirements. Our developers provided these details and worked to solve questions in three basic stages: 1. Clarify the requirements and consult official sources; 2. Documented step by step using our partner’s template; 3. If required, a prototype or demo to show the client and answer the question in a meeting. 
• Prototyping: Some work centered around proof of concept tasks, commonly known as POC tickets. This typically consisted of researching step-by-step documentation and sometimes creating demos or small apps to demonstrate (or validate) a particular approach for the client.
• Approving: After a task has been scoped, it is updated in the system and Salesforce Chatter is used to notify the project manager and QA engineer. The QA engineer adds to the scoping, then moves the ticket along to the project manager. In cases where there are outstanding questions, the ticketing system is used to track all discussions. Once both estimates are in the deck, the project manager marks the ticket as completed. Development begins only after the scoping is approved.

Developing

• Preparing the environment: The first step in the development phase requires checking the credentials in the user story to log into the sandbox org where the development happens. Once the credentials are set, developers retrieve the ArcGIS metadata using SalesforceDX and Visual Studio Code to prepare the org for development. 
• Documenting change: Some items for our solution could be configured by an admin. For example, using custom metadata types or custom settings to manage features. In these cases, documentation needs to be created using the company’s template for the user story to create this document. When finished, it needed to be shared with the development project manager with edit permissions enabled. There are sometimes additional questions in this phase. Some are addressed by the project manager and other more specific ones are recorded in a comment in a user story or Chatter feed for the ticket. 
• Finalizing dev work: We always add feedback and resolutions from the document comments, Chatter comments, or Slack conversations to the user story with the header as shown in the image to track what has been implemented. After development is finished, a change set is uploaded to the production environment and a link is sent to the Project Manager for validation. After the change set is validated, the ticket is moved to QA and the testing phase begins. 

Testing

• Creating test cases: We receive the user story for testing in the company’s DevOps application which runs on Salesforce. Once we get the user story’s information, we use an Excel spreadsheet to list our possible test cases.
• When we have finished writing down all the information, such as descriptions, steps, results, and observations for each test case, we are ready to move them to our TestLodge project, where these will be saved in each test suite. We only make these cases for projects that are usually updated, and we maintain with our clients. One-time projects are not counted between these. To begin with this flow, we must understand how things are configured in TestLodge.
• First, we log in, and once we are on the platform, we create a test plan containing our test suites. Then we create our first test suite containing our test cases. For example, having a test plan for each customer helps us organize better than just having each test plan for each test suite.  Once we have that, we can begin making a test run for any of these test plans. We create a new test run and select any test plans, cases, or suites to add to the test.

• Functional and integration testing: Regarding tests, we have two types of tests. We have the functional test, in which we try to introduce new functionality developed for a user story, and the integration test, where we see, if there were, any changes in older components that might impact and interact with the newly developed functionalities.
• Analyzing and reviewing code: We have a PMD source code analyzer (PMD) to install locally in Visual Studio code to work with static analysis and to have best practice recommendations while we are developing the solution. This tool is used as an assistant for all the clients’ projects. In addition to PMD, code is analyzed and reviewed by another teammate. The purpose of this is to detect and improve situations that we may have overlooked in some cases, to improve the efficiency of the code. This means that not only helps out with the current code but also helps the reviewer to make a better call in the future.
• Test reporting: To help improve the process internally, we generate monthly reports with all recommendations. This report is shared with the customer who manages the assignment of tasks to help reduce the number of existing recommendations before the use of PMD and gives more control over the code quality. 

Releasing

Our customer has several custom development projects that can be found in AppExchange, and our team is in charge of each product release. Before a package is released, we must run the security scanner. This cloud-based source code analysis tool helps us find any vulnerabilities in our code. Once the scanner passes and no issues are found, we are ready to upload our new release. When a new package is released, a URL is generated. Once this step is completed, a notification to the project manager is sent with the corresponding link.

Having a clear and well-defined workflow is what helps us develop a long-term partnership with our Salesforce Partners customers. Working with Salesforce Partners is only one of the many services Oktana provides. If you are a Salesforce partner looking to work with experts to help you provide the best custom app development solutions to your customers contact us. Our team will give you more information about these services.