small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

#### Post-Pandemic Growth

In response to the dynamic growth of the IT market in the post-pandemic period, **our team experienced unprecedented expansion,** a phenomenon common throughout the industry. **Our existing manual methods for managing personnel and related data, while effective on a smaller scale, quickly proved insufficient in the face of growing operational complexity and employee numbers.** Scaling these manual processes generated risks of errors, reduced efficiency, and hindered strategic resource planning.

#### Recognizing the Gap: The Search for Scalable, Tailored HR Management

We identified **an urgent need to implement a centralized system to streamline key HR processes.** The core requirements included secure storage of employee personal data in compliance with applicable regulations, precise cataloging of their technical and soft skills, and professional experience. Equally important was the ability to instantly update this information and automate the generation of competency profiles, essential for effectively allocating resources to new projects and responding to client inquiries.

We conducted an in-depth analysis of solutions available on the market. **We found that the market was dominated by extensive HRIS (Human Resource Information System) platforms,** which, although feature-rich, were **disproportionately complex** and **costly** relative to the current needs and scale of our organization. Implementing such a complex platform would involve inefficient resource utilization, lengthy implementation times, and a lack of the desired flexibility.


#### Developing a Homegrown HRIS Application

Consequently, we made the strategic decision to develop our own dedicated solution, precisely tailored to meet 100% of our specific requirements. **This led to the creation of our internal application,** informally nicknamed **"HRIS"** by the team. Its development was an iterative process – we successively expanded it with new modules, **guided by ongoing operational needs.** To the core database, we added functionalities for managing software licenses and assigned IT equipment, an integrated leave request handling system, a central repository for employee evaluations and feedback, a digital archive for employee documentation, and a module for recording salary history and tracking changes.

This application reliably supported our operations for a long time, **proving its effectiveness, stability, and value to the organization.** This internal success inspired us to consider its commercialization and make it available to other companies facing similar challenges. **We began conceptual work on version 2.0,** intending to release it to a broader audience in a SaaS model.
 
