How we develop software at WeOwn

Using the example of DeFinity Clarity app’s staking feature

Complex processes are best explained via an example. As the illustration below shows, different parties are involved in different functions at different times in a development project.
This article describes the entire end-to-end process along the entire software lifecycle development (SDLC) using the example of Staking, which WeOwn conceptualised, developed, tested and deployed as a technology service provider on behalf of DeFinity.
In this example, DeFinity is the client, and as a shareholder WeOwn is the technology provider responsible for the technical implementation from start to finish. WeOwn develops both on behalf of third parties and for in-house purposes. The processes described here are run through for every new function, regardless of the client, so that maximum efficiency in implementation, adherence to deadlines and quality in the final product can be guaranteed.

The development process over time
The way software is developed, tested and released has changed significantly in recent years. Many elementary components of the software development life cycle (SDLC) have changed, both in the IDEs, i.e. the development environments (cloud!), testing approaches, but above all in project management (agile!). As mentioned above, here we’ll use the example of the new staking function in the Clarity app to show what the SDLC process looks like at WeOwn.
A wide variety of tools are used along the SDLC, which are shown below:

Preliminary planning – UX Design
First of all, DeFinity’s management team decided to provide a staking functionality in the Clarity app. The essential parameters such as requirements, interest rate, allocation, redeem process etc. were the first to be predefined. The WeOwn project management team was then briefed in detail on those requirements.
As a first step, the most important processes were mapped in a wireframe tool by an assigned WeOwn project manager. At WeOwn, we use InVision for this purpose. This is what the sketch looked like for the staking functionality:

The focus of these sketches is to ensure that the functions are arranged logically and that all user scenarios can be mapped. Above all, a high level of user-friendliness is ensured. Once the first draft is complete, these scribbles are presented to the WeOwn development team for feedback. After the feedback was taken into account, the processes were presented to and approved by DeFinity’s management team.

Prototype – UI Design 
Next, the WeOwn graphics department creates initial proposals for the front-end of the new functions based on the wireframes. These screens are linked and allow testing the flow in detail and checking if all functions are easy to understand and logically arranged.

At this stage, the testers include their feedback directly into the prototype so that the graphics department can implement these changes immediately. Only when all processes fit do the project managers release the prototype so that it can be scheduled for one of the following sprints. For this purpose, a requirement is created with the exact criteria, and the prototype is linked.
While coordinating on the front-end, the back-end team simultaneously works on planning for the necessary smart contract and the interactions with the customer’s wallet.

Planning
In the sprint planning meeting, the assigned project manager presents the new function to the entire WeOwn dev team using the prototype, explains the requirements in minute detail and answers questions from all developers and testers.
Afterwards, the developers and testers create the necessary tasks and estimate the effort. At the end of the planning session, the capacity for the sprint is determined ensuring that the functionality can be delivered as desired within the necessary timeframe.

Implementation
At WeOwn, we have always developed using the Scrum method. Our team meets physically (virtually during Covid-19) for 15 minutes every day to answer these three questions:
“What have I done since the last DailyScrum?”,
“What will I do today?” and
“What is stopping me from doing my work?”

All sprints last 2 weeks and are initiated by the aforementioned Sprint Planning Meeting and followed by a Review Session. In this way, the work status is reviewed daily, and potential problems are identified immediately. Our developers estimate how much time they still need for the outstanding activities per task, and a so-called burndown chart is created daily. In the sprint when the staking function was developed and tested, this process was almost ideal. However, there have been sprints in which the burndown chart did not run quite so linearly (and this is to be expected) 😊.

The implementation for the Staking feature has taken place on two levels:

  • The frontend team implemented the functions agreed with the management teams according to the specifications of the agreed UX prototype.
  • The backend team provided the API endpoints needed for the frontend from their own and external systems (e.g. MetaMask).
  • The blockchain team developed the required smart contract, incorporated external audit feedback, deployed the smart contract first to the Ethereum testnet and finally to the mainnet.

 

Testing
Testing takes place on several levels. The test process is not always run through completely, but is applied depending on the functions in question:

Our developers implement so-called integration tests that cover essential functions on the code side. These tests are run automatically during the automatic deployments.
The test team creates a test plan that maps all scenarios and contains so-called edge cases. This ensures that incorrect entries are also caught correctly (for example, when entering the number of tokens to be clocked, the user enters letters). Or the number of tokens for staking is higher than the available number of tokens. All test runs are documented. If errors occur, they are documented in a bug tracking tool. Just like product backlog items or tasks, bugs also pass through several stages:

In the case of the Staking functionality, the following artefacts were created:

Product Backlog Tasks Bugs
1 18 3

Automated tests: The most important process steps such as staking, unstaking or redeeming an amount are mapped in the automatic test process. These automatic tests are run after each deployment and ensure that new functionalities have not inadvertently led to problems with existing functionalities (so-called regression errors).

Deployment
For security reasons, deployment takes place across multiple environments:

Developer environment: development initially takes place locally within a developer’s environment. During deployment, these functions are automatically merged.
Test environment: An automated process deploys the released builds several times a day to the test environment, where the manual tests are also carried out.
Demo environment: Once the new builds have been released by the test team, they are deployed to the demo environment. This usually happens towards the end of each sprint. At this point, external parties can test the new functions. In the case of DeFinity’s staking feature, both the WeOwn and DeFinity management teams participated in the test and gave feedback. This feedback was incorporated by the development team and deployed again.
Production environment: Upon approval, the final (stable) build is deployed to the production environment. A short smoke test ensures that all functions have been implemented correctly and that no errors occurred during deployment.

Marketing/Communication
Marketing and communication are part of the process, otherwise no one would know the new function(s) exists. The communication for the staking functionality was carried out in this order:
For the Staking app, a decision was made to create a short video showing the main features and benefits. The marketing team developed a concept and created a script. Then the graphics team created the video based on the above.

The graphics department created several graphics and animated sequences for social media, which were posted to accompany the video.

For the DeFinity Help Centre, the support team wrote additional articles so that users can get help directly from the Clarity app.

To illustrate what the process of developing software at WeOwn looks like, we have chosen the new staking function in DeFinity’s Clarity app, which went live on 16 July.
The processes and responsibilities described can be transferred to all functions that WeOwn develops either for its own blockchain and marketplace solution or for requirements that WeOwn implements on behalf of third parties.

Deutsch