Bug-related feedback can be given in two ways.
The first before the production stage of an update or application. This stage is known as the validation phase, enabling both the agency AND business to check that all the specifications have been taken into account and that everything is working as expected. The second way often occurs when a website is already in production and bug feedback is given by users.
The test / validation phase, pre-production
Validation must be completed before a new function enters production. It is first carried out locally (on the developers' machines), then in the pre-production environment by the project and business manager. Once validated by the production teams and the business, the update can be placed in production and be visible by other users.
Bug feedback in post-production (by client or users)
It isn't unusual to see bugs be reported by clients or users and this is perfectly normal. Either due to bad specifications, or because of development errors. Indeed, a developer must take into account all use cases AND work on different equipment (desktop, tablets, mobiles), different browsers (Chrome, Firefox, Safari, etc) and different operating systems (IOS, Android, Microsoft, Linux), which increases the likelyhood of different effects, even though these are taken into account, there is always a risk.
Therefore, a bug that is reported after production is often in a use case that has not been expected or as a side effect of another development.
To correct this type of bug, you need to know where it comes from. We therefore enter the analysis stage. For each bug, a relatively quick analysis stage (1h <) is essential.
The results of this analysis may show that the bug is a real development bug or a side effect, the correction will be Purjus' responsibility
It may also show that it isn't a bug but a new request or in a use case that was not defined at the start, and in this case we must define new specs with the business and the bug will become a development of what already exists and not a correction. It will therefore be invoiced to the client.
A small detail and not the least, we may not reproduce the bug, however, we cannot correct something that we cannot see. This means that the bug is not caused by the development, it could be from the host, the client, the user, a firewall, connections, etc... In this case, we can advise you as much as possible to enable you to solve the bug.
The analysis stage can bring to light the causes of bugs:
- the application (the most common case)
- technologies that need updating
- Unidentified Use Cases in the specifications
- Instability of environments
- The material used or the operating system
Warning, a bug is not necessarily critical and doesn't necessarily have to be resolved instantly, we can classify them according to their urgency:
- Minor: Non-serious bug
- Major: Serious but non-blocking bug
- Critical: Bug that prevents the correct use of the application
After these stages, the bug is pending correction and the business/client only intervenes when it needs to be re-tested after correction.
The Correction stage
An app, a website can be released with minor known bugs,
The correction stage doesn't necessarily require development. If the bug us due to imprecise specifications, the correction is a modification of specifications = impacted on the client
The re-test stage
Once the bug is corrected, it moved on to the re-test stage. The role of the tested is to check that the reported bug is corrected and check that this correction has not had any side effects, we then use regression testing.
As a consultancy agency, we will be able to offer the creative solution that is most coherent and efficient and will define the digital and marketing strategy together.
Model and Prototype
To us, models are a quick way to illustrate an idea or function, conceptualise the user interface (UI) and work on the user experience (UX). We use collaborative prototyping such as InVision and Adobe XD to test and react in real time throughout the project. The high quality of our models makes them extremely close to the final product.
We are extremely careful with the performance of our products, so that web users can quickly access the pages on our websites. What we mean here is their reliability and speed. The technologies we use are chosen for their ability to reduce loading times. Their upgradeability, crucial for optimal use and security.
We have chosen Podio as it is a comprehensive collaborative tool, that can be customised. It enables us to adapt each "space" to our client's project, including them in its management. Therefore, we define the specifications and manage together the progress of the tickets.
In the Podio management tool, that we also use in-house, each client has a private workspace. This space enables interactions will all players in the project (agency and business).
It includes all the documents linked to projects, such as specifications, design models, links to pre-production and production spaces, etc.
Each request for a new function, development, correction, is materialised in a "ticket" that will be assigned to the developer concerned, followed by the project manager and in which the client can interact, comment, etc. These tickets enable us to set deadlines and follow them day by day, enabling the constant development and validation of the project.
Podio also has an instant messaging function that resembles "Facebook Messenger, and is an efficient alternative to e-mails as it enables:
- Seeing who is connected
- Seeing our entire contact list
- Quick discussions and agreements
- Reduced processing times
THE PROJECT MANAGER'S OPINION
Podio is my main tool. It enables me to have a complete view of the different projects I am managing without opening my e-mails, Teams, Slack, or any other. Everything is done on Podio.
The Web is a constantly and rapidly developing field. At Purjus, we are on the lookout for digital innovations and we are careful to develop our skills in fields such as artificial intelligence or augmented reality.
We regularly attend events such as the annual SymfonyLive to learn about the latest innovations in the PHP framework we are specialised in.
The efficiency of a project is not defined by its designers, but its users. That is why we fully test the efficiency of our products, during the graphic design stage and before production.
The implementation of a version management system is a priority to monitor a project and maintain an application.
We use the version manager Git that has become the industry standard. It is used by most open source software (including the Symfony framework itself as well as most of its environment) and is supported by most IDE (including PhpStorm).
The GitHub service is a good addition to the Git version management system. The different formula include a host with deposit backup, management of project contributors, a source code visualisation tool, a ticketing tool, a wiki and statistics. Moreover, GitHub is used by the Symfony community to make open source bundles available.
Our project managers, developers and integrators work together, they interact constantly in a workplace that encourages discussion thanks to tools that set the boundaries, simplify and sometimes automate the work processes. With these tools, we mean Podio our ticketing tool for the comprehensive management of a project, GitHub for reviewing codes before production and Slack for instant exchanges.
The project manager
The Project Maner in an agency hears the needs of the client during the briefing, drafts the specifications with the client, lists the technical specificities, validates the editorial line and especially the product production plan. They play a crucial role in coordinate the technical teams and business (client) teams throughout the project or projects.
This position requires the start to finish organisation of the project. Good knowledge of the stakes and organisational ability are two decisive elements for good project management.
What are their hard skills?
- They are the link between the business (client) team and the technical (development) team and increases the fluidity of the project.
- They carry the vision of the product, they are the primary contact of users (admins).
- They define the specifications of a ticket with the different players and drafts the technical specifications
- Constantly called upon, they must be very available to encourage a forward-moving dynamic in teams
- They prioritise tickets and oversee the speed of developer teams
- They tests the functions in the pre-production and production stage
- They calculate costs after discussion with developers, give quotes and issue invoices
What are their soft-skills?
- Good knowledge of the business sector
- Ability to see the bigger picture
- Ability to technically define a product
- Good ability to listen and communicate
- Ability to make decisions and take responsibility for them
The agile method
A Purjus Communications, we believe in Agility (inspired by the Scrum framework) This method is in our opinion the most adapted to digital projects, focusing on customer satisfaction and the quality of the final product.
Several principals must be complied with to implement this process:
- Favour interactions and collaboration, in Agile project management each stakeholder must be involved and motivated. With short-term term targets, we speak several times a week to manage the project properly and stick to deadlines.
- Determine several versions of the website to plan frequent deliveries (monthly delivery, "print" principal). This enables functions to me processes one after another, test them and validate them in very little time and move on to the next.
- Adapting to change Short and regular deliveries enable fast production as well as adjustments, refining the initial needs without starting the project over.
Call for tender
What can you find in our answers to tenders ?
All our projects are based on the same structure, but adapt to each case.
First, you will find a presentation of the agency and the team's organisation.
Then we present our working methods. Indeed, we manage our projects using an "Agile" method, via a collaborative ticketing tool (Podio for those in the business). This method is different to project management in a company, which is why we wish to explain it beforehand.
Then, once we have understood the need explained in the specifications, we draft our proposed strategy, architecture and technologies, and present our dedicated project team.
Finally, we can share a first estimated deadline (shortest and longest) for development in days/person and an estimated price.
Depending on the tender and the project, we sometimes suggest pre-projects.
Do you have a project and want to speak to us? You can call us on +44 (0)4 42 26 83 42 or send us an e-mail firstname.lastname@example.org or contact us through our Chat Bot.
Purjus as a company subscribes to an Agile philosophy to meet project requests in the long term. Thus, we guarantee the upgradeability required by the digital world nowadays.
This Agile methodology means we have to work and interact in a short cycle and frequently with clients.
The aim is to reach:
- High reactivity
- Provide clients with constant visibility
- Bring the project owner and project management closer together
- Increase the skill of business teams
- Enable clients to constantly adapt their demands
Last but not least, avoid budget, function and deadline issues.
We therefore aim to understand the concepts of your business and offer clear solutions by using a common language and strong involvement from both parties.
On reading the specifications and ambitions of our client, we sometimes offer a pre-project phase in 3 stages:
- Launch: We offer to organise a quick project framework meeting to better understand needs.
- Sprint Design UX: with the business, creation of some of the graphic models and customer pathway to be as close as possible to the final result.
- Technical advice and recommendation: simultaneously with the UX, always iteratively, we offer technical choices/solutions to better meet your needs and satisfy your requirements.
3/4 of the way through the pre-project stage, we identify the budget requirements by lots (macros) to have a rough idea of each function. You can then manage, prioritise and organise your budget.
- Structural diagram
- Choice of technologies (front-end/back-end solutions, technical ecosystem)
- Budget as we go along
- What you should avoid
We decide together of the functional scope to comply with the target budget. The final aim is to come up with a detailed plan of the new platform, a graphic model as well as the precise budget.
It will enable you to know the exact result and the price.
Afterwards, if you are satisfied, we can give you a precise quote for the development of the platform.
Why use ticketing for wed development projects?
A ticketing tool is a project management support tool. It enables all discussions, all documents, all specifications and all stakeholders in a project to be centralised in one place. It greatly facilitates project management and avoids long e-mail exchanges in which information can be lost.
Ticketing also enables the needs and work to be completely to be clearly defined, and not go beyond the framework of a description in a ticket during production.
It also defines the exchanges and responsibilities of all players, keeping a trace of changes, discussions, agreements between parties, it is the project's "memory". Tickets also enable quotes to be regularly edited through sprint, therefore per month, then edit invoices according to the real time taken by developers to correct or develop a function.
Sprint Design is a process based on a time imperative devolved from the Agile method. This process is favoured by start-ups and major groups have started to use it to manage their projects in-house. It usually lasts five days, during the five stages of "design thinking" are implemented. the aim is to reduce risk during commercialisation of new services or innovative products.
The stages in a Sprint:
- Expression of a need: it is the most important stage in the sprint. It is a discussion time between our client and us to clearly and objectively define the requirements of the client for the functions to be developed and process them in order of priority.
- Planning the Sprint: we define and prioritise the product backlog with the client (the basis for developments to be completed to finish the project) that can be carried out in the next sprint.
- Sprint Review between the client and Purjus: Presentation of the functions developed.
- Validation and production
The aim of Sprint Design is to set the boundaries of the project with the business teams in little time and to be as profitable as possible thanks to comprehensive ideas.
Have this article been useful?