![hris.png](https://bitnoise-cms.btn.fyi/uploads/hris_c956f5ec82.png)

#### Reimagining the Product: A Strategic Pivot to Serve Field Teams

However, a series of internal strategic sessions, combined with market trend analysis, **led us to reorient our plans.** We decided on a strategic pivot, transforming the original HRIS concept into a solution with a **much broader functional scope,** addressing the needs of a specific, underserved market segment.

Thus, the concept for the **TaskForce** platform was born. Building on the proven foundation of human resource management, we enriched the system with modules dedicated **to optimizing the work and management of field service teams** – such as technical service engineers, assembly crews, installers, gardeners, and other specialists whose work involves performing tasks directly at the client's site or a designated location.

![hris-1.png](https://bitnoise-cms.btn.fyi/uploads/hris_1_a78d3f4a09.png)

#### Key Functional Expansions

A key extension is **the advanced order (task) management and scheduling module.** It enables managers and dispatchers to efficiently plan tasks on an interactive calendar, dynamically considering critical parameters: **job geolocation, required completion deadlines, priorities, necessary qualifications, and the availability of appropriate employees.** This directly translates into optimizing travel routes, reducing operational costs, maximizing the utilization of working time, and enhancing the overall efficiency of daily field operations.

Furthermore, we have introduced a range of innovative functionalities aimed at streamlining and automating communication between end customers and service providers (e.g., technicians). Details of these solutions, which include **notifications** and **job status updates,** will be presented soon. Their purpose is not only to improve information flow and increase transparency but also to strengthen the client's relationship with the service provider company, building loyalty through convenience and proactive communication facilitated by the TaskForce system.

![taskforce blog.png](https://bitnoise-cms.btn.fyi/uploads/taskforce_blog_f7ba876bf0.png)

#### Next Steps

In the near future, we plan to conduct closed **beta tests** with a dozen carefully selected partner companies from various industries. **After gathering and implementing their valuable feedback, TaskForce will be officially released to the wider market.** Concurrently, we will continue to work on the further development of the system, implementing subsequent expansion phases according to the adopted roadmap and responding to user needs.


thumbnail_blog-TaksForce_cover_high.jpg

blog-TaksForce_cover_high.jpg

Strategic Pivot: Transforming an HR Tool into a Modern Field Service Platform

Frontend Engineering

UX/UI Design

Research & Discovery

AI For Your Business

Services

Case Studies

Career

About us

Blog

I'm Luiza, the Head of Production at Bitnoise, a software development company. I also work as a development process consultant, focusing on team communication, project management tools, and efficiency. In this blog post, I will share some tips and tricks on how to organize your development process to keep it lean and efficient, using a real-world example from my collaboration with a London-based client. 

I will cover the importance of frequent delivery and client feedback, improved backlog management, and transparency in the development process. 

From this post, you will learn how my team and I delivered better, faster, and increased average sprint velocity by 35%.

#### **Background**
As a Head of Production and Project Manager, my main goal is to maximize the business value of projects. During my collaboration with clients, they expect three types of activities from me: 

- optimizing the development process, 

- speeding up delivery, 

- and generating savings.  


In this post, I will share how we achieved these goals with **a mobile front-end team** I collaborated with in the role of a Scrum Master. 

The company I worked with is an **international e-learning company with over 15 years of experience in the market**. Their solutions are used by millions of users worldwide. We were delivering for both iOS and Android platforms while trying out the Scrum approach for our development process.

#### **Measuring Success**
From what point did we start our reorganization process? From process metrics. What were they telling us? That we were inefficient and that we needed to understand why.  

The velocity chart displays the amount of work that was committed at the beginning of the sprint (gray bar) and completed at the end of the sprint (green bar). We used story points to measure the workload, and **chart no. 1** visualizes the velocity results from seven sprints before any of the process improvements were made. The measurements were taken in the middle of the year. Sprint velocity results suggested that the development process was not as effective as the company had expected, and only half of the planned tasks were eventually delivered (average CaC = 52%).  

**Chart no. 2** represents the sprint velocity results after 6 months of improvements. The measurements were taken at the end of the year, and **the effectiveness of the mobile team's delivery increased from 52% to 82%.**

**CaC = Completed / Commitment * 100%**

![ ](\uploads\blog-Boosting_efficiency_post01_73wsaA6BpWrq4vOUbw1Lzr.png)
![ ](\uploads\blog-Boosting_efficiency_post02_48PZie37iQTD0LuouVXtbJ.png)
For additional measurements of the development process effectiveness, we used the **burndown chart**. The burndown chart also represents the amount of work (in story points) that was completed in a sprint (2 weeks), but it also provides information about the history of story point completion and suggests any impediments in the development process.

Referring once again to the middle of the year period (so before any improvements were made) and **sprint no. 7** results, we noticed that our realization of the delivery plan was far from effective and perfect. The red line, instead of dropping down and getting closer to the gray line every day, was following horizontally. It meant that as a team, we were struggling with task delivery, and what's more, we were often adding new tasks to the sprint (shown as ups on the red line chart). We explored this situation further during the retrospective meeting and noticed that during **sprint no. 7**, we spent a lot of time waiting for requirement specifications and discussing excessively instead of focusing on development.

At the end of the year, after implementing all necessary process improvements, we measured **sprint no. 19** and **noticed a significant increase in our efficiency**. We were finally delivering and had minimized the gap between the realization and perfect plan lines. Although there were still ups on the red chart, indicating that we may have forgotten some tasks/requirements during sprint planning, we were able to present the increment by the end of the sprint.


![ ](\uploads\blog-Boosting_efficiency_post03_1xPIJErbzjEUjO2w6nSIYV.png)
![ ](\uploads\blog-Boosting_efficiency_post04_2ed0YhpBPBGulwyap3Bzs0.png)
So, what steps did we take to achieve this improvement in our software development process?

#### **Frequent delivery and client feedback**
One critical aspect of boosting mobile team efficiency was to implement frequent delivery and obtain regular client feedback. Our two-week development cycle always ended with a valuable increment, presented during a review meeting. **This allowed stakeholders to test the functionality and provide early feedback.** The review meeting included developers, the Product Owner, Scrum Master (the Scrum Team), internal clients such as business analysts and designers, and external clients. Moreover, together we discussed the backlog (requirements) and adjusted the plan for the next iteration (sprint).

For example, in a few sprints, we delivered an improved feature that allowed users to play, pause, skip, and seek the video. **The client's feedback after every iteration helped us identify some usability issues, which we addressed in the subsequent sprint.** This iterative approach ensured that the end product met the client's expectations, and we were able to deliver a feature that increased user engagement.

Regular retrospective meetings with the scrum team also helped us  identify areas for improvement. These meetings provided insights into  what went well and what didn't in our last iteration, offering valuable  information for planning the next steps.

Both review and retrospective meetings served as inputs for planning the next iteration, ensuring that the planning process also addressed necessary improvements and backlog adjustments.

These frequent feedback loops helped us minimize the risk of delivering unexpected results, set continuous process improvements, and foster better collaboration among team members.

#### **Improved backlog management**
However, at some point, we realized that poorly prepared requirements led to delays and inefficiencies in our development process. To address this issue, we took the following steps:       

- **Designated a single person (Product Owner) responsible for keeping the backlog up to date.** The Product Owner is the person who knows how the functionality should look and has the final say in its implementation. In our case, the Product Owner had a deep understanding of the client's industry and had been working with the client for over three years.     

- **Used JIRA as a single source of truth for the backlog.** This provided a central location for stakeholders to review the backlog during review meetings and for the technical team to discuss it during retrospectives and planning sessions.     

- **Organized the backlog as a list, with clear prioritization rules, issue types, and workload estimates (story points).** These steps helped us improve the quality of our requirements and streamline our development process.


Below, you will find the issue types that our team is currently using in Jira backlog:


![ ](\uploads\blog-Boosting_efficiency_post08_1oAJUGnZkAfJ8Knaqs1KiW.png)
Below, you can find the prioritization rules that our team is using in Jira backlog:

![ ](\uploads\blog-Boosting_efficiency_post07_tb5y0VLiEddmfgMgVQ4Pi.png)
- **Seek input from developers for technical analysis and involve designers and business analysts in refining requirements.** The Product Owner does not have all the knowledge about implementation details, so it's essential to get input from developers, designers, and business analysts when refining the requirements. Involving these team members in the refinement process eventually decreased the number of misunderstandings at the development stage. 

- **Ensure that all necessary requirements are finalized before the start of each sprint.** Having finalized requirements at the beginning of the sprint reduces uncertainty and ensures a smooth development process. Avoid changing these requirements at the implementation level.  


These improvements led to faster delivery, reduced time spent on unnecessary discussions, and increased transparency of what is going to be delivered next.

#### **Transparency and useful board flow**
Having a transparent and useful board flow is essential for an efficient development process. We customized our board flow to suit our team and sped up delivery. The board flow provides a visual representation of our development process, making it easier to track progress and identify bottlenecks.  

We have implemented **Work in Progress (WIP) limits** to quickly identify and address bottlenecks. As you can see in the example below, once we put three tickets in the "blocked" column, it becomes red. This means that developers should drop any ongoing work and quickly address issues with the Scrum Master or Product Owner so that they can support unblocking them. Why? Because without those tickets (requirements), we won't deliver what clients expect at the end of the sprint. Visualization is a vital practice in board management and supports fast delivery.  

Additionally, we used **burndown charts to visualize our sprint progress**, helping the team stay on track and adjust their efforts when needed. The burndown chart and up-to-date board became essential tools for our daily stand-up meetings, where we discussed our progress, identified any blockers, and ensured everyone was aligned with the sprint goals.

Below you can find the board rules set for our Mobile Frontend Team:


![ ](\uploads\blog-Boosting_efficiency_post05_5EDWNXN5NXg3eh0Nb97vmL.png)
#### **Conclusion**
In conclusion, by focusing on frequent delivery and client feedback, improved backlog management, transparency in the development process, fostering a collaborative culture, and measuring success, we were able to significantly boost the efficiency of our software development process. These improvements not only led to better quality products but also generated substantial savings for the client.  

Remember that every team is unique, and the methods we used might not be suitable for every situation. However, by continuously evaluating and refining your development process, you can unlock its full potential and achieve outstanding results.  

If you have any questions or suggestions, feel free to leave a comment below or reach out to me on social media. I'm always happy to help and share my experiences.

For the complete presentation and slides from the **Land on Moon event** (hubraum, Berlin), please check the video below.



Land on Moon #3

Land_on_Moon_3_-_Luiza_Kwiatek.mp4

small_blog-Boosting_efficiency_cover_high.png

thumbnail_blog-Boosting_efficiency_cover_high.png

blog-Boosting_efficiency_cover_high.png

Boosting the efficiency of software development processes: a real-world example

#### **Why do you need automation?**
 When working on a new feature, improvement, or bug fix, it is crucial to ensure that all changes adhere to the rules specified by the linting tools, such as [ESLint](https://eslint.org/)
 and/or [prettier](https://prettier.io/)
. Similarly, it is essential to run tests whenever changes are made to guarantee that there are no regressions.

 With a simple project setup utilizing ESLint for linting, and [jest](https://jestjs.io/)
 and [cypress ](https://www.cypress.io/)
for testing, at some point, you will need to execute the  following command:



 This is a lot to remember and as the project grows there can be more commands to run.  It can become annoying and repetitive really fast to run all of these commands by hand. Moreover, forgetting to run some of them can cause production builds to fail or introduce bugs that could’ve been easily avoided by executing these commands locally.

 It can become quite challenging to remember and manage all of these  commands, especially as the project grows. The list of commands can  quickly become overwhelming and repetitive to execute manually.  Additionally, forgetting to run some of these commands can lead to  production build failures or introduce bugs that could have been easily  avoided by running these commands locally.

Fortunately, there are tools available that can assist you in configuring all the necessary commands to run automatically whenever you need them, relieving you of the need to think about them ever again.

#### **Knock-out repetitiveness with Lefthook!**
[Lefthook](https://github.com/evilmartians/lefthook)
 is an incredibly useful, lightweight, and easy-to-configure tool that automates various aspects of your workflow, including code formatting, test execution, and more!

To begin, you'll need to install Lefthook in your project.





#### **Configure it with ease**
After the installation is complete, you can begin configuring Lefthook by creating a ``lefthook.yml`` file in the project's root directory.



So clean and simple! Now, whenever you commit changes, Lefthook will automatically execute all of these commands. Whenever you commit changes, you should expect to see something similar to this:

![ ](\uploads\blog-Leftook_post_01_6VHv6PDrJMZOEMQSUR0YMM.png)
If Lefthook is not firing, try running the following command:



#### **Built-in features**
 However, this script can be further improved. For example, there is no need to lint the entire project every time you commit changes. Ideally, linting should only be performed on the staged files. 

Moreover, it would be beneficial if the script could also handle fixing any auto-fixable warnings and errors automatically.

Lefthook has you covered with built-in lists of files that can be used for that exact purpose for example ``{staged_files}``.

Updated configuration will look like this:



- ``staged_fixed: true`` makes sure that any file that was changed by ESLint auto-fixing will be re-added to staged files.

- ``glob: “/*.{ts,tsx,js,jsx}”`` makes sure that ESLint is run only against javascript / typescript files within all the staged files.

#### **Running concurrently**
Running each command individually can be time-consuming, particularly when there are numerous commands involved. To expedite the process, Lefthook can execute all the commands in parallel by adding a single line to the configuration file, as demonstrated below:



- ``parallel: true`` will run all the commands concurrently, which should make the whole process a little bit faster.

#### **What else can be automated?**
 Another command that can be automated is the installation of packages whenever you merge changes into your working branch. Other developers may have added different packages at any given time, so it can be advantageous to install them automatically before starting your work.

How to achieve this in Lefthook:





Important to note: ``post-merge`` hook will not run if any conflicts were detected!

Whole lefthook.yml file should like like this:





#### **Conclusion**
Lefthook is a very powerful tool that can help with automating repetitive processes, thus improving the overall developer experience by allowing your team to focus on delivering code that will be linted and tested automatically.

It is very easy to configure in new and existing projects, so I highly recommend trying it out on your own!



small_blog-Lefthook_cover_high.png

thumbnail_blog-Lefthook_cover_high.png

blog-Lefthook_cover_high.png

How Lefthook helps improve development teams’ workflows

This year's [Vercel Ship](https://vercel.com/ship)
 event (May 1st - 5th, 2023) proved to be quite  interesting for Vercel users who find it a highly useful tool but  wouldn't mind some additional upgrades. Vercel introduced three major  innovations during the event, although it's important to note that some  of them are still in the beta-testing phase.

The new features are as follows:

1. Vercel KV: store key-value Redis, based on Upstash. 	 

2. Vercel Postgres: PostgreSQL database, based on Neon (beta). 	 

3. Vercel Blob: file storage, based on Cloudflare R2 (beta).  


At Bitnoise, we extensively utilize [Vercel](https://vercel.com/)
 for **developing, deploying,  and scaling websites and web applications**, both for our internal  projects such as [Land on Moon](https://www.landonmoon.co/)
 and while working for our clients.  Consequently, we closely monitor these changes and actively test the  available features.

In my opinion, once these new Vercel updates become available, they will greatly benefit us, especially during the MVP and PoC phases of software development. These phases require efficient time management, agility, and effective feedback from the end client for successful outcomes.

Now, let's delve into what Vercel is and how we utilize it.


#### **What is Vercel?**
Vercel is a cloud platform renowned for its **streamlined approach to website and web application development, deployment, and scaling**. It leverages a serverless architecture, allowing developers to create and host websites that seamlessly integrate both static and dynamic content. Vercel's key strengths lie in its user-friendly interface and exceptional performance, making it a highly effective choice for contemporary web development needs.  

The key advantages of utilizing Vercel in software development process are:  	  

- **Accelerated development**: Vercel empowers developers to iterate swiftly and collaborate seamlessly. Its user-friendly interface and comprehensive toolset facilitate a streamlined and efficient development workflow, minimizing the time spent on setup and configuration tasks.  

- **Scalability and performance**: Vercel incorporates built-in scalability features that ensure web applications can effortlessly handle high volumes of traffic. By automatically scaling resources based on demand, Vercel guarantees optimal performance and responsiveness for end-users.  	  

- **Continuous deployment**: Vercel simplifies the deployment process through seamless integration with popular version control systems like Git. With automated deployments and preview capabilities, developers can easily test modifications and confidently roll them out to production environments.


#### **How does Vercel benefit Bitnoise's software development process?**
As I mentioned in the introduction to the blog post, Vercel is a very useful tool that helps to speed up and improve our software development process, both for clients and internal projects.  

We have used and continue to use Vercel primarily for frontend applications. However, we have also used it for applications where we separated the frontend from the backend. Vercel enables us to **work seamlessly with testers who can immediately test individual changes before they are deployed to the production version**. It also offers quick configuration and setup for new projects, **significantly reducing the need for extensive DevOps work**.   

![ ](\uploads\blog-VercelChanges_post01_5xd70JrtoRsIKODvRhvRJg.png)
Here is an example of how we use Vercel:      

- Hosting websites and apps written in Next.js and Remix.     

- Integration with platforms like Bitbucket is a great convenience because it allows you to deploy your website or app directly from the repository using webhooks.     

- Creating hosting and testing environments, as well as staging environments for projects that are still in development.


#### **Use of Vercel in MVP and PoC**
What was mentioned before is especially important in [MVP and PoC](https://www.bitnoise.pl/services/proof-of-concept-mvp-development)
 phases of development when time and the possibility of consultancy and feedback from the client on every major change and development are crucial.

For me, it is particularly useful when we use Next.js to start any new application. Vercel's integration with Next.js simplifies the deployment process by **automating configuration, providing Git integration for seamless deployments**, enabling preview deployments for collaborative testing, supporting continuous deployment, and offering a secure and flexible way to manage deployment-specific environment variables.

In other words, it saves you time and effort, allowing you to focus on developing your Next.js app and delivering new features to your users with ease.

#### **How will the upcoming changes affect the future of Vercel usage?**
First, you need to keep in mind that most of these changes are still in the beta phase. There is a waitlist to test them, and it will take some time to fully introduce those features to new projects. However, based on our best knowledge and experience, as well as the information provided during the Vercel Ship event, there are some insights we can share: 

- **Vercel KV** upgraded serverless Redis implementation by leveraging the capabilities of Upstash. Redis, a widely adopted key-value store, is commonly utilized for tasks such as rate-limiting, session management, and application state. Vercel KV streamlines the process of creating Redis-compatible databases, enabling seamless read and write operations through Vercel's Edge Network in designated regions. This solution guarantees durability, simplicity, and minimal configuration requirements. By collaborating with Upstash, Vercel ensures the availability of serverless tooling that ensures data persistence in both memory and disk storage.  

- **Vercel Postgres** - PostgreSQL is a favored option for developers when it comes to handling relational data. In a collaborative effort with Neon, Vercel introduces Vercel Postgres, the inaugural serverless SQL database specifically designed for the frontend cloud. This innovative solution seamlessly integrates with popular frameworks like Next.js, Nuxt, and SvelteKit. Vercel Postgres offers comprehensive management, remarkable scalability, and fault-tolerance. It ensures high-performance and low-latency data retrieval, empowering developers to efficiently fetch data from Postgres databases and dynamically render content on the server.  

- **Vercel Blob** is a fast and efficient solution for storing files in the cloud. Powered by Cloudflare R2, Vercel Blob simplifies file storage by providing a storage API built on web standards. Developers can store various types of files, including images, PDFs, and unstructured data, without the need for complex configurations or heavy SDKs. With Vercel Blob, developers can easily manage files hosted on Vercel and programmatically upload or generate files during the build process.  Vercel's serverless storage solutions will enhance the platform's frontend cloud capabilities. Vercel KV is going to provide a durable Redis database, Vercel Postgres will officiate  a serverless SQL database, and Vercel Blob will simplifie file storage.   


**These changes are aimed at shortening the time of tests and deployment, and reduction of  extensive DevOps work.**  

#### **Conclusion**
Vercel's recent innovations and ongoing improvements position it as an excellent tool for accelerating project development, which is particularly crucial in the MVP and PoC phases. In my opinion, it can save around 3-4 days of work in a given project. With its user-friendly interface, comprehensive toolset, and integration capabilities, Vercel empowers developers to iterate swiftly, handle high volumes of traffic, and deploy changes seamlessly.  

Vercel has introduced new functionalities such as Vercel KV, Vercel Postgres, and Vercel Blob. These features aim to enhance key-value storage, provide a serverless SQL database, and enable efficient file storage, respectively. Although these features are currently in beta testing, they hold the promise of further optimizing the software development process and improving overall project efficiency.  

As Vercel continues to evolve and expand its offerings, it solidifies its position as a valuable resource for developers seeking speed, agility, and exceptional performance in their projects.



small_blog-VercelChanges_cover_high.png

thumbnail_blog-VercelChanges_cover_high.png

blog-VercelChanges_cover_high.png

How Vercel's upcoming changes will make it an even better tool for accelerating product development

If you have a million-dollar idea, you want to validate it as quickly as possible. Spending time on things that don't add much value can be wasteful, so it's important to be strategic. Component UI libraries can help you create your MVP quickly and efficiently. 

#### Tools tailored to your requirements

There are plenty of solutions in the market that help with that, and each of them will fit different needs. 

Bootstrap has been around for quite a while and is well-known in the web development world. It was created to make it easy to build responsive web apps. It is basically a simple CSS library, but it got integrated into many popular libraries and frameworks like React or Angular. 

Material UI draws its inspiration from Google's innovative design philosophy, "Material Design," which emphasises user experience, depth, and visual consistency. Its main focus is customization, allowing developers to create interfaces tailored to their specific needs. Based on that, you could create your own design system that would fit your needs exactly as you want it.

If you’re looking for more enterprise-level solutions, Ant design might be a better choice. It offers a big collection of components designed to facilitate the development of complex business applications, which include sophisticated interfaces for data tables, forms and charts.

Chakra UI prioritises developer experience through its modular, customizable components. It allows you to define and apply themes, promoting code reusability and ensuring a consistent look and feel across elements. However, it is less known than the predecessors, so the community might be a little smaller.

While established solutions have a track record, their designs may appear dated. If you're aiming for a modern look and feel, Next UI is a compelling choice with its focus on aesthetically pleasing components. Plus, they made sure it runs fast by using Tailwind CSS as the core, which cuts down on the extra classes in the bundle.

Considering the advantages and disadvantages, most of the solutions are similar, and by the end of the day, it could be a matter of personal choice. Let’s dive in and see the use of specific components to assess the developer experience.

#### Compare different components

In the next section, I will compare specific components, showing which features are available by default and which are not. Take into account that most of the things mentioned could be somehow implemented, however, I will focus only on the aspects that are handled by the library.

#### Commonly used component

I think the Button is the most used component from such libraries, so it would be best to start the comparison with it.

![tabelka 1_.png](https://btnw-strapi-prod.dev.btndev.space/uploads/tabelka_1_63332c5fbb.png)

All the component UI libraries support different button variants such as primary, outlined or of different colours and sizes. Managing the state can also be achieved by all of them, however, Bootstrap needs a little more code to be written around the logic of the loading state. Bootstrap also lacks icon support, so if we want to implement that, we have to manage it ourselves. 

#### A more advanced example

I think working in modals can be either pleasant or a nightmare, depending on the specific developer experience the tools provide. Seeing what features different libraries could offer can help us understand what would be easier to use in the long run.

![tabelka 2_.png](https://btnw-strapi-prod.dev.btndev.space/uploads/tabelka_2_1fa58e692d.png)

Compared to Button, here we can actually see some significant differences between the libraries. Ant Design simplifies the most common use case for models, which are confirmed dialogues. It provides an additional confirm function, which takes only texts and callbacks, allowing us to trigger it anytime we need it without focusing on defining content each time. This library also handles async logic, so calling APIs and showing its effect could also be simplified. Another difficult case would be modal nesting, which is supported by Material UI and Ant Design. This could facilitate handling of some complex business flow. Material UI also lets you drag modals around. It's a handy feature, but personally, I don’t see much use in business contexts.

#### What to choose?

With so many libraries on the market, choosing the one that works best for you can be challenging. If your design is simple, it is probably a matter of personal preference. With more complex applications, it would be good to assess if there are any specific harder use cases that some of the libraries might support better than others.

large_blog-DecodingReactUI_cover_high (1).png

medium_blog-DecodingReactUI_cover_high (1).png

small_blog-DecodingReactUI_cover_high (1).png

thumbnail_blog-DecodingReactUI_cover_high (1).png

blog-DecodingReactUI_cover_high (1).png

Decoding React UI: Unveiling the Best Component Libraries in a Head-to-Head Showdown!

### Cracking the Code: TypeScript Tips & Tricks to Catapult Your React Application

#### Introduction

Every project that uses Typescript under the hood will contain some custom types that are being used across the application. As an application evolves or demands shift, it's important to manage all those types in accordance with DRY and KISS foundations. In the name of type safety, it might be tempting to type every single element within the codebase. However, it can be beneficial to stop for a minute and ask those 2 questions:

- **Why** is there a need for a given type?
- **What** is it needed for?
- **Where** will it be used?

It's important to note that creating too many custom types can lead to the over engineered codebase. When one change request or a new feature requires updating x amount of custom types, it can make the codebase harder to maintain.
This blog post will cover some useful tips and tricks to add to the cauldron of typescript magic to keep in mind when working with custom types.

### The less typescript, the better

Excessive inclusion of types for every single data structure may seem like a good thing at first. However, having a lot of custom types can lead to an unnecessarily bloated and redundant codebase, where some types may be duplicated unnecessarily.

To better understand why often less is more it's best to show by example:


At first glance, the above code looks good. Everything is type safe, but this code can definitely be improved.
By following the three questions asked in the introduction:

- **Why** is there a need for `ParsedUser`? - So that an array returned by `parseUserData` could be used in different places in the codebase.
- **What** is `ParsedUser` needed for? - To have a simplified type of `User` type.
- **Where** is `ParsedUser` used? - For example, in some components' prop types.

Doing one thing at a time. `ParsedUser` is just a simplified version of the `User` type, so it makes sense that when `id` or `username` on the `User` type changes,  `ParsedUser` would also adapt.

This can be achieved by introducing typescript's built-in utility types. It's possible to reuse the `User` type to construct the `ParsedUser` type by using `Pick`.


With that small change, `ParsedUser` and `User` are "connected" so whenever `username` or `id` changes the `ParsedUser` will also update.

The next thing to consider would be how to handle the return type of the `parseUserData` function. If there ever will be a need to change the shape of `ParsedUser`,  e.g. adding a `fullName`. With the current state of the code, every change to `parseUserData` must be followed by updating the `ParsedUser` type, which may not be ideal.

Since `ParsedUser` type is closely related to what `parseUserData` returns, it's possible to use `ReturnType` utility type from typescript and create this type like so:

Two things have happened:

1) Typescript is smart enough to understand what types will be returned from a given function so it's possible to skip it in function declaration.

2) By using the `ReturnType` utility, the `ParsedUser` type will not only be dependent on the `User` type, but also on the `parseUserData` function. When the shape returned by `parseUserData` changes, the `ParsedUser` type will reflect that change as well.

  
_As an addition, it is still possible to use this approach with async functions by introducing yet another utility type `Awaited`, e.g._


_Adding [number] to array type will tell Typescript to look on type of an item within that array._

As the above example presents, with less typescript the code is still type safe AND highly adaptable to any changes.

Utility types used in this example are just the tip of an iceberg.
In typescript's documentation, there are   way more utility types that can lead to enhancing the implementation of custom types and reducing the number of types needed in the application.

[https://www.typescriptlang.org/docs/handbook/utility-types.html](link)

### Master union types

A type union is most commonly used when a given property can have more than one type or when creating a custom type.
Basic type unions could look like this:

However, type unions can also enhance the developer experience when working with React components.
Again, best explained by example:

This example is invalid because `UserCard` requires to pass both `userStatus` and `adminStatus` no matter what user role is passed. A better experience would be to require passing the `userStatus` only when the user's role is `USER` and vice versa.

Possible fixes would be:
- Make both `userStatus` and `adminStatus` optional, but that may not be the intended behavior of `UserCard`.
- Create a separate `AdminCard` for handling admin stuff, but that can lead to code duplication, which could violate the DRY rule.

In this simple example, it would not be the end of the world to make `adminStatus` and `userStatus` optional. Oftentimes, components have more complex structures and making a lot of optional types can make it harder to understand what components require and when.

There is a better way of solving this issue with both type unions and typescript magic:

By extracting the common properties (`fullName`) to separate type and creating additional two separate types joined by union `UserCard` now have props that will be required based on the provided `role` prop.

_Typescript will know that both types used in the union have a role property, so it will "merge" these into one type. In the end, the role will be of type "USER" | "ADMIN"._

This behavior improves the developer experience, when working with this component because it requires different props depending on the user's role.

With great power comes great responsibility, so this pattern should be used wisely as it has some drawbacks:
- it can make props type less readable
- can be difficult to implement when there are two or more props that change the outcome overall props shape

#### Generic types for not a generic dev

Implementing generics enhances the flexibility and reusability of code segments within a codebase. This typescript is a fundamental tool that developers should frequently reach out for, becoming an essential tool in the toolkit of every developer working with typescript.

Generics can simply be used to create custom utility types e.g.


Function `swap` can only be used with strings, but what if there is a requirement to swap numbers, or some other custom typed data? It's a good idea to make this function generic:

_Specifying return type [T, T] makes sense here, because this array will always consist of just two elements._

Now this function can swap not only numbers, but any data thrown in as arguments.

When working with React, generics can be used to create generic components f.g
instead of creating Lists components for every single array the codebase has, it can be done with one generic component:

_Thanks to adding <T extends { id: string }>, id which is used in item's key will be required part of item type._

The list can now be used with any type of data structure, which makes it a highly reusable component.

#### Summary

TypeScript is approachable for beginners with its gradual typing and JavaScript compatibility, but mastering its advanced features like typing nuances and generics can be challenging. Despite the learning curve, the benefits of static typing lead to more reliable code, better collaboration, and reduced bugs. TypeScript's robust tooling and community support further enhance its appeal. The initial ease of use gives way to long-term advantages, making it a worthwhile choice for developers aiming for code quality and maintainability.

Typescript is easy enough for beginners to start their journey with static typing, but some more complex features (generics or type unions) can be hard to get around at first. Still, they can improve the maintainability and reusability of some parts of the codebase, so it's worth getting to know them.

I hope this blog post will ease the learning curve of the more complex topics of Typescript.

large_blog-DecodingReactUI_cover_high (3).png

medium_blog-DecodingReactUI_cover_high (3).png

small_blog-DecodingReactUI_cover_high (3).png

thumbnail_blog-DecodingReactUI_cover_high (3).png

blog-DecodingReactUI_cover_high (3).png

Developer is sweaty, TypeScript spaghetti


Git is a fundamental tool that every developer must have in their arsenal. In a modern and agile world of software development, where codebases are managed by huge teams, having a tool that helps to streamline the process of adding features, changes, or fixes is, without a doubt, a necessity.

Like many tools, git is, with no exception, easy to learn and hard to master. In just one day, an inexperienced developer can learn how to connect to a remote repository, create a branch, push commits, create pull requests, and merge the code. This blog post aims to help developers become more mindful about what and when is being committed to keeping the history well organized, informative and clean.

Keeping the commits history clean helps understand what changes were made to the codebase to backtrack easier if something is not working properly. Not having descriptive commit messages or having too many changes in a single commit are common issues of larger codebases.

![blog-DecodingReactUI_blog_01.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_Decoding_React_UI_blog_01_8c93667a61.png)

#### The easy parts

Every developer knows these commands by heart:

These commands are the foundation of working with Git. However, some of these commands can be slightly modified to create better commits.

##### git add

When working on a new feature, it is often hard to stop in the middle of the process just to create a commit. After some time, the feature is fully implemented. X number of files have been altered, and Y files were added. The time to commit code has come. Instead of creating one big commit, it is often better to have multiple smaller ones, e.g., creating a UI component, creating a test case, updating the types, etc. But the work is already done, so how can one split it now?

Simply by adding `-p` (patch) flag to `git add` command will open an interactive window that will go change by change (it **will not** go through newly created files). Developer will be able to decide whether or not to add given change, skip it or break it down even more. Now all changes regarding the tests, creating new ui components or updating the types can be separated into a different commits. Same file can be committed multiple times containing different changes that are part of a given commit, thus bringing it one step closer to create a clean commit history.

##### git commit

Now that the bigger changes can be grouped into smaller chunks adding a descriptive commit message is next in order.

Adding one `-m` flag will create a header for the commit message that will be shown in the history. However, sometimes one liner is not enough to fully describe the changes because more context is required. Adding another `-m` flag will create a commit's description:

When running the `git log` to display the commit history, it will be displayed as so:

_To quit the git log command, click 'q' on the keyboard._

Descriptions can be improved by adding `$` before the description to introduce better text formatting.


_Adding \n creates a new line_

This will be visible as:


Not every commit requires a description. It is always up to a developer to consider if changes that are being committed require more context or not.

_At Bitnoise, we follow the guidelines laid out by the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) to ensure that our commit messages are well structured. This ensures that commits in the history have a similar structure, making them easier to read._

There can be cases where the commit was made, but there was a typo in the code, or some small improvement was still missing. Instead of creating a new "fix typo" or "remove console.log" commit ```--amend``` flag can be used.


It will add all new changes to the last existing commit, so it's super useful for small updates on the last commit (how to update commits that are higher in the history will also be covered later in the blog post).

_Amending will change the commit hash, so if the commit has been pushed to the remote branch, it will be required to force push; thus, amending on shared branches must be avoided!_

#### Bringing it all together

Moving changes from one branch to another is a crucial part of working with git. It serves three purposes:

- shared branch can be merged to a local branch to have it up-to-date with the latest changes made by the rest of the team,
Local branches can be merged into a shared branch to make the new feature or bug fix accessible to other developers in the team (usually via pull request).
- local branch can be merged to another local branch to have them up-to-date

These cases may seem the same at first - making one branch up-to-date with the changes of the other. However, there is an important difference between the shared branch that is being used by the whole team and the local branch that's being used by one developer. The difference is that on a shared branch, the commit hashes should never change (pushing with force should never be required). On local branches, commit hashes can change (until the changes are not merged to the shared branch), and it will not impact the team's work.

In those scenarios, the developer has access to two different strategies: **merging** and **rebasing**.



**When is it safe to rebase?**

- when updating the private branch with the shared / main branch to preserve linear history.
- When making changes to the commits made on the private branch that are not a part of the shared branch, e.g., editing commits, rewording commit messages, squashing commits, or deleting them.

**When is it not safe to rebase?**

- when working on a shared branch like development or main, it's always better to use merge over rebase to ensure that commit hashes will not change and no forcing push will be required. If merge commits are not needed, `git merge branch-name --ff-only` can be utilized to merge changes without adding the merge commit.

  
##### Interactive rebasing

Where rebase surely shines is the interactive version, which can be used to alter the commit history in many ways.

_ n - number of commits in the history to take into the rebasing from latest to oldest f.g if two latest commits should be rebased, then n = 2_

Interactive rebasing allows you to edit committed files, reword commit messages and even squash or delete commits.

When running the command, it will show a window that can look like this:


For example, above following actions can be utilized to organize the commits better:

_When editing a commit, after editing was finalized, `git rebase --continue` should be executed to move to the next commit_

Rebase will go through each listed commit, execute the desired action, and after completion, replace a commit, thus **changing commit hash**, and move to the next one.

_If the commits were already pushed to the remote branch push with force will be required._

When a need arises to edit a commit message or whole commit that is not the latest one (the latest one can be updated by amending with `git commit—-amend`), interactive rebasing truly becomes handy.

#### More is not always better

On the other hand, having 30 commits for a single feature or bug fix might be an overkill and reduce the history's readability rather than improve it. Sometimes, it makes more sense to join or squash some commits into one bigger commit with more substance.

For example:


The commits above are very granular, and it does not make sense to have them separated like that. One can leverage interactive rebasing to squash these commits easily.

The end result may look something like this:

Now, instead of having multiple remove console.logs, typo fix commits can be organized into one big, easy-to-understand commit.

#### Conclusion

Many developers stop learning git after understanding the basics, which can negatively influence the team's work. Clean history is a part of code documentation and improves not only tracking what was done and when but also reviewing the code in pull requests. Tracking where something could've gone wrong when bug fixing is also less painful if commits are well organized.

This blog post shows that small changes to well-known commands can drastically improve the quality of the commits being created. Adding interactive rebasing into the mix will also make any developer an even better team player.

#### Useful tips and tricks

##### Git game

If you're a beginner and those topics still appear too advanced, you may want to check out this [game](https://learngitbranching.js.org) to familiarize yourself with the git basics.

###### Editing name of the branch

Sometimes, a typo can sneak into a branch when creating it. So here is a flow that will allow me to edit branches to fix the typo. 


##### Removing all local branches

When working on a big project, sometimes a lot of old branches can be deleted. Instead of going branch by branch, this command can be used to delete all local branches:

large_blog-DecodingReactUI_cover_high.png

medium_blog-DecodingReactUI_cover_high.png

small_blog-DecodingReactUI_cover_high.png

thumbnail_blog-DecodingReactUI_cover_high.png

blog-DecodingReactUI_cover_high.png

Git Gut: Take care of your commits history like a pro

In the latest episode of PozTechTalks, Łukasz, Piotr, and Patryk delve into the realm of AI tools for developers. Serving as a continuation, this discussion builds on the insights and evaluations presented in the previous episode and accompanying article, providing a deeper exploration of innovative AI solutions tailored for programming challenges.

[**What the Diff**](https://whatthediff.ai/): This tool, aimed at enhancing pull request descriptions, integrates directly with GitHub. It distinguishes itself by generating comprehensive change summaries. However, its effectiveness varies, with occasional inaccuracies in generated descriptions, highlighting a mismatch between actual changes and the tool's interpretations. The tool also offers code review suggestions, which didn't perform well in tests, suggesting unrelated changes. Its usage is constrained by token limitations, making its free plan somewhat impractical for regular use.

[**Lintrule**](https://www.lintrule.com/): Differing from traditional linters, Lintrul allows for the creation of custom, human-readable rules for code consistency checks. It directly integrates with GitHub, enhancing code quality by enforcing project-specific conventions that might not be covered by standard linters. Despite its innovative approach, the need for precise rule definition and potential costs for extensive usage were noted.

[**ChatGPT**](https://chat.openai.com/auth/login): Not directly a development tool, ChatGPT's versatility is highlighted, showing its ability to analyse dependencies, generate code snippets, and interact with APIs using natural language. Its ability to browse the web and execute plugins extends its utility beyond simple Q&A, proving useful for various development-related tasks. However, reliance on this AI requires careful verification of its outputs due to occasional inaccuracies.


To conclude, the trio's exploration of AI tools reveals the evolving landscape of software development, where AI not only optimises workflow but also introduces new methodologies. Their discussions underscore the necessity of blending technical precision with creative experimentation to leverage AI's potential in programming fully. This insightful journey through AI tools not only broadens understanding but also invites developers to engage with these technologies, promising enhancements in efficiency and innovation.

Check out the full episode (in Polish)!


PozTechTalks 19

large_blog-AI Tools for Developers_cover_high.png

medium_blog-AI Tools for Developers_cover_high.png

small_blog-AI Tools for Developers_cover_high.png

thumbnail_blog-AI Tools for Developers_cover_high.png

blog-AI Tools for Developers_cover_high.png

Exploring AI Tools for Developers: Insights from PozTechTalks part 2

Quite recently, we delivered a project for one of our German clients, Inklusion Digital. Our task was to design and build an application for two groups of users: German teachers and students. Within the solutions provided, both groups had a common goal: to develop annual goals for students and verify their progress through feedback and self-reflection.

This is a fascinating example of an implementation in which we involved many different specialists; I had the pleasure of acting as the Product Owner of the entire idea. Today, I want to tell you the history of this whole project in several posts - so that you can understand the completed stages of the project, learn about the tools and practices... and learn from our mistakes.

We will start by analysing the discovery and design phases, allowing us to develop product design and UX tailored to users' needs.


In startups, the discovery and design phase is often overlooked and, as it later turns out, the most necessary. This stage of the product creation and development process aims to understand user problems, market needs, and technological possibilities. During this phase, the product team collects and analyses information to define the product's vision and determine its potential value and the risks associated with its implementation.

Suppose you are asking yourself what this is or are already answering this question by claiming that you do not see the relationship between the project's success and this phase. In that case, I will help you pragmatically out of this mistake.

According to [the latest research](https://www.nngroup.com/articles/discoveries-in-industry-revealed/) by Nielsen Norman Group and MIT:
- Product Discovery can help you lower the risk of failure by 75%.
- Teams using Product Discovery report 83% 𝗼𝗳 𝗽𝗿𝗼𝗱𝘂𝗰𝘁 𝘀𝘂𝗰𝗰𝗲𝘀𝘀.
- Discovery saves 50% of development rework time & 𝗰𝘂𝘁𝘀 𝗰𝗼𝘀𝘁𝘀 𝗯𝘆 33–50%. 

![blog-grafika 1 - discovery phase.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_1_discovery_phase_639acd94c3.jpg)


The above information guided us and convinced us that it is worth investing money into the discovery phase, as the results at the delivery and launch stages can be much more profitable. 
Before we started the design phase, we decided to work with the client in several weekly sprints to understand the needs of our end users (teachers and students) and their most significant pain points. How did we do it?

#### Customer Journey - process mapping

We set out to build a tool for the German education market to digitize the existing manual process of creating and managing students' annual goals. Using customer journey mapping, we analyzed the current process in German schools and identified the associated challenges. The results exceeded our expectations—it became clear that goal cards are often lost or forgotten, and their current format needs to be updated and made more appealing. As a result, students are less motivated to achieve their goals.

We definitely obtained tips and information that—as it now turns out—were the core of building basic functionalities in both applications.

We have placed the map and all information in MIRO.

#### User Personas - who is our end-user?

In parallel to building the Customer Journey, we decided to deepen our knowledge about our potential users - teachers and students in Germany. We started from the level: we want to make applications for all children and teachers in Germany. We concluded that the needs and requirements for using different applications are different and depend, among others, on the age of children/teachers, the type of school, and the education regulations of a given Bundesland. And this is how we defined our end-users (in an extensive summary :)):

- children and teenagers from various backgrounds, aged 10 to 16 (the most popular age group, we do not want to expose younger ones to technology), from secondary-level schools (business reasons for the client: gymnasium, Forderschule, Gesamtschule.. - the largest group of students)
- teachers - of different ages (challenge here!), and secondary-level schools (the same as above).
In addition to the specific characteristics of our users group - we have defined their key pain points, wishes and expectations in accordance to the build solutions. 

![blog-grafika 2 - personas.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_2_personas_26f5211ca0.jpg)
_Sample user personas template: https://miro.com/templates/personas/_


#### Business Model Canvas + User Stories
##### What do we want to build, and what are its chances of success?

After completing work on the customer journey and user personas, we felt ready to define the scope of our new product—digital applications for teachers and students that will improve the process of achieving school goals—together with the client.
We knew that: 
![blog-grafika 3.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_3_599cd991e0.jpg)


We started developing a [BMS](https://miro.com/templates/business-model-canvas/) and an Epic and User Stories outline. And we were like, wow - we create products tailored to the real needs of users! The Discovery Phase lasted about a month in total. After that, we started the design phase with full excitement. 

Those needs were converted into user stories with a MoSCoW prioritisation. We ended up with two scopes of products: one for teachers and a second for students. Suddenly, we realised that we were creating products that truly meet user needs. The Discovery Phase lasted about two weeks, and we moved on to the design phase, which took about a month.
Here, you can see the effects of the user stories slicing process: in the form of 2 maps in the Miro board.

![blog-grafika 4.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_4_1a511232de.jpg)
![blog-grafika 5.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_5_ac22b5d1a6.jpg)

The design was really smooth, primarily because of the great output from the discovery phase and the client’s involvement in the reviewing process. Teachers could expect a module as an add-on to the existing platform, and students would experience a separate app (independent of this platform). Teachers could, among other things, set annual goals together with students, leave feedback on progress, view results on an interactive chart, set a reward system and monitor students’ emotions. On the other hand, students carried out the self-assessment process, were recipients of rewards, collected points and shared their emotions. We have validated the design three times and, most of all - tested prototypes with teachers and students. We have received an enormous amount of input that has confirmed that we are ready for the development process.


large_blog-Inclusion Digital Saga part. 1 _cover_high.jpg

medium_blog-Inclusion Digital Saga part. 1 _cover_high.jpg

small_blog-Inclusion Digital Saga part. 1 _cover_high.jpg

thumbnail_blog-Inclusion Digital Saga part. 1 _cover_high.jpg

blog-Inclusion Digital Saga part. 1 _cover_high.jpg

The discovery and design phase as the main component of product success - the Inklusion Digital Saga part 1

Being a Product Owner (PO) is a challenge that requires managing many aspects of the project, from understanding user needs to working with the development team. Especially in the MVP phases, it is worth balancing between what is necessary and what is unnecessary. However, there are essential tools that cost nothing, can improve the quality of your work, and make it much easier at the same time. In this article, we will look at several of the most critical tools, such as Jira, Miro and Chat GPT and how they helped me build digital products for German students and teachers.

#### Jira - Backlog and Task Board Management

Holly Jira, but I won't hide it - I like this tool. Maybe I'm old-fashioned, but I enjoy collaborating with teams in this particular tool. In the beginning, when building an MVP, the free version was completely sufficient for me! Why?

**Because I could flexibly manage the development plan (so-called timeline).**
Jira's timeline uses the epic level to build a delivery plan. At first, I managed to create just a few epics (including login/registration epics, building the basic architecture, etc.). Still, as development work progressed, I learned more and more and eventually built a 4-month development plan (for both applications - teacher and student). This was great because I made sure that the most important screens and functionalities for both end-users would be delivered, tested, and working. What's more, the timeline function revealed to me the fact that it's worth starting development work by building an architecture and backend to get ahead of the frontend a bit - thanks to this, we built interfaces based on a working system and endpoints.

**Because I could manage the backlog at the level of tasks and functions**
For me, the backlog is a sacred tool for every Product Owner. Properly organised, it supports the team, and introduces transparency and order instead of chaos. How did we organise it within the project?
- Backlog as a list - and looking at it from above - there were tasks with the most significant degree of detail, which were refactored and ready for development. At the bottom of the backlog were tasks at an early stage of their preparation.
- project scope in form of ticket types
as the development team progressed, the backlog was supplemented with backend tickets, stories, bugs or extra change requests from the CEO, CTO and other stakeholders.
- impact analysis - every time a new scope (sometimes more or less needed) was reported to the team - we tried to analyse its impact on the timeline and current priorities in the backlog. 

Keeping the nice and clean backlog is not easy, but it is necessary if the Product Owner expects the development team to operate efficiently at the delivery stage.
![blog-grafika 1_poprawiona (1).jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_1_poprawiona_1_b9f060cf50.jpg)



**Because I could order delivery on the Kanban board**

For me, the Kanban board is a must and a standard tool for tracking tasks and communicating with the team. A good task board reflects the team's current work and helps rather than hinders. Therefore, our Kanban board has evolved, as the needs reported by, among others, the team have grown. We started from the level of "TO DO, IN PROGRESS, DONE" columns and ended up... on the Mendeleev board ;)

![blog-grafika 2.jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_2_f5c7177481.jpg)

#### MIRO - visual collaboration and brainstorming

Miro is an interactive board that made it easier for me to visually present ideas and collaborate in real-time. Since our team worked entirely remotely, it was a challenge to work out solutions together. MIRO came to our aid. 
- Discovery and Research—If you red a previous article and learned what our Discovery phase looked like, you will know that all diagrams, User Personas, research results, Customer Journeys, and BMS were visualised and developed in MIRO.
- Workshops and Brainstorming: Miro was primarily used in my work to plan new features and their early visualisation. For example: gamification logic in the student and teacher application.  I visualised several scenarios for both end-users and carried out a requirements refinement, which was then used to create the final design and flows. In addition, our developers were also very keen to use it for their activities. For example, our Senior BE developer led Event Storming sessions in MIRO, thanks to which we learned the scope of necessary endpoints to prepare for the entire project.
- Retrospectives and presentations at review meetings - Miro is very rich in [templates](https://miro.com/templates/retrospective/), and I decided to transfer the process of conducting retrospectives and tracking actions from retro right there . My favorite retrospective is [the 4L method](https://miro.com/templates/4-ls-retrospective/) - and it's great that I didn't need any additional external tool to conduct it. 

![blog-grafika 3.jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_3_15848c3225.jpg)

Going further into experimenting with MIRO, I also decided to check the slide-show function - I used it to present the results of increments at a review meeting. But here, honestly? I would go for simpler tools like Google Presentations or Canva :)

#### ChatGPT - my personal advisor

Last but not least - ChatGPT. There is so much talk about genAI in products and projects, but I personally had a hard time getting used to this new reality. However, I managed to find a practical application for ChatGPT in my work as a Product Owner. What did I do with this tool?
- I planned meetings - the structure, flows, timeboxes and Agendas e.g Review Meetings. ChatGPT gave me also insights on how to engage programmers and stakeholders so we could conclude any assumptions and key points from discussions
- I looked for statistical data - ChatGPT came in handy during the discovery phase when I validated various data and statistics regarding the education industry in Germany. And so, among other things, I learned that the most popular age group among young people are children aged 6 to 14, and German schools have problems accessing wifi and working equipment. So I adjusted the strategies of both products (teacher and student) with additional assumptions: the age of end-users and the need to design the flow of the feedback and self-assessment process so that it meets its goals both remotely (on users' private devices) and at school (on, e.g. a school tablet).

#### Summary

Creating an MVP, which is really two products, requires managing many tasks and collaborating with various specialists. Although I built products from scratch and didn't need advanced tools to start with, without Miro, Jira and ChatuGPT, everything would have taken me longer, and the quality of my work as a Product Owner would have been questionable.

large_blog-Inclusion Digital Saga part. 2_cover_high.jpg

medium_blog-Inclusion Digital Saga part. 2_cover_high.jpg

small_blog-Inclusion Digital Saga part. 2_cover_high.jpg

thumbnail_blog-Inclusion Digital Saga part. 2_cover_high.jpg

blog-Inclusion Digital Saga part. 2_cover_high.jpg

Product Owner Tools: What to start with and how we dealt with this topic - the Inklusion Digital Saga part 2

Going from the design phase to the delivery phase always brings excitement but undoubtedly doubt. Project Managers and Product Owners wonder: What functionalities should we start production with? How can we stay within budget? And finally, what methodology should we choose so as not to overdo it and deliver?

#### Soft start 
We have engaged three specialists for the project - a backend developer, a frontend developer and a tester. When we started, we knew that:
- we want to build an MVP in the form of an application for students and an additional module attached to the main product for teachers,
- we have obvious expectations, a well-designed design and support from our stakeholders (CTO, CEO, Marketing Team, sales team, German teachers),
- we are aiming for a production release in March 2024 (at that time, we had the end of December 2023),
- during the ongoing work, we have to include tests with teachers and students to obtain valuable feedback,
- we have to ensure the scalability of the product and remember the assumptions in the Discovery phase (i.e. who we are doing it for, why, what long-term product strategy, etc. - I presented the conclusions in this article: [click](https://www.bitnoise.pl/blog/the-discovery-and-design-phase-as-the-main-component-of-product-success-the-inklusion-digital-saga-part-1))

We started the development by:
- Setting up the infrastructure, building the architecture of the new student application,
- Integrating this application with the existing platform for teachers,
- working on the first endpoints of the login process (probably a classic of every startup - you start by logging in).

This soft start allowed for a smooth, gradual addition of the frontend programmer and QA. We had a week or two of spare backend work on the frontend at each project stage. Our QA specialist, on the other hand, divided his time between working on our MVP and the team working regularly on the educational platform for teachers. This is how it went for the following weeks of work.

![blog-grafika 1.jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_1_25a52940f3.jpg)

#### Scrumban - was it worth going crazy like that?

In my career, I have implemented projects using many methodologies and frameworks, such as AgilePM, Scrum, Kanban, and staged/waterfall. Using them had its pros and cons. Due to the specifics of working for a client (including the lack of Scrum Master/Agile coach roles, the need to synchronise work and releases with a parallel development team) and a completely anticipated project (because there was a design, an available client) - I decided to try a delivery framework with an exciting name: Scrumban. How did it look for us?

_Firstly, abandoning cyclical sprints in favour of flexible releases_

Working in regular sprints was out of the question - among other things, due to the size of the team, we knew that it would simply be a management "overkill". For us, the moment of meeting with the client for a review and deciding on a release was a reasonably flexible statement based on "Okay - interactive, working things are starting to appear - we feel that we should collect feedback on this part". However, once we had a demo, it was really effective, interactive and valuable. Additionally, we had such meetings planned in our roadmap (although they were supposed to be shiftable), and we conducted the demo about four times in total.

_Secondly, the backlog and roadmap as the main sources of information_

As standard, as in most agile frameworks - we worked with a backlog and roadmap in Jira. At the beginning of development, we built the roadmap of both solutions (the application for students and the new module for teachers). We corrected it continuously, considering change requests or delays/accelerations. The backlog lived daily - supplemented with tasks, stories and bugs - which were released by the Product Owner to the Kanban board of functions at the right time.

_Thirdly, limiting team meetings to daily and refinement meetings_

Our team was small (but agile!), so we decided to limit the daily to 3 times a week. Due to the abandonment of cyclical sprints in favour of flexible releases, we also eliminated planning meetings - we focused on refinements with the client in written form (on the messenger) and the form of cyclical meetings (twice a week). Thanks to this, we kept the backlog and the roadmap up to date and prioritised, and production breaks did not happen to us.

![blog-grafika 2.jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_2_152354db94.jpg)


#### Conclusions

To sum up, the delivery phase in this project was exceptionally dynamic and demanding, but our approach based on flexibility and adapting to the client's real needs brought the expected results. The most important thing is that we delivered the project in 4 months (we closed the development work in April) and managed to release both solutions in production in May (client's business issues). Focusing on a small, essential team: a Ui&UX designer, two programmers, one tester and a Product Owner minimised the costs for the client and helped us maintain agility. Giving up cyclical sprints in favour of flexible releases allowed us to better adjust the pace of work to the real needs of the project and the second parallel team. Thanks to this, we could respond more effectively to feedback and introduce changes smoothly and without downtime. Limiting meetings to a minimum allowed us to maintain high team productivity without unnecessary breaks in work. Soft start allowed savings in the project and conclusions from the discovery phase - to reduce the rework time by 50%.

large_blog-Inclusion Digital Saga part. 3_cover_high.jpg

medium_blog-Inclusion Digital Saga part. 3_cover_high.jpg

small_blog-Inclusion Digital Saga part. 3_cover_high.jpg

thumbnail_blog-Inclusion Digital Saga part. 3_cover_high.jpg

blog-Inclusion Digital Saga part. 3_cover_high.jpg

Scrumban and a small team to ensure high-quality project delivery - the Inklusion Digital Saga part 3

Imagine this—you are building a product MVP for two users: a teacher and students. These users are to work together to develop annual goals for students, which they will try to work on during the semester. Both groups of users use two separate applications, and progress towards achieving this goal is measured using teacher feedback and student self-assessment.

You are in the final phase of beta testing, which means production deployment to your end users. You have already had a few demos and tests with target users, and you have obtained valuable feedback on various increments of both applications, **but you have not yet had the opportunity to present both solutions fully connected to your stakeholders** (and the client). And now the question - how to do it, to encapsulate 4 months of teamwork in an hour meeting? And get a blessing, but above all, is it valuable feedback?

This is the challenge we set for ourselves as a development team, and in addition to joint discussions, ChatGPT helped us.


#### ChaGPT Helpline

The last demo is on the calendar. We call chatGPT, and I explain to him through a prompt:
- we are finishing the project, and in order to close the scope of the MVP phase and move on to beta testing and sales - we need to get the green light from the stakeholders (client-side teachers, other Product Owners, CTO, CEO) - and that it really was a great team!),
- we have an hour, maybe 1.5 hours, to explain how the application behaves
- we need to keep the stakeholders and devs engaged
- I am looking for alternatives to the standard demo form (we don't want to bore anybody). 

![blog-grafika 1.jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_1_eaac1fee08.jpg)


The answer was long, and I will tell you about how we planned our demo in detail soon. However, I will detail specific answers from the Chat that confirmed the direction of my thinking about this demo, namely:

![blog-grafika 2.jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_2_e8385d84d6.jpg)

![blog-grafika 3.jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_3_4e8d4c96b4.jpg)

So I came back to the team, and we confirmed what we had been thinking for a long time: let's do an interactive workshop!

#### A short planning demo, and off we go!
We sat down together as a development team and planned our hour-long demo meeting with stakeholders. We really wanted our stakeholders to experience both products to the fullest, and we thought this was the first step in the beginning of "knowledge sharing."

Based on ChatGPTt's suggestions, we decided to:
- pair participants in advance, assigning each person in the pair an appropriate role: teacher and student,
- separate "rooms" for each pair,
- prepare tasks to be performed as part of testing both products (we prepared the tasks in the form of instructions for each pair),
- develop a simple MIRO board where each pair could leave their feedback and thoughts on the tested flow.

We organised everything remotely, using channels (rooms) on Discord, which was a natural choice for us, because it is the client's communication channel.

#### Demo - progress and conclusions

The session began with a brief presentation of the Agenda demo—this time, we skipped the presentation and discussion of the latest changes. We wanted the participants to start playing with the products immediately.

10 of the planned 16 people came to the meeting (Yup, that was a difficulty we didn't foresee). We informed the participants about their pairs and roles. After giving each person task instructions, we divided the pairs into rooms.

The instructions with tasks were prepared for a given role. This meant that the person who was our “teacher” had to perform a set of tasks in one application and the person who was a “student” in the other. Since the prepared solutions are focused on the collaboration of these two users, some tasks require cooperation between these roles—just like in school life. Each of the five pairs had the same scope of tasks to perform.

The tasks had to reflect the processes that teachers and students were soon to implement in our applications. Hence, our "students" tested, among other things, the process of logging in with a QR code, co-creating goals with the teacher and implementing **self-assessment**. "Teachers" tested, among other things, generating these QR codes, co-creating goals with students, or exchanging **feedback**.

We left our testing group the choice of writing down their thoughts either on an ongoing basis or after the tests were completed. We used the MIRO board for this purpose, which looked like this:
![blog-grafika 4.jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_4_0b9567adf3.jpg)

Completing all the tasks from the instructions took from 10 to 20 minutes - those who already knew the applications a bit better came through the applications and completed the tasks more efficiently. It was also interesting that everyone completed the tests without significant problems and shared their thoughts in an open, approximately 20-minute session in MIRO.


#### WHAT WENT GREAT:
- planning demo was short, and the instructions for each role were clear - as evidenced by the time it took to complete the tasks and feedback from the participants
- we collected valuable comments from the participants - and we decided to implement the most important ones before beta testing,
- we finished in 1 hour,
- we got the blessing from the stakeholders and clear satisfaction with the results,
- absolutely everyone got involved: programmers, designers, teachers, company owners. The observations were varied (after all, everyone paid attention to something different), but all of them were accurate and valuable. 

#### What went so-so and what I would change

- I would try to prepare instructions that would require even more independence - to verify better the intuitiveness of the designed processes in the applications,
- at the end of the meeting, we held an open session with conclusions, and unfortunately, not everyone had time to express their opinion (and they wanted to). Next time I would divide the participants into two groups, e.g. teachers and students, divide them into rooms and ask them to prepare statements with the most important points/thoughts,
- each pair carried out the same range of tasks. It is possible that a better solution would be for each group to test a completely different area of ​​the application, e.g., one group would use the reward system, and the other would create a goal.


#### Summary

Organising this interactive demo with the help of ChatGPT turned out to be a bullseye. With the support of AI, we managed to plan and run a meeting that engaged all participants and provided us with valuable feedback. Using the workshop format allowed stakeholders to fully experience both applications, which was crucial to gaining their acceptance.

The demo was well organised, and the prepared tasks were spot on, as confirmed by the positive feedback from the participants. The comments we collected allowed us to make necessary corrections before the beta testing phase. Although several aspects could be improved, the event's overall success strengthened our belief that this approach to project presentations was effective and inspiring for the entire team.


large_blog-Inclusion Digital Saga part. 4_cover_high.jpg

medium_blog-Inclusion Digital Saga part. 4_cover_high.jpg

small_blog-Inclusion Digital Saga part. 4_cover_high.jpg

thumbnail_blog-Inclusion Digital Saga part. 4_cover_high.jpg

blog-Inclusion Digital Saga part. 4_cover_high.jpg

How did AI help me deliver the best client demo possible? - the Inklusion Digital Saga part 4

In today's technological world, where user expectations and design requirements are constantly changing, the role of a QA tester becomes crucial. I recently had the opportunity to participate in an exciting project with a German client, where I was responsible for manual testing and overall product quality assurance. This project was a demanding challenge but provided many valuable lessons I would like to share with you today.

#### The beginning of the adventure with the project

I joined the team as a QA tester when the SPLINT Feedback project was underway.

At this stage, the most crucial task was actually to get to know the project and plan further work:
- The first step was to get to see the documentation, application architecture and functional requirements;
- I had to take into account that the analysis of requirements, design and planning was still ongoing;
- the project was not yet stable enough to introduce automated tests;
- However, the already created BE and FE allow manual testing.

Organizing the work helped me better understand the project and plan an effective test strategy. My experience working on the SPLINT application, of which SPLINT Feedback is a sub-product, proved helpful.


#### Tests, tests, tests..!

Testing was an integral part of the application development process. We focused on the highest-priority tasks, which were accepted and sent to test environments. This allowed us to examine the functionalities closely, analyse their usability, and make the final changes by end users' expectations. How did it look in this case?
- The entire testing process was based on unit tests (performed by the development team) and manual tests for which I was responsible;
- The application consisted of two modules: SPLINT Feedback for Teachers (part of the web application) and SPLINTY—PWA for students. When planning the tests, I took into account not only the needs of both groups but also the need to broaden the scope to include tests on physical mobile devices.
- Our main goal was to enable students and teachers to jointly develop annual goals and cooperate on achieving them through self-assessment and feedback processes. To ensure that everything works as it should, we, the dev team, often assume the role of end users.
- During the testing stage, a solution did not fulfill its intended role, and we had to modify it. In such situations, the tests' conclusions allowed us to create a new, more adapted solution.
- From the application development perspective, pre-release and post-release testing were very important. The test environment, a copy of the production environment, significantly accelerated the smooth release of the latest changes and allowed me to work independently and engage the team.
- To ensure the app was “production ready” at the project's end, we ran acceptance tests with external testers. This allowed us to confirm our previous choices and catch any discrepancies.

Our approach, based on iterative testing and adaptability, was crucial to success.

#### Communication is key

Even the best tests are useless if there is no communication within the project team. Direct contact with developers, product owners (POs), and customers, as well as using tools such as Jira, allowed me to constantly update my priorities and adjust the testing process to the project's needs. Transparency and shared responsibility for the product's quality helped create a strong team and allowed for agile change implementation.

#### Summary 

The SPLINT Feedback project developed quickly and with great flexibility. Thanks to a small, closely related team and constant communication, we could focus on critical aspects of testing. Getting a good grip on the project at an early stage allowed for early detection and prevention of defects, which directly contributed to shortening the development time, reducing costs and improving product quality. Working in an agile environment allowed for quick modification of tasks and improving solutions that the tests indicated were worth refining. Communication was vital, and thanks to the shared responsibility for the quality of the product, our small group had the freedom to make decisions. We analysed the test results, identified errors and adapted the application to users' needs. Most importantly, the conclusions from this project will be valuable to us in future endeavours, and the knowledge and experience gained will have a lasting impact on our team.

large_blog-Inclusion Digital Saga part. 5_cover_high.jpg

medium_blog-Inclusion Digital Saga part. 5_cover_high.jpg

small_blog-Inclusion Digital Saga part. 5_cover_high.jpg

thumbnail_blog-Inclusion Digital Saga part. 5_cover_high.jpg

blog-Inclusion Digital Saga part. 5_cover_high.jpg

From the QA diary: experiences from developing applications for teachers and students - the Inklusion Digital Saga part 5

After several months of work and the involvement of the entire team, the time has come to plan and **execute the release**. For many, this may be an exciting moment, but from a technical perspective, it is often accompanied by **stress**. So how can the entire process be planned so that next time, when asked, 'How's the **release** going?' you can respond, '**Don't worry; it's real ease**.'


In ideal circumstances, deploying an application for the first time can be relatively stress-free. We start with a 'clean slate' - we don’t have to worry about users who might encounter a bug because there simply aren't any yet. Of course, such a release still needs to be planned, but the team has significantly more room to make mistakes or test something in the target environment.

In our scenario, the situation was more complicated. For a long time, we have been working together on an existing platform for teachers in Germany to facilitate collaboration among them to best support students' development. The application was growing very intensively, continuously delivering new solutions and responding efficiently to the needs of its users. It turned out that this was not the end. The application fulfilled its purpose and facilitated teachers' work but needed more student elements. The next step was creating a smaller platform for students to observe their progress, track their goals, and earn rewards. At this point, we decided to expand and split the development team slightly to get to work. Team A was to continue the daily work on the teacher platform, while Team B was to start implementing the new student platform.


Thus, as we entered the final phase and began planning the release, we found ourselves in a rather unusual and difficult situation. Here are our conclusions about the steps that need to be taken to maximise the chances of a successful release.

#### Organisational Planning Phase


##### **Release Date**
First and foremost, the planned release date must be established. Sometimes, this date is dictated by the client or managers, but usually, it will be a time frame rather than a specific day. As the project nears completion, the team should be able to pinpoint a particular day for the official release. At this point, adding at least one extra day to the planned date is advisable to provide a buffer for any potential complications.

In our case, setting this date was more complex because while Team B was finishing the implementation of the new platform, Team A was continuously working on new features and conducting their releases. Therefore, we had to gather both teams and jointly decide on a moment that would allow Team A to complete and test the current phase of their work while also allowing Team B to deploy their module without blocking either side.

##### **Responsible Persons**
If you have yet to assign individuals for specific tasks permanently, this is also a good time to designate responsible persons. Our situation required significantly more coordination and inter-team communication, so outlining specific tasks and assigning individuals to them was crucial for the process to run as smoothly as possible. However, creating a task list will be helpful even in less complicated scenarios.

Remember that projects often include less experienced members. An organisation like this will clarify them and offer valuable learning opportunities.


##### **Attention to Details**
It's worth remembering to write down even the most minor things that come to mind because as the planned release date approaches, more things will demand our attention, causing us to forget details that seemed evident during the planning stage. Keep in mind the detailed documentation related to the deployment process, such as:
- Creating or updating the README file,
- Updating user documentation: FAQs, release notes, instructions, and guides,
- Ensuring all licenses, cookies, and legal information are up to date

#### **Technical To-Do:**

Before initiating the deployment of your application, it's crucial to address several technical tasks to ensure a smooth and successful release. These steps help minimise the risk of disruptions and ensure your application functions as expected in the production environment. Here’s a comprehensive checklist of technical tasks to complete:












##### **Data Backup**

Data backup is a critical step in the deployment process, as it ensures that you have a reliable way to recover your application and its associated data in case something goes wrong. 

This is especially important when deploying an application that automatically performs database schema migrations at the time of deployment.

##### **Ensuring All Dependencies Are in Place**
Our application may be another piece of the puzzle in more complex systems that are dependent on other services. These may sometimes include a database, a queue system, or a data encryption service. We must ensure that all configuration variables are correctly set and that these systems can seamlessly integrate with our application.

##### **Create a Staging Environment**
It's crucial to thoroughly test the entire configuration in an environment that closely mirrors our production environment. This allows us to catch critical errors during internal testing stages.

##### **Deploy to Production Early**
When creating a new system, we can sometimes deploy our application to production ahead of the official release date. This was precisely the case for us. We deployed the new services a week earlier and tested their full functionality. Meanwhile, the integration parts in existing services were hidden using a feature flag. Nothing changed from the users' perspective, but this allowed us to begin testing in production by enabling the feature flag for specific users. Thus, the final release was simply disabling the feature flag for everyone.

##### **Conduct Alpha and Beta Testing**
Alpha tests are internal tests, while beta tests are conducted externally with a limited group of users. This approach not only helps us catch bugs but also allows us to gauge what our target users like or dislike. It also enables us to identify logical errors and verify our assumptions.

##### **Monitoring**
It is very important to maintain the health and performance of your application. Effective monitoring helps identify and address issues before they impact users or lead to significant downtime.
- Set up tools to monitor the performance of the application and servers.
- Establish alert thresholds to respond quickly to issues.

##### **Contingency Plan**
A contingency plan is a crucial component of your deployment strategy, designed to ensure that you can respond effectively to unexpected issues and minimise disruption if things don’t go as planned. 
- Prepare a plan to revert the deployment in case of critical issues.
- Team on Stand-by: Ensure key personnel are available and ready to act in case of an emergency.


In our case, this was an essential part. We needed the best contingency plan as our release affected real users. Any issues that might have happened during the release needed to be easily reverted or at least quickly hidden. 

#### Conclusion 

Successfully planning and executing a release requires careful consideration and thorough preparation. By addressing both organisational and technical aspects, you can significantly reduce the risk of complications and ensure a smoother transition to production.
 
 
In our case, the complexity of deploying a new student platform alongside ongoing work on an existing teacher platform highlighted the importance of detailed planning. Establishing a clear release date, designating responsible individuals, and paying attention to every detail were crucial steps. Moreover, implementing data backup procedures, effective monitoring, and a comprehensive contingency plan were key to managing potential issues and ensuring a successful release.

Ultimately, a well-executed release meets project goals and sets the stage for future success. By learning from each release and refining your processes, you can continue to improve and achieve greater ease in future deployments. With the proper preparation and mindset, you’ll be well-equipped to handle the challenges of any release and turn potential stress into a seamless experience.

Strategic Pivot: Transforming an HR Tool into a Modern Field Service Platform

Adrian

Boosting the efficiency of software development processes: a real-world example

Luiza

How Lefthook helps improve development teams’ workflows

Michał

How Vercel's upcoming changes will make it an even better tool for accelerating product development

Piotr

Decoding React UI: Unveiling the Best Component Libraries in a Head-to-Head Showdown!

Wioletta

Developer is sweaty, TypeScript spaghetti

Michał

Git Gut: Take care of your commits history like a pro

Michał

Exploring AI Tools for Developers: Insights from PozTechTalks part 2

Magdalena

The discovery and design phase as the main component of product success - the Inklusion Digital Saga part 1

Luiza

Product Owner Tools: What to start with and how we dealt with this topic - the Inklusion Digital Saga part 2

Luiza

Scrumban and a small team to ensure high-quality project delivery - the Inklusion Digital Saga part 3

Luiza

How did AI help me deliver the best client demo possible? - the Inklusion Digital Saga part 4

Luiza

From the QA diary: experiences from developing applications for teachers and students - the Inklusion Digital Saga part 5

Piotr

Release or Real ease - the Inklusion Digital Saga part 6

Daria

GET IN TOUCH