Services
Blog
Français
People always ask me what we do, but after 20 years of taking up IT challenges, I feel like asking what we DON'T do, as our network of skills has diversified over time!
This page is aimed mainly at project leaders who wish to learn more about Agile development methods and benefit from our cross-disciplinary skills to build internet applications on an à la carte package basis rather than on a person-day basis for specific profiles.
You can construct your offer from our various packages which, together, offer you a complete accompaniment from a concept to the development of a “Minimum Viable Product”, from €20,000 ex. VAT.
The minimum viable product (MVP) is the version of a product that allows you to obtain maximum customer returns with minimum effort: it is the first version of your new product.
The importance of the minimum viable product is to evaluate the viability of a new business model: it allows you to start serving your first customers.
This is a curious thing in our industry: not only do we not learn from our mistakes, but we also do not learn from our successes.
The first stage of project management is communicating and identifying the project requirements. It starts with the documentation of requirements in Agile format.
Concretely, it is a technical-commercial profile whose responsibility is the quality of your development and ensuring that it meets your expectations.
The next stage of the process requires the team of engineers to collaborate openly and estimate each User Story in Story Points, which together compose the Epics: this can easily take up a whole day because an estimate is registered only if it has the unanimous agreement of the developers!
This documentation will help you to start an “Agile Development Sprint” with YourLabs Business Service and to ask for quotes from other developers.
There are two ways to build a software architecture: one is to make it so simple that there are no obvious flaws, the other is to make it so complicated that there are no obvious flaws.
A “User Story” is a statement defining a feature used by a user, e.g.: “The User can authenticate themselves on the platform”.
An “Epic” is a set of User Stories that go together, for example, the Epic “Authentication” involves the following User Stories:
The requirements documentation in Agile format consists of Epics and User Stories.
A single “Story Point” is assigned to the simplest task and other User Stories get a proportional number of Story Points in terms of complexity.
Several User Stories may be cumulated to make a Story Point if they are too simple. In the “Authentication” Epic example above, the User Stories are each valued at 1 Story Point because this is a classic approach for the developer as authentication is a subject that has been seen and reviewed and there is really nothing new to be invented here, as a general rule.
The platforms we develop benefit from a free basic design according to the standards of Material Design, a user interface standard developed and maintained by Google.
Your interface will therefore be as pleasant to use as a Google product at no extra cost; however, we also offer the design of alternative mock-ups.
Simplicity is the ultimate sophistication.
At this stage, you have at your disposal an updated specification document in Agile format with estimates for each of your user stories thanks to the project management, and optionally, mock-ups.
You can now start a “sprint” of IT development that will result in your Minimum Viable Product or a new major version of it.
Inform the prime contractor of your priorities, the developers can commit to which user stories will be completed during the sprint, and your development can finally begin!
The biggest challenge for the IT engineer is to not be confused by the complexity of his own creation.
The “Sprint” closes with a review, i.e. an interview for the team to present the result of the development to you, the product owner.
This is the time to say everything that really matters to you! Because we will make any changes you require in the days following the review.
Don’t worry if you miss something because you still have 2 months warranty after the review to report bugs that you or your users discover in your project.
Would you like more technical details about our method?
Woul you like to learn the jargon of the professionals?
Then let’s go!
A “Deployment” is the act of putting code at the service of users and may also require the updating of data or database structures, known as “migrations”.
“Continuous Delivery” is a practice that consists of automating deployments. A developer has delivered code to you? If you’re satisfied with the changes, all you have to do is click a button to deploy it on your main “production” site.
A program that produces incorrect results twice as fast is infinitely slower.
When a bug that has been fixed reappears, it is called a “regression”. How do we prevent this? Just fixing the bug now won’t prevent it from coming back in the future!
We start by coding a second mini-program (a “test”) that “reproduces” the bug: that is to say, it simulates the conditions that cause the bug to appear.
Now we can execute this second program and check that the bug occurs: this means that it correctly reproduces the bug! At this point, we can start to develop a “patch” to fix the original program.
Result: we end up with a patch for your program plus a program that allows us to verify that the bug is still squashed, in the blink of an eye.
When we generalize this practice to all our code, it is called “Test-Driven Development” and it is a practice popularized by “eXtreme Programming”.
All of our production code comes with its test code equivalent, which allows us to determine whether or not we have broken anything every time we modify the project’s code!
“Continuous Integration” is the practice of automating the execution of the test software every time a developer wants to modify the project code.
If a modification breaks a test then the developer is blocked and cannot send the modifications to production: it’s a lifeline, a safety net that you hang on to to avoid capsizing when you want to update your code.
Code never lies, but comments sometimes do.
Docker or better, with a new CRUDLFA+ project on Django (which we have been using since 2008) and a PostgreSQL database behind a Traefik https load balancer.
Thanks to uWSGI, the project already has a cron, a spooler and a native memory cache at its disposal to enable it to orchestrate triggered calculations to satisy the requirements of the most creative project owners.
Debugging is twice as difficult as writing code, so if you write code as cleverly as you can, you are, by definition, not clever enough to debug it.
A “BarCamp” is a meeting, an open non-conference, that takes the form of participatory workshop events where the content is provided by the participants.
That is to say, we meet in an informal context and exchange our passions in computing. We cultivate knowledge that multiplies when we share it in a friendly and playful atmosphere.
